The Most Dangerous Single Point of Failure Isn’t Technical

Throughout my career in enterprise technology, I have worked with organisations that invested significant time and money in identifying technical single points of failure.

Infrastructure was made redundant. Disaster recovery procedures were documented and tested. Monitoring was introduced to identify problems before they became outages. Recovery objectives were discussed, challenged and measured.

The underlying principle was sensible: every system will eventually experience failure, so resilience should be designed before that failure occurs.

What I have found interesting is that organisations do not always apply the same thinking to themselves.

Sometimes the most dangerous single point of failure is not a server, an application or a data centre. It is a person.

When indispensability becomes dependency

That does not necessarily mean the person has done anything wrong. In many cases, the dependency develops gradually and may initially look like a strength.

One person becomes the person who understands how a critical process really works. One executive relationship depends almost entirely on them. Important approvals begin passing through their inbox. When something becomes complicated, everyone knows who to call.

Over time, the organisation stops seeing this as a risk and starts describing the person as indispensable.

I have always been slightly uncomfortable with that word.

Exceptional people are valuable, but organisational dependency is not the same as exceptional performance. A healthy organisation should be able to benefit from someone’s expertise without becoming unable to function in their absence.

Visibility is not always value

The distinction matters because the person at the centre of every decision is not always the person creating the most value.

Sometimes they genuinely are outstanding. They may have built deep expertise, earned the trust of customers and colleagues, and repeatedly helped the organisation navigate difficult situations.

Sometimes, however, they are simply very effective at managing perception. Their visibility becomes confused with impact. Their involvement in every conversation is interpreted as evidence of importance, even when the dependency they have created slows decisions, weakens others and adds cost.

In those situations, the organisation may not have found its strongest performer. It may simply have allowed one individual to become the centre of the system.

The question that exposes the risk

A useful question is:

If this person left tomorrow, what would stop?

Not what would become temporarily more difficult. Any experienced person leaving will create disruption.

What would genuinely stop?

• Would customers lose confidence because no one else owns the relationship?
• Would decisions stall because authority was never distributed?
• Would teams struggle because critical knowledge existed only in conversations?
• Would projects lose direction because everyone had learned to wait for one person before moving?

When the answer reveals that large parts of the organisation cannot function without one individual, the issue is no longer succession planning alone. It is an organisational design problem.

Making dependency visible

One of the most practical ways I have found to understand these situations is to document how work actually happens.

Not how the official process says it happens. Not how the organisation chart suggests decisions are made. The real process.

When approvals, escalations, customer relationships and decision paths are mapped visually, patterns often become obvious very quickly. Every arrow may lead to the same person. Every exception may require the same approval. Every difficult conversation may depend on the same relationship. Every gap in the formal process may be quietly filled by the same individual.

A dependency that exists only in conversations is easy to dismiss. Once it is visible on paper, it becomes much harder to pretend it does not exist.

Documentation does not solve the problem by itself. It creates the opportunity to address it.

Leaders can then decide to distribute knowledge, share relationships, delegate authority, remove unnecessary approval points or develop others who can take ownership. Even if they choose not to act, the risk has at least been made explicit.

That matters because accountability often begins with visibility.

When the organisation chooses the risk

I have also seen situations where the dependency was documented, acknowledged and still allowed to continue.

In those cases, the accountability may exist only on paper and have little practical effect. The organisation knows the risk, but the willingness to change it is not there.

That may be because the individual is politically protected. It may be because senior leaders believe challenging the arrangement would create too much disruption. It may be because the organisation rewards control, visibility or loyalty more than resilience. In some cases, the informal power structure may even be working exactly as those at the top intend.

This is where the problem becomes more difficult than a simple process improvement exercise.

Removing a bottleneck is relatively straightforward when everyone agrees that it is a bottleneck. It becomes much harder when the dependency benefits influential people, protects existing relationships or reinforces an inner circle that controls information and decisions.

At that point, the organisation is not simply failing to recognise the risk. It may be choosing to accept it.

The uncomfortable leadership question

Technical teams rarely celebrate single points of failure. They design around them because they understand what happens when one component becomes too important to lose.

Organisations often do the opposite with people. They celebrate indispensability, concentrate knowledge and relationships, and only begin discussing resilience when someone resigns, burns out or becomes too powerful to challenge.

I do not think there is a universal solution to this.

Process documentation helps. Shared ownership helps. Meaningful succession planning helps. Leaders who actively distribute knowledge, authority and relationships create stronger organisations than those who concentrate them.

But none of those practices can compensate for senior leadership that sees dependency as useful rather than dangerous.

Perhaps the first step is simply being honest about what has been built.

If you mapped how work really happens in your organisation, where would all the arrows lead?