Bus Factor as an Engineering Org Health Metric
How knowledge concentration in teams creates hidden operational risk.
The on-call rotation says four engineers are eligible to take the page. In practice, every incident in that domain routes to the same person, regardless of whose week it is. The sprint board shows a team of ten, but planning quietly works around one engineer's vacation schedule because nobody else can safely touch the billing module while she's out. These are the visible symptoms of bus factor, the minimum number of people who would need to leave a project before it stalls from knowledge loss alone. The name comes from a grim hypothetical, the number of engineers who'd have to be hit by a bus for the project to grind to a halt, but treating it as a thought experiment undersells what it actually measures: a team of ten can carry a bus factor of 1 if only one person understands how the critical billing system actually works. Headcount tells you how many people are on the roster. Bus factor tells you how much of what they know is recoverable if any one of them walks out the door, and the two numbers can diverge sharply even on well-staffed teams. Dependency risk belongs in this picture too: organizations inherit the bus factor of the open-source projects they depend on, and a 2016 study of 25 popular open-source projects found that ten of them had a bus factor of 1, meaning internal knowledge can be distributed perfectly well while the project still rests on fragile external foundations. The rest of this piece sets that dependency risk aside and stays focused on what happens inside the codebase a team actually owns.
What a bus factor score means
A bus factor score only becomes useful once a reader knows what the number actually implies about risk, and the scale runs in four bands. A score of 1 is Critical. A score of 2 is High. A score of 3 to 4 is Medium. A score of 5 or more is Low risk. The jump from 1 to 2 feels reassuring on paper, but a bus factor of 2 still counts as High risk, because losing either one of those two experts drops the project straight back to Critical. Redundancy only becomes real once a third person has working knowledge of the system, not before.
A bus factor of 1 means the team is one resignation, one extended illness, or one competing job offer away from a serious operational problem, and the clock on that risk is entirely outside the team's control. Engineers informally call it a bus factor of 0, a system where the sole knowledgeable contributor has already left and the code is effectively orphaned, understood by no one currently on the team. In practice, a bus factor of 1 is visible in mundane, easy-to-miss ways: a single person reviewing every pull request for a given service because no one else understands it well enough to catch a mistake, incident response quietly routing to the same engineer no matter who is formally on call, sprint planning bending around one person's calendar, and new hires avoiding a module entirely because there's no documentation and the one person who could explain it is too busy to pair. None of these look like a crisis day to day. Together, they're the signature of concentrated risk sitting quietly inside a team that otherwise looks healthy.
Measuring bus factor in a large, complex codebase
Version control history is the obvious place to start measuring bus factor, and it's also where naive methods go wrong. The simplest approach lists every contributor to a repository, ranks them by commit volume, and counts how many people are needed to account for more than half of all contributions. That count becomes the bus factor. The flaw is structural: this method treats a one-line typo fix and a foundational architectural commit as equivalent units of knowledge. A developer who wrote a handful of commits establishing the core design of a system can rank below someone who made hundreds of small documentation edits, which inverts the very risk the measurement is supposed to catch.
A more rigorous approach, the Degree of Authorship (DOA) algorithm, corrects for this by scoring each developer's relationship to each file along three dimensions: whether they originally created the file, which signals foundational understanding; how many times they've modified it since, which signals ongoing engagement; and how many times other developers have committed to that same file, which signals how much that original understanding has eroded or been overtaken by competing contributors. Contributors whose DOA score on a file exceeds 0.75 are considered authors of that file, holding enough working understanding to maintain it without help. The DOA-based bus factor then asks how many of these qualified authors are needed to cover more than half of all files in the codebase, a cleaner proxy for real recoverability than raw commit counts.
Commit history carries a second distortion that DOA alone doesn't fully solve: staleness. A developer who contributed heavily years ago and then left the company still shows up prominently in raw commit logs, and without some form of time-weighting, their accumulated commit count can outrank the person currently maintaining the system, pointing leadership toward people who are no longer even on the team. A practical first-pass heuristic cuts through this: if 90% of code commits in the last six months come from a single email address, the risk is Critical. The six-month window is recent enough to reflect who holds the knowledge today. At the scale of a large monorepo or a sprawl of hundreds of microservice repositories, none of this is something a team can do by hand once a quarter. The calculation has to run continuously and automatically, built into the same pipelines that already track code health, rather than performed as an occasional audit that goes stale the moment it's finished.
Commit data, however sophisticated the weighting, still only captures one channel of knowledge. Code review, architecture discussion, and documentation authorship all carry signal that version control never records. A developer who consistently approves every pull request for a given service holds critical review knowledge, the ability to catch a bad change before it ships, that never appears anywhere in their own commit count. A full measurement of bus factor has to account for these channels alongside commit history.
Where knowledge concentration hides in a large codebase
Even teams that actively measure bus factor can miss where it's actually concentrated, because knowledge accumulates in places that standard commit analysis and standard team rituals don't reach. Legacy subsystems are the clearest example: code written by engineers who left years ago, never documented, and untouched recently enough that it doesn't register in a six-month commit window, even though someone will eventually need to modify it. Cross-repository dependencies hide a second kind of concentration. A developer may hold the only working understanding of how a particular field or service behaves across five different repositories, a span of knowledge that no single repository's commit history could ever capture on its own.
Review bottlenecks are a third hiding place, and one of the easiest to overlook precisely because it doesn't register in authorship-based metrics. When the same name is the sole approver across a set of services, that concentration makes that person a functional single point of failure for how fast change can ship, regardless of how distributed the underlying commit history looks. Incident and escalation paths hide concentration in a similar way: the same engineer gets paged for every incident in a domain because routing has quietly drifted to match wherever the real expertise lives, regardless of what the on-call rotation says.
Distributed and offshore engagements add a structural amplifier to all of this. When only one or two people inside a vendor team understand a platform in real depth, the effective bus factor for that system shrinks to match that small group, not the total headcount the contract implies. That gap tends to stay invisible until a scaling event or an emergency forces someone to go looking for the person who actually knows how the system works, and discovers there's only one.
Why bus factor matters to different readers
The same measurement carries different weight depending on who's reading the number, and that range is part of why bus factor deserves a place in org-level reporting rather than staying confined to engineering retrospectives. For engineering leaders and CTOs, a low bus factor across critical systems is a direct signal that scaling will be hard: new engineers can't meaningfully contribute to parts of the codebase they can't navigate, and low bus factor tends to travel together with documentation debt, which makes onboarding into those same areas slower and more expensive than it needs to be.
For investors and acquirers, bus factor functions as a due diligence instrument. TechMiners uses bus factor during technology due diligence to identify concentrated knowledge risks that could jeopardize scalability, maintenance, or company valuation. A bus factor of 1 on a revenue-critical system is a red flag that belongs directly in valuation and retention planning, because the departure of a key engineer during a transaction or an integration tends to land at exactly the moment the business can least afford delivery disruption.
For new engineers, and for non-engineers trying to understand how a system works, concentrated knowledge changes what's even possible to learn from the artifacts in front of them. When the real context for a design decision lives only in one or two people's heads, reading the code or the documentation isn't enough. The only path forward is finding the right person and hoping they have the time to explain it, and that interrupt cost doesn't fall evenly across the team. It lands disproportionately on the senior engineers who already hold the concentrated knowledge, pulling them away from their own work to answer the same questions repeatedly, which compounds a productivity drain on exactly the people a team can least afford to pull off task.
When concentration is correct
Not every instance of concentrated knowledge is a management failure, and treating every low bus factor score as an emergency leads to effort spent in the wrong places. Two forms of concentration are legitimate. The first is a module genuinely at the end of its life, no longer under active development, where concentrated knowledge reflects the natural wind-down of a system. The second is a highly specialized system where real depth of expertise requires years of tenure to build. In that case, the fix is making sure the specialist's knowledge is written down and recoverable even if the specialist's day-to-day bandwidth stays concentrated.
A survey of engineers, conducted by researchers Elgun Jabrayilzade and Eray Tüzün, found that bus factor is perceived as an important problem in collective development, which suggests engineers broadly recognize the risk even where day-to-day priorities push attention elsewhere. The deeper difficulty is that bus factor risk tends to stay invisible until it isn't: it produces no acute pain while the concentrated expert is still around, so teams consistently underinvest in distributing knowledge until a departure forces the issue into the open.
The right response is to prioritize along two dimensions at once: how critical the system is to delivery, and how likely the person holding the concentrated knowledge is to leave. A low bus factor on a legacy internal tool with no planned changes sits well below a low bus factor on the payment processing service whose primary owner just took a call from a recruiter. That prioritization logic is what should shape where remediation effort actually goes.
Five practices that structurally raise bus factor without creating busywork
Raising bus factor doesn't happen by accident. It requires deliberate choices from engineering leadership, woven into how the team already works rather than bolted on as extra process that everyone quietly resents. The first practice is treating the codebase as a shared asset rather than a set of personal territories: teams with healthy bus factor scores default to code review, pairing, and shared ownership rather than treating them as exceptions reserved for especially risky changes. In practice, that means triaging bugs by asking who doesn't know this part of the system as often as asking who knows it best, deliberately assigning mismatched work so knowledge spreads faster than it would under pure volunteer ownership.
The second practice is documenting decisions, not just systems. Documentation that only describes what currently exists is far less valuable than documentation that explains why it was built that way, including the trade-offs considered and the alternatives that were rejected along the way. Architecture Decision Records capture context that would otherwise live only inside the original author's head, and because they're written down and searchable, that context survives the author's departure.
The third practice is building rituals that normalize knowledge transfer as a routine part of the work. Teams with strong bus factor scores tend to layer architecture reviews, internal tech talks, code walkthroughs before major releases, regularly updated onboarding playbooks, and searchable postmortems on top of their standard agile ceremonies. These rituals work precisely because they turn knowledge transfer into a predictable rhythm of the work cycle rather than something that only happens after someone has already left.
The fourth practice is treating cross-training as a baseline expectation rather than a special initiative that only gets attention when a reorg forces the issue. When rotating engineers through unfamiliar parts of the system is just how the team operates, rather than an occasional program with its own kickoff meeting, knowledge spreads as a byproduct of normal work instead of requiring a separate effort that competes with delivery deadlines.
The fifth practice is measuring bus factor continuously and treating the score as a standing input to planning decisions, not a one-time audit result that gets filed away and forgotten. A score calculated once a year tells a team what its risk looked like at that moment, but knowledge concentration shifts constantly as people join, leave, and move between projects. Teams that track bus factor the same way they track test coverage or deployment frequency, as a live signal that feeds directly into staffing and roadmap decisions, catch concentration while it's still cheap to fix rather than discovering it in the middle of an incident.
