The engineer who has missed three commitments

"An engineer has missed three commitments in a row. Run the conversation."

What the question is actually testing

Three things, and none of them is whether you are willing to have a hard conversation.

Whether you diagnose before you correct. "Missed three commitments" is a symptom with at least six causes, and the right response differs completely between them. A candidate who goes straight to a performance conversation has skipped the only step that matters.
Whether you have been the cause. Unclear requirements, shifting priorities, an unrealistic estimate you accepted, or an interrupt load you allowed are all management failures presenting as an individual one.
Whether you can be specific and kind at the same time. Vagueness here is the cruellest thing a lead does, because it denies someone the information they need to fix it.

The structure to announce, as with every role-play: first move, information I would gather, line I would not cross.

The answer

First move: gather before you talk

Do not open the conversation until you can describe the three misses concretely. Spend an hour on:

The three commitments. What was promised, by when, what was delivered, and how late. If you cannot state this precisely, you are about to have a conversation about a feeling.
The estimates. Who produced them? If you or a PM set the date and they accepted it, this is a different conversation entirely.
Interrupt load. What fraction of those sprints went to on-call, support, reviews, or helping others? Look at the actual data, not the impression.
Dependencies. Were they blocked, and for how long, and did anyone unblock them?
The pattern. All three the same kind of work? All three involving the same unfamiliar system? Estimation error, or execution?
Anything else in the picture. Recent role change, a reorg, a new manager, something visible going on in their life.

Then check your own contribution honestly, because in my experience it is present more often than not: did priorities change mid-sprint, was the scope stable, did they have what they needed, and did they raise a risk that I did not act on?

The conversation

Private, scheduled with enough time, not tacked onto a 1:1 agenda alongside six other items. Open with observation rather than judgement, and then stop talking.

"I want to talk about the last three sprints. The payment retry work was committed for the 8th and landed on the 22nd; the webhook migration was committed for the 19th and is still open; the search fix slipped two sprints. I'm not here to tell you off. I want to understand what's happening, because from where I sit I can't tell whether this is estimation, blockers, priorities, or something else, and the answer changes what I do."

Three properties of that opening are deliberate. It is specific (dates and items, not "you've been missing things"). It is non-accusatory but not soft (the facts are stated plainly). And it ends with a question, which is what makes the next five minutes theirs.

Then listen properly. The answer usually falls into one of six buckets, and the response is different for each:

What you hear	What it actually is	Your move
"I keep getting pulled onto other things"	Interrupt load, a management failure	Fix the shield: rotation, explicit protection, say no on their behalf
"I thought it would be simpler than it was"	Estimation skill	Break work down smaller; estimate together for a while
"I was blocked on the platform team for a week"	Dependency management	Escalate earlier; teach them the escalation ladder and use it yourself
"I don't really understand that part of the system"	Capability gap	Pair, reassign, or scope down; this is a plan, not a problem
"I didn't want to say it was slipping"	Psychological safety, a management failure	This is about me, not them; fix how bad news is received
Nothing coherent, or it does not match the facts	Possible performance issue, or something personal	Slow down; do not conclude in this meeting

Note that two of the six are your failures, and in practice they are two of the most common. That is the point of diagnosing first.

Closing the conversation

Whatever the cause, end with the same four things, and put them in writing the same day:

A shared statement of what is happening, in their words as much as yours.
One specific change from them, small enough to be achievable: "flag anything at risk by Wednesday, not at sprint end."
One specific change from you, because there almost always is one: "I'll keep you off the support rotation for the next two sprints."
A check-in date, close enough to be real. Two weeks, not "let's see how the quarter goes."

"So: you'll raise anything at risk by Wednesday midweek rather than waiting for the review, and we'll estimate the next two pieces together so I can see where the gap is. I'll take you off support for two sprints and I'll go to the platform team myself about the queue dependency. Let's look at it again in two weeks. Does that match what you heard?"

That last question is not politeness. Misremembered agreements are how these conversations fail, and the written follow-up is what makes "no surprises" possible later.

If it is a performance problem

If the diagnosis is capability or effort rather than circumstance, the sequence is:

Name the gap early and explicitly. Not "we'd like to see more ownership" but "the last three pieces of work needed the design reworked in review; at your level I need designs that hold up."

Put expectations in writing, with what good looks like and by when.

Provide support, so that the plan is a plan rather than a countdown: pairing, a mentor, scoped work that builds the missing skill, more frequent check-ins.

Review on the stated date, and decide. Extending indefinitely is a failure of nerve that helps nobody, least of all the person, who is spending their career on a role that is not working.

The rule that governs all of it: no surprises at review time. If someone is surprised by their performance rating, that is a management failure, not theirs. The formal process should be a summary of conversations already had, never the first one.

And involve HR early rather than late, both because the documentation matters and because a performance conversation that becomes a legal one without warning is bad for everybody.

Where this goes wrong

Skipping the diagnosis. Going straight to a performance conversation when the cause was interrupt load damages a good engineer and leaves the actual problem in place. It is the most common failure in this scenario.

Softening it into nothing. "How's it going? Anything I can do?" is not a conversation about missed commitments. They will leave not knowing there was a problem, and the next conversation will be a much worse surprise.

Making it about the dates. The three misses are evidence, not the subject. The subject is what is causing them, and a conversation that stays on the dates produces better date-hitting behaviour like padded estimates rather than better outcomes.

Not naming your own contribution. If priorities shifted three times and you say nothing about it, you have taught them that the story is one-sided, and you will not get honest information from them again.

Waiting. Three misses is already late. The conversation belonged after the first, as a small, low-stakes check rather than a serious one.

Letting it be verbal only. Without a written summary, six weeks later you and they remember different agreements, and there is no basis for the next conversation.

Interviewer follow-ups

"They say the estimates were never realistic and they told you so." Then I check, because they may well be right, and if they are I say so plainly: "you did flag it and I didn't adjust, that's on me." Then we separate the two problems. Mine is that I accepted a date I had been told was unrealistic. Theirs, if it exists, is whether they raised it once in passing or escalated it clearly enough that it could not be missed. Both can be true, and conceding my half is what makes it possible to talk about theirs.

"They get defensive and say everyone else misses commitments too." I decline the comparison and stay on specifics: "I'm not comparing you to anyone. I'm talking about these three pieces of work and what would help." If the underlying claim is that the team's commitments are generally unrealistic, that is worth investigating separately and I would say so, and then look at it, because if they are right it is a planning problem and I should fix it rather than have six versions of this conversation.

"It turns out something personal is going on." Stop the performance conversation. Switch to support: what do they need, what can be reduced, does HR or an employee assistance programme have something useful, do they need leave. Adjust expectations explicitly and temporarily, with a date to revisit rather than an open-ended suspension. Keep it confidential from the team while being clear with the team that priorities have shifted. Restart the performance conversation only if the pattern persists after the circumstance resolves.

"What if they're a strong engineer whose estimates are just optimistic?" Then it is a calibration problem and it is very fixable. Break work into pieces small enough that a bad estimate costs days rather than sprints, estimate together for a few cycles so I can see where the gap opens, and shift from single-point estimates to ranges or confidence levels. Optimistic estimation is extremely common in good engineers, because they estimate the happy path, and it responds well to structure rather than to exhortation.

"How do you avoid this happening in the first place?" Shorten the feedback loop so a miss is visible in days rather than at sprint end: work broken down so nothing is larger than a week, a mid-sprint check that asks explicitly what is at risk, and a norm that raising a slip early is rewarded rather than punished. That last one is mine to establish, and it is the highest-leverage of the three, because the expensive version of this problem is the one where someone knew two weeks ago and did not feel able to say.

Production evidence

Camille Fournier's The Manager's Path treats the diagnose-before-you-correct sequence and the no-surprises rule as core practice, and is the most likely shared reference with an interviewer for this scenario.

The SBI model (Situation, Behaviour, Impact), from the Center for Creative Leadership, is the standard structure for the feedback itself: describe the specific situation, the observable behaviour, and its effect, rather than characterising the person.

Google's re:Work research on psychological safety is the evidence base for the fifth row of that diagnosis table: on teams where people do not feel safe raising bad news, slips are hidden until they are unrecoverable, and that is a property of the team's environment rather than of the individual.

Andy Grove's High Output Management supplies the underlying distinction that makes the diagnosis table work: underperformance is either a matter of capability or of motivation, and the interventions are entirely different, so guessing wrong wastes the intervention.

Interview delivery note

Open with the structure and then, critically, with the diagnosis: "First move, information I'd gather, line I wouldn't cross. And my first move isn't the conversation, it's an hour of preparation, because 'missed three commitments' is a symptom with about six causes and at least two of them are mine."

Then the conversation itself: "I'd open with the specifics, dates and items rather than 'you've been missing things', say plainly that I'm trying to understand rather than to tell them off, and then stop talking. The answer usually tells me whether it's interrupt load, estimation, blockers, a capability gap, or that they didn't feel able to say it was slipping. The last one is about me, not them."

Close with the line and the rule: "The line I wouldn't cross is vagueness. Being unspecific here is the cruellest thing a lead does, because it denies someone the information they need to fix it. And whatever the cause, it ends with one change from them, one change from me, a check-in date, and a written summary the same day, because no surprises at review time is the rule and that only works if the conversations happened."

The depth signal is naming that two of the six causes are management failures and volunteering to check your own contribution first. Most candidates run this as a conversation about the engineer.

The Staff & Team Lead Interview Reference