Blog

Raising a performance problem while it's still small

How to prepare and hold the first conversation about an engineer's slipping performance: a script, likely causes, tricky reactions and the written follow-up.

Most new managers notice a performance problem weeks before they mention it. The pull requests are slower, the estimates keep slipping, the design doc that was "nearly done" is still nearly done. You tell yourself it's a rough patch and you don't want to pile on. Then review season arrives, and the first time the engineer hears there's a problem is in writing, with a rating attached. This post shows you how to prepare and hold that first conversation while the problem is still small.

Why you're putting it off

Kim Scott's Radical Candor has a name for this: ruinous empathy, caring about the person but not challenging them. It feels kind, but it isn't. The person can't fix something nobody has told them about, and every week of silence makes the conversation harder because it now has to cover "why didn't you say something sooner?"

The other reason is uncertainty. You're not sure it's really a problem, you don't know the cause, and you're worried about getting it wrong. The first conversation doesn't need a verdict. It needs to say what you've noticed, find out what's going on, and agree on what happens next.

Is it time to say something?

One bad week isn't a performance problem. Use a simple rule: if you've seen the same gap two or three times, or you've started to work around the person, raise it. Working around someone looks like quietly reassigning their tickets, reviewing their code more closely than everyone else's, or leaving them off a project you'd normally give them. If you're doing any of those, the problem is already affecting the team, and the person is the only one who doesn't know.

Prepare in 20 minutes

Write down three things before you book the time.

1. The expectation. What did you expect, specifically? "Senior-level ownership" isn't an expectation. "Breaks work down so that nothing in the sprint sits in progress for more than three days" is. If you can't write the expectation down, there's a real chance you never made it clear, and that's the first thing to fix, with an apology rather than a complaint.

2. Two or three examples. Recent, specific and observable, in Situation–Behavior–Impact form (the Center for Creative Leadership model covered in the PTMP study guide): when it happened, what they did, what effect it had. Leave out anything you heard second-hand and can't describe yourself; "people have mentioned" puts someone on the defensive and gives them nothing to act on.

3. Your guesses about the cause, held loosely. You'll be wrong often enough that you shouldn't lead with them, but thinking them through helps you listen for the real one.

Possible cause What it often sounds like What usually helps
Unclear expectations "I didn't know that was my job." Write the expectation down together; agree what good looks like.
Skill gap "I'm not sure how to approach this part." Pairing, a smaller first step, more frequent check-ins for a while.
Overload or blockers "I've been pulled into three other things." Take work off their plate; fix the interruption at its source.
Something outside work Quiet, vague, "it's been a lot lately." Flexibility and support; you don't need details. Point to your company's leave or support options.
Fit or motivation "Honestly, I don't enjoy this kind of work." A real conversation about what work they want, and whether it exists here.

Pick a private, unhurried slot early in the week rather than late on a Friday, so there's time to follow up. Your regular one-on-one is usually right; if the problem is serious, a separate meeting signals that. Either way, don't hold it straight after an incident or a heated meeting.

The conversation, in five steps

Plan for about 30 minutes. Here's a script for a hypothetical case: say Sam, a mid-level engineer, has had three tickets sit in review for over a week this sprint and missed a hand-off another team was waiting on.

1. Say why you're there, up front. Don't warm up with small talk and then switch. "I want to talk about something I've noticed in your work over the last few weeks. It's not a crisis, but I'd rather raise it now than let it build."

2. Describe what you've seen, briefly. Two or three examples, then stop. "In this sprint, the retry work, the config cleanup and the metrics ticket each sat in review for more than a week. On Thursday the payments team was waiting for the schema change and we missed the date we gave them. They had to push their release."

3. Ask, then listen. "How does that match how it's felt from your side?" Then be quiet for longer than is comfortable. This is the most important part of the meeting. You're trying to find out which row of the table you're in, and you'll learn more from 10 minutes of listening than from your preparation.

4. Restate the expectation. Once you understand their side, say clearly what good looks like. "What I need is for work to keep moving: if something has been stuck for two days, flag it in stand-up or ping me so we can unblock it. And when another team is waiting on us, the date we give them is one we hit or renegotiate early."

5. Agree on next steps, both sides. What will they do, what will you do, and when you'll look at it again. "So you'll flag anything stuck for two days, and I'll take you off the on-call swap for the next two weeks so you have the time. Let's look at how it's going in our one-on-one on the 20th."

Before you finish, say the plan back in one sentence and ask whether it's fair.

When the reaction isn't what you expected

Crucial Conversations (Patterson, Grenny, McMillan and Switzler) describes these as conversations where stakes are high, opinions differ and emotions run strong. Expect at least one of these:

  • Defensive ("That's not fair, the reviews were slow because of X"). Don't argue about each example. Acknowledge what's true, keep to the pattern: "That's useful to know, and I'll look at the review queue. The pattern I'm worried about is work sitting without anyone knowing it's stuck."
  • Surprised ("Why didn't you tell me earlier?"). If it's fair, say so. "You're right, I should have raised it sooner. That's on me, and it's why I'm raising it now rather than later."
  • Upset. Offer a pause. "Do you want to take a few minutes, or pick this up tomorrow?" Then actually pick it up tomorrow.
  • Agrees immediately. Quick agreement can mean relief, or it can mean they want the meeting over. Ask one more question: "What do you think has been getting in the way?" Then listen to the answer.
  • Tells you something personal. Thank them, ask what would help, and adjust the plan. You don't need the details and you shouldn't push for them.

Write it down the same day

Send a short note after the meeting. It makes sure you both left with the same understanding and gives you something to look back at in two weeks.

Thanks for talking today. To sum up what we agreed:

  • What I've noticed: work sitting in review for over a week without being flagged, and the missed schema hand-off to payments.
  • What good looks like: anything stuck for two days gets flagged in stand-up or to me; dates we give other teams are hit or renegotiated early.
  • What you'll do: flag stuck work at two days.
  • What I'll do: take you off the on-call swap until the 20th; look at the review queue.
  • When we'll check in: our one-on-one on the 20th.

If I've got any of this wrong, tell me.

Keep the tone of the note as warm as the conversation; if it reads colder, the person will believe the note.

After the first conversation

At the check-in, look at the evidence together. If things have improved, say so specifically; improvement that goes unmentioned tends to fade. If they've partly improved, adjust the plan and set another date.

If nothing has changed after two or three rounds, or the problem is serious from the start (missed commitments to customers, behavior that harms colleagues), tell your own manager and talk to HR before you go further. Formal processes such as performance improvement plans vary by company and country, and you shouldn't improvise one. Even then, your earlier conversations and notes matter: they show the person had a fair chance, and they mean nothing in a formal process will come as a surprise. It's the same rule as in one-on-ones that engineers don't dread: nothing in a review should be news.

Mistakes that make it worse

  • The feedback sandwich. Praise, problem, praise. People remember the bread and miss the filling.
  • Hinting. "You might want to think about turnaround times" is easy to say and easy to ignore. Say what you've noticed.
  • Saving it all up. Ten examples from four months read as a case file, not a conversation.
  • Diagnosing their character. "You don't seem to care" is a judgment they can only deny. "The hand-off was missed" is a fact you can work on together.
  • Fixing it all yourself. Taking work back silently solves this sprint and teaches nothing.
  • Not following up. If the check-in date passes without a word, you've told them it didn't matter.

Before you book the meeting

Answer these on paper:

  1. What exactly did I expect, and did I ever say so clearly?
  2. What are two recent, specific examples I saw myself?
  3. What's my best guess at the cause, and what would change my mind?
  4. What am I willing to change on my side?
  5. When will we look at this again?

If you can answer all five, book the time this week.

Working toward PTMP Practitioner?

The free study guide covers every competency area on the PTMP exam, with practical examples.

More from the blog

Practical articles for technical managers at every stage. All posts

  1. A weekly status update people actually read

    A five-part template for the weekly project update, with a before-and-after example, honest status colors and how to deliver bad news early.

  2. A senior specialist track that isn't a consolation prize

    How to define staff and principal levels for a specialist group so the track rewards real impact, keeps your experts and doesn't turn into a parking lot.

  3. Forecasting delivery dates as a range your stakeholders can plan around

    Replace the single estimated date with a forecast from your team's own throughput, a confidence level, and a plan for when scope grows.