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.
Student edition · understand, apply, verify
Respond to performance concerns through explicit expectations, context, support, and fair confidential processes.
What you should be able to do: Avoid inferring motivation, health, or role fit from a single task; use documented evidence and qualified support.
Context-dependent people-management guidance, not a universal HR/legal policy or verified autobiographical record. Work from observable behavior, explicit expectations, appropriate privacy, fair support/accommodations, and your organization's qualified process. Example outcomes are illustrative, not guaranteed.
Concepts explained in this guide
Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.
Coaching, delegation, and expectations
Coaching develops reasoning through questions, practice, and feedback. Delegation transfers defined work/decision responsibility with support. Expectations make outcomes and behaviors explicit.
Example. Delegate a design decision with authority, constraints, check-in, and escalation trigger—not hidden standards.
Boundary. Match support to experience/risk. Performance policies and legal requirements vary; no universal PIP timeline or personality label is a fair diagnosis.
SBI feedback and observable behavior
Situation–Behavior–Impact frames feedback around context, observed action, and its effect. Ask for perspective and agree a concrete change.
Example. 'In Tuesday's review, you interrupted two explanations; we missed rollback discussion. What was happening, and how can we finish those discussions next time?'
Outputs are produced things; outcomes are changes for users/business/team. Useful metrics state definition, denominator, population, period, and attribution limits.
Example. 'Shipped a tool' is output. 'Median onboarding fell ten to six days in this cohort' is an outcome with sample/context caveats.
Boundary. Before/after does not prove sole causation. Avoid gaming, selection bias, hidden costs, and unlike-team comparisons.
Psychological safety and constructive conflict
A shared belief that asking questions, reporting mistakes, or disagreeing can happen without humiliation or retaliation. It supports learning alongside clear standards.
Example. A junior engineer reports a suspected fault early; the lead examines evidence instead of attacking the person.
Boundary. It does not mean universal comfort/agreement or no accountability. Power, incentives, and context shape who can speak safely.
Ownership, accountability, and decision rights
Ownership names who drives follow-through; accountability names who answers for outcomes. Decision rights specify who chooses/approves and who is consulted.
Example. A migration has a coordinating owner, service owners, and named release authority.
Boundary. DRI/RACI/DACI are local conventions, not guarantees. Role labels do not replace authority, capacity, and follow-through.
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.
The spine: diagnose root cause (skill / will / fit / context) → set clear expectations → concrete, timely feedback → written plan with a timeline → support and document → humane, decisive outcome → team protected.
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.
What the interviewer is looking for
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)
Practice draft: first-person narratives below are not independently verified autobiographical evidence. Use their structure, not their claimed results; replace with your genuine safe-to-share experience.
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.
A task outcome does not reliably diagnose skill, motivation, or fit. Treat these as tentative hypotheses; examine context, support, workload, expectations, and the person's perspective.
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
Evaluate documented evidence under clear fair expectations, adequate support, contextual factors, and the organization's qualified process. A missed target does not automatically mandate termination.
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.
A reliable, solid engineer suddenly drops in performance. Walk me through your diagnostic process.
How to answer
Treat a sudden drop as a signal, not a verdict. Someone who was reliable and then wasn’t has almost always had something change — the job is to find what changed, not to reach for a plan. Start from curiosity, in a 1:1, with specific observable facts (the stalled diffs, the missed handoff), then mostly listen.
Check work context and offer appropriate support. Do not press for medical/private details or make health diagnoses; respect voluntary disclosure and qualified accommodation processes.
A task outcome does not reliably diagnose skill, motivation, or fit. Treat these as tentative hypotheses; examine context, support, workload, expectations, and the person's perspective.
Match the intervention to the cause, with no surprises. Ramp and pairing for context; a direct motivation conversation for will; redeployment for fit — all with concrete expectations, continuous feedback, and a fair window, so the eventual outcome is never a shock.
Evidence to collect with your approved tools
A decision/review record with the problem, constraints, options, and your contribution.
Relevant tests, dashboards, or measurements with definitions, denominators, dates, and uncertainty.
Incident or delivery records showing actual outcomes and unresolved limitations.
Stakeholder agreements and follow-up actions with owners and review dates.
Only authorized, minimized, safe-to-share evidence. Do not copy confidential personnel notes into a public story.
Worked example: a reliable engineer misses two handoffs
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
Sequence for this example. The table explains the evidence and decision at each step.
Step
Evidence, decision, and expected result
Describe observable facts
State the handoffs and impact; ask what changed without demanding medical or private life details.
Check work context
Clarify goals, dependencies, workload, onboarding, tools, and support before diagnosing the person.
Agree a supported plan
Set job-relevant outcomes/behaviors, resources, feedback cadence, and a fair policy-consistent review period.
Review alternatives and evidence
Consider learning/support/role adjustments with qualified HR guidance. An exit/PIP timeline is not a universal law or automatic outcome.
Check your understanding: Can one task classify someone as 'skill, will, or fit'?
No. Those are hypotheses, not diagnoses. Gather contextual evidence, hear the employee, consider support/accommodations, and follow fair policy.
Practice with your own situation
Write the expected outcome/behavior, observed evidence, context and alternative explanations, your agreed support/action, decision owner, review date, and evidence that would change the plan. Keep confidential personnel material out of public examples.
Use genuine, safe-to-share evidence. Example numbers here illustrate reasoning; they are not claims about your work or a guaranteed outcome.
