Once upon a time, a few months into his probation, a developer I had hired came back to me after a carefully designed round of onboarding sessions. I had built that onboarding so that no single person - certainly not me - would carry the weight of his ramp-up. Responsibility, on paper, was distributed.
He told me, kindly, that he had concluded the opposite. “You’re the sole point of failure of the entire system.”
That sentence has stayed with me longer than most performance reviews.
Two roads to indispensability
There are, in my experience, two ways a leader becomes operationally indispensable.
The first is the one nobody admits to: ego. The leader who fixes things personally because being needed feels good. Who holds context they should be writing down. Who says yes to every escalation because saying no would mean the work continues without them, and that is somehow intolerable.
The second happens when the system genuinely had no other choice. You arrive as the first internal engineer. There is no Tech Lead because there is no tech to lead. You make every architectural call, you are in every technical meeting, you review every requirement and implementation plan because you are the only person in the room who can.
I want to be careful here, because I have spent a lot of time telling myself the second story to avoid noticing the first is also a risk. The uncomfortable truth is that the two roads converge. Whatever route brings you in, the behaviours look the same after a year or two. You answer the Slack ping you should redirect. You fix the bug you should let someone learn from. You make a call that should have gone to a Tech Lead because it is faster, and you tell yourself it is just this once. Two roads, both potholed, both arriving at the same place. The leader who got there by ego will recognise themselves in this. The leader who got there by circumstance will protest. Both are right; both are stuck.
The small signals
Indispensability rarely announces itself. It accumulates quietly, and you notice it - if you notice it at all - on a Friday afternoon.
It arrives during the weekly planning session. You lay out the upcoming week and find yourself across teams, projects, and topics with nothing in common, somewhere between fifteen and twenty distinct points are either waiting for you or depending on you. Waiting for you.
The other signals are quieter. A meeting with ten invited colleagues gets postponed because you cannot attend, and three people request a 1:1 instead. A planned day off starts to feel like a betrayal, because your absence will slow down five different teams. A vacation has to be negotiated against production calendars in domains that were never designed to rest on one person. If a sick day feels like a fraud committed against the company, you are not loyal. You are trapped. The two states look identical from the inside, which is part of the problem.
What it does to the organisation
Knowledge in a healthy organisation is a network. Knowledge in an organisation with a sole backbone is a star, and the person at the centre is a structural risk dressed up as an asset.
The visible symptom is that decisions route through one desk. The less visible one is that processes start to name a specific person instead of a role. “We need to / should ask X first.” The moment a process names a human rather than a function, you have institutionalised the problem. Holiday cover becomes fiction. Onboarding documents reference a person who, in three years, may not be there. The company has built a load-bearing wall out of one biography.
Teams adapt to this rationally. They stop developing the muscle to make calls without checking. Peers stop challenging decisions because the backbone will be there at 2am on a Sunday and they will not, so it is easier to defer. The asymmetry is not malicious; it is the predictable response to the incentives. But it is corrosive.
What it does to the architecture
The architectural cost is the one most pieces on this topic skip, and still is one I find equally interesting.
Unchallenged decisions accumulate. When the same person makes most of the calls, peer review degrades - not because people are lazy, but because they are reading the room correctly. You hired smart people after all, they know - implicitely - what’s going on. Why argue with the architect at 4pm on a Thursday when you know they will be the one merging the production fix at 2am? So they don’t. The architecture ends up reflecting the taste, the blind spots, and the unspoken assumptions of one single mind.
ADRs get skipped. The backbone knows what they are doing - or thinks they do - and writing it down feels like overhead when there is no one to disagree with. Three years later, no one - including the backbone - can reconstruct why this service talks to that one in exactly this shape.
Then there is the bypass pattern. The backbone gets named explicitly as the secure channel, the emergency button, the person who can override the rules when the rules are inconvenient. Everyone understands this is for emergencies. Everyone slowly forgets what counts as an emergency. The bypass becomes the path. Worst of all, the backbone starts to trust their own override more than the system - because in their experience, the override has always worked. That is the moment, retrospectively, that scares me most. It is the moment you stop being a leader and start being a single point of failure with administrative privileges.
What it does to the team
A team led by someone who fixes things personally does not develop. It cannot. The Tech Lead who never gets to make the call does not become a Tech Lead; they become a senior engineer with a title. The mid-level engineer who never gets to own a hard problem stays mid-level. The team learns to wait, because waiting works.
This is not a failure of the team. It is the predictable outcome of a system in which the highest-leverage move is always to escalate. People are not stupid. They optimise for the gradient they are given.
What it does to the person
The first thing you lose is the ability to rest. Not the right; the ability. A weekend stops being a weekend because five threads are still open in your head and you know that on Monday morning the queue will have grown. A vacation stops being a vacation when the pre-leave handover takes a week and the catch-up takes another. Eventually you stop taking the vacation, or you take it and check Slack three times a day, which is worse.
The second thing you lose is the ability to distinguish your role from yourself. When the company is, in some meaningful sense, depending on your continued presence, “I am tired” and “the company is at risk” become the same sentence. That is not a healthy place to live. It is also not a place from which good decisions get made.
I have not burned out, but I have walked the perimeter of it long enough to know the geography. The leaders who tell you they are fine while running this pattern are, in my experience, lying - to you, but mostly to themselves.
How you get out
The way out is not personal heroism, and it is not just delegation. Delegation is a verb people use when they want to feel like they are addressing the problem without addressing it. The way out is structural.
You change the system so it cannot route through one person, even if that person volunteers.
Concretely: you move decision rights out of your desk and into named roles, in writing. You build the Tech Lead and Team Lead layer deliberately, and you give them real calls to make - including ones you would have made differently. You set up guilds and structures where decisions happen in rooms you are not in. You document what was in your head, and you treat that documentation as a leadership artifact, not as overhead. You set WIP limits on yourself, borrowing unironically from Kanban: if you are personally working on more than two or three things, you are hoarding capacity that should belong to someone else or you should start saying no, so that the organization can optimise for the right gradient.
And - this is the hard part - you practice not being available. You let the Slack ping sit for two hours. With discipline, like a anti-anxiety therapy. You let the meeting happen without you. You let the decision get made by the people whose decision it should be, even when you would have made it slightly differently. The discomfort of watching that is part of the work. If it does not feel slightly wrong, you are still the backbone.
The Tech Leads I have grown are, by some distance, the leadership achievement I am proudest of. Not because I taught them anything specific, but because they took calls I used to take, the calls were as good or better, and the system kept running on weeks I was on holiday. That is the metric. Not output. Continuity in your absence.
Strategic, not operational
The framing that finally helped me was this: a leader’s job is to be indispensable, but in a specific sense.
You should be indispensable strategically. The vision, the accountability, the cross-functional bridge, the difficult conversations, the calls that genuinely require your seniority - that is the job, and it does not delegate cleanly.
You should not be indispensable operationally. Nobody should need you to merge a PR, approve an expense, unblock a deployment, or answer a question a documented process should answer. The day-to-day must run without you, for weeks at a time, without anything cracking. That is the test.
The leader who does this well becomes a kind of invisible glue. Present in the architecture of the organisation, but absent from its daily operations. The team functions. The systems hold. The decisions get made. And the leader, on a Friday afternoon, plans a week in which they are needed for three things instead of thirty.
I am still learning how to 100% be that kind of leader. I suspect most of us are. The Unbeareable Heaviness of Being the Sole Backbone is, in the end, a weight you put down by building a structure that does not require you to carry it.
The structure is the work.