Glossary
Bus factor measures how many team members could leave before a project fails. Understand this critical risk metric for product teams.
Bus factor (also called truck factor or lottery factor) is the minimum number of team members who could disappear before a project enters serious trouble. A bus factor of 1 means one person leaving — being "hit by a bus" — would be catastrophic. The bus factor measures knowledge and capability concentration within an engineering team. It reveals structural fragility in how expertise is distributed.
At UshaOm, our bus factor on the payment module was literally one. That engineer went on vacation for two weeks and three features froze. That is when I started documenting everything.
The bus factor is a measurement of risk concentration in software engineering teams. A project has a bus factor of N if losing any N specific people would cause the project to fail, stall, or enter crisis. The lower the number, the more fragile the team's organizational structure.
The term comes from the morbid thought experiment: how many developers could be "hit by a bus" before the project collapses? It is also called the truck factor or lottery factor (what if they won the lottery and quit?). The underlying concept is the same: what is the minimum number of people whose absence breaks the project?
Bus factor is a measure of knowledge concentration, not just team size. A 20-person engineering team can have a bus factor of 1 if one senior engineer holds all the architectural knowledge, owns the deployment process, and is the sole reviewer for critical systems. Adding more people to the team does not improve bus factor unless those people actively learn the concentrated knowledge.
Bus factor is fundamentally a product velocity problem, not just a risk management problem. When critical functionality depends on specific individuals, those individuals become structural bottlenecks in decision-making and execution.
A PM cannot greenlight a roadmap change for a system with bus factor 1 without acknowledging that the project fate depends on retaining one person. Estimation becomes unreliable because the person with the knowledge is also the person who must implement the solution. Design decisions slow down because they require input from the person who holds the architectural context.
Most importantly, bus factor measures something that sprint velocity and test coverage miss: what actually keeps the product running depends on people, not processes. A team with 95% test coverage and low bus factor is still fragile.
Bus factor is not calculated with a single formula — it is assessed by analyzing code ownership concentration across critical systems. The most common methods:
Git commit analysis: Calculate the percentage of commits to a critical system made by each contributor over the last 6-12 months. If one person accounts for 60%+ of commits and no other contributor is above 20%, bus factor = 1 for that system.
Code review concentration: If one reviewer approves 70%+ of changes to a critical system, bus factor = 1 regardless of how many contributors write code.
The replacement test: Could another engineer debug a critical production incident in this system using only the documentation and code as reference? If not, bus factor = 1.
Onboarding time variance: If some systems take 2 weeks to onboard and others take 6 months, the slow ones likely have bus factor = 1. The time difference is explained by knowledge concentration.
The practical formula: Bus factor = number of people who must be removed before the system becomes unworkable. For most individual subsystems at early-stage companies, this is 1.
Consider a SaaS platform with three major subsystems: authentication, data processing, and the user-facing API. During the initial hire phase five years ago, three senior engineers each owned one system.
Now the company has grown. The auth system has six engineers who understand it thoroughly. The API team has four engineers with strong knowledge overlap. But the data processing system still has exactly one engineer — Chen — who understands the entire pipeline, the rationale for its architecture, the specific edge cases that broke production twice, and the undocumented integrations with partner systems.
When Chen wants a promotion or considers a transfer, the organization has a problem. Can Chen be replaced? Yes, eventually. But the handoff process would take months. Feature development that depends on the data pipeline stalls. If Chen leaves before a replacement is found, the team goes into survival mode.
Calculating bus factor starts with identifying your critical systems, then assessing knowledge concentration in each one.
Step 1: List your critical systems. What systems, services, or codebases would cause significant impact if they failed or could not be modified? These are your bus factor measurement targets.
Step 2: Analyze commit history. For each critical system, run a git log analysis to see who has committed to it in the past 6 months. Tools like git shortlog -sn give a quick contribution summary. Look for concentration: if 2-3 people account for 80%+ of commits, bus factor is low.
Step 3: Audit code review patterns. Which engineers approve changes to each system? If a single reviewer is required for all PRs on a critical system, that is a bus factor signal regardless of contribution patterns.
Step 4: Run the replacement test. For each critical system, ask honestly: if the primary contributor left today, how long would it take another engineer to handle a production incident independently? Under 1 week = bus factor 2+. Over 1 month = bus factor 1.
Step 5: Build a bus factor map. For each critical system, note the current bus factor, who holds the concentrated knowledge, and the risk level. This map becomes your improvement backlog.
Improving bus factor is not about eliminating specialization. It is about ensuring that critical knowledge is shared across at least 2-3 people.
Step 1: Identify your critical systems. List every system that would cause significant impact if it went down or could not be modified. Systems with bus factor 1 are highest priority.
Step 2: Create a knowledge map. For each critical system, document: who built it, who maintains it, who can review PRs, who can handle incidents. This map reveals single points of failure.
Step 3: Implement pair programming rotations. The fastest way to transfer knowledge is working together on real tasks. One hour of pairing transfers more knowledge than a week of documentation.
Step 4: Rotate on-call responsibility. If only one person can handle incidents for a system, bus factor = 1. Gradually add more people to the on-call rotation, starting with shadow on-call where they observe before taking primary responsibility.
Step 5: Require multi-person code review. For critical systems, require at least one reviewer who is not the primary maintainer. This forces knowledge distribution through the review process.
Step 6: Write Architecture Decision Records. Document the why behind architectural decisions. When the original author leaves, successors can understand the reasoning, not just the code.
Step 7: Measure and track. Review your bus factor map quarterly. Celebrate when it improves. Flag when it regresses (often happens when people leave or change teams).
| Team Size | Minimum Acceptable | Target | Risk if Bus Factor = 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 ensuring at least one other person has surface-level familiarity with each system.
Growth-stage (10-50 engineers): Bus factor of 1 is unacceptable for any production system. Actively invest in cross-training. Budget 10-15% of engineering time for knowledge sharing.
Enterprise (50+ engineers): Bus factor should be 3+ for all critical systems. Formal knowledge management programs and rotation policies become necessary.
The OpenSSL Heartbleed Case (2014). The Heartbleed vulnerability in OpenSSL affected millions of servers. OpenSSL was maintained by essentially one full-time developer — bus factor of approximately 1 for a project critical to internet security. This led to the creation of the Core Infrastructure Initiative to fund critical open-source projects.
The left-pad Incident (2016). One developer unpublished a small npm package called left-pad, breaking thousands of builds including React and Babel. The npm ecosystem had a bus factor problem at the package level: critical dependencies maintained by single individuals.
Knowledge Loss During Layoffs. When companies do large layoffs, entire knowledge domains can disappear overnight. Companies that maintained bus factor of 4+ for critical systems were significantly less impacted than those that had not.
"Writing documentation solves bus factor." Documentation reduces risk, but only if it is complete, accurate, and includes architectural reasoning. Bus factor is solved through a combination of documentation, code review practices, and rotation patterns that require multiple engineers to maintain systems. Documentation is necessary but not sufficient.
"Bus factor only matters when someone actually leaves." Bus factor is about velocity and decision-making, not just survival. A team with bus factor 1 runs slower than a team with bus factor 3, even if no one leaves. The person holding the knowledge becomes a bottleneck in planning and estimation.
"Adding more people fixes bus factor." Headcount does not fix bus factor if new people are not brought up to speed on the concentrated knowledge. Adding three engineers to a team where one person holds all the knowledge and does not have time to share it does not improve bus factor.
What is a good bus factor?
A bus factor of 2 or higher for mission-critical systems is acceptable. A bus factor of 3+ is ideal for systems that generate revenue or enable the core product. Bus factor 1 for any production system is a risk that should be actively reduced.
What is the bus factor in software engineering?
The bus factor in software engineering is the minimum number of team members who could become suddenly unavailable ("hit by a bus") before the project enters serious trouble. It measures knowledge concentration risk: how many people hold critical, undocumented, or non-transferable knowledge about the system.
What is bus factor 1?
Bus factor 1 means a single person holds knowledge or capability that the team cannot function without. If that person leaves, goes on vacation, or becomes unavailable, the project stalls or enters crisis. Bus factor 1 is the most common and most dangerous configuration, especially for critical subsystems at growing engineering teams.
What is the difference between bus factor and tribal knowledge?
Bus factor is a measurement — a number indicating how many people must be removed before a project fails. Tribal knowledge is the underlying cause of low bus factor — information held by a small group that is not documented or shared. High tribal knowledge concentration leads to low bus factor. Reducing tribal knowledge is the primary mechanism for improving bus factor.
How do you calculate bus factor from git history?
Run git shortlog -sn --no-merges on each critical repository to see commits by contributor. Calculate each contributor percentage of total commits. If one contributor accounts for 60%+ of commits on a critical system and no other contributor is above 25%, bus factor is effectively 1 for that system.
Keep reading
Related resources
Blog
