The 'Hit by a Bus' Conversation You Keep Postponing

TL;DR: Someone on your team made the joke - "well, if Marta ever gets hit by a bus, we're done" - and everyone laughed, and the meeting moved on. That laugh is your risk register. The fix is a ninety-minute tabletop drill: simulate two weeks without one person, write down the exact wall you hit, convert it into two actions. Free, this week, nobody gets blamed. Below is the script.

You've heard the joke in planning. Maybe you've made it. It gets a laugh precisely because everyone in the room knows it's true, and the laugh is what lets the meeting continue without anyone having to do anything about it. Your org has a documented plan for a database failover and no plan at all for the failure mode you joke about weekly.

If you've already run this conversation properly, close the tab - genuinely. This article is for everyone who keeps almost having it.

What is the "hit by a bus" scenario?

It's the thought experiment that gave bus factor its name: how many people can your team lose before a system goes dark? The bus is a stand-in for the boring versions: resignation, illness, parental leave, burnout, a better offer. When the answer for a critical system is "one person," you're looking at a bus factor of 1, and the scenario stops being philosophy.

It is also not a rare, unlucky configuration. Avelino et al. (2016) estimated truck factors for 133 popular GitHub systems: 34% sat at exactly 1, and around 65% at 2 or lower. Concentration is the default state of a codebase nobody is actively counter-steering, which is why you're likely one engineer away from disaster right now, whether or not anyone has said it without laughing.

Why the conversation keeps getting postponed

Three reasons, all understandable, all wrong:

It feels morbid or insulting. Asking "what if we lost you?" sounds like doubt, so leaders skip it to be kind. But the person carrying a one-person system usually knows it best: they're the one who can't take a real vacation. Done right, the drill is the kindest meeting they'll attend this quarter.

There's no deadline. An outage pages you; a knowledge silo doesn't. In the 2024 Stack Overflow survey, 45.2% of developers agreed knowledge silos keep ideas from crossing the org, and 30% said silos hit their productivity ten-plus times a week, a cost that arrives daily in pieces too small to escalate. Nothing forces the conversation until a resignation does, and then you're running it inside a notice period.

Concentration looks like efficiency. The expert is fast, so routing everything to them feels like good management. That's the loop that builds silos without anyone hoarding anything, and it tightens every sprint you postpone.

How to run a bus factor drill in 90 minutes

No tooling required. One system, one room, one rule: the system is on trial, never the person.

1. Pick one critical system - the one from the joke. Don't boil the ocean; the single-point-of-failure inventory can wait until you've drilled once.
2. Invite the owner as the expert witness. Say the framing out loud: "this is about making your vacations real, not about replacing you."
3. Simulate two weeks, hour by hour. It's Monday and they're unreachable. Who takes the pager? Who reviews the open PR? The deploy - who runs it, and from what instructions? Keep going until you hit the wall: the step where the room goes quiet. Write that wall down verbatim. (It's usually an undocumented deploy step, a vendor relationship, or a codebase nobody documented.)
4. Convert to exactly two actions. The one that pays best is almost always a review rotation on that system: Bacchelli & Bird's Microsoft study found that while finding defects is the top stated motivation for code review, the real outcomes lean toward knowledge transfer and team awareness. The second is usually routing the next two tickets in that area to a successor with the expert navigating; the mechanics are in how to reduce bus factor.
5. Put the next drill on the calendar before you leave the room. Quarterly, next system on the list. Run once, it's an anecdote. On the calendar, it's a control.

The acceptance test for the whole exercise: the person at the center takes two consecutive weeks off, and nobody messages them.

What a drill can't see (and what your git history can)

The tabletop drill is the best free tool you have, and it has two honest limits: it covers one system at a time, and its output is a snapshot that starts rotting the sprint after you run it. Ownership moves with every merge.

This is the part Busfactor automates. It computes real ownership per area from your git history - authorship-weighted and review-aware, the method sketched in how to calculate bus factor - flags the areas sitting at bus factor 1, and runs the departure simulation continuously: it takes two people not showing up, and eight areas become orphans. Every drill you'd never get around to running, pre-run weekly, with receipts linked to real commits and reviews. The honest limit runs the other way: git shows authorship and review, not pager lore or vendor relationships. The map tells you where to point the drill; the drill catches what no tool can see. You want both.

The door

An acquirer's diligence team will eventually run this exact exercise on your repo with money attached; your future self would rather you ran it first. Book the ninety minutes this week - the script above is the whole prep. And if you'd rather walk in with the map already drawn and the orphan simulation already run: connect your repos, and it's the first thing you'll see.