Diagnosing underperformance

It took me six to twelve months, the first time, to see that the engineer I was coaching did not need more coaching. He agreed in every 1:1, acknowledged every piece of feedback, sometimes even brought ideas, and the PRs kept coming back with the same comments while releases slipped and reviewers burnt time iterating on the same issues. I kept reading what he said in our 1:1s and missing what he never did outside them. I should have been reading the rest of the team instead, because they were watching me tolerate a problem I had misdiagnosed, and quietly losing trust in my judgement.

Flagging underperformance is a separate problem, and if your ladder and quarterly reviews are not yet doing that job, start with levels and progression. The rest of this essay is the diagnosis you run once someone has been flagged.

The standard coaching frame is a 2x2 you have seen in most management books: skill on one axis, will on the other, four quadrants with four labels (enthusiastic beginner, disillusioned learner, reluctant expert, disengaged) and four actions attached. It is popular because it lands a clean diagnosis in a single conversation, and it is wrong about two things at once: it labels the person instead of the situation, and it hides the failure mode that fooled me for a year.

The diagnosis I run keeps two axes, but they are skill and intent, and one check runs before either of them.

Most lists you will find add fit (does this role match this person) and context (does the environment let them succeed) as a third and fourth axis. In a 200-engineer org with role mobility, that can be honest. In a Series B startup with 40 engineers and three product areas, fit and context collapse to one of two answers: either the role is what it is and the fit is not there, in which case you part ways, or the context is broken, in which case you own the fix instead of diagnosing a person for it. The four-way split sounds rigorous, and in practice it works as a stall, because every extra axis buys the manager another quarter of diagnosing instead of deciding. The working version is two axes plus a room test.

Test the room first

Treat pay, project mix, and people as fixed for a moment, and look at the whole team before you look at the individual.

If intent looks low across most of the team, the cause is yours. Look at:

• the work mix
• the last pay cycle
• the narrative you have been telling them
• your own manager

In December 2023 my team came out of a layoff into a year with no hike, and intent across the whole room looked rough. None of those people were the problem, because the problem was the story I was telling them. That arc belongs to re-narrating change when direction shifts. The part this essay needs is the room test itself: a team-wide intent dip means you look at yourself before you look at any individual.

If intent looks low in one person while the rest of the team is performing, the team is your control group. Their good performance is the evidence that pay, project, and people are not the problem, and the signal is the person. Only now do you start diagnosing the individual.

Find the cell

The individual diagnosis has four cells, and all four can look the same in a Tuesday status meeting while calling for different actions.

Skill gap, fixable. The engineer wants to close the gap, the gap is bounded, and the ramp is realistic. Go to the repair loop. In the early years of someone's career, most of your diagnostic load should land here.

Skill gap, unfixable. The gap is too large or the ramp is too long for the team to absorb, and you part ways. It is rare, because most "unfixable" calls turn out to be skill-fixable cases the manager gave up on too early, or intent cases hiding behind a skill label.

Intent gap, loud. The engineer dodges the harder ticket, debates every piece of feedback, and games the standup, which makes this the easy diagnosis and the easy action. Once the obvious motivators (pay, people, project) have been ruled out, it is rarely fixable.

Intent gap, silent. This is the one that took me a year. The engineer engages, agrees, acknowledges, sometimes brings ideas, and gives you nothing on the surface to push back on. The ambition to push past the current level is the piece that never shows up, and an absence is much harder to see in a status meeting than a behavior. They have made peace with their ceiling and would honestly like to keep doing their job, which is not the same thing as being unmotivated by the work. The case shows up most often in seniors who arrive with a bar set by a previous company: if the work was good enough there, they expect it to be good enough here, and for many months the whole thing reads as a slow skill build.

What finally flipped the diagnosis on my engineer was not a piece of code or a missed release. It was a question I asked myself between two 1:1s: when was the last time he came to me about this without waiting for the calendar? The answer was never.

Run the kernel test

The kernel test asks whether the engineer drives the improvement process or only reacts to it. An engineer who drives sets the next move on their own, and an engineer who reacts waits for you to set it. Three probes:

• Do they bring their own solutions, or do they ask which solution you would like?
• Do they come asking for feedback between 1:1s, or do they wait?
• Do they propose the checklist, or do they build the checklist you suggested and never touch it again?

Agreement and acknowledgement without self-driven motion is the ceiling tell.

The same kernel test catches a different case that looks identical from the outside. I have had engineers with the same surface symptoms whose root was confidence rather than ceiling, often after years of harsh feedback from a previous manager. They want to drive the process and second-guess every motion of it. The kernel test still answers cleanly (yes, they drive), and the action is different: that arc belongs to the repair loop rather than here.

Hand off the diagnosis

Once you have the diagnosis, the action is one question: is their current level good enough for the team's required bar?

The handoffs:

• Confirmed ceiling case. The answer is almost always no, and you hand off to parting well.
• Skill-fixable or confidence cases. Hand off to the repair loop.
• Team-level intent dip. Hand off to the work you owe the room.

The engineer being parted is not the main audience for whatever you decide. The rest of the team named the problem in their own heads before you said it out loud, and they are watching to see whether you can say it too, and whether the bar moves up or down once you do. A misdiagnosis is cheap for the person you keep too long, who gets more time, and expensive for the strong engineers around them, who pay for it first in review cycles and then in how much they trust your judgement.

The cycle time on this diagnosis was six to twelve months the first time, and it is closer to weeks now, not because the test got sharper but because I stopped waiting for a change in results and learnt to read the absence of self-driven motion directly. What used to take three quarterly reviews and a stack of PR comments now reads off one or two 1:1s and the pattern of who initiates.