The underperformance sequence and the no-surprises rule

"An engineer on your team is underperforming. Walk me through what you do."

What the question is actually testing

  1. Whether you diagnose before you act. "Underperforming" is a symptom with at least six distinct causes, and the response differs completely by cause. A candidate who goes straight to a performance plan has skipped the only part that matters.
  2. Whether you own your contribution. In a large share of cases the manager's expectations were never made explicit, and the person is failing to meet a standard nobody stated.
  3. Whether you can be direct without being cruel. The failure modes are symmetric: vague feedback that leaves someone working hard on the wrong thing, and blunt feedback delivered as a verdict.
  4. Whether you understand the no-surprises rule. If a formal process is the first time the person hears there is a problem, that is a management failure regardless of their performance.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: diagnose, because "underperforming" is six different problems

Before any conversation, work out which of these it is:

CAUSE                          WHAT IT LOOKS LIKE
-------------------------------------------------------------
UNCLEAR EXPECTATIONS           They think they are doing well.
                               Their work is good by a standard
                               nobody told them was wrong.
                               -> MY failure. Fix by stating
                                  the expectation.

MISSING SKILL                  Consistently struggles with one
                               category of work.
                               -> Training, pairing, or a
                                  different assignment.

WRONG ROLE FIT                 Strong at things the role does
                               not need, weak at what it does.
                               -> Often an internal move, and
                                  the best outcome available.

MOTIVATION                     Capable, disengaged. Something
                               changed.
                               -> A conversation, not a plan.

PERSONAL CIRCUMSTANCES         A sudden change in someone
                               previously reliable.
                               -> Support first. Almost
                                  everything else is wrong here.

ENVIRONMENT                    Blocked by dependencies, buried
                               in interrupts, poorly onboarded,
                               or set up to fail.
                               -> MY failure again.

Three of the six are the manager's failure, and that ratio is not an accident. In my experience the single most common cause is unclear expectations, and the person is genuinely surprised that anyone is unhappy.

The evidence to gather before deciding:

SPECIFIC EXAMPLES        Three to five concrete instances with
                         dates. "Quality is inconsistent" is not
                         actionable; "these three PRs needed
                         four review rounds each for the same
                         class of issue" is.

THE COMPARISON           Against the role's expectations, not
                         against the best person on the team.
                         A perfectly adequate engineer next to
                         an exceptional one is not
                         underperforming.

WHAT CHANGED             Was this always the case, or did it
                         start? A change has a cause.

MY OWN RECORD            Have I stated the expectation? In
                         writing? Have I given feedback that
                         was clear enough to act on? If not,
                         the sequence starts there, not with a
                         plan.

Then: the conversation, well before anything formal

This is the step that determines whether the rest is necessary. Private, direct, and it opens with the specific rather than the general.

"I want to talk about the last few weeks, and I want to be direct because I don't think being vague would be fair to you.

Three examples: the payments PR needed four rounds because of the same null-handling issue each time. The migration ran two weeks past the date without a heads-up until the day it was due. And in the design review last Thursday you presented an approach that hadn't accounted for the constraint we discussed the week before.

What I'm seeing is a pattern of work going out before it's ready. And before we go further, I want to check something: is that consistent with how you think it's going? Because if it isn't, then I haven't been clear enough about what I'm expecting, and that's on me."

Four properties, each doing work:

It leads with specifics, dated. Not a characterisation. Three instances they can verify.

It names the pattern, because three examples without a pattern is a list of complaints and three examples with one is a diagnosis.

It asks whether they agree, genuinely. If they are surprised, the cause is unclear expectations and the rest of the conversation changes.

It offers the manager's contribution as a real possibility, which is disarming, usually accurate, and the thing that makes the person engage rather than defend.

Then: the plan, informal and written

Before any formal process, an informal plan with a date.

WRITTEN DOWN, because a verbal plan is remembered differently
by each party within two weeks.

  What specifically needs to change, with observable
  criteria. Not "improve quality": "PRs go out with tests
  covering the null and error paths, and the design is
  agreed before implementation on anything over two days."

  What support I am providing. Pairing, a reduced load, a
  clearer spec, removing an interrupt source. If I am asking
  for change and providing nothing, the plan is a
  documentation exercise.

  A check-in cadence. Weekly, short.

  A review date. Six to eight weeks is typical: long enough
  to demonstrate change, short enough to be a real deadline.

  What happens if it does not change. Stated plainly and
  early, not saved as a threat.

That last item is the no-surprises rule in practice. The person should know, at the informal stage, that the next step is formal. Discovering that only when the formal process starts is the failure.

Then, only if needed: the formal process

By this point the person should be able to predict it
exactly. If a formal PIP is a surprise, I have failed at
the previous steps.

The formal process is HR's shape, and my job is:
  - the criteria are objective and achievable
  - the timeline is realistic for the change requested
  - I do not stop supporting them because it is formal
  - I have documented the informal stage, because HR will
    ask and because it protects both of us

And the honest statement about what a PIP usually is: in most organisations the majority of people on a formal plan leave, either by failing it or by choosing to go. That does not make it a formality, and treating it as one is a mistake in both directions: some people genuinely turn it around, and running a process you have already decided the outcome of is dishonest.

The exit, when it comes

Two paths, and offering both is right:

  RESIGN WITH DIGNITY   A conversation offering a transition
                        with a reference and time to find
                        something. Frequently the better
                        outcome for everyone, and it should
                        be offered honestly rather than as a
                        threat.

  COMPLETE THE PROCESS  If they want to try, they get a real
                        chance and my genuine support.

Either way: no surprises, and the team is told something
truthful and respectful. "X has decided to move on" when
everyone knows otherwise damages your credibility with the
people who remain, who are watching how you treat someone on
the way out and calibrating how you would treat them.

Where this goes wrong

Skipping the diagnosis. Going straight to a plan when the cause is unclear expectations means running a formal process against someone who was never told the standard.

Vague feedback. "You need to step up" is not actionable and is the single cruellest thing a manager does, because the person works hard on the wrong things and the next conversation is much worse.

Waiting too long. The most common failure. Three months of hoping it resolves, then a sudden formal process. The person is entitled to be furious about the three months.

Comparing to the strongest person on the team rather than to the role's expectations. That produces "underperformance" findings against people who are entirely adequate.

Not documenting. A verbal conversation is remembered differently by each party within two weeks, and by the formal stage the discrepancy is a problem for both of you.

Treating a PIP as a formality. If the decision is already made, say so and offer a transition. Running a process whose outcome you have decided is dishonest and the person can usually tell.

Not telling the team anything. The team knows. Silence reads as either indecision or as something worse, and the people staying are calibrating how you would treat them.

Interviewer follow-ups

"How quickly should you have the first conversation?" Within about two weeks of noticing a pattern, and the emphasis is on pattern rather than incident. One missed deadline is an event; three in six weeks is a pattern. Waiting three months is the most common failure and it is unfair in a specific way: every week you do not say anything is a week they spend not knowing they need to change, and they are entitled to be angry about that later.

"What if they disagree with your assessment?" Take it seriously rather than restating, because sometimes they are right. I would ask what they see, and specifically whether they were blocked by something I did not know about, and whether the expectation was ever stated. If their account holds up, my assessment changes. If it does not, I show the specific gap: "here's what the role needs, here are three instances where the work didn't meet it, help me understand the difference." Being willing to be wrong is what makes the rest credible.

"What if the cause is personal circumstances?" Then almost everything above is the wrong sequence. Support first: leave, reduced scope, a temporary reassignment, whatever the organisation can offer. A performance process against someone dealing with a serious personal situation is both wrong and, in many jurisdictions, legally risky. I would loop in HR early precisely because they know what support exists and what the obligations are. Performance management resumes when circumstances allow, and I would say that explicitly so it is not ambiguous.

"How do you handle it if they were fine and something changed?" Ask, directly and early, because a change has a cause and the cause is often something I can address: a reorg that removed their favourite work, a new manager relationship, a project they think is pointless, or something outside work. The mistake is treating a sudden decline the same as a persistent inability, because they need completely different responses and the sudden one is frequently the more fixable.

"What do you tell the rest of the team?" Truthful and minimal. During: nothing about the individual's performance, because that is theirs. After: something honest that does not pretend. "X is moving on, here's how we're covering their work" is fine; "X decided to pursue other opportunities" when everyone knows otherwise costs you credibility with the people staying. And I would be aware that the team is watching how someone is treated on the way out and inferring how they would be treated.

"What if you inherited this person mid-process?" Restart the diagnosis rather than continuing someone else's conclusion. I would read the documentation, talk to the person, and form my own view, because the previous manager's assessment may have been correct or may have been a personality mismatch, and inheriting a conclusion without testing it is unfair. I would also tell the person I am doing that, because being re-evaluated by a new manager is frightening and being explicit that I am forming my own view is worth a lot.

"What if they're a strong individual contributor with bad collaboration?" That is a performance problem, and I would name it as one rather than tolerating it because the output is good. The concrete version is to make the collaboration expectation explicit and observable, the same way I would for code quality, and then to treat it identically. What I would not do is have a vague conversation about "being a better teammate", because that is unactionable. See the toxic code reviewer, which is the same problem in a specific form.

Production evidence

Camille Fournier's The Manager's Path supplies the no-surprises principle and the argument that specificity is a form of respect, and it is direct that a formal process arriving as a surprise is a management failure.

Kim Scott's Radical Candor frames the two symmetric failure modes precisely: ruinous empathy, being kind at the expense of clarity, and obnoxious aggression, being clear without care. The underperformance conversation is where both are most costly.

Google's re:Work manager research documents that the highest-rated managers give clear, specific, timely feedback, and that unclear expectations is among the most common causes of poor performance, which is the empirical basis for diagnosing before acting.

The widely-reported statistic that a large majority of employees on formal performance plans leave is why the informal stage matters: by the time it is formal, the outcome is largely determined, so the effort belongs earlier.

SBI (Situation-Behaviour-Impact), from the Center for Creative Leadership, is the standard feedback structure and is what the "three dated examples plus the pattern" formulation implements.

Interview delivery note

Open with the diagnosis, because it is the step candidates skip and it is where the judgement is: "My first move isn't a conversation, it's working out which problem this is. Underperformance has about six causes: unclear expectations, a missing skill, wrong role fit, motivation, personal circumstances, and environment. Three of those six are my failure, and in my experience unclear expectations is the most common, where the person is genuinely surprised anyone is unhappy."

Then the conversation, with the specific mechanics: "Then a private conversation, well before anything formal, that opens with three dated examples rather than a characterisation, names the pattern, and then asks whether they agree. And I'd explicitly offer that if they're surprised, I haven't been clear enough, and that's on me. That last part is disarming, usually accurate, and it's what makes them engage rather than defend."

Name the no-surprises rule as a rule: "And the person should be able to predict the formal process before it starts. If a PIP is the first time they hear there's a problem, I've failed at every step before it, regardless of their performance."

The line about the plan that shows you have run one: "The informal plan is written down, with observable criteria rather than 'improve quality', with what support I'm providing, and with what happens if it doesn't change stated plainly and early rather than saved as a threat. If I'm asking for change and providing nothing, the plan is a documentation exercise."

Close on the line you would not cross: "The line I wouldn't cross is being vague to be kind. It's the cruellest thing a manager does, because they work hard on the wrong things for months and the next conversation is far worse. And the second is waiting: three months of hoping is the most common failure, and they're entitled to be furious about it later."

Further reading

  • Camille Fournier, The Manager's Path, on the no-surprises principle and career conversations.
  • Kim Scott, Radical Candor, particularly the ruinous-empathy failure mode.
  • Google re:Work's manager research, on feedback specificity and unclear expectations as a cause.
  • The Center for Creative Leadership's SBI feedback model.