Bus Factor Calculator
Calculate your team's bus factor and knowledge concentration risk. Identify critical knowledge silos before they become problems.
Bus factor answers a blunt question: how many people would have to leave before a codebase or a critical area is in trouble? A bus factor of 1 means one person carries knowledge nobody else has, so a single resignation, a long holiday, or an illness can stall the work.
This calculator turns that question into a number. Enter your team size, count the people who can deploy and who understand the core architecture, and list any critical systems with their maintainer counts. The result is your weakest link plus a read on how concentrated your knowledge has become.
The point is not to predict who leaves. It is to surface the silos that already slow you down every day - the systems where every question routes through one person.
Enter Your Team Data
Key Capabilities
Critical Systems/Modules
Optional: List specific critical areas and how many people can maintain each
Enter your team size and at least one capability metric to see your bus factor analysis.
About Bus Factor
The bus factor (also known as the "lottery factor" or "truck factor") is the minimum number of team members who would need to suddenly disappear before critical knowledge is lost. It measures your team's resilience to unexpected departures, whether from resignations, illness, promotions, or winning the lottery.
Why It Matters
- • Business continuity and risk management
- • Reduced stress on key individuals
- • Better vacation coverage and work-life balance
- • Faster onboarding for new team members
- • More flexible team assignments
How to Improve
- • Pair programming and mob programming
- • Comprehensive documentation and runbooks
- • Cross-training and rotation schedules
- • Code reviews as learning opportunities
- • Regular knowledge-sharing sessions
Critical - Single point of failure
High Risk - Still vulnerable
Medium - Some resilience
Healthy - Well distributed
How it’s calculated
Bus factor is the smallest number of people who can independently keep a critical capability running. We treat each capability you enter as its own count, then take the minimum across all of them. The team is only as resilient as its thinnest coverage.
The inputs we score
- People who can deploy to production end to end.
- People who understand the core architecture well enough to make substantial changes.
- Each critical system or module you list, with the number of people who can maintain it.
How the numbers turn into a verdict
- Collect every capability count that is greater than zero.
- Bus factor is the minimum of those counts - your single weakest area, not an average.
- Knowledge concentration is the gap between team size and the average coverage across capabilities, shown as a percentage. The more people you have relative to how few can do each job, the higher the concentration.
- Risk bands: 1 is critical (single point of failure), 2 is high risk, 3 to 4 is medium with some resilience, 5 or more is healthy.
We use the minimum rather than an average on purpose. A team where ten people understand the architecture but only one can deploy still has a bus factor of 1. Averaging would hide the exact failure that takes you down.
Worked example
Take a team of 8 engineers. Three can deploy to production. Four understand the core architecture. They list two critical systems: a Payment API maintained by 1 person, and an Auth Service maintained by 2.
- Capability counts: deploy = 3, architecture = 4, Payment API = 1, Auth Service = 2.
- Bus factor = minimum of those = 1, driven entirely by the Payment API.
- Average coverage across the four capabilities is 2.5 people, against a team of 8, so knowledge concentration lands near 69 percent.
The verdict is critical risk. On paper this looks like a healthy team - most areas have three or four people - but one undocumented Payment API owner sets the whole score. The fix is narrow and obvious: pair a second engineer onto payments and write a deployment runbook. Do that and the bus factor jumps to 2, then 3, without touching anything else.
Our Take
Bus factor is really a 'knowledge distribution' metric. A bus factor of 1 isn't bad because someone might leave - it's bad because knowledge silos slow everyone down every day.
When only one person understands a critical system, every question, every bug, every decision routes through them. This creates bottlenecks during normal operations, not just during emergencies. Teams with low bus factors experience longer incident resolution times, slower feature development, and higher stress on key individuals - regardless of whether anyone actually leaves.
"Codebases with bus factor 1 on critical modules have 3x longer incident resolution times."
— Derived from incident response benchmarks across distributed teams
Key terms
- Bus factor
- The minimum number of people who would need to leave before a project loses the knowledge it needs to keep going. Also called the truck factor or lottery factor.
- Knowledge concentration
- How centralised expertise is across the team. High concentration means a few people hold most of the critical knowledge while the rest of the team cannot cover for them.
- Knowledge silo
- A critical area that only one person genuinely understands, so every question, bug, and decision in that area has to route through them.
- Key person dependency
- A state where normal operations rely on a specific individual being available, turning their holiday or departure into an outage rather than an inconvenience.
- Critical area
- A system, module, or capability whose failure would stop the team or the business - deployment, core architecture, payments, auth, and similar.
Frequently Asked Questions
Bus factor (also called truck factor or lottery factor) is the minimum number of team members who would need to suddenly disappear before a project or team loses critical knowledge and ability to function. A bus factor of 1 means a single person holds critical knowledge that nobody else possesses. The term comes from the morbid question: "How many team members would need to be hit by a bus before the project fails?" It's a key metric for measuring organizational risk and knowledge distribution.
Want to track this automatically?
CodePulse connects to your GitHub and calculates these metrics in real-time. No more manual data entry or spreadsheets.
Free tier available. No credit card required.
See These Features in Action
Detect bus-factor-1 code before it becomes an operational risk.
Find high-churn files and correlate change frequency with ownership.
Learn More
The 'Bus Factor' File That Could Kill Your Project
Use the Bus Factor Risk Matrix to identify where knowledge concentration creates hidden vulnerabilities before someone leaves.
The Tech Lead Dashboard Your Manager Shouldn't See
The metrics that matter for tech leads - code quality, technical debt, architecture decisions, and delivery. Different from EM metrics, focused on technical excellence.
The Git Query That Finds Your New Hire's Perfect Mentor
Use Git activity data to accelerate new hire onboarding, identify domain experts for pairing, and track ramp-up progress.
Related Tools
PR Size Analyzer
Analyze your pull request sizes and get recommendations. Learn the optimal PR size for faster reviews and fewer bugs.
Technical Debt Cost Calculator
Quantify the cost of technical debt. Calculate how much productivity you're losing and build a case for refactoring.
SPACE Framework Assessment
Assess your team across all 5 SPACE dimensions: Satisfaction, Performance, Activity, Communication, and Efficiency. Get a visual radar chart and recommendations.