<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://craighagerman.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://craighagerman.github.io/" rel="alternate" type="text/html" /><updated>2026-09-15T01:01:26+00:00</updated><id>https://craighagerman.github.io/feed.xml</id><title type="html">Craig Hagerman</title><subtitle>Craig Hagerman&apos;s digital garden</subtitle><author><name>Craig Hagerman</name></author><entry><title type="html">Holding the Performance Bar: Effort Gaps, Capability Gaps, and Knowing the Difference</title><link href="https://craighagerman.github.io/posts/holding-the-performance-bar/" rel="alternate" type="text/html" title="Holding the Performance Bar: Effort Gaps, Capability Gaps, and Knowing the Difference" /><published>2026-09-06T00:00:00+00:00</published><updated>2026-09-06T00:00:00+00:00</updated><id>https://craighagerman.github.io/posts/holding-the-performance-bar</id><content type="html" xml:base="https://craighagerman.github.io/posts/holding-the-performance-bar/"><![CDATA[<blockquote>
  <p>Failing a student is the closest thing a teacher has to firing someone. A student who failed my course and came back twice, and a senior hire who did not work out, and what each taught me about holding a performance bar without wrecking the person on the other side of it.</p>
</blockquote>

<p><strong>TL;DR</strong></p>

<ul>
  <li>Tell people where they stand while they can still do something about it. Honesty is the kindest version of the conversation, not the harshest.</li>
  <li>A performance bar you have documented, repeated, and practiced is a bar you can hold. Personally own that bar.</li>
  <li>Offer grace, but make people ask for it. “Come talk to me if you are stuck” has to be said out loud, and it only works if the person uses it.</li>
  <li>Distinguish a coaching problem from a performance problem. Coaching that produces no change across 2-3 checkpoints is a signal.</li>
  <li>Before I decide, I give them a fair test of the thing I actually need, that is aligned with their own claimed strengths.</li>
  <li>Then act. Identify issues → act decisively. Once the evidence is in, a slow decision doesn’t help anyone.</li>
  <li>Hold the line and treat the person well, with empathy. Those are not in tension.</li>
</ul>

<hr />

<h2 id="teacher-to-em">Teacher to EM</h2>

<p>I spent 15+ years as a teacher &amp; university professor. I learned a lot about how to keep the performance bar. As an engineering manager I sometimes have to deal with someone who doesn’t meet the performance bar, and might even have to let them go. As a teacher I couldn’t “fire” a student but there is an analogue - failing the class. Firing and failing are both unfortunate outcomes none of us want, but still happen.</p>

<h2 id="tell-people-where-they-stand-while-they-can-still-act">Tell People Where They Stand While They Can Still Act</h2>

<p>I taught a course in “Introduction to Civil Liberties” to undergrad students for years. I remember one student clearly who failed to meet the bar. As I’ve written elsewhere I take seriously my responsibility to clarify tasks/assignments and have  regular reminders. This student missed some classes, and had weak deliverables early on. Basically she was putting in a half-assed effort. Students can always drop a course without penalty during the first few weeks if they want. For that reason, I like to let students know where they stand as early as possible so that they can drop if they want. I pulled this one aside to ask if she was struggling or had some conflicts … i.e. hinting it’d be OK to drop the class. She said no, she was fine and in fact enjoyed my class. I said something like, “Well this early assignment won’t count for much overall but it isn’t a great sign. You’ll have to put in a bit more effort.” She continued, but failed to give me a mid-term essay and ended up dropping the course.</p>

<h2 id="holding-the-line-when-you-have-already-given-every-warning">Holding the Line When You Have Already Given Every Warning</h2>

<p>She was back again in my class the next year. It was an elective but she said she had enjoyed the course, but hadn’t focused much in her first year. She did much better, handing in assignments on time, collaborating on presentations etc. But there was a final essay requirement worth a lot of the overall grade. And that had a precondition of giving me an outline and getting approval for the topic. For most students that was a trivial bar to meet. This was in the syllabus. This is something I mentioned many, many times throughout the term. This is something we <em>practiced</em> in class. I even emailed a few students and/or talked to them after class to remind them about the outline, including this one. The due date was <em>weeks</em> before the last day of class (when the essay was due). But this student never did the outline. She did everything else. I reminded her <em>in person</em>. I reminded her <em>by email</em>. I directly told her that I wouldn’t accept an essay without the outline before hand (as written in the syllabus) and that she was in danger of failing. You can probably guess what happened. She didn’t give me the outline or get approval. She also missed the final class but did send me her essay by email a couple days later. I gave her a zero (as specified in the syllabus) and she failed the course.</p>

<h2 id="when-the-bar-gets-challenged">When the Bar Gets Challenged</h2>

<p>She complained to the school admin and I met with her and them, went through the syllabus and dates. I also told her I’m sorry that you failed the course after the effort you put in, but I have been reminding you of requirements. And I also reminded her that I have explicitly said if someone has a conflict or too much on your plate <em>come talk to me</em> and I can probably give you some grace. But she didn’t do that, and I have to hold the performance bar that I had defined.</p>

<h2 id="a-third-try">A Third Try</h2>

<p>I figured she would have hated me after that. So I was shocked when she was back in my class in her 3rd year! I pulled her aside for a talk. This is an elective for you, do you really want to do this? I also mentioned that I had re-jiggered the whole course over the previous summer. I had dropped some modules, expanded others. So it might not even be like re-doing something you already know. She said she was sure she wanted to take it.</p>

<h2 id="holding-a-line-without-burning-the-person">Holding a Line Without Burning the Person.</h2>

<p>There were some minor slacking with her (like missing a class), but nothing out of the ordinary. And she did a great job on all the major assignments and passed with an ‘A’. I have no idea what was going on with her the previous years but I like to think she was like me in my first year of university. I slacked off, got behind on assignments and way over my head. And when I asked for help got told off and ridiculed by profs. (My CS prof told me I should go pump gas or something and stop wasting my parents money!) I never went back to those profs’ classes. But at least with this student I held a line but also treated her with empathy. I like to think that’s why she came back for a third crack.</p>

<h2 id="a-strong-resume-and-a-slow-start">A Strong Resume and a Slow Start</h2>

<p>I’ve had to deal with a few performance failures in my EM career. One is a person I almost forgot about. I’ll call him Steve. He was interviewed and hired just before me. I had a 1:1 with him within my first couple days and was impressed. He had an impressive educational background in machine learning and AI. (PhD if I remember correctly.) And he seemed to have some solid work experience. But I already noticed a few issues during out next check-in. He seemed very slow and the quality of his coding rather low. This is during his onboarding phase so I assumed that he was getting used to the codebase. I gave him some coaching in clean code practices and advice on how to get up to speed quickly. But by our next checkpoint I didn’t see any improvement in his code or delivery rate. I had also learned that he was spending a time with other team members giving advice on their work and also working on architectural designs. Neither things that were in his purview. It seemed like this might not be a “coaching” issue but actually a performance issue.</p>

<h2 id="coaching-problem-or-performance-problem">Coaching Problem or Performance Problem?</h2>

<p>I had a straightforward chat with him. Why are you doing these things? And why are you working through some simple coding tasks so slowly. It turns out in his previous job he had been “more of an architect” and didn’t do any hands-on coding. He would develop algorithms, and architecture designs … but never do any actual production implementation. He admitted he was “rusty” and had tried to fall back on his “strengths” to carve out a comfortable position for himself.</p>

<h2 id="give-them-a-fair-shot-at-proving-you-wrong">Give Them a Fair Shot at Proving You Wrong</h2>

<p>I told him I thought there had been some sort of misunderstanding. But we didn’t have a need for a (non-coding) architect. We needed a hands-on senior or lead who could take on large ambiguous implementation tasks. I told him I had concerns about his ability to meet those performance demands. I would need to see some evidence of those skills. I assigned a range of tickets to him - some of which should be quick and easy, some requiring more autonomy and ambiguity tolerance. He said he was an “architect” - at least he should be able to architect a solution to the latter.</p>

<p>He failed to meet the bar on either kind of ticket. The low-hanging fruit tickets weren’t quick, didn’t meet Clean Code standards and lacked adequate testing. The more ambitious tickets did have nice architectural designs and discussions attached but the implementation was problematic.</p>

<h2 id="making-the-call">Making the Call</h2>

<p>I had to make the decision to let Steve go. It was not a good fit. I believe he lacked  professional experience of engineering solutions (in Python) and didn’t have the foundations to allow him to get up to speed.</p>

<h2 id="why-one-came-back-and-one-did-not">Why One Came Back and One Did Not</h2>

<p>Two stories. Opposite outcomes. But the same instinct behind both. I did fail (fire) the student (twice) but she came back a third time. Fired employees don’t have that option to do a re-try. What’s really different here?</p>

<p>The student didn’t have a talent gap. She had the ability but wasn’t applying it. i.e. she didn’t have the will. Steve had the will but not the ability. Effort gaps (student) respond to reminders, clarifying requirements and second chances. That is what the performance bar is for. But capability gaps don’t move on the same kind of timescale. A reminder or clarification isn’t going to help bridge a capability chasm.</p>

<p>The thing is you can’t always tell what type of issue you have in front of you. Is it a capability gap or an effort gap? Even then, will the person respond to coaching or demonstrate no movement. You don’t know what kind of gap until you test for it.</p>

<p>The two stories had the different outcomes, but the same conduct. In both cases I told the people plainly (and early) where they stood, and tried to do so with respect and empathy.</p>]]></content><author><name>Craig Hagerman</name></author><category term="teacher" /><category term="EM" /><category term="performance-bar" /><summary type="html"><![CDATA[Failing a student is the closest thing a teacher has to firing someone. A student who failed my course and came back twice, and a senior hire who did not work out, and what each taught me about holding a performance bar without wrecking the person on the other side of it.]]></summary></entry><entry><title type="html">Setting the Performance Bar: What Nobody Tells You About Missed Expectations</title><link href="https://craighagerman.github.io/posts/setting-the-performance-bar/" rel="alternate" type="text/html" title="Setting the Performance Bar: What Nobody Tells You About Missed Expectations" /><published>2026-08-27T00:00:00+00:00</published><updated>2026-08-27T00:00:00+00:00</updated><id>https://craighagerman.github.io/posts/setting-the-performance-bar</id><content type="html" xml:base="https://craighagerman.github.io/posts/setting-the-performance-bar/"><![CDATA[<blockquote>
  <p>Fifteen years of teaching taught me that most missed expectations are a failure to set them. What my classroom experience taught me about defining and holding a performance bar as an engineering manager.</p>
</blockquote>

<p><strong>TL;DR</strong></p>

<ul>
  <li>If someone misses a bar I never described, that is a management failure (mine!), not a performance failure. Run the retro on yourself first.</li>
  <li>Separate the instructions from the task. People should be evaluated on the work, not on their ability to decode what was wanted.</li>
  <li>Describing “good” is not enough. Show it. Give exemplars. A weak version next to a strong version teaches more than a rubric does.</li>
  <li>Name it immediately. Letting it slide (deadlines!) or delaying feedback lets the low bar become the standard.</li>
  <li>Fix the system, not just the instance. Set people up to succeed rather than catching them after they fail.</li>
  <li>Build the standards with the team, not <strong>at</strong> them. Shared agreement on what “good” looks like is what makes a bar hold, not my oversight.</li>
  <li>Standards and goals are different things. Skipping tests is a performance issue. A model that misses its number is not.</li>
  <li>Empathy is not a reason to avoid the hard conversation. It is how you deliver straight talk as someone who wants them to succeed.</li>
</ul>

<hr />

<h2 id="teacher-to-em">Teacher to EM</h2>

<p>I spent 15+ years as a teacher &amp; university professor.  I have roughly 10,000 hours of teaching experience. I learned a lot about how to manage performance from this, trying new things or tweaking my approach with every class and every term. I think a lot of this is relevant to managing performance as an EM.</p>

<h2 id="if-the-instructions-werent-clear-you-are-the-problem">If the Instructions Weren’t Clear, You Are the Problem</h2>

<p>I once proctored a final English test at a high school in Osaka. I don’t remember details but it was some kind of listening test. My duty was to take attendance, hand out test papers and then start a recording for an initial listening test. This was a timed test and I was no permitted to stop or restart the recording.</p>

<p>After starting the recording I stood to the side of the room to observe. I immediately noticed an issue. The instructions for what to do for this listening test were not written on the test sheet - they were delivered orally … in English on the recording. What I noticed was that one girl had misunderstood the instructions and was on the wrong track.</p>

<p>Afterwords I talked to her teacher (Dan) and told him what happened. I thought it was unfair and suggested perhaps he could take that misunderstanding into consideration when grading her test. He said he didn’t think that was necessary. “It’s ALL part of the test” was his opinion, including instructions.</p>

<p>I disagreed… but it wasn’t my place to say or do more so I left it at that. But the experience has stuck with me.</p>

<p>I had learned (during teacher training) that separating instructions from the actual assessment is a fundamental part of the test pedagogy. If it were me I would have realized that I was responsible for not delivering clear instructions and … I don’t know what. Probably have some human understanding and take that misunderstanding into consiration when grading her. I would definitely take that as a learning experience and change the approach next time (i.e. provide written instructions, probably written in Japanese, rather than English.) Holding a quality standard doesn’t mean you have to be a hardass.</p>

<p>One reason this incident hit home is that I, myself, have a form of aphasia that causes delayed processing. I’ve been in this exact situation a few times where oral instructions are given that I didn’t completely get.</p>

<h2 id="a-bar-i-never-actually-set">A Bar I Never Actually Set</h2>

<p>I’ve also been on the other side as a teacher more than once. I have been the teacher who gave an assignment that was not completed well and, on reflection, I realized I could have been more clear and proactive about clarifying expectations and deliverables. In one case, I was teaching a 1st year (university) class. The assignment was that all students had to give a short presentation (in pairs) about one topic from the syllabus. The first pair got up and … did a truly terrible job. But the thing is they had obviously done research and prepared materials and had collaborated well. And they were actually enjoying themselves. (Gregarious, natural performers.) But the thing was, there was not there … there. It was light on substance. More like just a list of facts and descriptions of photos they prepared. It most definitely didn’t meet the bar. While they were talking I was doing a retro in my head trying to determine how this had come to pass. I decided by the time they were done talking that I bore some responsibility. I could have given examples of good vs bad, the type of insights I was looking for and what “good” looks like.</p>

<p>After they finished I thanked them and told everyone to give me ~5 minutes to write my reflection. That gave me some breathing room to think. I came to a decision. I think it is always better to address issues as soon as possible and be as straight as possible. But on the other than doing so would mean calling them out in front of their peers - something I’d normally consider a red line. But I did just that. My rationale was that (1) I needed to correct the problem NOW before other student’s took this as the standard, (2) I needed to clarify expectations and give better instructions and and (3) these girls were a bit more extroverted and I thought I could manage the correction without psychological damage.</p>

<h2 id="showing-them-what-good-looks-like">Showing Them What “Good” Looks Like</h2>

<p>I looked through my materials and found a topic that hadn’t been chosen for a presentation. Great - I’ll use that as an example. I went to the front of the room and said I’d like to give some feedback as well as advice for the rest of the class. I framed it as a “compliment sandwich” (putting the critique between ‘slices’ of compliments.)</p>

<p>“You both have very clear speaking voices…. You made great eye contact and connection with the audience… You used speaking notes and  didn’t just read straight off a page…” etc etc.  “But … there are some issues with the presentation. This isn’t what I was looking for… “</p>

<p>Their faces fell. I told them I feel I didn’t prepare them well enough so I’d like them to deliver a “part 2” in one of the following classes. I started talking to the class about what kind of content I was looking for, the level of analysis, the surfacing of nuance. I wrote notes on the board as I went. Students started to take their own notes. I told them I’ll give a brief example off-the-cuff on another topic. I pretended to be giving two different presentations. “Here’s the weaker version….” and delivered a surface level speech. “And here’s a stronger version…” and talked about the same content but at a deeper level of analysis, and connected themes together. The two girls started nodding. “Ah naruhodo” they said. They said they got it now. I asked them to recap for everyone else. They stood up and did so and gave great examples of how they could have done a better job. I closed the compliment sandwich by praising their quick understanding. And I told everyone my point here was not to embarrass them but to set everyone up for success. They did the “part 2” version a couple weeks later. To be honest it wasn’t the best, but it did meet the performance bar now that it had been clarified.</p>

<h2 id="fixing-the-assignment-not-just-the-presentation">Fixing the Assignment, Not Just the Presentation</h2>

<p>In subsequent terms/years I’ve iterated on this assignment. I give students my rubric, explain shallow vs deeper content, give examples of those and ask students to meet with me before their presentation date and have them show me an outline and their general direction. In those subsequent classes most students did a great job. (Because I intentionally set them up for success.) Live and learn. First fix the instance. Then go back and fix the system that produced it.</p>

<h2 id="the-same-problems-with-engineers">The Same Problems, With Engineers</h2>

<p>I have found A. LOT.  of my teaching experience and development has provided a good foundation for being an engineering manager.</p>

<p>I have experienced and learned first hand the need for clarifying expectations, being clear about the performance bar, being transparent about performance evaluation … and continuously reflecting and iterating to hone my overall approach and customize it to the situation I am leading.</p>

<h2 id="when-nobody-sets-the-standard-everyone-sets-their-own">When Nobody Sets the Standard, Everyone Sets Their Own</h2>

<p>A couple times in my career as an EM I’ve found the whole team isn’t really meeting the performance bar due to no one having set standard practices. In those cases that lead to people merging directly to main, or self-approving PRs or approving PRs as a rubber stamp, all of which is a recipe for NOT holding any bar. In these cases created protocols and did code review for every PR for a while. I added documents on clean code/architecture, GitOps flow, testing requirements and a Definition of Done to the repo and went over everything as a group. I invited the team to contribute or suggest changes to these → the larger point is about establishing a shared practice of engineering and shared agreement of what “good” looks like.</p>

<h2 id="performance-standards-are-not-project-goals">Performance Standards Are Not Project Goals</h2>

<p>With all teams I’ve been clear that performance standards are separate from project goals. You need to follow the standards and meet the performance bar. That is non-negotiable. But if you do that and we do not meet our goals, that is separate. If a model doesn’t hit a certain number that doesn’t reflect poorly on your performance. If evals have regressed and we have to push back a release, that doesn’t reflect poorly on your performance. But if, for example,  you don’t write and run tests but do finish a task quickly that DOES reflect poorly on your performance.</p>

<h2 id="empathy-is-not-avoidance">Empathy Is Not Avoidance</h2>

<p>With the pair that did a poor presentation I named the problem right away. I try to that that with my team. If someone is below the bar name it. I am empathetic, but that doesn’t mean I avoid tough conversations. Rather I use my empathy to deliver straight talk from someone who wants to see them succeed.</p>]]></content><author><name>Craig Hagerman</name></author><category term="teacher" /><category term="EM" /><category term="performance-bar" /><summary type="html"><![CDATA[Fifteen years of teaching taught me that most missed expectations are a failure to set them. What my classroom experience taught me about defining and holding a performance bar as an engineering manager.]]></summary></entry></feed>