Most organisations know what a single point of failure is when it sits in a server rack. Very few have noticed that the most expensive one in the building is a person, and that the person is usually the one running the place. A company where every decision waits for the leader is not a fast company: it is a company with a bus factor of one, growing no faster than one human calendar, and worth less than it thinks on the day someone asks what remains without him. This piece is about how that structure builds itself, what it actually costs, and why getting out of it is a structural job rather than a motivational one.
Every organisation has a bus factor, and most leaders never compute their own
The bus factor is the smallest number of people whose sudden absence would stall the work. Engineering teams have used the idea for decades, usually about a developer who is the only one who understands a critical component. Wikipedia’s entry on the concept notes that it is a close relative of the older key person risk, the difference being that key person risk was framed around financial and managerial executives while the bus factor was framed around technical knowledge.
That split is convenient and wrong. The two risks are the same risk, and in most mid sized companies they have merged into one person.
Run the calculation honestly for a moment. Not on your most senior engineer. On yourself. Which decisions cannot be made this week if you are unreachable? Not the decisions you would like to be consulted on. The ones that physically cannot be taken without you, because nobody else holds the context, the authority, or both.
In the companies I work with, the answer is rarely small. Tool selection. Vendor renewal. Whether to rebuild or patch. Whether to sign three years or one. Which incident is serious and which is noise. Which internal request is a real priority and which is someone’s pet project. Taken one at a time, each is a two minute call. Taken together, they are the entire steering of the technical side of a business.
A bus factor of one is tolerable in a side project. In a company with employees, customers and contracts, it is a structural defect that has simply not been named yet.
Centralising on the leader is an economy before it becomes a liability
The structure is not a mistake, which is exactly why it is hard to dislodge. It is an optimisation that was correct at the time and was never revisited.
Early on, a company has no slack. Explaining a decision costs more than making it. Checking someone else’s judgment costs more than exercising your own. The founder decides because the founder deciding is genuinely the cheapest available mechanism. The organisation saves the coordination overhead that a larger company has to pay.
Ichak Adizes built an entire lifecycle model around what happens next. In his account of the early stages, founders are their companies and the companies are their founders, and the critical transition is the one where the organisation has to acquire administrative systems and a leadership role that does not depend on any single person. A company that cannot build those is, in his words, in the founder’s trap. Mark Rittmanic, writing on the same model, described the trap as beginning when the organisation cannot separate itself from dependency on the founder, and noted that the usual symptom is a founder who announces delegation and then adds that people should ask before engaging anything significant.
That addendum is the whole problem in one sentence. Delegation with a right of recall is not delegation. It is a queue with a friendly interface.
What makes the trap durable is that it never presents itself as control. It presents itself as speed. Nobody inside the company experiences the leader as a bottleneck in the moment: they experience him as the fastest way to get an answer. The people who could have learned to decide stop proposing, not out of passivity, but because they have observed that proposals get re-decided. The leader observes that nobody proposes anything, which confirms that he has to keep deciding. The loop closes without anyone acting in bad faith.
By the time it is visible, the dependency is not a habit. It is the architecture.
The cost shows up in four places, and none of them is the P&L
This is the part that gets skipped, because the cost of a leader-centred company is real and almost entirely invisible to accounting.
It shows up in the calendar. The queue in front of the leader is not measured in his hours, it is measured in the waiting time of everyone behind him. A decision that takes two minutes to make routinely takes three weeks to reach, because it has to find a slot in one person’s week. Multiply that across every pending technical arbitration in a company and you get a permanent latency that nobody books anywhere.
It shows up in growth. The company cannot outgrow one person’s bandwidth. This is the cruellest part, because the standard response is to hire, and hiring does not move the constraint. New people generate more decisions, which arrive at the same desk. Capacity goes up, throughput does not. Leaders in this position often describe the feeling as running harder for the same output, and attribute it to the market.
It shows up in resilience. A week of genuine unavailability does not slow one project down. It stops everything that needed an arbitration during that week, and the restart is not free: the decisions come back in a pile, out of context, and get made faster and worse than they would have been. The organisation has no continuity plan for its most loaded component, and would never accept the same situation for a piece of infrastructure.
It shows up in what the company is worth. Any serious acquirer, investor or successor asks the same question in some form: what survives if this person leaves? If the honest answer is that the technical direction of the business lives in one head, with no written mandate, no decision thresholds and no second judgment trained, that answer is priced. Not as a discount on a number: as a condition, an earn out, a lock in. The leader who spent fifteen years being indispensable discovers that indispensability is a liability on the one day it matters most.
I will not put figures on any of this. Every number I could offer would be invented, and an invented number is worse than no number. The cost is real and it is measurable inside a given company, by the company. It is simply never measured.
A services company that ran on one head
What follows is a composite. The details are changed, the sector is generic, and no single organisation is being described. The pattern is not a composite: it is the one I see most often.
A B2B services company, a little under two hundred people, fifteen years old, profitable, the kind that is known in its region and unknown outside it. The founder still runs it. He is not technical, has never claimed to be, and is unusually clear eyed about it. He hired well on the technical side: an IT manager with real seniority, two systems people, a long standing integration partner for the core platform.
Nobody would have described the company as dependent on him for technology. He would have been the first to say he knew nothing about it.
Then he spent six weeks almost entirely outside the business, working on an acquisition in another country. Not an emergency, not an illness, a planned absence that any healthy company should absorb without noticing. He delegated carefully before leaving: budgets, client relationships, signature authority up to a threshold, an explicit instruction that normal business should continue.
Here is what the six weeks produced.
A platform migration that had been prepared for months reached its go or no-go point in week two. The IT manager had the technical answer and did not have the mandate. The decision had commercial consequences for three large accounts, and nothing in writing said who could weigh that trade off in the founder’s absence. The migration did not fail. It waited. The partner’s team, booked and staffed for that window, waited with it.
A three year contract on a tool the company had already decided to leave came up for renewal in week three. Leaving required a decision about where to go instead, which required an arbitration nobody had the authority to make. The notice period expired. The contract renewed. The company is now paying for three more years of something it had collectively agreed to abandon, and the migration it was planning has been pushed behind that horizon.
A final round interview for a senior operations role was the founder’s. Scheduling it inside the six weeks was impossible. The candidate took another offer in week four. The role was re-opened and filled eight months later by someone else.
A vendor advisory landed in week five. It was not dramatic and it was not nothing: it required somebody to decide whether to take a service window immediately or wait for the scheduled maintenance slot. The IT manager flagged it, correctly, as a decision with business impact. There was no one to take it. It waited for the slot.
And two commercial conversations stalled, because the sales side could not say whether a particular integration would be supported, and the person who could say it was in another country doing something else.
None of these is a disaster. That is the point I want to make precisely. There was no incident, no outage, no loss anyone wrote down. The company had a good quarter. The founder came back, cleared the pile in four days, and told himself the business had coped well.
What actually happened is that a planned six week absence produced a locked three year contract, a missed hire that took eight months to replace, a delayed migration, a security decision taken by default, and two commercial opportunities that cooled. Every one of those consequences outlived the absence by a factor of ten or more.
And the structure that produced them was still exactly where it was before he left.
The detail I find most telling is what the company concluded. Not that the decision architecture had failed. That the absence had been too long. The remedy adopted was that the founder would stay more reachable next time. Which is to say: the company looked at a single point of failure, and decided to increase its uptime.
That is the normal response. It is also why the pattern is so stable. Every incident it produces reads as an argument for the leader being more available, never as an argument for the structure being wrong.
Execution was delegated, judgment never was
The case above is not a story about a founder who would not let go. He let go of a great deal. It is a story about what was and was not transferred.
Three things can be delegated and they are routinely confused.
Tasks are the easy one. Everybody delegates tasks, and delegating tasks is what most leaders mean when they say they delegate.
Authority is harder but still mechanical. It is a signature threshold, a budget line, a scope. It can be written down in an afternoon, and in the case above a good part of it had been.
Judgment is the one that does not transfer by decree. Judgment is the accumulated sense of which trade offs this company accepts, what was tried before, which risks are tolerable here and which are not, what the real reason was behind a decision taken four years ago. It lives in the leader’s head, it was never externalised because it never needed to be, and nobody else can exercise it because nobody else has the inputs.
This is why the standard remedies fail. You cannot org chart your way out of it: the chart says who holds a post, not what that post is allowed to settle on a Thursday evening when the leader is not answering. You cannot hire your way out of it either: a competent newcomer without the context produces decisions the leader will overrule, and after three overrulings the newcomer stops deciding. The structure regenerates itself around the new person.
The transfer of judgment requires two unpleasant inputs. The context has to be written down, which is tedious and feels like a waste of time to the one person who does not need it. And the successor has to be allowed to decide badly for a while, which is the only known mechanism by which judgment is acquired, and which the leader experiences as watching avoidable damage happen in slow motion.
Most leaders will do the first and not the second. The first alone changes nothing.
Getting out is a structural job, and the first months are worse than the status quo
Nothing about this is motivational. The leader in a founder’s trap does not lack will, he lacks a structure that makes his absence survivable, and structures are built, not decided.
Three pieces do most of the work.
Externalising the context. Not documentation in the IT sense: a written record of the decisions that constrain the present. What was chosen, why, what was rejected, what is reversible, what is locked by contract until when. The value is not archival. It is that a second person becomes able to reach the same conclusion the leader would reach, which is the precondition for anyone else deciding anything.
Writing the mandate rather than granting it verbally. Who decides what, up to what threshold, and without asking. Including the uncomfortable half: where the default answer is no, and what has to be true before it becomes yes. A verbal mandate collapses the moment the leader is unavailable, because nobody wants to be the person who guessed. A written one holds precisely because it does not require him.
Holding the gap while judgment is built. There is a window, usually measured in months, where the designated person’s decisions are worse than the leader’s and must not be overturned. Somebody has to absorb that window: review the reasoning rather than the outcome, catch the genuinely irreversible mistakes, and leave the rest alone. Doing this from inside the company is very hard, because inside the company taking the decision back is always the fastest option, and the fastest option is what built the trap in the first place.
The honest version of the timeline is that things get slower before they get better. The leader is spending time on externalising context on top of his existing load, decisions are being made less well than before, and nothing visible improves for a while. There is no version of this that feels like progress in month two. That is the actual reason most attempts stop, and it has nothing to do with the merits of the idea.
Four questions tell you whether this applies to you
I would rather leave you with a test than with a conclusion.
How long can you be genuinely unreachable before something stalls? Not before something is uncomfortable. Before something stops. If the honest answer is measured in days, you have a bus factor of one and you have simply been lucky with the weather.
Who has made a technical decision in the last quarter that you disagreed with, and that stood? If nobody has, no judgment is being transferred anywhere in your organisation, whatever your org chart says.
What is written down about why the current setup is the way it is? If the answer is nothing, then the context lives in one place, and that place takes holidays.
And the one that tends to land hardest: if someone bought your company tomorrow, what would they be buying that is not you?
A large tent held up by a single central pole is comfortable, cheap to build, and perfectly stable until the day somebody has to move it, repair it, or let it take the wind alone. The people underneath rarely look up at the pole. They have no reason to, right up until the moment they have every reason to.
Sources
- Bus factor, Wikipedia. Definition of the bus factor and its relationship to the older notion of key person risk.
- Single point of failure, Wikipedia. The engineering concept applied here to an organisational component.
- The Corporate Lifecycle: How Companies Mature (Adizes Model), Rework. Account of Ichak Adizes’ lifecycle model and of the founder’s trap at the Go-Go to Adolescence transition.
- Avoid the Founder’s Trap in Your Organization, Mark Rittmanic, Entrepreneur, 20 July 2016. Symptoms of the founder’s trap and the delegation-with-recall pattern.
- Adizes Corporate Lifecycle, Adizes Institute. Primary presentation of the lifecycle stages by the institute that maintains the model.
FAQ
What is the bus factor, and why does it apply to a CEO or founder?
The bus factor is the smallest number of people whose sudden absence would stall the work — originally used for engineers who are the only ones who understand a critical component, and a close relative of the older ‘key person risk’. In most mid-sized companies the two have merged into one person: the leader. To compute your own, ask which decisions physically cannot be made this week if you’re unreachable — not the ones you’d like to be consulted on, but the ones nobody else holds the context or authority to take.
Why can't a founder or leader fix a one-person bottleneck just by delegating tasks and authority?
Because three different things get confused under ‘delegation’: tasks (easy, everyone does it), authority (a written signature threshold or budget line, mechanical), and judgment (the accumulated sense of what trade-offs this company accepts and why past decisions were made). Judgment can’t be transferred by decree — it requires writing down the context that constrains the present, and then letting the successor decide badly for a while, which is the only known way judgment is acquired. Most leaders do the first part and not the second, and the first part alone changes nothing.
