Find Your Single Points of Failure: What Stops When You Are Not There

A single point of failure is any piece of work that stops entirely if you are unavailable. Not work that slows down, and not work that someone covers awkwardly. Work that stops.

Every senior leader has some. The question is whether you know what yours are, because the ones you have not named are the ones setting the ceiling on your team.

Why holding work feels like being valuable

Start with the reason this persists, because it is not laziness and it is not ego in the way people usually mean.

Being the person everything routes through feels good. It feels like being needed, being in the loop, being the one who can actually get things done. Every escalation is a small confirmation that you matter. From the inside, a dependency is nearly indistinguishable from importance.

The org chart says you lead a function. The workflow says you are a dependency inside it. Both can be true at once, and only one of them shows up in your title.

That is why single points of failure survive years of good intentions. They do not feel like a problem. They feel like being good at your job.

The gap you are manufacturing

Now the structural part, and it is the argument that should change what you do this week.

"It is faster if I just do it" is almost always true. It is also a statement about the past rather than a reason about the future.

The reason you are faster is that you have always done it. Every instance you handle yourself makes you slightly faster and leaves your team exactly where they were. The gap between your speed and theirs is not a fixed fact you discovered. It is something you are actively widening, one reasonable decision at a time.

Which means the cost of handing something off only ever goes up. The handoff you skip today because you are busy will take longer in six months, because by then the distance will be larger and the work will have absorbed more of your particular habits.

Delegation is not a productivity technique. It is maintenance on a gap that grows by default.

The unplanned week test

Here is the diagnostic, and the wording matters.

What would stop entirely if you were unavailable for one full week, starting tomorrow, with no notice?

Not a planned vacation. Planned absence hides dependencies, because you prepare for it. You write the handover doc, you pre approve the things you know are coming, you tell three people what to watch. The preparation is exactly the work that conceals what would otherwise break, which is why executives come back from two weeks off convinced their team is fine.

Unplanned is the honest version. Nobody prepared. Whatever stops, stops.

Write the list. For most senior leaders it runs to somewhere between four and ten items, and about half of them are surprises.

Four kinds of single point of failure

The list is more useful once you sort it, because each type has a different fix and people tend to apply the wrong one.

Knowledge. Only you know how something works, where it lives, or why it was built that way. Common with legacy systems, old vendor relationships, and anything you personally set up. The fix is documentation, which is boring and works. Not a polished runbook. A page that lets a competent person get started.

Authority. Only you can approve it. Nothing about the work requires you, but the permission does. The fix is decision rights, not documentation. Writing down how you would decide is useless if the person still has to wait for you to actually decide.

Relationship. Only you have the relationship. A key customer, a board member, a counterpart in another function who will only take your call. The fix is a deliberate second introduction, made while nothing is wrong. Introducing someone during a crisis reads as escalation. Introducing them during a quiet quarter reads as normal.

Access. Only you have the credential, the seat, the login, the signing authority. The fix is provisioning, and it is usually the fastest item on the whole list. It is also the one most likely to still be there in a year, because nobody's job is to notice it.

Most executives assume all their dependencies are knowledge problems and reach for documentation. Sort the list first. Documentation will not fix an authority problem, and a runbook cannot make a customer trust someone new.

Tasks come back, outcomes do not

There is a mechanism underneath most failed delegation, and it is not about picking the right person.

Delegating a task means handing over instructions. Delegating an outcome means handing over the goal and the authority to reach it.

Tasks come back. They come back because instructions never cover the case that actually arises, and when the person hits the gap, the only move available is to return to you. You experience this as the work bouncing, and you draw the reasonable conclusion that delegation does not work here. So you delegate less. So the gap widens. So it works even less well next time.

Outcomes do not come back the same way, because when the unexpected case arrives, the person has the authority to handle it. They may handle it differently from you. That is the trade.

The test of a handoff is not whether it went out cleanly. It is whether it came back.

The moment a handoff dies

At some point in the first month, someone will reach the outcome you asked for by a route you would not have chosen.

What happens next decides whether anything you did here holds.

If you correct the method, you have taken the work back without saying so. The person now understands that they own the outcome and also the process, which means they own neither, which means the next ambiguous moment comes to you. Nothing about this requires you to be harsh. A mild "next time, maybe try it this way" is enough to do it.

If you let the method stand and only engage where the outcome missed, the handoff survives. You will find this harder than it sounds, particularly for work you used to do well.

Delegating outcomes means accepting methods you would not have chosen. That is not a side effect of delegation. It is what delegation is.

The cost nobody puts on a slide

One more reason to take the list seriously, beyond your own capacity.

Your single points of failure are also your team's ceiling. Whatever you hold, they never learn. The person who could have grown into that work stays exactly where they are, and after a while the strong ones notice that the interesting problems never reach them.

Good people do not usually leave because of workload. They leave because the work stopped teaching them anything. A leader who holds too much produces that outcome reliably and never sees the connection, because the resignation conversation is always about something else.

How to tell if Distribution is your constraint

The signature is distinct from the components upstream of it.

If your time is reasonably protected, your inflow is manageable, and decisions clear at a decent pace, but the honest answer to the unplanned week test is a long list, the constraint is here.

If instead you cannot even get to the handoffs because your week is fragmented, look upstream at your attention, or further up at what is reaching you in the first place. Being overloaded and being a bottleneck feel similar from the inside and have different causes.

The fastest way to tell the difference: ask whether your problem is that you have too much to do, or that too much cannot happen without you. Those are different sentences and they point in different directions.

FAQ

What counts as a single point of failure? Work that stops entirely in your absence, rather than work that merely slows. If someone else can carry it badly for a week, it is a risk but not a single point of failure.

How many should a senior leader have? Two or fewer is a reasonable target. Zero is unrealistic and probably means you have stopped doing anything that requires your judgment.

Is not some key person dependency normal? Yes, at the level of genuine judgment. The problem is the accumulated set of approvals, credentials, and relationships that require you for no reason other than history.

What if my team genuinely cannot do the work? Then the capability gap is the constraint, and closing it is your job rather than a reason to route around it. Worth checking honestly whether the gap is real or inherited from never having tested it.

How long does this take to fix? The access items take a day. Documentation takes a few weeks. Relationships take a quarter, because they need normal occasions rather than manufactured ones. Authority is the fastest of the meaningful ones, which is why decision rights are usually the first thing to write down.

Bob Stanke is a Chief of Staff, the role companies create when an executive's operating system has outgrown them. He writes about the operating layer of executive work: what reaches you, where your attention goes, how decisions clear, and what leaves your desk.

The Executive Operating Index scores all four components in about five minutes and tells you which one is actually binding. Take the assessment.