Bus factor is the minimum number of people who could leave a software project before the loss of their knowledge causes work to stall. A bus factor of one means one person's absence can put a critical system at risk.
The name is deliberately dark, but the underlying problem isn't.
People resign. They transfer teams. They take parental leave. A senior engineer becomes unavailable during an incident. The risk isn't that someone gets hit by a bus. It's that the organization discovers too late that a system and one person's memory had become the same thing.
Software-engineering research treats bus factor as a measure of knowledge concentration, not just commit ownership. A 2022 study surveying 269 engineers found that version-control history alone misses important ways engineering knowledge is created and distributed, especially through code review and team communication.
That gives engineering leaders a much better question than “Who wrote the most code?”
Who does the organization stop functioning without?
Why bus factor is more than engineering folklore
Bus factor is often treated like an inside joke because the name sounds like one. Research suggests engineering teams take the underlying risk much more seriously.
In Bus Factor In Practice, researchers from JetBrains Research and academic collaborators surveyed 269 engineers, tested their estimation method on 13 JetBrains projects and concluded that engineers regarded bus factor as an important issue in collaborative software development. Crucially, their model improved when it incorporated code reviews and communication data alongside version-control history.
The full paper explains the methodology.
Earlier work reached a similar conclusion from repository data at larger scale. A 2016 study estimated the truck factor of 133 popular GitHub projects and found that 65% had an estimated factor of two or lower. The authors also stressed that there's no universally accepted formula for calculating the number.
See A Novel Approach for Estimating Truck Factors.
You shouldn't treat bus factor like an accounting metric where a score of 1.7 has some universally agreed meaning. What it gives you is a structured way to find dangerous knowledge concentration before a resignation, reorganization or incident finds it for you.
And the useful unit often isn't the whole company.
A 100-person engineering organization can have a decent organization-wide bus factor while one payment service, legacy integration or deployment pipeline still has a bus factor of one.
Don't calculate bus factor from commits alone
The easiest way to estimate bus factor is to open git log, count authors and assume the most active contributor knows the system best.
That's a useful starting signal.
It isn't enough.
The 2022 bus-factor research found that knowledge flows through multiple channels, which is why its proposed multimodal method incorporates version control, code review and meetings rather than relying on commits alone.
For an internal engineering audit, I'd start with three signals.
Signal 1: ownership concentration
Run repository history at the directory or subsystem level, not only for the repository as a whole.
You're looking for paths where:
- one engineer dominates meaningful changes
- very few other engineers touch the code
- the secondary contributors made only superficial changes
- activity has remained concentrated over a long period
A file with 20 authors isn't necessarily safe if 19 of them changed configuration strings while one person built every meaningful behavior.
The goal isn't to establish perfect authorship. It's to locate the places worth investigating.
A 2024 JetBrains Research project called Bus Factor Explorer takes a similar subsystem-oriented view. It uses version-control history and treemap visualizations to identify files and areas at risk when developers leave.
Signal 2: review concentration
Now look at who approves changes.
A senior engineer may have written almost none of a subsystem recently and still be its real knowledge owner.
You see it when:
- nearly every meaningful PR requests the same reviewer
- changes wait until that person is available
- other reviewers approve syntax and style but defer architecture questions
- a developer says “I'd rather wait for Alex to look at it”
Commit history misses that knowledge.
Review topology catches some of it.
That's one reason the Bus Factor In Practice researchers included code-review activity in their model rather than treating version-control authorship as a complete proxy for knowledge. (arXiv)
Signal 3: question routing
The third signal barely needs tooling.
For two weeks, record where engineering questions go.
Not the answers. Just the destination.
Examples:
How does the retry logic work?
→ Maya
Why can't we change this schema?
→ Maya
Where does the settlement job actually run?
→ Maya
Can I safely remove this queue?
→ Maya
When that pattern appears repeatedly, the org chart can say whatever it wants. Maya is part of the runtime.
This signal matters because bus factor is fundamentally a knowledge-distribution problem. Repository activity tells you who changed software. Question routing tells you who the team believes can explain it.
What’s your bus factor risk?
Don't answer for the entire engineering organization. Pick one system whose failure would hurt.
1. Contribution concentration
0 points: several engineers make meaningful changes
1 point: two engineers dominate
2 points: one engineer dominates
2. Review concentration
0: reviews are distributed
1: one reviewer appears frequently
2: meaningful changes effectively require one person's approval
3. Question concentration
0: questions distribute across the team
1: one or two people answer most of them
2: nearly every difficult question routes to one person
4. Backup ownership
0: another engineer can take over now
1: a backup exists but needs help
2: there is no credible backup
5. Safe-change capability
Ask:
If the primary expert were unavailable tomorrow, could someone else make and ship a non-trivial change to this system this week?
0: yes
1: probably, with delays
2: no
Your score
0–2: Distributed context → Low immediate key-person exposure.
3–5: Concentrated context → Worth monitoring and deliberately spreading.
6–8: Key-person dependency → One absence is likely to slow meaningful work.
9–10: Critical exposure → Treat the system like any other production single point of failure.
What reduces bus factor
The standard answer is “write better documentation.”
Documentation helps. It isn't enough.
The reason becomes obvious when you separate different kinds of engineering knowledge.
A README can explain how to start a service. An architecture diagram can show its major components. Neither necessarily captures why an engineer knows that one innocuous-looking call can't be moved inside a transaction because someone tried it three years ago and triggered a production incident.
Reducing bus factor means distributing several kinds of context rather than producing more pages.
Record decisions that code can't explain
Architecture Decision Records, design notes and well-kept decision history preserve something source code can't: alternatives and rationale.
The code tells you what won.
It rarely tells you what lost and why.
That distinction becomes particularly important when ownership changes. A new engineer can inspect the current queue implementation. They can't infer with certainty which failure caused the team to introduce it.
Record high-impact decisions close to the work and link them to the code, issues or PRs they concern.
Rotate ownership deliberately
Shared ownership doesn't happen because a second engineer attended two pairing sessions.
They need to make meaningful changes.
Give another engineer:
- a real feature
- an incident
- a migration
- a production fix
- review responsibility
and let the primary owner become the backup.
Yes, this can reduce short-term velocity. That's the cost of buying down concentration risk.
If an organization refuses to pay any short-term cost for knowledge distribution, it is implicitly choosing to pay later when the primary owner becomes unavailable.
Make routine system knowledge queryable
There is another class of question that doesn't need a senior engineer's judgment at all:
- Where is this implemented?
- Which services call it?
- Do we already solve this elsewhere?
- Which repository contains the equivalent behavior?
- What files are relevant to this workflow?
Those questions often route to humans because asking a colleague is faster than manually exploring an unfamiliar codebase.
That behavior changes once asking the system becomes faster.
Tentaro is designed around that layer. It indexes private repositories and returns grounded code context to engineers and compatible AI tools rather than generating code itself. Answers can point back to real source locations so the engineer can verify the result rather than treating generated prose as organizational truth. Tentaro's internal product boundary explicitly defines it as grounded context, not code generation.
The goal isn't to “replace the expert”.
It's to stop using the expert as a human search endpoint for questions the repositories can answer.
A quarterly bus factor audit you can run without buying anything
Run this once per quarter on your most important systems.
Repository layer
- Identify dominant contributors per subsystem
- Ignore cosmetic or mechanical changes when assessing meaningful ownership
- Flag areas with one dominant author
- Check if the dominant contributor is still on the team
Review layer
- Find the most frequent reviewers per subsystem
- Flag modules where one reviewer is effectively mandatory
- Identify PRs delayed while waiting for one person
- Name a credible secondary reviewer
Knowledge layer
- Track question destinations for two weeks
- Count repeated questions
- Identify questions answerable directly from repositories
- Separate structural questions from decision/rationale questions
Continuity layer
- Name a backup owner
- Give that backup a real change to ship
- Confirm they can deploy and troubleshoot independently
- Record the critical decisions code alone can't recover
The audit shouldn't end with a spreadsheet.
Pick the two worst systems and put knowledge-distribution work on an actual roadmap.
When the bus has already hit
Sometimes you're reading about bus factor because the person already left.
The priorities change.
You aren't reducing hypothetical risk anymore. You're reconstructing enough understanding to operate safely.
First: freeze avoidable risk
Don't freeze the entire system. Freeze non-essential changes in the parts nobody can currently explain.
Every speculative refactor performed during a knowledge gap adds another variable.
Second: find the remaining knowledge paths
The former owner may be gone, but context can survive in:
- code reviews
- pull request discussions
- issues
- ADRs
- incident reports
- commit messages
- teammates who worked adjacent to the system
Recover the highest-blast-radius decisions first.
Third: name a new owner before they're ready
Waiting until someone “fully understands” the system leaves it ownerless during the period when ownership matters most.
Give someone responsibility now and make knowledge acquisition part of their work.
Fourth: test independence with a real change
Don't measure transfer in meetings attended or pages written.
Give the new owner a non-trivial task.
Can they identify the relevant code, trace its dependencies, explain the likely impact, make the change and get it safely through review?
If not, you've found the remaining knowledge gap.
The engineer left. What can the team no longer answer?
Pick one affected system and write down five questions the team now routes to the departed owner.
Then split them:
STRUCTURAL
- Where is it?
- What calls it?
- What depends on it?
- Where else is it implemented?
HISTORICAL / JUDGMENT
- Why was it designed this way?
- What was rejected?
- Which constraint still matters?
The first group can often be reconstructed from code.
The second survives only if someone recorded it.
CTA: Bring one high-risk system to an onboarding teardown
AI changes both sides of the bus-factor equation
AI can help reduce some forms of knowledge friction.
DX analyzed onboarding data across six multinational enterprises in 2025 and found that engineers using AI daily reached their tenth PR in 49 days compared with 91 days for engineers who didn't use AI. The study uses tenth PR as an onboarding milestone rather than claiming it equals complete system mastery.
DX explains the analysis here.
DX's 2026 data shows the broader time-to-tenth-PR metric continuing to fall, reaching an average of 33 days across its dataset. Again, faster contribution isn't the same as distributed architectural knowledge, but it shows AI can materially change how quickly new engineers begin working in a codebase.
See DX's 2026 measurement guidance.
At the same time, AI can increase the amount of code the organization needs to understand.
Faros's 2025 analysis of teams with high AI adoption reported 98% more merged PRs, 91% longer PR review time and 154% larger PRs compared with lower-adoption teams. Faros is explicit that the data is observational, so it shows correlation rather than proving AI caused each change.
Read the original Faros report.
That gives bus factor a new wrinkle.
Historically, a system could become dependent on one person because that person built it over years.
Now code production can accelerate faster than knowledge distribution.
A module can be new and still have concentrated understanding.
The question therefore isn't only:How many people know our old systems?
It's increasingly: How many people can explain the software we're shipping now?
Don't confuse bus factor with headcount
Adding another engineer doesn't automatically increase a system's bus factor.
Neither does adding another person to a repository.
A useful test is much harder: If the primary expert disappeared today, who could make tomorrow's difficult decision without them?
If the answer is nobody, your bus factor hasn't changed.
The same applies to documentation. Fifty wiki pages don't necessarily distribute knowledge if everybody still asks the same engineer before making a change.
Measure observable independence instead:
- Can another engineer review the subsystem?
- Can they diagnose it during an incident?
- Can they explain its major dependencies?
- Can they make a meaningful change without the original owner?
- Can they verify answers against sources rather than relying on memory?
That is much closer to the risk bus factor is trying to describe.
Start with your bus-factor-one systems
Don't build an organization-wide bus factor program.
Find the systems where one absence causes the most damage.
For each one:
- Map contribution concentration.
- Map review concentration.
- Track question routing.
- Name a backup owner.
- Move routine structural questions out of one person's head.
- Record decisions that can't be reconstructed from source.
- Give the backup owner a real change.
- Repeat the test next quarter.
The goal isn't a perfect metric.
It's a system where someone's resignation is an HR event rather than an architecture event.
Which part of your codebase still has a human API?
Start with one system where questions repeatedly route to the same engineer.
Tentaro can index the repositories behind it and make structural code context queryable to engineers and compatible AI assistants, with answers grounded in source rather than another person's availability. It doesn't recover decisions nobody recorded and it doesn't replace engineering judgment. It handles the part the code itself can actually answer.
