What is the bus factor?
Length:
4 min
Published:
June 9, 2026
What is the bus factor?
The bus factor is the number of people who would have to suddenly disappear from a project before the work stalls because nobody else knows how to continue. It is a simple measure of key-person risk: how much critical knowledge lives in too few heads. A bus factor of one is the danger zone, because losing a single person stops the project.
The name comes from a grim thought experiment: "What happens if someone gets hit by a bus?" You will also hear it called the truck factor or lottery factor. The point is the same, no matter how the person leaves. People quit, get sick, take parental leave, or move to another team, and the project should survive all of it.
In plain words
The bus factor is like a recipe that only your grandmother knows by heart and has never written down. As long as she cooks, dinner is great. The day she cannot, nobody can reproduce it. A bus factor of one means one person is the recipe, and the team has no written copy.
How to measure and reduce it
You do not need a formula to spot the risk. Ask one question for each important part of your system: if the person who understands this left tomorrow, could someone else keep it running? Wherever the honest answer is "no", your bus factor for that area is one.
A few signals that point to a low bus factor:
- One name keeps coming up in every conversation about a service or component.
- Code reviews on a given area are always approved by the same single reviewer.
- Onboarding a new engineer depends entirely on one person's availability.
- A part of the system has no documentation, and the "docs" are in someone's head.
To raise the bus factor, spread the knowledge instead of concentrating it:
- Write things down. Architecture decisions, runbooks, and the reasoning behind tricky choices belong in shared docs, not in chat history or memory.
- Rotate ownership. Pair people on unfamiliar areas, swap reviewers, and let more than one person ship changes to each critical service.
- Review the map regularly. A short, recurring check of "where is our bus factor one?" catches new single points of failure before they bite.
Common pitfalls
- Mistaking a hero for a healthy team. A person who can fix anything is impressive, but if they are the only one who can, they are a risk, not a safety net.
- Counting heads instead of knowledge. Ten engineers on a project still means a bus factor of one if only one of them understands the payment flow.
- Treating documentation as a one-time task. Docs that nobody updates rot fast, and a stale runbook can be worse than none because it gives false confidence.
- Fixing it only after someone leaves. By then the knowledge is already gone. The cheap time to raise the bus factor is while the expert is still around to share what they know.
Related articles:
- What is developer experience and why you should care - The conditions that let teams share knowledge instead of hoarding it.
- The role of technical documentation in developer success - Why writing things down is the cheapest way to raise your bus factor.
- Developer lifecycle: how to make onboarding smooth like butter - Good onboarding spreads knowledge from day one.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.