This post is part of my Tech Lead Series, a collection of practical advice for engineers stepping into leadership roles.
Inheriting a struggling team is one of the hardest things a tech lead can face. The problems run deep and the trust is gone. But it’s also an opportunity. Teams in crisis have nowhere to go but up.
Understanding What You’ve Inherited
Before you can fix anything, you need to understand what’s actually broken. The symptoms are visible; the causes are usually hidden.
Talk to everyone. Schedule 1:1s with every team member in your first week. Ask open questions: What’s working? What’s not? What would they change? What do they wish leadership understood? Listen more than you talk. This is the same advice from your first 90 days, but compressed.
Read the history. Old retrospectives, incident reports, architecture documents, Slack history. What patterns emerge? What keeps going wrong? What decisions led to this point?
Understand the departures. If people left, find out why. Exit interviews if they exist, informal conversations if you can manage them. People leave struggling teams for reasons, and those reasons tell you what’s wrong.
Identify the real problems. The obvious problems are rarely the root problems. Technical debt is often a symptom of unclear priorities. Low morale is often a symptom of feeling unheard. Dig until you find causes, not just effects.
Find the bright spots. Even struggling teams have things that work. People who still care, processes that function, code that’s actually solid. Build on these rather than only focusing on what’s broken.
Quick Wins Matter
Struggling teams have often been promised turnarounds before. They’ve heard the speeches about change. They’re sceptical, and they should be.
Words alone won’t change their minds. Only action builds credibility.
Find something you can fix in the first two weeks. Something visible, something the team cares about. It doesn’t have to be big. Cancel a useless meeting. Fix the flaky test that everyone hates. Push back on an unreasonable demand from stakeholders.
The specific fix matters less than what it signals: things can change, and raising problems with you leads to action.
Building Trust
Trust is usually the deepest wound. The team has learned that leadership doesn’t deliver and that feedback goes nowhere.
You rebuild trust through consistent, small actions over time.
Do what you say. Every commitment you make matters. If you say you’ll follow up on something, follow up. If you say you’ll look into a problem, look into it. Dropped promises confirm that nothing has changed.
Be honest about what you can’t do. Don’t promise changes you can’t deliver. “I can’t fix the technical debt in a month, but I can protect time for us to address some of it” is honest. “I’ll fix everything” is a lie.
Admit what you don’t know. You’re new. You don’t understand everything. Pretending otherwise insults your team’s intelligence. “I’m still learning how this system works” builds more trust than pretending expertise.
Protect them. When unreasonable demands come from outside, push back. Let the team see you doing it. Nothing builds trust faster than watching your lead fight for you.
Follow through on feedback. When someone raises a concern, act on it or explain why you can’t. The worst thing is asking for feedback and then ignoring it.
Addressing Performance Issues
Struggling teams sometimes have performance issues that were never addressed. The previous lead was too busy firefighting or too conflict-averse to have hard conversations.
You need to address these, but carefully.
Don’t rush to judgment. People underperform in struggling teams because the environment enables it. Before concluding someone is a poor performer, give them a functioning team to perform in.
Separate environment from individual. Is this person struggling because they’re not capable, or because the context makes success impossible? Fix the context before judging the person.
But don’t avoid the hard calls. Sometimes performance issues are real and persistent. When you’ve given someone a fair chance and clear feedback and they still don’t improve, you have to act. Keeping non-performers hurts everyone else.
Be fair. The team is watching how you handle this. If you’re arbitrary or cruel, trust collapses. If you’re fair and clear, even difficult decisions can build credibility.
Fixing the Technical Mess
Struggling teams usually have struggling codebases. Tech debt, architectural rot, unclear ownership. This can’t be fixed quickly, but it can be managed.
Stop the bleeding. Before improving anything, stop making it worse. Establish minimum quality standards. No more shortcuts that create debt.
Make debt visible. Track it. Name it. Talk about it in planning. When the team understands the cost of debt, they’re more motivated to address it. I’ve written about reconsidering how we talk about tech debt elsewhere.
Carve out time. Protect some percentage of each sprint for debt reduction. It doesn’t have to be a lot. Even 10% adds up.
Celebrate progress. When a gnarly piece of code gets cleaned up, acknowledge it. Progress on debt is real work, even if stakeholders don’t see it.
Be patient. Technical messes take time to create and time to fix. Rushing leads to new messes. Steady, sustainable progress beats heroic sprints.
Communicating with Stakeholders
Stakeholders have learned not to trust this team. They’ve been burned by missed deadlines and broken features. Your job is to reset that relationship.
Be honest about where things stand. Don’t hide the mess. “We have significant technical debt that’s slowing us down and causing quality issues” is better than pretending everything is fine.
Set realistic expectations. Don’t promise a quick turnaround to look good. Set timelines you can actually meet. Rebuilt trust comes from kept promises, not optimistic forecasts.
Show progress. Regular updates on what’s improving. Delivered features, but also fewer incidents and better velocity. Make the recovery visible.
Ask for what you need. If the team needs time, resources, or protection from demands, advocate for it. Stakeholders can be reasonable when they understand the situation.
The Long Game
Turning around a struggling team takes time. Not weeks, but months. Probably six months before things feel genuinely different. A year before the turnaround is clearly sustained.
The early period is the hardest. You’re fixing problems that aren’t your fault and cleaning up messes you didn’t make. It feels thankless.
But teams that come through hard times together get strong. The engineers who stay through a turnaround are committed, and they don’t take things for granted.
The way up is hard, but it’s rewarding in ways that leading a comfortable team never is.
Published on .