Managing Underperforming Engineers with Empathy
Managing underperformance is one of the most draining parts of engineering leadership. It often feels like a choice between being "nice" (and letting the team suffer) or being "harsh" (and feeling like a bad manager).
But letting underperformance slide isn't kindness—it's avoidance. When one person struggles, the rest of the team bears the load, and morale quietly erodes.
In this guide, we will look at how to handle these situations with clarity and structure, ensuring you are fair to the individual while protecting the team's health.
Here is what we'll cover:
- Diagnosis: How to determine if it is a Skill, Will, or System problem.
- The Gap Conversation: How to deliver feedback without "sandwiching" it.
- The Mechanics of Improvement: Practical steps to help them recover.
- The PIP: What it is actually for, and how to write one.
1. Diagnose Before You Prescribe
When an engineer is missing deadlines, our instinct is often to push for "faster coding." But speed is rarely the root cause. Before you intervene, you need to diagnose why they are struggling.
I use the Skill vs. Will framework to categorize the issue. You cannot fix a "Will" problem with training, and you cannot fix a "Skill" problem with motivation.
| Scenario | Diagnosis | The Approach |
|---|---|---|
| High Will / Low Skill | "The Junior on Fire" | They try hard but lack knowledge. Needs training, pairing, and smaller scope. |
| Low Will / High Skill | "The Bored Senior" | They can do the work but don't care. Needs new challenges or a readjustment of role. |
| Low Will / Low Skill | "The Wrong Fit" | They cannot do the work and aren't motivated to learn. Needs a transition out. |
| Systemic Failure | "The Victim" | The environment (unclear specs, tech debt) is blocking them. You need to fix the system. |
Mentor Tip: Always rule out "Systemic Failure" first. Ask yourself: "If I put my strongest engineer in this person’s seat, would they succeed?" If the answer is "maybe not," you likely have a clarity or tooling problem, not a personnel problem.
2. The "Gap" Conversation
Once you have a diagnosis, you need to speak to them. Many managers use the "Feedback Sandwich" (Compliment, Criticism, Compliment) to soften the blow. This is a mistake. It confuses the message and leads to the engineer thinking everything is fine.
Instead, I recommend discussing "The Gap."
This method frames the conversation around the distance between Expectations (the role requirements) and Reality (current output).
How to frame it
You don't need a script, but you do need clarity. Focus on the data: "I want to talk about your output on the payment service. For a Senior Engineer, the expectation is end-to-end ownership of features. Currently, I'm seeing that you need significant help from peers to finish tickets. There is a gap between the role expectation and current delivery. Let's talk about how to close it."
This approach removes the emotion. You aren't attacking their character; you are simply pointing out a discrepancy that needs to be resolved.
3. The Mechanics of Improvement
If the diagnosis is a Skill Gap, "trying harder" won't work. You need to change the way they work.
Real World Example
I once managed a Lead Engineer whose detailed design docs vanished, and he started shipping buggy code. I almost put him on a PIP. Instead, I asked: "What is the granular blocker?" He admitted he was spending 6 hours a day in meetings and coding at midnight. The fix wasn't "code better"—it was "decline meetings." I gave him permission to block his calendar from 9am to 1pm. His performance recovered in two weeks.
Tactics that work
- The Daily Sync: For severe cases, move to daily 15-minute check-ins. It provides the tight feedback loop they need to unblock.
- Pairing: Assign a senior "Running Mate" (not you) to pair with them for specific tasks.
- Reduced Scope: Remove the multi-tasking. Give them one clear task: "Ship feature X."
4. The PIP (Performance Improvement Plan)
If informal coaching and support don't close the gap, you move to a formal PIP.
A PIP is often seen as a legal formality for firing, but a good PIP is actually a contract for clarity. It removes the anxiety of "am I doing enough?" by defining exactly what "enough" looks like.
A Structured PIP Example:
yaml# Performance Improvement Plan Goal: "Return to Senior Engineer delivery standards" Timeline: "4 weeks" Expectations: - Deliverable: "Ship the User Profile API endpoints independent of heavy assistance." - Quality: "Pass Code Review with fewer than 2 rounds of logic corrections." - Ownership: "Proactively communicate status updates in Standup without being prompted." Support Provided: - "Weekly 1:1 code review sessions with Principal Engineer." - "Reduced on-call load for duration of PIP."
If they hit these goals, the PIP ends and they stay. If they don't, they leave. The clarity ensures fairness for both sides.
Summary
Managing people is difficult because it is emotional. But "being nice" by ignoring the problem is the unkindest thing you can do.
- Diagnose: Is it Skill, Will, or System?
- Communicate: Define the Gap clearly.
- Support: meaningful changes to their workflow (pairing, scope).
- Formalize: Use a PIP if the informal support fails.
The goal isn't always to save every engineer. The goal is to be fair, clear, and decisive so the team can keep moving forward.
