Handling Underperformers as a Tech Lead: A Fair, Direct Approach

No part of technical leadership is harder than dealing with an underperforming team member. It is emotionally draining, legally sensitive, and has consequences for the entire team regardless of the outcome. I have handled this situation approximately 15 times in my career, and it never gets easy. What does get easier is the process: recognizing underperformance early, diagnosing the root cause, addressing it directly, and following through with fairness and consistency.

Here is what I wish someone had told me the first time I had to handle an underperformer.

First: Make Sure It Is Actually Underperformance

Before you label someone an underperformer, verify that the problem is real and not a perception issue. Ask yourself these questions:

• Are expectations clear? If you never explicitly told this developer what "good performance" looks like, they might be meeting their own expectations while failing yours. That is a communication failure, not a performance failure.
• Are they set up for success? Does this person have the tools, access, context, and support they need? A developer assigned to an unfamiliar codebase with no documentation and no onboarding buddy is not underperforming. They are unsupported.
• Is the comparison fair? If you are comparing a mid-level developer to your best senior, of course they look slow. Compare against the expectations for their level, not against your top performer.
• Is it a skill gap or a will gap? A developer who does not know how to write integration tests has a skill gap that can be fixed with training. A developer who knows how but refuses has a will gap that requires a different approach.

Diagnosing the Root Cause

Underperformance is a symptom, not a diagnosis. The root cause determines the treatment. Here are the common causes I have encountered:

Skill Gap

The developer does not have the technical skills the role requires. This is the most fixable cause. Solution: create a targeted development plan with mentoring, pair programming, and specific learning goals. Give them 2-3 months to close the gap. Most people improve significantly with structured support.

Misalignment

The developer is talented but in the wrong role or on the wrong project. A backend developer struggling with frontend work. A detail-oriented person overwhelmed by ambiguous projects. Solution: explore whether a different assignment, team, or focus area would be a better fit. Sometimes the best solution is a lateral move, not a performance plan.

Personal Issues

Divorce, health problems, family crisis, mental health struggles. These are real and they affect work. Solution: be human. Ask "Is there anything outside of work that is affecting you right now?" Offer flexibility, reduced expectations temporarily, and point them to whatever support your company provides (EAP, flexible schedules). Do not pry for details. Just create space for them to tell you what they need.

Motivation Decay

The developer was once excellent and has gradually disengaged. They are bored, burnt out, or have lost faith in the project, the company, or their leadership. Solution: have an honest conversation. "I have noticed a change in your engagement over the past few months. What is going on?" Sometimes the fix is a new challenge. Sometimes it is hearing that their work matters. Sometimes the relationship is simply over and they need to move on. Read about burnout prevention as it may be related.

Attitude Problem

The developer is technically competent but difficult to work with: dismissive in code reviews, resistant to feedback, undermining decisions, or creating a toxic atmosphere. This is the hardest cause because it feels personal. Solution: direct feedback with specific examples and clear consequences. "In the last three code reviews, you dismissed your colleagues' suggestions without explanation. This is undermining collaboration. I need to see constructive engagement starting immediately."

The Performance Conversation

Once you have diagnosed the root cause, you need to have the conversation. This is where most tech leads fail, not because they do not know what to say, but because they avoid saying it.

Prepare Before the Meeting

• Document 3-5 specific examples of the performance issue with dates and impacts
• Define what "improved performance" looks like in concrete, measurable terms
• Check in with your manager and HR before the conversation (they need to know)
• Plan the conversation but do not script it word-for-word; you need to listen

The Conversation Framework

1. State the problem directly. "I want to talk about your performance over the last 6 weeks. I have concerns, and I want to work with you to address them."
2. Share specific examples. "In the last sprint, the search feature took 8 days instead of the estimated 3. The authentication PR had 4 bugs caught in code review. The incident response on Thursday was delayed by 2 hours because the runbook was not followed."
3. Ask for their perspective. "What is your view of how things have been going?" Listen. Genuinely listen. They might share context that changes your understanding.
4. Agree on a plan. "Here is what I need to see over the next 4 weeks: [specific, measurable goals]. I am going to support you with [specific support]. Let us check in weekly to track progress."
5. Be clear about consequences. "If we do not see improvement by [date], we will need to escalate this to a formal performance improvement plan." Do not threaten. State facts.

The Informal Improvement Period

Before a formal PIP (Performance Improvement Plan), I always try a 4-6 week informal improvement period. This gives the developer a genuine chance to improve without the stigma and pressure of a formal process.

During this period:

• Meet weekly to review progress against specific goals
• Provide feedback in the moment, not just in weekly meetings
• Offer concrete support: pair programming, reduced scope, clearer specifications
• Document everything in writing (send a meeting summary after each weekly check-in)

In my experience, about 60% of underperformers improve during this informal period when the expectations are clear and the support is genuine. The other 40% either do not improve or do not sustain the improvement. For those cases, you move to formal processes.

When to Escalate

If the informal improvement period does not produce results, involve your manager and HR to initiate a formal PIP. This is not your decision alone and should not be. A formal PIP has legal and HR implications that need professional guidance.

Your role during a formal PIP is the same as during the informal period: provide clear expectations, regular feedback, genuine support, and honest evaluation. Document everything.

The Impact on the Team

Here is what many tech leads forget: underperformance is not a private matter. Your team sees it. They see the missed deadlines, the buggy code, the lack of engagement. And they watch how you respond. If you ignore it, they conclude that performance does not matter. If you address it fairly, they conclude that standards are real and leadership is credible.

You do not need to share details with the team. A simple "I am aware of the situation and I am addressing it" is sufficient if someone raises concerns. What matters is that they see action, not the specifics of what that action is.

Handling underperformance is one of the most important things you do as a leader. Not because firing people is fun (it is not) or because difficult conversations are enjoyable (they are not), but because your team's trust in your leadership is directly proportional to your willingness to address problems that everyone can see. Avoiding the conversation is not kindness. It is a failure of leadership that harms the underperformer, the team, and yourself.

When Someone Needs to Leave

Sometimes, despite genuine effort and support, a developer does not improve. When that happens, the kindest thing you can do is be honest. "Based on the last 3 months, this role is not the right fit. Here is how we can handle the transition in a way that respects you and gives you the best path forward."

Letting someone go is never easy. But keeping someone in a role where they are failing is not kindness. It is prolonging discomfort for everyone involved. The developer deserves to find a role where they can succeed. Your team deserves to work with colleagues who pull their weight. And you deserve to lead a team that meets its commitments.