The Recovery Instinct That Creates a Second Problem

Years ago, I have cleared my calendar for a failing project and called it a recovery plan. It felt like the right call for about two weeks. Then the team stopped making decisions without checking with me first, and I realised I had become the bottleneck I was trying to fix.

Most project recoveries start this way. And most leaders do not notice the moment it stops being leadership.

The Cognitive Logic Behind the Behaviour

When a project is visibly failing, there is a specific kind of pressure that builds on the person at the top. Every status update feels unreliable, every milestone slippage raises the question of what else is being underreported, and the natural response is to go closer to the source. Stop relying on summaries. Attend the meetings. See the work directly. This feels like good judgement, and in some ways it is: the instinct to improve the quality of information you are working with is sound.

What makes it a trap is the underlying assumption.

Most leaders reached their position through a period where their direct involvement produced direct results. That muscle memory does not disappear when the job changes. It just gets misdirected.

When things go wrong, the brain reaches for the tool that worked before, which is personal, hands-on engagement with the problem.

The context has changed entirely, but the response has not.

There is also a structural accountability dynamic running underneath this. When a project is publicly failing, the leader feels exposed. Getting visibly closer to the work creates a defensible position: whatever happens, it cannot be said that they were not paying attention. That is a reasonable human response to an uncomfortable situation, and it shapes behaviour in ways that are rarely acknowledged openly.

Where Getting Closer Stops Helping

None of this means the right answer is to stay back. A leader who deliberately maintains distance from a burning project, on principle, is not demonstrating trust. They are avoiding the discomfort of engaging with something that is broken, and calling it a management philosophy.

Some direct contact is necessary. The question worth asking at the start is: what specifically am I trying to learn, and how will I know when I have learned it? That framing turns an open-ended takeover into a structured diagnostic.

You are looking for the point of failure, not managing the work. You want to understand whether this is a process problem, a capability gap, a dependency that was never properly resolved, or some combination. You also want to understand who on the team has an accurate picture of where things stand, because that person is rarely the one doing most of the talking in status calls.

The problem is that reading reports, attending calls, and reviewing outputs all generate a genuine sense of being informed, which makes it easy to keep going past the point where it is useful. That activity has to produce a decision: what is broken, what changes, who owns the fix. If weeks pass without that judgment being made, the diagnostic has drifted into something else, and the team starts to feel it before the leader does. Every additional status update, every decision that now requires sign-off from above consumes capacity the team does not have. Work that would take three hours takes five, not because anyone is working slowly, but because two hours went into keeping the leader informed.

The less visible cost is what happens to how the team thinks. When people learn that their calls will be reviewed and their estimates questioned, they stop making calls. They wait, send messages asking for confirmation on things they would have decided themselves the week before, and the leader, now absorbed in the detail, starts answering those messages. The dependency compounds quietly, and by the time it is visible the project has a new structural problem layered on top of the original one.

The Conversation Only You Can Have

Most failing projects have a structural problem sitting underneath the technical one, and it is usually the one that nobody has named out loud.

• A dependency that everyone knows is broken but that has been carried forward in plans anyway.

• A scope that has grown steadily because the right person was never told no.

• A delivery date that was set for reasons that no longer exist but that has never been formally revisited because doing so would require an uncomfortable conversation with someone senior.

The team knows these things. They talk about them. What they cannot do is resolve them, because resolution requires authority they do not have. The tech lead cannot tell the steering committee the deadline is not achievable. The project manager cannot push back on a VP who keeps adding requirements. These conversations require someone with enough standing to have them without it becoming a career event, and that person is usually the one who has spent the last three weeks reviewing tickets.

The shift that actually turns a recovery around is when the leader stops managing the work and starts managing the conditions around the work. Clearing a blocker that has been stuck for two weeks. Making a scope decision that everyone knew needed to be made but that nobody wanted to own. Having the timeline conversation that the team could not have. That is where the leverage is, and it is almost always underused because the pull towards the detail is so strong.

The Monday question is simple: what conversation are you avoiding that only you can have?