Every project rescue I have taken on reaches the same moment. The evidence stops pointing at the codebase, the tooling or the backlog and starts pointing at a person. Usually someone well liked. Often someone senior. Sometimes the person who hired half the team.
Saying so is the hardest part of the job, and the way most people say it more or less guarantees it will not be heard.
What it looks like
A recent example, with the details removed. The team described itself as running Scrum. The person running the process pulled more tickets into every sprint regardless of velocity. There was no sprint goal worth the name, and every fortnight the committed scope carried over. Anyone in the room who understood Scrum could see the problem. When it was suggested, gently, that the team was really running something closer to Kanban, the suggestion was rejected on the grounds that the team does Scrum.
The underlying risk is simple to state. What happens when the person in charge of the process does not have the experience to govern it? The process has no brake, the team absorbs the overload, delivery slips, and eventually somebody like me is brought in to find out why.
The harder part comes next.
Why the business protects its point of failure
When the finding was raised, the people around that individual did not investigate it. They rallied round and protected them. From the outside it looks irrational: the organisation is shielding the thing that is holding it back. From the inside it usually makes sense, for one of four reasons.
History. The person has been there longest and has delivered before. Their track record is real, even if it was earned in a different role.
Sponsorship. Someone senior hired or promoted them. Admitting the person is struggling means admitting that decision was wrong, and the sponsor has more power than you do.
Visible effort. Points of failure are often the busiest people in the building. I wrote about this in the hero developer anti-pattern: the person who is always firefighting looks indispensable precisely because the system around them is broken.
Fear of the gap. If they go, who runs it? A known problem feels safer than an empty chair.
Understanding which of these is in play matters, because each one needs a different approach. Loyalty is dealt with differently from a sponsor protecting their own judgement.
Name the mechanism, not the person
The single most useful change I have made in how I raise these findings is this: I stop naming the person and start naming the mechanism.
"The sprint process is being run badly" is an accusation. Everyone knows who it is aimed at, and the defensive instinct fires immediately.
Compare that with: "Sprint scope is being set without reference to velocity. Over the last six sprints, committed scope has exceeded completed scope every time. Here is the burn-down." That is a finding about how work flows, backed by data the team produced itself. Nobody is being accused, so there is nobody to defend.
Everyone in the room will still make the connection. The difference is that they reach it themselves rather than having it forced on them, and people defend conclusions they were handed far harder than ones they worked out.
Go to the person first, privately
Before any of this reaches a wider audience, talk to the individual. In my experience a good number of them already know something is wrong. They may be exhausted by it. Some are relieved that someone has finally said it.
Then go to the sponsor, and frame it around protecting their decision rather than overturning it. "You put the right person in the role you hired them for. The role has changed since then, and it now needs experience they have not had the chance to build." That gives the sponsor a way to be right, which is often what unlocks the conversation.
Offer a route that is not an exit
Most points of failure are not bad people. They are in the wrong seat, or they were never given the training the seat needs. Removal is rarely the first answer and it should not be presented as one.
Options that usually work better:
- Change the process to match reality. If the team is actually running Kanban, call it Kanban and add work in progress limits. The person is suddenly running a process that fits what they do.
- Pair them with experience. An experienced delivery lead or coach for a fixed period, with a clear handback.
- Narrow the role. Keep the parts they do well and move the governance elsewhere.
A route that lets someone stay and improve is far easier for the business to accept than a recommendation that reads as "remove this person".
When they still will not listen
Sometimes none of this works. The finding is heard, understood and set aside.
At that point the honest position for a consultant or fractional CTO is to say it once, clearly and in writing. What the finding is, what evidence supports it, what I recommend, and the date I raised it. After that, the decision belongs to the business.
It is tempting to keep repeating it. Resist that. A finding raised every week stops being a finding and becomes background noise the organisation has learned to absorb.
What you can do is manage your own exposure. Be clear about which risks you are carrying, scope your own deliverables so they do not depend on the thing that is broken, and if the risk becomes unacceptable, say so and step back. That is professional, not petulant.
For the sponsor reading this
If someone from outside tells you that a respected person is the constraint, the discomfort you feel is not evidence that they are wrong. Ask them for the mechanism and the data. Checking costs you very little. Not checking can cost you the project.
If you are in the middle of this and would like a second opinion, I am happy to talk it through. No pitch, just a conversation if it is useful.
