How many people can disappear from your team before a critical system becomes unmaintainable?
That's the bus factor — the minimum number of team members who could leave before the project enters serious trouble. A bus factor of 1 means one person leaving would be catastrophic. A bus factor of 3 means you can absorb the loss of any two people.
For most teams, the honest answer for their most critical systems is one.
Why Bus Factor Matters
Bus factor is not an academic concept. It's a direct measure of operational risk.
When key engineers leave (and they will), the team's ability to maintain, debug, and evolve that system drops dramatically. Everything slows down: feature development, incident response, code reviews. New engineers can't get up to speed because the person who could explain the system is gone.
Common triggers:
- Employee turnover — Engineers leave. Average tenure in tech is 2-3 years.
- Reorgs and layoffs — Knowledge domains can vanish overnight.
- Illness and vacation — Even temporary absence of a bus factor-1 engineer creates blockers.
- Promotion — When a senior IC becomes a manager, they stop writing code but nobody absorbs their knowledge.
How to Calculate Bus Factor
For any system, module, or codebase area:
- Look at git commit history over the last 6-12 months
- Count how many unique contributors have made meaningful changes
- Identify the minimum set of people whose combined knowledge covers the system
- That number is your bus factor
A more precise approach: For each file or module, identify who can independently debug and fix production issues (not just review PRs). If only one person truly understands the billing pipeline enough to fix it at 2 AM, the bus factor for billing is 1.
Codebase intelligence tools can automate this by analyzing git history and deriving knowledge distribution maps.
Bus Factor by Team Size
| Team Size | Minimum Bus Factor | Target | Risk if BF = 1 |
|---|---|---|---|
| 2-3 people | 2 | 2 | Critical |
| 4-6 people | 2 | 3 | High |
| 7-10 people | 3 | 4+ | High |
| 10+ people | 3 | 5+ | Medium |
Startups (2-5 engineers): Bus factor of 1 is common and sometimes unavoidable. Mitigate with documentation and recorded architecture sessions.
Growth-stage (10-50 engineers): Bus factor of 1 is unacceptable for any production system. Budget 10-15% of engineering time for knowledge sharing.
Enterprise (50+): Bus factor should be 3+ for all critical systems. Formal rotation policies become necessary.
Real-World Examples
The OpenSSL Heartbleed Case. In 2014, the Heartbleed vulnerability affected millions of servers worldwide. At the time, OpenSSL was maintained by essentially one full-time developer. A project critical to internet security had a bus factor of ~1.
The left-pad Incident. In 2016, one developer unpublished a small npm package and broke thousands of builds including React and Babel. The npm ecosystem had a bus factor problem at the package level.
Knowledge Loss During Layoffs. When companies do large layoffs, entire knowledge domains disappear overnight. If the three people who understood the billing system are all let go, the bus factor drops to zero.
How to Improve Bus Factor
Step 1: Identify critical systems. List every system that would cause significant impact if it went down. For each, identify who can independently debug production issues.
Step 2: Pair programming rotations. The fastest way to transfer knowledge. One hour of pairing transfers more knowledge than a week of documentation.
Step 3: Rotate on-call responsibility. If only one person handles incidents for a system, start with shadow on-call where others observe before taking primary.
Step 4: Require multi-person code review. For critical systems, require a reviewer who is NOT the primary maintainer.
Step 5: Write Architecture Decision Records (ADRs). Document the why behind decisions. When the original author leaves, successors understand the reasoning.
Step 6: Measure and track quarterly. Celebrate when bus factor improves. Flag when it regresses.
The Tribal Knowledge Connection
Bus factor and tribal knowledge are two sides of the same coin. High tribal knowledge = low bus factor. When critical understanding lives in one person's head, you're one resignation away from a crisis.
The fix isn't just documentation — it's making knowledge discoverable and distributing it through deliberate practices.
Originally published on getglueapp.com/glossary/bus-factor
Glue calculates bus factor automatically from your git history and alerts you when knowledge silos form in critical systems.
Top comments (0)