Here's an uncomfortable question: how many people would have to leave your team before a critical system became unmaintainable? For a lot of teams the answer is one or two, and they don't find out until it happens. Researchers have a name for it, the bus factor, and when they measured it across real projects, the numbers were alarming.
Key Takeaways
- The bus factor is the number of people who'd have to leave before a project stalls (bus factor).
- A study of 133 popular GitHub projects found 65% have a bus factor of 2 or less (Avelino et al.).
- Concentrated knowledge is a silent risk: everything's fine until the one person who understands a system quits.
- You reduce it deliberately, through ownership-with-backups, documentation, and pairing.
What the Research Found
Researchers studying knowledge concentration measured the "truck factor" (a politer bus factor) across 133 popular GitHub projects. The result: most systems are dangerously concentrated. 65% have a truck factor of two or less, meaning if just two key people left, the project would be in serious trouble; fewer than 10% had a truck factor above ten (Avelino et al.). These are popular, active, open-source projects, the ones you'd expect to be resilient. Private company codebases are often worse, because there's no crowd of outside contributors spreading the knowledge.
The reason this is dangerous is that it's invisible until it triggers. A system with a bus factor of one runs perfectly, right up until the one person who understands it goes on vacation during an incident, or takes another job. Then you discover the risk you'd been carrying all along.
Why Knowledge Concentrates
It's not negligence; it's the path of least resistance. The person who built a system is fastest at changing it, so they keep getting assigned to it, so their knowledge deepens while nobody else's does. Every "just let Sara do it, she knows that code" is a small deposit into a single point of failure. Efficient this week, fragile over the year.
| Bus factor | What it means |
|---|---|
| 1 | One person leaving stalls the system |
| 2 | The 65%-of-projects danger zone |
| 3–5 | Healthier; knowledge is shared |
| Deliberately managed | Ownership with real backups |
A Concrete Version
The one engineer who understands your billing system, the retries, the edge cases, the reasons behind the weird bits, gives two weeks' notice. Suddenly the team realizes nobody else can safely touch billing, there's no doc, and the knowledge is walking out the door. You spend those two weeks frantically extracting what you can, and for months afterward every billing change is slow and scary. A bus factor of one just cost you far more than the effort it would have taken to keep it at two.
The Honest Counterpoint
You can't, and shouldn't, make everyone know everything; that just trades concentrated knowledge for shallow knowledge everywhere, which the code-ownership research shows raises defects. Deep ownership is genuinely valuable, and the goal isn't to erase it. It's to make sure every critical system has at least a primary owner and a real backup, someone with enough context to keep the lights on. Bus factor two-to-three, not everyone-knows-nothing. It's insurance, not a redesign of how your team works.
How to Fix It
Three cheap moves raise the bus factor without much overhead. Pair or rotate a second engineer through each critical system so context spreads, the fastest form of knowledge transfer, as we noted on pair programming. Write down the non-obvious "why" behind critical systems, the high-ROI docs from documentation ROI. And when you add capacity, deliberately give newcomers ownership of things currently trapped in one head. See available engineers.
Frequently Asked Questions
What is the bus factor?
The number of people who'd have to leave a project before it stalls for lack of knowledge. A bus factor of one means a single departure can cripple a system.
How common is a low bus factor?
Very. A study of 133 popular GitHub projects found 65% have a bus factor of two or less. Private codebases are often worse, since fewer people share the knowledge.
How do I raise my team's bus factor?
Give every critical system a primary owner plus a backup, pair or rotate people through it, and document the non-obvious reasoning. Aim for two to three, not everyone-knows-everything.
Isn't deep ownership good?
Yes, and you shouldn't destroy it. The goal is a backup for each critical system, not shallow knowledge everywhere, which raises defects. It's insurance against a single departure, not a change to how ownership works.
The Bottom Line
Most projects are one or two departures away from a crisis, and they don't know it. The bus factor is a real, measurable risk: 65% of studied projects sit at two or less. Give critical systems a primary and a backup, spread context through pairing and docs, and you turn a silent single point of failure into a manageable one.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
