bus factor concept in black and hot pink editorial style, Amelia S. Gagne
Lessons Learned • 8 min read

The Bus Factor: What Happens If Your Key Person Disappears

In a study of 133 popular open-source projects, 46 percent had a bus factor of one, meaning a single person held enough of the knowledge that the project would stall if they walked away, and 65 percent had a bus factor of two or fewer (Avelino, Passos, Hora and Valente, 2016). The bus...

In a study of 133 popular open-source projects, 46 percent had a bus factor of one, meaning a single person held enough of the knowledge that the project would stall if they walked away, and 65 percent had a bus factor of two or fewer (Avelino, Passos, Hora and Valente, 2016). The bus factor is the minimum number of people who would have to disappear before work grinds to a halt. Most small businesses have never counted theirs, and the number is almost always lower than they hope.

A single lit desk in a dark empty open-plan office, illustrating bus factor and key-person risk
When one desk stays lit after everyone else has gone home, the business has a bus factor problem it can feel but rarely measures.

The name comes from a blunt thought experiment: what happens if the one person who understands the payroll export, the DNS records, or the client history gets hit by a bus? The morbid framing is the point. It forces a question owners avoid because the answer is uncomfortable. I study behavioral psychology because that avoidance is predictable, and because naming the risk calmly is the first step to reducing it.

What the bus factor actually measures

The bus factor, also called the truck factor or lottery factor, is defined as the minimum number of team members who have to suddenly leave before a project stalls for lack of anyone who knows how it works (Wikipedia: Bus factor). The term traces to 1994, when a Python contributor asked what would happen to the language "if Guido was hit by a bus."

A bus factor of one is the danger zone. It means there is exactly one person who can do a critical thing, and no written trail, no second set of hands, and no way to recover the knowledge quickly if they are out sick, on vacation, or gone for good.

What makes this measure useful is that it is specific. It is not a vague worry about "being too dependent on Sarah." It is a countable number, per function, that you can raise deliberately. Payroll might be a one. Deployments might be a one. Knowing which client prefers which invoice format might live entirely in one inbox.

Why almost every small team has a bus factor of one

Concentration of knowledge is not a failure of discipline. It is the natural result of getting work done fast. The person who built the system understands it best, so the next related task goes to them too, and the gap between what they know and what everyone else knows widens with every efficient decision.

The research bears this out. The same open-source analysis found that fewer than 10 percent of systems had a bus factor above ten, so high concentration is the norm even in projects with many contributors (Wikipedia: Bus factor). If well-resourced software teams drift toward single points of failure, a two-person or five-person business will drift there faster.

There is a psychological pull underneath it. Being the only one who can do something feels like security. It looks like job protection and like value. The uncomfortable truth is that indispensability is fragility wearing a flattering outfit, and it is fragile for the owner as much as for the specialist. This connects to a pattern I have written about in what I stopped outsourcing and what I will never build in-house: the goal is not to hoard capability, it is to place it where it survives.

The cost is not the emergency, it is the slow drag

Most owners picture bus-factor risk as a sudden crisis: someone quits, and the wheels come off. The more common cost is quieter and continuous. When knowledge lives in one head, everyone else spends time waiting for it or recreating it.

Panopto's Workplace Knowledge and Productivity Report, a study of more than 1,000 workers, found that 42 percent of the knowledge needed to do a job is unique to the individual who holds it, not shared with anyone else (Panopto, 2018). The same research found workers lose an average of 5.3 hours a week waiting on information from a colleague or reconstructing something that already exists but was never written down.

Gartner reached a similar place from a different angle, reporting that more than half of digital workers struggle to find the information they need to do their jobs (Gartner, 2023). A bus factor of one is not a rare catastrophe you insure against. It is a tax you pay every ordinary week, and it compounds.

How knowledge concentrates, and how to distribute it

The mechanics are simple to draw. On one path, a task goes to one person, that person becomes the silo, and the silo becomes a single point of failure. On the other path, the same task is documented and shared, so the knowledge lives in the system rather than in one person, and the loss of any individual is survivable.

Diagram contrasting a bus factor of one with a distributed, documented team
The same work, two structures: one concentrates risk in a person, the other distributes it into documentation and shared practice.

The distinction matters because the fix is not "hire more people." Adding headcount to a business that documents nothing simply creates more silos. The lever is where the knowledge lives, not how many people you employ. We run Kief Studio as a two-person studio, and the way we protect against key-person risk is described in the two-person studio model: systems carry the load that a larger org would spread across staff.

This is also why data governance is the real prerequisite for AI. You cannot automate or delegate a process that only exists as intuition in one person's head. Distribution has to happen at the level of documented, structured knowledge before any tool can help.

Documentation is the cheap insurance

The single highest-return move for raising a bus factor is writing things down, and it is undervalued precisely because it feels like overhead. The cost of documentation is a few hours now. The cost of its absence is those 5.3 hours a week, spread across everyone, forever, plus the tail risk of a departure you cannot recover from.

Good documentation is not a binder no one reads. It is the runbook for the three things that would hurt most if the person who does them were unavailable: how money moves, how the site stays up, and how a client is served. Start there, not with an exhaustive wiki. The point of institutional memory that survives turnover is that the memory lives outside any single skull.

Documentation also decays, which is why writing it once is not enough. This is the same discipline behind the idea that automation maintenance is the job, not the launch: a runbook that describes last year's process is a trap, not a safeguard. A documentation-first habit, close to what async-first working demands, keeps the written record current because the written record is how work actually gets coordinated.

Cross-training without doubling your headcount

Documentation raises the floor. Cross-training raises the ceiling. A written runbook lets a second person recover a process under pressure; a second person who has actually run it can do so calmly. The two together move a function from a bus factor of one to a bus factor of two, which is the difference between fragile and merely thin.

You do not need to duplicate every role to do this. The software teams in the truck-factor research raised resilience through practices that fit any size: pairing on a task occasionally, reviewing each other's work, and rotating who owns a recurring job (Wikipedia: Bus factor). A quarterly "you run it this month" rotation on invoicing or deploys spreads knowledge without adding a salary.

Managed operations are one way small businesses buy a higher bus factor without hiring, which is much of what LTFI exists to provide: the person who knows how the system runs is not your single point of failure when the system is run as a documented service. The same logic informs how we think about building systems before you need them, because the calm time to raise a bus factor is long before anyone is missing.

Raising your bus factor without slowing down

None of this requires fear, and none of it requires stopping to build bureaucracy. It requires one honest inventory: list the handful of things that would genuinely stall if a specific person were unreachable for two weeks. That list is short. It is almost always shorter than owners expect, which is the reassuring part.

For each item, pick the cheaper of two moves: write the runbook, or teach one other person. Neither takes long, and both convert a hidden liability into a boring, documented, survivable process. Secure and resilient operations are a byproduct of building this way, not a separate project you bolt on later.

The bus factor is worth measuring because it turns an anxiety you cannot act on into a number you can raise on purpose. You are not trying to make anyone replaceable. You are trying to make sure that the business, and the person, are both free to take a real vacation.

Related reading

Frequently Asked Questions

What is a bus factor in simple terms?

The bus factor is the smallest number of people who would have to leave, all at once, before a project or a business function stalls because no one left knows how it works. A bus factor of one means a single person holds knowledge that exists nowhere else. Higher is safer, because the knowledge is spread across more people and, ideally, into written documentation.

How do I calculate my business's bus factor?

Go function by function rather than trying to score the whole company at once. For each critical process (payroll, deployments, client onboarding, the website staying up), ask how many people could carry it out unaided if the usual person vanished for two weeks. If the answer is one, that function has a bus factor of one. The list of ones is your priority order.

Is a low bus factor really a problem for a small business?

It is, though the cost is usually quiet rather than dramatic. Research found that 42 percent of job-critical knowledge is unique to one person and that workers lose about 5.3 hours a week waiting on or recreating information (Panopto, 2018). The everyday drag of concentrated knowledge often costs more over a year than any single departure.

What is the cheapest way to raise a bus factor?

Documentation, done narrowly. Writing a short runbook for the two or three processes that would hurt most if their owner were unavailable costs a few hours and immediately makes recovery possible for someone else. Cross-training a second person raises it further, but a written record is the lowest-cost first step.

Does cross-training mean I have to hire more people?

No. Cross-training is about moving knowledge, not adding headcount. Occasional pairing, reviewing each other's work, and rotating who owns a recurring task all spread knowledge across existing staff. Managed operations can also raise your effective bus factor by running documented systems as a service rather than leaving them dependent on one internal person.

Operations Jul 28, 2026 7 min

Antifragile Operations: Building a Business That Gains From Disruption

A single disruption to lean, just-in-time production cost the global auto industry an estimated $210 billion in lost revenue in 2021, per consulting firm AlixPartners. An antifragile business reads a shock like that differently: not as a catastrophe to survive, but as information to...

Work With Us

Need help building this into your operations?

Kief Studio builds, protects, automates, and supports full-stack systems for businesses up to $50M ARR.

Newsletter

New writing, straight to your inbox.

Strategy, psychology, AI adoption, and the patterns that actually compound. No spam, easy to leave.

Subscribe