There’s an old, slightly morbid joke in software teams: how many people would need to get hit by a bus before your project grinds to a halt? Ask it at your next planning meeting and watch the room go quiet. Most teams have never actually counted.
The term is called the bus factor, and despite the dark humor, nobody has to literally get hit by anything for it to matter. People take new jobs. They go on parental leave. They get sick, burn out, or just decide they’re done. The bus is a stand-in for any of the completely ordinary ways a person can stop being available to a team with almost no warning. Some people call it the “lottery factor” instead, for the same reason but a happier spin: imagine that person won the lottery and never logged in again. Same math, less funeral.
Table of Contents
What the number actually measures
The bus factor is the smallest number of people whose sudden, simultaneous absence would stop a project cold – not slow it down, stop it. If one engineer is the only person who understands how the payment system talks to the warehouse, and that person disappears, the bus factor for that part of the system is one. If it would take losing five specific people before nothing could move forward, the bus factor is five.
A low number doesn’t mean the team is bad at its job. It usually means the opposite – someone got good enough at a hard problem that everyone else quietly stopped needing to learn it. That’s a completely reasonable thing to happen by accident, and it happens constantly.
It’s more common than most teams think
Researchers have actually gone and measured this instead of just joking about it. A widely cited 2016 study by Avelino, Passos, Hora, and Valente looked at a large sample of open source repositories and found that about 65% of them had a bus factor of two or lower. Two people. For a huge share of software that other software depends on.
It’s not just a small-project problem either. A team at JetBrains – a company that builds developer tools for a living, so if anyone should have this under control, it’s them – ran a study across thirteen of their own internal projects, pulling in not just commit history but code review activity and meeting data too, and still found the same pattern showing up: a small number of people quietly holding together far more than their job title would suggest. The Open Source Security Foundation has flagged the same fragility at the level of entire ecosystems – plenty of widely used infrastructure is maintained, in practice, by one or two unpaid volunteers, which is exactly the kind of thing that sounds fine until it very suddenly isn’t.
Why it sneaks up on teams
Nobody sets out to build a bus factor of one. It happens through a series of small, reasonable decisions that add up to a real problem.
Someone solves a nasty bug once, and from then on, “just ask Dave” becomes the informal escalation path for anything in that part of the codebase. It’s faster than digging through documentation that may not exist yet, so nobody writes the documentation, because Dave is right there and faster. Code review quietly follows the same pattern – the person who understands a module best is also the fastest reviewer for changes to it, so they end up reviewing almost everything that touches it, which means they’re the only one getting the reps needed to actually understand it deeply. Everyone else stays a step removed. A year later, “just ask Dave” has become “only Dave can safely touch this,” and nobody remembers exactly when that shift happened.
None of this shows up as a warning on any dashboard. Builds stay green. Deploys go out on schedule. The system looks perfectly healthy right up until the day it depends on someone who isn’t there anymore.
Getting a rough number without a research team
You don’t need an academic tool to get a useful estimate. A blunt but workable exercise: for each critical part of the system – the build pipeline, the deployment process, the gnarliest legacy module, the thing that only works because of a script someone wrote three years ago – ask how many people on the current team could operate it without help today. Not “who wrote it originally,” but who could actually pick it up cold right now. If the honest answer for something important is “one,” you’ve found a bus factor problem, whether or not anyone ever calls it that out loud.
Code review data is worth checking specifically, because it tends to catch a case that commit history alone can miss: someone who writes very little of a module’s code but reviews almost all of it. That person understands the tradeoffs well enough to catch mistakes, which is a deeper kind of knowledge than authorship, and it’s easy to overlook if you’re only looking at who typed the most.
Raising the number without slowing everyone down
The fixes aren’t exotic, but they only work if someone actually commits to them instead of nodding along in a retro and moving on.
Rotating who reviews changes to the riskiest parts of the system forces more than one person to build real familiarity with it, rather than rubber-stamping the same expert’s work forever. Pairing on genuinely hard problems, even occasionally, spreads understanding in a way that a Slack thread never quite manages – you can skim a written explanation and still not really get it, but you can’t fake your way through pairing on a live problem. Documentation helps, but only the kind that explains why a decision was made, not just what the code does; the “why” is almost always the part that disappears first once the person who made the call is gone. And treating “only one person understands this” as a flagged risk – something a team lead actually tracks, the same way they’d track a flaky test or a security finding – matters more than any specific technique, because most of the damage happens simply because nobody was watching for it.
None of this is really about any one engineer’s individual skill. Some teams work through this kind of gap by pulling in outside software engineering support to help spread the load and document what’s currently living in one person’s head before it becomes urgent rather than after. Others handle it entirely in-house with enough discipline. Either way works, as long as somebody’s actually keeping score instead of assuming it’ll sort itself out.
The number worth checking before it matters
The bus factor doesn’t need a fancy dashboard or a research paper to be useful. It just needs someone willing to ask an uncomfortable question honestly: for the parts of the system that would really hurt to lose, how many people could actually step in tomorrow? If the answer is one, that’s not a crisis yet – it’s a heads-up. What happens next is the part that’s actually optional.
