“Bus factor” is an awkward term for a serious idea. It asks a blunt question: how many people would have to be hit by a bus — or, less dramatically, leave, fall ill, or simply quit in a huff — before your technology grinds to a halt? If the answer is one, you have a bus factor of one, and you are carrying an existential risk that is disguised as a perfectly normal staffing arrangement.
Most businesses with this problem do not know they have it, because nothing is visibly wrong. The systems work. The person is reliable. Right up until they are not there, at which point the business discovers exactly how much was resting on one set of shoulders.
Why it is so easy to end up here
A bus factor of one is rarely a decision. It accumulates. One capable person builds something, then maintains it, then becomes the only one who understands it because there was never a reason to involve anyone else. Knowledge that lives only in their head was never written down, because they were always there to answer the question. Over time, more and more of the business comes to depend on what that one person silently knows — and because they keep delivering, nobody notices the dependency forming.
Free · 4 minutes
If your most senior engineer left tomorrow, would anyone still understand the system?
Fourteen questions on documentation, dependencies, and the gap between how the architecture works and how many people know it. Banded finding on screen, full sheet by email.
It is not a sign of a bad employee. Usually it is the opposite — a good, dependable person who quietly became indispensable. That is exactly what makes it dangerous: there is no warning sign, because reliability is the symptom.
Why it is genuinely existential, not just inconvenient
The risk is not “it would be hard if they left.” It is that the loss of one person could stop the business from functioning, and that the loss can come without notice. People resign, get poached, burn out, fall ill. When the one person who understands a critical system goes, you are left with systems you cannot change, problems you cannot fix, and no one who knows how any of it works. The recovery is slow and expensive — a new person has to reverse-engineer what was never documented — and during that time the business is exposed. It is the quiet version of the crisis covered in your only developer just resigned, except you have not had even the courtesy of a notice period.
There is a related tell worth noticing: if there is a system everyone works around because only one person dares touch it, you are looking at the same risk from another angle — the situation described in the system nobody will touch.
How to find out if you have it
You do not need a long project to discover your bus factor. It comes down to a few honest questions, asked system by system. For each important part of your technology: if the person who looks after this left tomorrow, could anyone else keep it running, change it, or fix it when it breaks? Is what they know written down anywhere, or only in their head? Could a competent newcomer pick it up from documentation, or would they be starting from nothing?
Wherever the answer is “only one person can do this and it is not written down,” you have found a bus factor of one. The audit to establish this across a business typically takes about a day, and the result is a clear map of where the business is dangerously dependent on individuals.
What to do about it
The fix is not dramatic, and it does not mean replacing anyone. It means deliberately spreading what is concentrated: documenting the critical knowledge while the person is still there to share it, making sure access is held by the business rather than the individual, and involving a second person in the systems that matter most. It is also usually the moment to address the technical debt that made the system impenetrable to anyone but its author in the first place. None of this is expensive compared with the cost of finding out the hard way.
A bus factor of one is existential risk dressed as a staffing quirk, and an audit takes about a day to expose it. We will find out where your business depends on one person, and how to reduce that risk before it is tested.
Start a ConversationBuild and rescue work
Hands-on delivery of this kind is handled by Sixteen Pillars Studio.
Free interactive tool
Website compliance checklist
What your site has to do, based on what it actually does
Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.
Everything that applies
Ordered by what to do first: legal requirements you can close quickly, then larger pieces of work, then what is expected rather than required. Not exhaustive, and not a legal audit.
Dated PDF, yours to keep or circulate.
Can you trust the architecture you have?
Architecture diagrams rarely show the reality of how systems actually operate. An independent review establishes what is really there.