Orgledge / Bus factor
What Is Bus Factor? Definition, Calculation and How to Improve It
Bus factor tells you how fragile your team's knowledge is. Here is what it means, how to measure it from Git data, and what to do when it is low.
Bus factor is the smallest number of people who would have to leave a project, suddenly and for good, before it loses the knowledge needed to keep going. A bus factor of 1 means a single person holds critical knowledge.
Why bus factor matters
Every team has people who know one system better than anyone else. That is normal. It becomes a risk when nobody else can maintain, debug or safely change that system. If that person leaves, takes a long vacation or gets sick, work slows down or stops.
For startups and small teams the risk is higher. Teams are small, ownership is informal and one early engineer often wrote most of the core code. CTOs and investors increasingly ask about bus factor during technical due diligence.
A simple example
Imagine a repository with three areas and the people who made most of the changes to each.
| Area | People with real knowledge | Bus factor |
|---|---|---|
| Payments service | Alex | 1 (high risk) |
| Web frontend | Sam, Priya | 2 |
| Infrastructure | Alex, Sam, Priya | 3 |
The whole project looks fine on average, but the payments service depends on Alex alone. That is the number to act on. A single project-wide bus factor can hide this, so measure it per area.
How to calculate bus factor
There is no single official formula. A practical approach based on Git history works like this:
- Collect authorship. For each file or directory, list who contributed and how much, using commits.
- Find who "knows" each area. Count a person as knowing an area if they contribute a meaningful share of the work, not just a one-line fix.
- Remove people one by one. Start with the top contributor. Count how many people you must remove before a large share of the code, often 50%, has no knowledgeable author left.
- Repeat per area. Do this for each service, module or directory so you can see where the risk sits.
Commit counts alone are a rough signal. Code reviews, recent activity and ownership give a more realistic picture, and people who have been inactive for months should count less.
Limits of any bus factor number
- Git shows who changed code, not who understands it. Treat the result as a signal, not proof.
- Documentation, pairing and chat discussions spread knowledge in ways Git cannot see.
- The number is a risk indicator. It is not a performance score for people.
What is a good bus factor?
- 1: High risk. One departure can stop work on that area.
- 2: Minimum for critical code.
- 3 or more: Comfortable. Hard to reach everywhere on a small team, so prioritize critical systems.
How to improve your bus factor
- Review across the team. Make sure code in risky areas is reviewed by someone other than its author.
- Pair on critical systems. Let a second person work on the area with the expert.
- Rotate ownership. Give secondary owners real tasks, not only reading access.
- Write short docs. Document architecture, deployment and known pitfalls for key systems.
- Track it over time. Measure again after each change to confirm the number actually goes up.
Measure bus factor automatically
Orgledge analyzes read-only Git activity metadata, never your source code. It finds areas where knowledge is concentrated, explains the risk and tracks improvement across scans. GitHub is supported first, and GitLab is planned. Orgledge is in early access.
Join the waitlistFrequently asked questions
What is a good bus factor?
A bus factor of 1 is high risk because one departure can stop a project. A bus factor of 2 is a minimum for critical code, and 3 or more is comfortable. Small teams cannot reach 3 everywhere, so focus on the most critical areas first.
Why is it called bus factor?
The name comes from the grim thought experiment of how many team members would need to be hit by a bus before a project is in serious trouble. It describes dependency on individuals, not any real danger. Some teams use the friendlier term lottery factor.
How do you calculate bus factor from a Git repository?
Count how many contributors you would have to remove before a large share of the code or files has no remaining author who knows it. Most approaches use commit history and file authorship, and better ones also weigh recency, code reviews and ownership.
Is bus factor a measure of employee performance?
No. Bus factor measures a dependency risk in how knowledge is distributed. It does not rate individuals, and it should not be used to rank or evaluate people.
How can a small team improve its bus factor?
Use code reviews across the team, pair on critical areas, rotate ownership, write short documentation for key systems, and track the metric over time to confirm it improves.