Low performance is a diagnosis, not a verdict
Most engineers I have managed through a performance problem were not bad engineers. They were in the wrong setup. How I tell the difference, what a real improvement plan looks like, and when to stop.
The phrase "low performer" does a lot of damage before anyone has looked at the situation. It turns a person into a category, and once a manager has filed someone under that category, the rest of the process tends to become an exercise in confirming it.
I have managed enough of these situations to know that the label is right less than half the time. The other half, the person was capable and the setup was broken, and the setup was usually something I had built.
Start by asking whether it is the person or the setup
When delivery slips for more than a few weeks, before I say a word to the engineer, I write down what I think is happening. Then I go looking for the four causes that account for most of the cases I have seen.
Unclear expectations. The engineer thinks the job is one thing and I think it is another. This is the most common cause and the most embarrassing, because it means I never wrote down what good looks like. An engineer who has been quietly polishing a service for a month while I expected them to ship a feature is not underperforming. They are doing a different job than the one in my head.
Wrong assignment. I once moved an engineer onto the oldest, least documented part of our system because he was the calmest person on the team and I figured he could handle it. He spent two quarters slowly drowning. When I moved him to a greenfield service, he shipped more in six weeks than in the previous six months. Nothing about him changed.
Something outside work. A sick parent, a divorce, a new baby who does not sleep. People rarely volunteer this, and it is not my business to dig, but it is my business to notice a change and ask whether they are okay. Sometimes the right performance plan is two weeks of leave.
An actual skill gap. It happens. Someone was hired into a role that turned out to need something they do not have, or the role grew past them. This is the case people assume is always true, and it is the one that most needs an honest conversation, because it is the one where a plan might not work.
I do not skip this step, ever, because the conversation that follows is completely different depending on which cause I find.
Say it plainly, early
The worst version of this process is the one where the engineer finds out there is a problem when they see the formal plan. I have been on the receiving end of that and I remember exactly how it felt.
So the first conversation happens the week I notice, not the month I decide to act. It is direct and short. Here is what I am seeing, here is what I expected, here is the gap, what is going on from your side? Then I stop talking. What comes back usually tells me which of the four causes I am dealing with, and about a third of the time the problem is resolved by that conversation alone because the gap was a misunderstanding.
What a real plan looks like
If it is not resolved, I write a plan. Not a template from HR with the name swapped in. A document for this person, with three parts.
What good looks like, in terms we could both observe. Not "improve communication." Instead: a written update in the team channel every Thursday, design docs reviewed by a peer before they reach me, no ticket in progress for more than five days without a comment. If I cannot describe it in observable terms, I have not thought hard enough to hold anyone to it.
What I will do. This part is missing from most plans and it is the part that makes them fair. If the cause was unclear expectations, I owe them a written role description and a weekly check on whether the work matches it. If the cause was the assignment, I owe them a different assignment. Putting my obligations in the document changes the tone from disciplinary to shared.
A date. Thirty days for the first check, sixty for the decision. Long enough to see real change, short enough that the team is not carrying the gap for a whole quarter. I tell them the date on day one, and I tell them what happens at the end of it if things have not moved.
We review the plan in the regular 1:1, not in a separate meeting. Separate meetings make the plan the only thing the relationship is about.
The AI rollout changed what low performance looks like
When we moved to an AI first way of working, two things happened to my mental model of performance, and both of them surprised me.
First, a few engineers I had quietly worried about turned out to be excellent once the tools took the typing away. They were slow at producing code and fast at knowing what code should exist. With generation handled, the second skill was all that mattered and they became some of the most productive people on the team. I had been measuring the wrong thing for years.
Second, a couple of people who had looked productive started producing large volumes of generated code with no judgment behind it. Pull requests tripled in size and the number of things they could explain in review went down. That is a performance problem too, and it is a new one. The plan for it looks different: smaller changes, and a rule that they walk me through every line before it merges.
The lesson I took is that performance is always relative to what the job actually requires, and the job changed under everyone's feet. Some of the labels I had been carrying were wrong in both directions.
When to stop
Sometimes the plan does not work. The causes were real, the support was real, and sixty days later the observable things I wrote down have not happened.
At that point, continuing is not kindness. The rest of the team has been carrying the gap and they know it. Every week I delay, they learn something about what I will tolerate. And the engineer is spending their days somewhere they are failing, which is a bad place to spend your days.
So I end it, on the date I said I would, with the same directness the process started with. I have done this a handful of times. It is the worst part of the job. Every time, the person landed somewhere that fit them better, and the team got measurably faster within a month. Both of those outcomes were better than the version where I let it drift.
The label was never the point. The diagnosis was, and the diagnosis is the manager's job.