Bus Factor: What It Is and What It Costs You

TL;DR: Bus factor is the number of people your team can lose before a project stalls. When researchers measured 133 popular GitHub projects, 34% had a truck factor of exactly 1 - one departure away from an orphaned codebase. Yours is probably worse than you think. The good news: it's computable from git history in an afternoon, and fixable on purpose instead of during an exit interview.

Somewhere in your codebase there is a directory exactly one person understands. You know the one. Everyone routes questions about it to the same name in Slack, every PR touching it waits for the same reviewer, and the standing joke is "don't let them get hit by a bus." The joke is doing a lot of load-bearing work. Buses are rare; resignations, parental leave, burnout, and better offers are not.

What is bus factor?

Bus factor is the minimum number of team members who would have to disappear before the project can no longer meaningfully move forward. The proverbial bus does the disappearing in the joke; in real life it's a competitor with a better offer. A bus factor of 1 means a single departure orphans critical knowledge. A bus factor of 5 means your team can absorb real turnover and keep shipping.

Higher is better. That direction matters, because the metric is occasionally defined backwards; agree on it before it goes near a dashboard.

One nuance carries most of the weight here. Bus factor is a property of each area of your system, and the company-wide number is mostly decoration. Your API layer might be comfortably shared while your billing integration and that one legacy deploy service are both riding on a single person. The org-level number is only as good as the worst area you actually depend on.

Where the term comes from

The idea has been folklore since at least the 1990s, usually told about a project's irreplaceable maintainer. Academics adopted the politer "truck factor," and you'll also hear "lottery factor," the optimistic framing where your key engineer wins the jackpot instead of meeting a bus. Same metric, same funeral.

It stopped being folklore when researchers made it computable. Avelino, Passos, Hora, and Valente (2016) estimated truck factors for 133 popular GitHub systems using authorship data from git history. The results, in their numbers: roughly 65% of the studied systems had a truck factor of 2 or less, and 45 of the 133 - a full 34% - had a truck factor of exactly 1. A third of the most popular open-source projects on GitHub were one person away from trouble, and those are the projects successful enough to be studied. Your internal codebase does not have thousands of volunteer contributors waiting in the wings.

What a bus factor of 1 actually costs

Nothing, until it costs you everything at once. That's what makes it a genuinely nasty risk: it's invisible in every sprint where nobody leaves. The system ships and the expert keeps answering questions, so velocity looks fine. You find out the real number the week the resignation letter lands, when "who's picking up payments?" gets answered with silence.

The day-to-day tax is quieter but real. One qualified reviewer means one review queue. The expert ships worse code before every vacation because they can never fully log off. And single-owner areas harden into silos that slow everyone around them. In the 2024 Stack Overflow Developer Survey, 45.2% of professional developers agreed or strongly agreed that knowledge silos prevent them from getting ideas across the organization, and 61% reported spending more than 30 minutes a day searching for answers or solutions. A bus factor problem is a knowledge silo that hasn't detonated yet. We cover how to hunt them in how to find knowledge silos in engineering teams.

And to be fair to the humans involved: the single owner rarely built an empire on purpose. They kept saying yes when nobody else wanted the on-call for that service. Roast the system that let ownership concentrate, never the person holding it up.

How do you calculate bus factor?

Start with git history. Map who actually authored and reviewed each part of the codebase over a recent window, decide what level of contribution counts as "could carry this area alone," then count how many people you can remove before more than half of an area's files have no remaining knowledgeable owner. That removal count is the bus factor.

Commit counts alone will lie to you. The person who typed the most lines is not always the person who understands the system, and reviewers accumulate real knowledge without authoring a byte. The honest method, including the degree-of-authorship weighting the researchers use and the places where the math misleads, gets its own walkthrough in how to calculate bus factor from git history.

If you want the continuous version, an ownership map that recomputes as the team and the code move, that's what the knowledge and bus-factor view in Busfactor renders from your existing git history.

Fixing a low bus factor

Spread ownership deliberately, in the few areas where it actually matters. "Everyone should know everything" is how teams achieve nothing. Rank your single-owner areas by blast radius - how much of the product stalls if this one goes dark - then fix the top of the list first and ignore the rest without guilt.

The moves that work, roughly in order of cost:

1. Review rotation. The cheapest knowledge transfer in existence. If the same person reviews every PR into an area, assign a second reviewer and let them earn context on someone else's diff. Reading changes builds real familiarity.
2. Ownership spreading. Route the next meaningful feature in a single-owner area to a different engineer, with the current owner as reviewer instead of author. Slower for one feature; structurally faster forever after.
3. Docs where the churn is. Skip the wiki nobody reads. Put a README and a runbook inside the areas that are both active and single-owned, anchored to the code so they change when the code does. Documentation written once and never touched is a comfort blanket.
4. Pairing on the hot paths. The most expensive option, so spend it only on the areas where a departure would genuinely stop the business.

What doesn't work: mandatory pairing on everything (a tax nobody pays for long), knowledge transfer as a two-week offboarding panic (you're transferring from someone whose motivation just left the building), and hoping. Hoping is the most popular strategy and has the worst track record.

When should you check it?

Before the exit interview - which in practice means on a schedule. Bus factor drifts every quarter as people change teams and code changes hands; the areas that were shared in January can quietly become single-owned by June. Measure it the way you'd measure test coverage: continuously and boringly, with a ranked list of the worst spots so the fix is always concrete.

You architected redundancy into your infrastructure. Your team deserves the same.

Unlike most engineering-org problems, this one has a number, and the number comes straight from data you already have. Every move that improves it is something your team should be doing anyway.