Most engineering leaders know when someone on their team is underperforming. They also know they should do something about it. The gap between knowing and doing is where teams quietly fall apart. A structured approach makes the conversation easier to start, fairer for the engineer, and better for everyone regardless of outcome.
You have seen this play out before. There is someone on the team who is not performing. Everyone knows it. The other engineers know it because they are picking up the slack, reviewing the same code three times, or quietly routing the harder problems away from that person's queue. You know it because your gut has been telling you for weeks, maybe months. And yet, the conversation has not happened.
It is one of the most common failure patterns in engineering leadership. Not because managers are cowards. Most are not. It is because they have no repeatable process for having the conversation, so every instance feels like improvisation with someone's career on the line. That is genuinely hard. But avoiding it is worse. For the underperforming engineer, for the rest of the team, and for you.
Research from the Harvard Business Review found that managers who delay difficult performance conversations report higher stress, lower team engagement, and worse outcomes when the conversation finally happens.[1] The delay does not make things better. It makes everything harder.
Ask most engineering managers why they have not addressed an underperformance issue and you will get some version of the same three answers.
"I'm not sure it's bad enough yet." This is the most common one. The engineer is not failing spectacularly. They are just... not quite there. Their code works but needs heavy review. They hit deadlines but only when someone else unblocks them. They attend meetings but rarely contribute. It is death by a thousand paper cuts, and no single cut feels serious enough to warrant a formal conversation.
"I don't want to damage the relationship." Engineering managers who were promoted from technical roles often value their relationship with the team above almost everything else. A performance conversation feels like it might break that trust. In reality, avoiding the conversation breaks it faster, just with different people. Your high performers are watching, and they are drawing conclusions about what standards actually mean on this team.
"I'm hoping it will resolve itself." Sometimes it does. A rough quarter, a personal issue, a bad project fit. But if you have been hoping for more than a few weeks, hope is not a strategy. It is procrastination with a nicer name.
The common thread is that none of these reasons are about the underperforming engineer. They are about the manager's discomfort. And that is the thing worth being honest about. The conversation is hard because you do not have a system for it, not because the situation is genuinely ambiguous.
Underperformance rarely arrives as a single dramatic event. It builds gradually, and the early signals are easy to rationalise away if you are not paying attention.
Increasing dependency. The engineer who used to work independently now needs frequent guidance. They ask more questions, escalate more decisions, and their pull requests sit longer because they are less confident in their own work. This is not the same as a junior engineer learning the ropes. This is someone who was previously capable and is trending in the wrong direction.
Narrowing contribution. They stop doing the extras. No more volunteering for code reviews, no more participating in architecture discussions, no more helping onboard new hires. They do their assigned tickets and nothing else. In isolation, this looks like someone having a quiet month. In combination with other signals, it is a pattern worth investigating.
Quality drift. The code still ships, but it requires more review cycles. Edge cases get missed. Tests are thin or absent. Other engineers start doing quiet rewrites after merge. This is often the first signal that peers notice, sometimes before the manager does.
Disengagement in one-to-ones. An engineer who used to have opinions and push back on decisions now says everything is fine. They have stopped advocating for anything. This is not contentment. It is withdrawal.
The key insight from organisational psychology research is that early intervention dramatically improves outcomes.[2] The longer underperformance continues without acknowledgment, the harder it is to reverse, because the engineer internalises the behaviour as acceptable and the team internalises the manager's silence as indifference.
This is the part most people dread. Here is how to make it less painful and more productive.
Prepare with specifics. Vague feedback is useless and unfair. "Your performance needs to improve" gives the engineer nothing to work with. Instead, come with concrete examples: specific pull requests that required excessive rework, particular deadlines that slipped, documented instances where the work did not meet the standard the rest of the team is hitting. Data removes ambiguity. It also protects both of you from the conversation becoming a debate about perceptions.
Lead with curiosity, not conclusions. Before you tell someone they are underperforming, ask what is going on. There might be context you do not have. A personal crisis, a health issue, a fundamental misunderstanding of expectations, a bad team dynamic you have not noticed. The EM Tools framework makes a sharp point here: unclear expectations are the most common cause of underperformance, and they are as much the manager's failure as the engineer's.[3] Start by establishing whether expectations were genuinely clear and mutually understood.
Be direct about the gap. After listening, be honest. "Here is what I'm seeing. Here is what good looks like at your level. There is a gap, and I want to help you close it." Direct does not mean harsh. It means clear. Most engineers respect directness far more than they respect being managed around.
Agree on what happens next. A conversation without a follow-up plan is just a warning shot. It creates anxiety without creating a path forward. Before you leave the room, agree on specific, measurable changes, a timeline, and when you will check in next.
A good improvement plan is not a paper trail for a firing. It is a genuine attempt to help someone succeed, with enough structure that both sides know exactly what success looks like.
Define success in observable terms. "Improve code quality" is not a goal. "All pull requests pass review with no more than one round of revisions over the next six weeks" is a goal. "Demonstrate technical leadership" is not a goal. "Lead the design review for the authentication refactor and present the recommendation to the team by the end of the month" is a goal. If you cannot observe it, you cannot measure it, and if you cannot measure it, you are setting the engineer up for a subjective judgement call that will feel unfair regardless of the outcome.
Set a realistic timeline. Most improvement plans run between four and eight weeks. Shorter than four weeks rarely gives someone enough time to make genuine changes, especially if the underperformance involves skill gaps rather than effort. Longer than eight weeks and the plan loses urgency, and the rest of the team starts wondering if anything is actually going to change.
Check in weekly. Not to monitor. To support. Weekly check-ins serve two purposes: they give the engineer regular feedback on whether they are on track, and they give you a documented record of the process. Both matter. The engineer needs to know where they stand at every point, not just at the end.
Separate the plan from the relationship. This is subtle but important. The improvement plan is a formal process. Your one-to-ones, your team interactions, your daily working relationship should not become defined by it. The engineer is still a member of the team. They still deserve to be treated with respect and included in normal team activities. The moment you start treating them as a problem to be managed rather than a person to be supported, you have already decided the outcome, and they will feel it.
A well-run improvement process has exactly two endings. Both of them are genuinely good.
The turnaround. Sometimes the structured feedback, clear expectations, and regular check-ins are exactly what someone needed. They did not know the gap existed, or they knew but did not know how to close it, or they had lost motivation and the direct conversation was the reset. I have seen this happen more times than you might expect, and it never gets old. You often end up with someone who is not just back to baseline but actively better, because they now have clarity and support they did not have before.
The respectful exit. Sometimes, despite everyone's best efforts, the gap does not close. The engineer is in the wrong role, on the wrong team, or at the wrong company. A clear, well-documented improvement process makes this outcome less painful for everyone. The engineer knows exactly why the decision was made because they were part of the process at every step. There are no surprises. And because the process was fair, it is possible to part ways with dignity and genuine goodwill. That matters more than most managers realise, because the rest of the team is watching how you handle it.
The trap is treating the exit as a failure. It is not. Keeping someone in a role where they cannot succeed is the failure. A respectful exit gives them the honest feedback that their previous managers were too uncomfortable to provide, and it frees them to find a role where they can actually thrive. That is not cruelty. It is the most honest thing you can do for someone's career.
Here is what most guides on this topic miss: managing underperformance is not a private matter between a manager and one engineer. The whole team is affected, and the way you handle the process carries further than you think.
Your team already knows. This is the uncomfortable truth that managers consistently underestimate. Engineers talk to each other. They review each other's code. They know who is pulling their weight and who is not. When you avoid addressing underperformance, you are not protecting the team from an uncomfortable situation. You are confirming their suspicion that standards are optional, or that management is not paying attention. Research on team dynamics consistently shows that unaddressed underperformance is one of the fastest ways to erode trust in leadership.[4]
Do not discuss the details. While the team knows something is going on, they should not know the specifics. The improvement plan, the conversations, the timeline: these are confidential. If someone asks, the appropriate response is: "I'm aware of the situation and I'm handling it. I can't share details, but I want you to know it's not being ignored." That single sentence does more for team trust than months of avoiding the topic.
Watch for burden shifting. During an improvement period, there is a risk that work quietly redistributes to the rest of the team. If the underperforming engineer is taking on less complex work, someone else is absorbing it. Be explicit about workload distribution and make sure you are not inadvertently burning out your high performers to accommodate the process.
When someone exits, address it honestly. You cannot share the reasons, but you can acknowledge the departure directly and with warmth. "X is leaving the team. I want to thank them for their contributions and wish them well." Clean, honest, respectful. The team reads the tone more than the words.
If you have someone on your team right now who is underperforming and you have been putting off the conversation, here is what to do this week.
First, write down three specific, observable examples of the gap between where they are and where they need to be. Not feelings. Not impressions. Concrete instances with enough detail that the engineer would recognise them.
Second, schedule a one-to-one with enough time for a real conversation. Not fifteen minutes bolted onto a standup. At least thirty minutes, ideally forty-five, in a private setting.
Third, open the conversation with curiosity. Ask what is going on before you share your observations. Listen to the answer. Then be direct about the gap and what needs to change.
Fourth, leave the meeting with a written plan: what success looks like, what the timeline is, and when you will check in next. Share it with the engineer in writing after the meeting so there is no ambiguity.
The conversation will be uncomfortable. It always is. But the alternative, months of avoidance followed by a crisis, is worse in every dimension. For the engineer who deserves honest feedback. For the team who deserves to know that standards matter. And for you, because carrying an unresolved performance issue is one of the heaviest things in management, and putting it down starts with one conversation.
A note from fusecup
At fusecup, we work with engineering leaders who care about building teams where people do their best work. If you are dealing with a performance situation and want someone to think it through with, or if you are trying to build the kind of management practices that prevent these situations from escalating, we are always happy to have a conversation. No agenda, no pitch. Just honest thinking about what might work for your specific situation.
Uncertainty does not just slow teams down. It disconnects them from the work. The engineering leader's job during a pivot is not to pretend everything is fine. It is to create enough clarity that people can keep building while the bigger picture comes into focus.
You have read the case for fractional technical leadership. You understand the cost savings. What you still do not know is what the first eight weeks actually look like. Here is the work, week by week.
It is almost never just about the money. The engineers you most want to keep are leaving because of how they are managed, not how they are paid. The good news is that the three practices that make the biggest difference cost nothing. They just require consistency, honesty, and a willingness to treat growth as seriously as delivery.