How to Handle Underperformance on an Engineering Team

Nobody becomes an engineering manager because they enjoy difficult personnel conversations. We get promoted because we're good at building systems, and then we discover that the hardest system to debug is a person who's not meeting expectations. I've managed 47 engineers over 9 years, and I've handled 14 underperformance situations that required formal intervention. Nine of those engineers improved and stayed. Five left or were let go. Every single one of those situations taught me something.

This post is the process I wish someone had handed me the first time I had to tell an engineer their work wasn't good enough.

# Why Engineers Underperform (It's Not What You Think)

The default assumption is that underperformers are lazy, checked out, or not skilled enough. In my experience, that's the actual reason less than 20% of the time. Here's the breakdown from my 14 cases:

• Unclear expectations: 4 cases (29%). The engineer genuinely didn't know what "good" looked like.
• Wrong role fit: 3 cases (21%). Strong engineers in positions that didn't match their skills.
• Personal circumstances: 3 cases (21%). Health, family, burnout they hadn't disclosed.
• Toxic team dynamics: 2 cases (14%). The engineer was fine; the environment was the problem.
• Actual skill gap: 1 case (7%). Hired above their level.
• Motivation/attitude: 1 case (7%). Genuinely checked out.

The contrarian take: if your first instinct when someone underperforms is "they're not good enough," you're probably wrong 80% of the time. The cause is usually environmental, and that means the fix is on you as the leader.

# The Diagnostic Framework: WHAT Before HOW

Before you decide how to address underperformance, you need to diagnose what's actually happening. I use a 4-question diagnostic that takes about a week of observation:

Question 1: Is the expectation clear and documented?

Pull up the engineer's last performance review, their role leveling doc, and the last 3 project briefs they received. Can you point to a specific, written statement that describes what success looks like? Not "write good code" but "deliver features within 10% of estimated timeline with fewer than 2 bugs per release."

If you can't point to it, the problem might be yours. I had a senior engineer "underperforming" for 2 months before I realized I'd never explicitly told him I expected him to mentor juniors. It was obvious to me. It wasn't obvious to him. He thought his job was shipping code.

Question 2: Does the engineer have the tools and context they need?

Check their access to systems, documentation, and tribal knowledge. I once put an engineer on an improvement plan, and during our first 1:1, she told me she'd been blocked on a permissions issue for 3 weeks and didn't know who to ask. She'd been working around it, which made her work look slow and convoluted. The "underperformance" was actually an onboarding failure.

Question 3: Is this a pattern or a blip?

Look at the last 90 days of their work. Plot it roughly: was there a specific point where quality dropped, or has it been consistently below expectations? Blips have external causes (personal events, a bad project assignment, team reorganization). Patterns require intervention.

Question 4: Have I given direct feedback already?

Not hints. Not "it would be nice if..." Direct, specific feedback with examples. "In the last sprint, your PR for the auth migration had 14 review comments, 6 of which were logic errors. That's 3x the team average. I need to understand what happened and how we get that closer to the team baseline."

If you haven't given feedback that direct, you haven't actually addressed the problem yet. You've just been hoping it resolves itself.

# The Improvement Framework: The 30-60-90 Structured Plan

Once you've diagnosed the root cause, here's how I structure the improvement process. This isn't a PIP (Performance Improvement Plan) in the HR sense, though it can become one if needed. It's a structured support plan with clear milestones.

# Days 1-7: The Alignment Conversation

Schedule a 1-hour meeting. Not in a conference room with HR on standby. That's for later, if needed. This first conversation is in your regular 1:1 setting.

The script I use:

"I want to talk about your work over the past [timeframe]. I've noticed [2-3 specific examples with dates and details]. I want to understand what's going on from your perspective, and then I want to work together on a plan to get things where they need to be."

Then shut up and listen. In 9 of my 14 cases, the engineer told me something I didn't know that changed my understanding of the situation.

Critical rule: Document this conversation immediately afterward. Send a follow-up email summarizing what was discussed and what was agreed. Not to build a paper trail (though it does), but because memory is unreliable and you both need a shared reference point.

# Days 1-30: The First Checkpoint

Set 3 specific, measurable goals for the first 30 days. Not "improve code quality" but:

1. "Reduce PR review comments to fewer than 5 per PR (current average: 14)"
2. "Complete sprint commitments at 80% or higher (current: 55%)"
3. "Pair with a senior engineer on at least 2 tasks per sprint"

Meet weekly during this period. These aren't "checking up" meetings. They're support meetings. Ask: "What's blocking you? What do you need from me? Are the goals still realistic given what you've learned this week?"

# Days 30-60: The Progress Assessment

At day 30, evaluate honestly. There are three possible outcomes:

Clear improvement (60% of my cases): Acknowledge it explicitly. "Your PR comments dropped from 14 to 6. That's real progress. Here's what I want to see in the next 30 days." Adjust goals upward.

Partial improvement (25% of my cases): Some goals met, others not. Dig into the misses. Were the goals wrong? Is there a specific skill gap? Adjust the plan.

No improvement (15% of my cases): This is where the conversation shifts. "We agreed on these goals 30 days ago. The numbers show [specific data]. I want to understand what happened, and I need to be honest that if we don't see meaningful improvement in the next 30 days, we'll need to involve HR in a formal plan."

# Days 60-90: The Decision Point

By day 60, you have enough data to make a fair decision. Either the engineer is on an upward trajectory (in which case you continue support and can begin to relax the structure), or they're not (in which case you begin the formal HR process with a well-documented history of support, clear expectations, and specific data).

# The Stealable Framework: The Underperformance Decision Tree

Is the expectation documented and communicated?
  No --> Document it. Communicate it. Wait 30 days. Not an underperformance issue yet.
  Yes --> Continue.

Does the engineer have the tools, access, and context to succeed?
  No --> Fix the environment. Wait 30 days. Not an underperformance issue yet.
  Yes --> Continue.

Have you given specific, direct feedback with examples?
  No --> Give it today. Start the 30-60-90 framework.
  Yes --> Continue.

Has the engineer shown improvement after 30 days of supported effort?
  Yes --> Continue support. Extend timeline. They're trending right.
  No --> Formal improvement plan with HR. 30-day deadline with weekly check-ins.

# What I Got Wrong Early in My Career

I used to wait too long. My average time from noticing underperformance to having the first direct conversation was 11 weeks in my first management role. Eleven weeks. That's almost 3 months of the engineer not knowing there was a problem, the team compensating, and the situation getting worse.

I've gotten it down to 2 weeks now. Not because I'm tougher, but because I realized that quick, direct feedback is kinder than letting someone fail in slow motion. The engineers who improved fastest were the ones who got clear feedback earliest.

The hardest thing I've learned is that some underperformance situations aren't fixable in the current role. Two of my best outcomes were engineers who moved to different teams or different roles within the company and thrived. Underperformance isn't always about the person. Sometimes it's about the match.

# Your Action Items

1. Audit your current team: is there anyone whose performance you've been "hoping" would improve without direct intervention?
2. If yes, run the 4-question diagnostic this week.
3. Have the alignment conversation within 14 days.
4. Set up the 30-60-90 structure with measurable goals.

The goal isn't to fire people. The goal is to be honest early enough that you can actually help them succeed. Most of the time, they will.