The Turnaround Playbook

Diagnosis: Understanding What Went Wrong

The first step is always diagnosis, not treatment. I spend my first two weeks doing nothing but listening and observing. I interview every team member individually, review the backlog, examine the codebase, and study the communication patterns.

Common symptoms include: unclear requirements, technical debt preventing progress, lack of automated testing, poor communication between product and engineering, unrealistic deadlines, and team burnout.

The key is identifying root causes, not symptoms. A team that's missing deadlines might seem like an execution problem, but often it's a planning or communication problem upstream.

The most useful tool in this phase is the individual, private conversation, and it works best when it genuinely reaches past the layer that normally summarizes reality for leadership. Filtered reporting is how organizations hide problems from themselves, usually without anyone intending it. When I ran this process as Fractional CTO at Realpad, the interviews surfaced something no status report would ever have contained: the lead engineer assigned to the company's top revenue priority did not personally believe that priority mattered. That is not a detail you find in a backlog.

Ask questions that are hard to answer with a slogan. What's the last thing that shipped smoothly, and why did that one go well? What would you change if nobody could veto you? What are we all pretending is fine? Where does your time go that feels wasted? You're not collecting a list of complaints. You're looking for the same underlying problem described five different ways by five different people, because that convergence is your root cause.

Be disciplined about not acting yet. The pressure to demonstrate value early is enormous, particularly as an outsider, and rushing past diagnosis is the single most common way I've seen turnarounds fail. A confident intervention built on three days of understanding will be wrong in ways that cost you exactly the credibility you'll need in month three.

Stabilization: Creating Immediate Wins

Once you understand the problems, resist the urge to fix everything at once. Instead, identify 2-3 quick wins that will build confidence and demonstrate that change is possible.

This might mean fixing a particularly annoying bug, automating a manual process that wastes hours every week, or resolving a long-standing technical debt issue that blocks other work.

The goal of this phase is psychological as much as practical. Teams that have been struggling need to remember what success feels like before they can tackle bigger challenges.

Choosing the right quick win is more constrained than it sounds. A good one has three properties: the team already agrees it's a problem, it can be finished in days rather than weeks, and the benefit lands on the people doing the work rather than only on stakeholders. Automating a deployment step the team performs manually eleven times a week qualifies. Rewriting a service does not, no matter how badly it needs rewriting.

Watch what these wins cost. A quick win that creates new debt, or that only one person understands afterwards, buys a week of goodwill and hands you a fresh problem. And resist taking credit for them. The wins have to belong to the team, because the entire point of this phase is rebuilding their belief in their own capability, not establishing yours.

Process Redesign: Building Sustainable Systems

With some momentum established, it's time to address systemic issues. I typically focus on three areas: planning, execution, and communication.

For planning: implement proper sprint planning with realistic capacity estimates, establish clear definition of done, and create a transparent prioritization framework that stakeholders understand.

For execution: introduce or improve code review processes, establish testing standards, and implement CI/CD if not already in place. The goal is to make quality the default, not an aspiration.

For communication: establish regular cadences for syncing with stakeholders, create visibility into progress through dashboards or reports, and foster direct communication between engineers and product owners.

A caution on how you introduce all of this. In a team that has been struggling, process arrives feeling like bureaucracy, and bureaucracy feels like blame. I've had the most success introducing rituals as agreements rather than rules, and only where the team can already feel the friction the ritual is meant to relieve. At Deepnote, the shift that mattered wasn't a framework I imposed. It was redefining velocity as a consistency metric rather than a speed one, which turned the process into something that protected the team from chaotic stakeholder intervention rather than something that measured them. The most durable form of this is a working agreement the team authors itself - at Deepnote the team agreed that code reviews would be finished within twelve hours, and a bot rather than a manager reminded people of their own promise.

Also, resist running every team the same way. A platform or infrastructure team and a product team need genuinely different delivery cultures. One runs on incident protocols, SLA definitions and technical debt windows; the other on user stories, design reviews and demos. Unifying the process across both looks tidy on an org chart and quietly kills the team whose working style you overwrote.

Alignment: Getting Everyone Pulling the Same Rope

Everything above assumes the team wants the change. Some of them won't. This is the part of a turnaround that most frameworks skip entirely, and it is the part that decides whether any of the rest survives contact with reality.

When you arrive and start changing how people work, a portion of the team will read it as a verdict on them. Not on the process - on them. You are implicitly saying the old way was wrong, and they built the old way, or at least lived inside it comfortably for years. That reading is almost never what you intended and it is almost always what somebody hears. Everyone on board needs to understand that you are not against them. You are trying to make the situation better for everyone, including the people who built what came before.

I have been on the receiving end of exactly this. When I introduced engineering metrics at Deepnote, the team's first reaction was not curiosity but something closer to a revolt: are you spying on us, and will we be fired if our stats drop? I had picked the right tool and had done nothing to prepare the ground for it. The fix was not a better dashboard. It was saying out loud what the measurement was for, promising it would never appear in a performance review, and handing the team the authorship of its own rules.

So find these people early and deliberately. They are not hard to spot once you are looking for them: the person who goes quiet in planning, the one whose objections arrive as jokes, the one who agrees in the room and relitigates in private messages afterwards. Left alone they do not stay neutral. Uncertainty and quiet resentment travel through a struggling team faster than any process change you introduce, and they travel in channels you cannot see.

Do not handle this in a meeting room. Take them out for a coffee, go for a walk, sit in a park, have lunch. The setting matters far more than people expect. A conference room with a calendar invite frames the conversation as management doing something to them. A walk frames it as two people talking. You want the second one, because you are about to ask someone to be honest with you, and that is not a thing people do across a table with a clock running.

Then tell them what you are genuinely excited about and why. Explain what is changing, and why you believe it is better than what came before. And here is the part that makes the whole thing work: name the things that will be worse for them, too. Not vaguely. Specifically. If you are introducing code review across team boundaries, say it plainly - this will take time away from your own programming, and that is a real cost to you. An honest inventory of the downsides is what makes the upsides believable. A pitch with no costs in it reads as a sales job, and people who feel sold to stop telling you things.

Then stop talking. Let them correct you. Let them tell you how they feel and what is actually wrong, about the change, about your read of the situation, about you. Some of what comes back will be right, and when it is you should say so out loud and adjust. This is not a technique for manufacturing compliance. It is how you find out what you got wrong from someone who has been living in this system considerably longer than you have. If you have already decided that nothing they say will change anything, do not have the conversation at all. They will know, and you will have spent the last credibility you had.

Where the discomfort is real and unavoidable, frame it honestly as a stepping stone rather than pretending it away. The same cross-team code review that costs you programming hours also puts another team's domain knowledge in your head. That makes you more valuable to the company and harder to replace, and it is exactly the kind of breadth that turns into a promotion conversation later. As the company grows and you take more of it onto your shoulders, you grow with it. That argument works because it happens to be true - which is also the only condition under which you should make it.

What these people need, more than they need to agree with you, is to be listened to and understood. Most resistance during a turnaround is not disagreement about the plan. It is the feeling of having things done to you by someone who showed up three weeks ago. Sitting with someone, hearing what they have been carrying, and being straight with them about what it will cost converts that feeling into something else entirely. You are not trying to win an argument. You are trying to give them a purpose inside what comes next, and a reason to believe that it is partly theirs.

Cultural Reset: Addressing Team Dynamics

Process changes alone won't fix a team that's lost trust or psychological safety. Cultural issues must be addressed directly.

I create forums where team members can voice concerns without fear of repercussion. I establish norms around blameless post-mortems and constructive feedback. I model vulnerability by admitting my own mistakes.

Often, teams have fallen into patterns of blame-shifting or learned helplessness. Breaking these patterns requires consistent modeling of better behaviors and celebrating when team members demonstrate the culture you want to build.

The most effective version of this I've run came after a round of layoffs, where the retrospective stopped being about tickets and became the only place people could say what was actually happening. It wasn't a grief circle, but it wasn't business as usual either. We established a no-bullshit zone: no taboos, no harm intended, but absolute honesty about the grim parts. Stripping away the corporate veneer rebuilt the team's spirit considerably faster than any morale-building event would have.

Understand that trust is rebuilt through consistency, not through vision. When people have been let down, a compelling speech about the future is evidence of nothing at all. Being the most predictable person in the room for three straight months is evidence. Reliable rituals do a lot of quiet work here, because they supply a sense of normalcy at exactly the moment everything else feels arbitrary.

Scaling Success: Making Changes Stick

The hardest part of any turnaround is making sure improvements persist after the initial intervention. This requires transferring ownership to the team.

I document everything we've changed and why. I identify "culture carriers" within the team who can champion the new ways of working. I establish metrics that make progress visible and create accountability.

Practically, this means replacing your presence with systems. You cannot attend every standup once you're responsible for more than one team, and attempting it is how a turnaround regresses the moment you look away. Identify lieutenants within each team and move your own rituals up a level, to something closer to a sync of syncs where you discuss blockers rather than status. Push documentation hard enough that a decision which wasn't written down is treated as a decision that didn't happen. In a fragmented organization that isn't bureaucracy, it's the only thing holding alignment together.

Agree on what finished looks like before you need the answer. Long change efforts drift, and without a defined milestone and an honest checkpoint they consume budget on momentum alone. I prefer releasing effort in short increments with an explicit review at each one: if the milestone isn't hit, funding pauses and we run a post-mortem rather than quietly continuing. Setting that up is an uncomfortable conversation, and it protects everyone in the room, including you.

By the time I transition out, the team should be self-correcting and capable of continuing to improve without external intervention.

Conclusion

Turning around a struggling engineering team is challenging but deeply rewarding work. The framework I've outlined here - Diagnose, Stabilize, Redesign, Align, Reset, Scale - has worked across different companies, team sizes, and technical stacks. The key is patience, empathy, and a commitment to addressing root causes rather than symptoms. But if I had to keep only one phase, it would be Align. Processes can be corrected in a sprint. A team that has quietly decided you are working against them takes far longer to recover, and usually you don't find out until the damage is already done.