Managing Underperformance
Final Prep · People Management — how to diagnose why someone is missing the bar, give them a fair and concrete path to recover, and reach a humane, decisive outcome that protects the team.
This is one of the highest-signal management questions there is, because it is where empathy and accountability collide. A weak answer is either all heart (endless patience, no standard) or all edge (a plan built to justify a firing). The interviewer wants to see that you diagnose the root cause before you act, set unambiguous expectations, give specific and timely feedback, put a written plan with a real timeline in place, support and document in equal measure, and are willing to reach a decisive outcome — recovery or a clean exit — while protecting the rest of the team. Answer in CARL shape, with most of your words on the actions.
What this question is really testing
Two things. First, judgment: can you tell the difference between a skill gap you can coach, a motivation problem you must confront, a role-fit mismatch you should redeploy, and a context failure that is actually your fault as the manager? Second, decisiveness with humanity: will you act clearly and in time, or will you let a problem fester because the conversation is uncomfortable — which is the most common and most damaging failure mode. Letting underperformance drift punishes your strongest people, who carry the load and watch you tolerate it.
How to answer- Diagnose the root cause first. Sort it into skill (can’t yet), will (won’t / disengaged), fit (wrong role for their strengths), or context (unclear goals, bad onboarding, personal crisis, my own failure to set them up). The fix is completely different for each.
- Set clear, concrete expectations. Define what “meeting the bar” looks like in observable terms — not “more ownership” but “drive this project to launch, unblock yourself on X, land reviews within a day.”
- Give specific, timely feedback. No surprises. The formal conversation should confirm what regular, concrete feedback has already made clear — with examples, not vibes.
- Write down a plan with a timeline. Explicit goals, the support you’ll provide, checkpoints, and a realistic window. The plan is a genuine attempt to help them succeed, not a paper trail — but it is also documented.
- Support, document, then decide. Coach hard and remove blockers during the window; then reach a decisive outcome — recovery, redeployment to a better-fit role, or a respectful exit — and always protect the team’s morale and load throughout.
- Root-cause diagnosis before action — skill vs will vs fit vs context.
- Expectations concrete enough to be measured, not aspirational.
- “No surprises” — feedback well before any formal step.
- Genuine support paired with honest documentation.
- Decisiveness and humanity together, plus awareness of the team you’re protecting.
A worked example (CARL)
Context. I had a mid-level engineer on the Ads Events storage team — call him R — who had shipped well for a year and then visibly stalled over two quarters. Diffs sat unfinished, an on-call handoff runbook he owned went stale and contributed to a slow incident response, and in calibration his trajectory had clearly flattened while his peers moved up. Two of my stronger engineers had started quietly routing work around him, which is the tell that a team has lost confidence in someone. I had to act, but I didn’t yet know why he’d stalled — and acting on the wrong theory would have made it worse.
Actions. I started with diagnosis, not a plan. In a 1:1 I laid out the specific, observable gaps — the stalled diffs, the stale runbook, the slipped commitments — and then I mostly listened. It came out that two things were true at once: a piece was context (I had reorganized ownership six months earlier and left him with a system he’d never been properly ramped on, so he was quietly stuck and embarrassed to say so), and a piece was will (he’d become disengaged because he thought the storage-migration work he wanted was going to someone else). Neither was a raw skill problem, which changed my whole approach. On the context piece, I owned my part explicitly — I’d set him up badly — and paired him with a senior engineer for two weeks of real ramp on the system, plus I rewrote the expectations for his role so they were concrete: own the runbook to a defined quality bar, land the two stuck diffs within three weeks, and take primary on the next storage-migration workstream. On the will piece, I was direct that disengagement was showing up in his output and that I couldn’t hand him the migration he wanted while his current commitments were slipping — but I made the path explicit: hit the near-term bar and the migration was his. I put all of this in a written development plan with a six-week checkpoint and weekly 1:1 check-ins, and I was honest with him that this was a real plan with real stakes, not a formality. Throughout, I gave feedback continuously — small course-corrections every week — so nothing at the checkpoint would be a surprise. I also managed the team around it: I quietly reset the work that had been routed around him so he had a genuine chance to rebuild credibility, and I did not discuss his plan with anyone, to protect his dignity.
Results. R recovered. Within the six-week window he landed the stuck diffs, rebuilt the runbook (which held up cleanly in the next on-call rotation), and took the migration workstream, which he drove to launch the following quarter. His calibration trajectory recovered and the team started routing work to him again. It doesn’t always end this way — I’ve also had a case where the honest outcome was that the role was the wrong fit, and I helped that person move to a team that matched their strengths rather than forcing a plan I didn’t believe in. But in R’s case the diagnosis was the whole game.
Learnings. If I had jumped straight to a generic improvement plan, I’d have treated a context-and-motivation problem as a skill problem and probably lost a good engineer. The lesson I carry: spend real time on the root cause before you spend any time on the plan — and be willing to own the part of the failure that is yours. The second lesson: acting in time is a kindness to everyone, including the person, because ambiguity is crueler than clarity.
Common follow-ups
How do you tell skill from will from fit?
How to answer- Skill: they’re trying and engaged but the work is beyond their current ability — the fix is coaching, pairing, and scoped-down stretch.
- Will: they’re capable but disengaged — the fix is a direct conversation to find the root (motivation, grievance, burnout) and a clear expectation.
- Fit: they work hard but their strengths don’t match the role — the best fix is often redeployment, not a plan to make them into someone they aren’t.
- Test it cheaply. Give a scoped, well-supported task and watch: struggle-but-progress reads as skill, effortless-but-absent reads as will, competent-but-wrong-shape reads as fit.
What if the underperformance is partly your fault as the manager?
How to answer- Say so, out loud. Unclear goals, bad onboarding, or a mid-flight reorg are context failures you own — naming your part builds trust and gets to the real fix faster.
- Fix the context before you judge the person. Reset expectations, provide the ramp or the clarity that was missing, and give a fair window to respond to the corrected setup.
- Reset the clock, honestly. If they were set up to fail, the evaluation window starts once the conditions are fair — don’t hold prior context failures against them.
- Learn systemically. If your onboarding or goal-setting caused it, fix the process so the next person doesn’t hit the same wall.
How do you protect the rest of the team during this?
How to answer- Act in time. The biggest morale hit isn’t the underperformer — it’s your best people watching you tolerate a problem and quietly absorbing the extra load.
- Protect confidentiality. Never discuss someone’s plan with peers; the team’s trust in you depends on knowing you’d handle them the same way.
- Rebalance load explicitly. Redistribute critical work so the team isn’t silently carrying the gap while you run the process.
- Recognize the carriers. Make sure the people covering are seen and valued, so the fix doesn’t burn out the people you can least afford to lose.
When do you decide it’s time to exit someone?
How to answer- When the plan was real and it didn’t work. After clear expectations, genuine support, and a fair window, a sustained miss is your answer — delaying further helps no one.
- When fit, not effort, is the issue. If they’re trying hard in the wrong role, exit-from-the-team via redeployment is often the kinder and better outcome than exit-from-the-company.
- Decisive and humane together. Be direct, be respectful, preserve their dignity, and give them a clear runway — how you exit someone is watched closely by everyone who stays.
- Never a surprise. If the outcome shocks them, the feedback loop failed earlier — that’s a process failure to avoid, not a step to skip.
- Perf / calibration records — pull the trajectory that flattened and the recovery (or the fair, documented basis for an exit).
- 1:1 notes — pull the running feedback trail that proves “no surprises” and the diagnosis conversation.
- GSD — pull the concrete deliverables and checkpoints that made the expectations measurable.
- On-call / SEV records — pull the operational impact (e.g. the stale-runbook incident) that made the gap concrete and objective.
- Development / improvement plan doc — pull the written plan with goals, support, and timeline as evidence of a fair, genuine process.