One of your engineers is underperforming. How do you handle it?

The diagnosis comes before the plan

The interviewer is not checking whether you can fire someone. They are checking whether you can hold two things at once: genuine care for an individual and an unwillingness to let a team absorb the cost of unaddressed underperformance indefinitely. Candidates fail this question in two symmetrical ways. The soft failure is endless coaching with no defined endpoint, which is kindness that quietly ruins a team. The hard failure is reaching for a performance improvement plan in the first minute, which signals you treat process as a substitute for management.

The strong answer moves in a specific order: diagnose, own your part, give specific feedback, write down an expectation with a date, and only then consider formalising. Saying that order out loud is most of the score.

Diagnose before you act

"Underperforming" is a symptom, not a cause, and the four common causes call for four different interventions. Confusing them is the most expensive mistake available here.

Skill. The engineer is trying and the output is not there because the work is above their current capability, or in an unfamiliar part of the stack. The intervention is scoping, pairing, and a narrower brief — not motivation.

Will. Capability is evident but engagement has gone. This is usually a symptom of something else: a passed-over promotion, a project they think is pointless, a manager they no longer trust, an offer in their pocket. The intervention is a candid conversation about what changed, and it is often the only one that works.

Clarity. They believe they are doing well. Nobody ever told them the bar, or the bar moved when they were promoted or when the team's priorities shifted. This is the most common cause and the one most often misdiagnosed as will.

Environment or health. Interruptive on-call, a hostile reviewer, a broken build, caring responsibilities, illness, or a mental health issue. Some of this you can remove. Some of it you must not treat as a performance matter at all, which is precisely why you diagnose first.

The diagnosis comes from evidence, not impressions: their actual work over the last two or three months, review comments, incident involvement, and what you hear when you ask peers about collaboration without inviting them to build a case against a colleague.

Own your part first

Before any conversation, answer honestly whether you contributed. Did you set the expectation explicitly, or assume it? Have you given feedback at the time, or saved it up? Did you put them on a project nobody could have succeeded in, or one with no clear owner? Have you been giving them work below their level and then reading the disengagement as a performance problem?

Two tests are worth applying. First, if the engineer would be surprised to hear there is a concern, that is a management failure before it is a performance failure, and you should say so in the room. Second, if nobody on the team is succeeding at the thing you are measuring, the problem is the system, not the person.

The first conversation

Hold it in a one-on-one, unhurried, and be direct in the first minute. Ambiguous openings make people spend the whole conversation trying to work out how serious it is.

"I want to talk about something more directly than I have been. Over the last two months the work coming out of your side of the payments migration has been slower and needed more rework than I'd expect at your level — the reconciliation job was three weeks past what we agreed and came back twice in review for the same error handling gap. That is a real gap against what I need from a senior engineer on this team, and I want to be honest that I have not been clear enough with you about it before today, which is on me.

I don't have a conclusion about why, and I'd rather hear it from you than guess. What's your read on how the last couple of months have gone?"

Then stop talking. The diagnosis usually arrives in the next five minutes, and it is frequently something you did not know.

Notice what the phrasing does. It cites observable behaviour with dates rather than delivering a verdict about the person. It names the standard in terms of their level. It puts your own failure on the table without dissolving the concern. And it ends with a genuine question rather than a plan you have pre-decided.

Write the expectation down

Whatever you agree, convert it to writing the same day — a short note in your shared document, not an HR form. It should name one or two specific, observable outcomes, the support you are providing, and a date to review. "Improve code quality" is not an expectation. "The reconciliation service ships behind a flag by the 20th, with tests reviewed by Priya, and we review progress every Thursday" is one.

The written record matters for three reasons that are worth saying aloud in an interview: it removes the possibility of two different memories of the conversation, it lets you tell improvement from wishful thinking at the review date, and if this does end up formal, the engineer will already have seen every word of the concern.

The cost of letting it run

Strong candidates volunteer the team effect. Peers notice long before you act. They start silently rerouting work, they conclude the bar is negotiable, and the strongest engineer on the team — the one absorbing the slack — is the one most likely to leave over it. Unaddressed underperformance is a retention risk aimed at your best people. Saying that in the same breath as the care is what separates a manager from someone conflict-avoidant who has learned the vocabulary.

Bringing HR in

Involve your HR or people partner at the point you first have a documented concern and are considering formalising, not on the day you want an exit. Early involvement gets you the local legal and policy constraints, calibration on whether the gap you are describing is really a performance gap, and a check on whether anything you have heard means this should be handled as a health, accommodation, or conduct matter instead. Arriving late usually means being told to spend another two months building a record you could have been building all along.

If it does become a formal plan, the plan must contain no new information. Every gap in it should be something the engineer has already heard from you, in those words, at least twice. A formal plan that surprises the person receiving it is evidence the manager avoided the hard conversations, and interviewers hear it that way.

The trap

The trap is treating the formal process as the management. Candidates describe a tidy pipeline — feedback, then a plan, then exit — and never mention that the outcome they should be working towards is this engineer succeeding, or that a real possibility is discovering the underperformance was caused by their own assignment decisions. The strong answer keeps both endpoints genuinely open: this may end in a plan and it may end with someone recovering, and which one it becomes depends partly on a diagnosis you have not made yet. Simultaneously, you must be honest that a plan is on the table, because a manager who cannot say that has no leverage and is only postponing a worse conversation.

Diagnose before you intervene, put your own contribution on the table early, and make the standard so specific and so early that a formal plan, if it ever arrives, contains nothing the engineer is hearing for the first time.