Managing Underperformance: A Humane EM Playbook
2026-07-18 · 9 min read · Career & Promotions
Most Engineering Managers wait too long to address underperformance. They hope the situation improves on its own. They give feedback that's too soft to land. They mistake being kind with being vague. Then one day the situation has gone on for six months, the team's morale has taken a hit, and the options have narrowed to a formal performance plan or a departure.
Addressing underperformance early, clearly, and humanely is one of the hardest things an EM does — and one of the most important. Here's how to do it without brutalising the person or ignoring the problem.
First: Diagnose Before You Intervene
Not every performance problem has the same cause, and the response should fit the cause.
Skill gap: The engineer doesn't yet have the capability to do what's expected at their level. This is a development problem, not a discipline problem. The response is coaching, pairing, and targeted growth opportunities.
Motivation or engagement: The engineer has the skills but isn't applying them — disengagement, loss of purpose, burnout, or a personal situation making it hard to be present. The response here is a different kind of conversation: what's going on for them? What would change things?
Mismatch: The engineer is capable but in the wrong role, the wrong team, or the wrong company. The technical skills are there; the fit isn't. The response here is an honest conversation about whether this is the right place for them to do their best work.
External obstacles: Something in the environment is blocking the engineer — unclear requirements, a toxic teammate, tooling that makes basic work painful, being under-resourced for what's expected of them. The response is environmental change, not performance management.
Willful or repeated underperformance: The engineer is capable, has been given clear expectations and support, and still isn't meeting the standard. This is the situation that eventually leads to a formal process.
If you intervene with a formal process when the problem is actually a skill gap, you'll lose a potentially good engineer who needed coaching. If you coach and coach when the problem is willful underperformance, you'll exhaust yourself and demoralise the team. Diagnose before you prescribe.
The Early Conversation: Before It's Formal
The worst thing about most underperformance processes is that the engineer doesn't hear clear feedback until things are already serious. The first time someone explicitly names a problem should not be in a performance improvement plan.
As soon as you notice a pattern — not a single incident, but a pattern over 2–4 weeks — name it directly in a 1:1. Be specific and behavioural, not evaluative.
Vague: "I'm a bit worried about your performance lately."
Direct: "I want to flag something I've been noticing. In the last three sprints, you've missed your delivery estimate by 50% or more, and I've had to follow up to find out where things are rather than getting proactive updates. I want to understand what's happening and figure out how we fix it."
The direct version does three things: names the specific pattern, describes the impact, and opens a dialogue. It doesn't threaten. It doesn't soften the concern to the point of invisibility. And it treats the engineer like an adult who deserves to know where they stand.
This conversation should happen early enough that there's time to improve. If you're having this conversation the week before a performance cycle closes, you've waited too long.
Setting Clear Expectations
Once you've named the concern, the next step is to be explicit about what "better" looks like. Many underperformance situations persist because the engineer genuinely doesn't know what the expectation is — they think they're doing fine, or they know something is wrong but don't know what specifically to change.
Be concrete:
- "I need you to give me a heads-up by Wednesday if a ticket is going to slip the sprint — not Friday when it's too late to adjust."
- "When you're blocked, I need you to surface it the same day, not work around it for three days."
- "The code review standard we need is: 24-hour turnaround on PRs under 300 lines, and substantive comments, not just approvals."
Then agree on a timeframe. "Let's check in on these three things specifically in four weeks." A short, defined window — not an open-ended "keep improving" — creates shared accountability.
The Check-In Cycle
After the initial conversation, check in frequently. Not to monitor, but to support — and to gather the information you need to make a judgment.
Weekly 1:1s during this period should explicitly revisit the expectations you set:
- Is the pattern changing?
- Are they getting the support they need?
- Are there obstacles that are getting in the way that you can remove?
Document these conversations. Not in a formal or threatening way — just your notes, with the date, what was discussed, what was committed to. If the situation escalates to a formal process, this documentation becomes important. More practically, it helps you track whether things are actually improving or just appearing to improve when attention is on them.
When Informal Isn't Working
If you've had 4–6 weeks of explicit conversations, the expectations are clear, the support is in place, and the pattern hasn't changed — it's time to escalate to a more formal conversation.
This conversation is not a performance improvement plan. It's the conversation that makes explicit what you've both been discussing:
"I want to be direct with you about where things stand. Over the past six weeks we've talked about [specific expectations]. I've seen some improvement in [area], but [specific pattern] is still not where it needs to be. I want to figure out whether this is something we can turn around, and I need you to be honest with me about whether you think it is too. If we're both committed to it, here's what the next four weeks need to look like. If you've lost confidence in this role or this team, I'd rather have that conversation now."
This is hard to say. It needs to be said. An engineer who's been in an ambiguous performance conversation for months deserves clarity about where they actually stand.
The Performance Improvement Plan
If you reach the point of a formal PIP, a few principles:
The goal of a PIP is not to fire someone — it's to create clarity. A well-run PIP gives the engineer a real chance to turn things around with unambiguous expectations. It also creates a fair, documented record if the outcome is termination.
Be specific in the document. "Improve communication" is not a PIP goal. "Send a written update in the team Slack channel by 5pm on Fridays summarising what shipped, what's in progress, and any blockers" is. Every goal should be observable and measurable.
Set a realistic timeline. Four weeks is standard for most PIP cycles. Six weeks for more complex situations. Shorter than four weeks rarely gives enough time to demonstrate genuine change. Longer than eight weeks drags the situation out past the point where the team is affected.
Check in weekly, in writing. Each week of the PIP should include a short written summary: what improved, what didn't, what the next week's expectation is. This removes any ambiguity about how the PIP is progressing and makes the final assessment clear to everyone.
Involve HR. Once you're at PIP stage, involve your HR partner from the start. Not to weaponise the process, but to ensure it's fair and consistent with how your company handles these situations.
The Hardest Part: Protecting the Team
Underperformance that goes unaddressed doesn't just affect the underperforming engineer. It affects everyone around them. Engineers who are picking up slack, covering for missed work, or watching someone get away with a lower standard will notice. It's one of the fastest ways to lose your best people — they'll accept a lot, but they won't accept long-term inequity.
You can address this without naming the person. Be clear with your team about expectations. Recognise explicitly when the bar is being met. Keep the slack from accumulating silently on top of other people's plates.
Your team doesn't need to know the details of someone's performance situation. But they need to know you see the full picture and are doing something about it.
A Final Note on Dignity
Managing underperformance well is not just about protecting the team — it's about treating the underperforming engineer with dignity throughout.
Clear feedback, delivered early, is a kindness. Vague reassurance followed by sudden termination is not.
Give them real information about where they stand. Give them a genuine opportunity to improve. If the outcome is ultimately a departure, make it as graceful as possible. How you handle the worst case is part of how your team judges what kind of manager you are.
Track 1:1 notes, action items, and patterns over time to catch performance concerns early — before they escalate. Try Emtricks free for 30 days.