What is the bus factor?

The number of people who would have to be hit by a bus — or resign, or go on long-term leave — before a project stalls because the knowledge to continue it left with them. A bus factor of one is the common and dangerous case: one person understands the deployment pipeline, the billing edge cases, or the legacy service nobody else has opened.

How do you calculate bus factor?

The usual approximation ranks authors by how much of a codebase's surviving lines they wrote, then counts how many people from the top you have to remove before the remaining authors account for less than half the code. It is a proxy, not a measurement — authorship is where the knowledge probably sits, not where it definitely sits.

What is a good bus factor?

There is no universal target, because the right number depends on how much the thing costs you when it stops. A bus factor of two on an internal admin tool is fine. A bus factor of one on the payment path is a business risk that happens to be recorded in a git history. Work out which of your services have a bus factor of one first, and argue about the target afterwards.

How do you improve bus factor?

By routing review and work through people who would not otherwise touch the code — pairing, deliberately assigning a second reviewer who lacks context, rotating on-call, and writing down the decisions rather than the mechanics. Documentation helps least of the four, because the knowledge that matters is usually why something is the way it is, and that rarely survives in a README.

Bus factor (truck factor): definition, formula and benchmarks

How it is measured

The usual approximation is authorship. Rank the contributors to a repository or directory by how many surviving lines they wrote, then count how many you have to remove from the top before the people left account for less than half the code. That count is the bus factor.

It travels well because every code host already has the data, and it needs no configuration and no one to remember to tag anything. That is also the whole of its evidence: it measures who typed the code, and infers that they are the person who understands it.

Two refinements make the inference less shaky:

Weight recent work more heavily. Someone who wrote a service four years ago and has not opened it since is not a live knowledge holder, and counting them inflates the number in exactly the direction that makes you relax.

Count reviewers, not just authors. A person who has reviewed thirty changes to a service has real working knowledge of it, and an authorship-only calculation is blind to them. This usually raises the number, and usually correctly.

Why it is worth watching

Bus factor is one of the few engineering measures that is about risk rather than throughput. Almost everything else on a delivery dashboard tells you how fast the team is moving. This one tells you what happens if a particular person stops.

It is also unusual in being actionable at the moment you look at it. Cycle time tells you something is slow and leaves you to find out why. A bus factor of one on a named service tells you who, what, and what to do about it — put someone else on the next change there.

The failure it predicts is not gradual. Teams with concentrated knowledge look completely healthy right up until the week the person takes leave, and then a routine change takes four days because nobody else has read the file.

What it misses

Authorship is not understanding. The line-count proxy will hand full credit for a file to whoever ran the formatter, and none to the person who designed it and reviewed every change since. Generated code, vendored dependencies and migration sweeps distort it badly, and have to be excluded before the number means anything.

It has no sense of what matters. A repository-level bus factor averages the risky parts with the trivial ones. The useful unit is a service, a directory, or a path — the payment integration, not the monorepo.

It ignores how hard the code is. A bus factor of one on a well-structured, well-tested module that a competent engineer can read in an afternoon is a mild inconvenience. A bus factor of one on an undocumented scheduler with implicit ordering assumptions is a genuine emergency. The metric reports the same number for both.

AI-assisted work confuses it further. When a substantial share of a diff was generated rather than written, authorship records who accepted the change, which is a weaker claim about understanding than it used to be. A rising bus factor on a repository where AI-generated volume is climbing may be measuring nothing at all.

How to read it well

Calculate it per service, not per organisation. The number only becomes a decision when it is attached to something specific enough to assign someone to.

Sort by consequence before you sort by number. Make the list of things with a bus factor of one, then order that list by what it costs when it stops. Most teams find that the top of the risk list and the top of the bus-factor list are not the same, and the risk list is the one worth working through.

Treat it as a prompt for routing, not for documentation. The instinct is to ask the single owner to write it all down, which produces a document describing the mechanics — the part that was never the hard bit. Getting a second person to make the next real change to that code transfers the part that matters: why it is shaped the way it is, and which of the obvious simplifications have already been tried and do not work.

And never put it in front of the person it names. "You are a bus factor of one" reads as a criticism of someone who has usually been carrying a service nobody else would take. The finding is about how work has been routed, and routing is a management decision.

Bus factor