Your bus factor has a name, and it's measurable, not folklore

Every team has the joke. Someone gestures at a module and says "if Priya gets hit by a bus, we're finished," and everyone laughs, and the meeting moves on, and nothing about that sentence gets written down anywhere. It's treated as a bit — grim enough to be funny, familiar enough to not really register as information. That's the strange thing about the bus factor: it is simultaneously the single scariest sentence a standup produces and the single most reliably un-acted-upon one.

It has an actual definition, and it isn't a vibe

"Truck factor" — the sturdier, less morbid name researchers gave it — is defined precisely: the minimum number of people who would have to leave a project before it stalls out from lost knowledge. Avelino, Passos, Hora and Valente built an automated algorithm to compute it directly from a project's commit history, rather than from a guess in a meeting, and ran it against 133 popular GitHub projects. Their headline finding is the one worth sitting with: roughly 65% of the systems they examined had a truck factor of one or two. Not "a few legacy edge cases." The majority.

That number matters because of what it implies about the joke in your standup: it is very likely not a joke. It is very likely an accurate, un-instrumented description of a real, measurable, structural risk that happens to get delivered in a register — laughing, off-hand — that makes it feel like it isn't one.

Low ownership isn't just a risk. It's already a defect generator.

Here's where the research gets uncomfortable in a different direction. Bird, Nagappan, Murphy, Gall and Devanbu, in a Microsoft Research study of two major Windows releases, examined the relationship between code ownership and software failures directly — not as a hypothetical future risk, but as a present-tense, already-happened one. Their finding: code with a larger number of low-expertise, low-ownership contributors, and a lower share of ownership concentrated in a clear primary owner, showed a measurably higher rate of both pre-release faults and post-release failures. This wasn't a study of code quality in the abstract. It was a study of exactly the situation the bus-factor joke describes — nobody clearly, deeply owning a piece of code — and it found that situation already correlates with more bugs, today, independent of whatever happens on the road.

Put the two studies together and the joke stops being about a hypothetical future. Avelino et al. says: most systems have dangerously few people who deeply understand any given part. Bird et al. says: the parts with the fewest deeply-invested owners are already failing more, right now, bus or no bus. The bus is a colorful way of talking about a cost that's already being paid.

Why the standup joke never becomes a standup action item

Three reasons, and none of them are about anyone not caring.

1. It's delivered as a joke, so it gets processed as one. The register does real work here — the same sentence, said flatly ("only one person can safely touch the payment retry logic"), reads as a finding. Said with a laugh, it reads as color commentary. Same information, opposite treatment.
2. Nobody's watching the number change. "Priya knows it" was true a year ago. Is it still true? Has anyone else touched that code since? A joke doesn't get revisited quarter over quarter. A metric does.
3. It has no natural subject. "The bus factor is bad" is a claim about the whole team's mood. "This specific function, carrying this much production traffic, has exactly one person who's committed to it in the last year" is a claim about one thing, and only claims about one thing get fixed.

What a measured bus factor actually looks like

Run Avelino et al.'s logic — knowledge concentration inferred from who actually authored and touched what — against your own commit history, joined against which of those functions are carrying real production load, and the joke resolves into an ordered, boring, extremely actionable list: not "the team feels nervous about the payments module," but "this function, called forty thousand times a day, has had exactly one committer in the last eight months, and that person hasn't touched it in six weeks." That's not a vibe anymore. That's a subject, a number, and a horizon — precisely the shape a checkable standup claim needs to have, instead of the shape a joke needs to have, which is just enough truth to be funny and just little enough specificity to never get scheduled.

A bus factor that never gets a number stays exactly where it's safest: as a joke everyone half-believes and nobody has to act on this sprint. Measured, it's just a name, a function, and a traffic figure — and none of those are funny anymore, which is precisely why they get fixed.

This is measurable directly from what you already have — no new instrumentation required, just the discipline to actually run the count instead of trusting the joke. (It's also, not coincidentally, one of the things a continuous, per-function view of commit authorship against production load makes visible without anyone having to run the analysis by hand every quarter — which is the register-shift this whole post has been arguing for: from folklore to a standing number.)

The test: say the sentence flat

Here's the smallest possible intervention, and it costs nothing to try in your very next standup. The next time the bus-factor joke gets made, don't laugh along and don't let it pass — just repeat it back flatly, without the joke's cadence: "so you're saying only one person on this team can safely change that code." Watch what happens to the room. Most of the time, the flat version gets a genuinely different reaction than the joke did, because it turns out the information was always serious. It just needed someone to say it in the voice that matches what it actually means.