Run the Fire Drill Before a Resignation Runs It for You

TL;DR: You drill for outages and security incidents. The failure you think about most, a key engineer resigning, is the one you've never rehearsed. So the first time you run it is the real thing: two weeks, on their schedule, with the answers due immediately. Run it as a drill instead: pick who's out, map the orphans from git, price the recovery, write the handover while it costs nothing. Free version below, this week. And run it as a rescue mission for the person carrying the load, never as a file on them.

The resignation letter arrives on a Friday afternoon. It's polite. It's two weeks. And in the ninety seconds after you read it, your brain runs the entire drill you never scheduled: What do they own? Who reviews payments now? Is the deploy pipeline documented? What do I tell the CEO on Monday?

Every question in that ninety-second panic was answerable last month. Cheaply. Calmly. With the person in the room and motivated to help. You have a fire drill for the building and a runbook for the database failing over. For the risk that actually keeps you up, your plan is to improvise against a two-week deadline.

You already know who it is

You didn't need a tool to picture the name. That's how universal this is. Avelino et al. (2016) measured truck factors across 133 popular GitHub systems and found 45 of them (34%) sitting at exactly 1: one departure away from orphaned code. Roughly 65% sat at 2 or lower. If healthy open-source projects concentrate that hard, your startup under deadline pressure is not the exception. The day-to-day version shows up in the 2024 Stack Overflow survey, where 45.2% of developers agree knowledge silos prevent ideas from crossing the org. The silo is taxing you before anyone resigns.

The wake-up call, realizing you're one engineer away from disaster, is its own moment, and bus factor has a name for it. This article is about the step after the wake-up: rehearsal. Because knowing the risk exists and knowing what Monday morning actually looks like are two very different kinds of prepared, and only one of them survives contact with a notice period.

Run the bus factor fire drill this week, free

1. Pick the scenario. Start with the name that made your stomach drop in the first paragraph. If you want the honest version, also run "worst case": whichever single departure orphans the most. One person, one hour, calendar blocked.
2. Map what would orphan, from git rather than memory. From the last 12 months of history, list the areas where they authored or reviewed most of the meaningful changes; the authorship-weighted method is in how to calculate bus factor. Then add what git can't see: deploys, migrations, vendor relationships, the pager. Ask the team "what would you ask them next?" and the invisible half of the map fills in fast.
3. Declare the blast radius out loud. Skip "we'd struggle" and say the specific sentence: "if they leave, these four areas have no confident reviewer, and this one stops shipping." Vague risk gets postponed; a counted consequence gets a meeting.
4. Sketch the handover now. One page per critical area: how it deploys, where the bodies are buried, who to call at the vendor, the first three things a successor should read. Writing this while it's hypothetical is calm work. Writing it during a notice period is triage with the clock running. Check whether any written doc actually exists for those areas; if the real docs live in one head, the drill just found its biggest finding.
5. Fix the top two exposures, starting today. Review rotation on the most exposed areas is the best free move available. Bacchelli & Bird's Microsoft study found review's real outcomes lean toward knowledge transfer and team awareness: a second reviewer builds working context on live code, sprint by sprint. The fuller playbook is in how to reduce bus factor.
6. Put the re-run on the calendar. Quarterly. The ninety-minute meeting format works well for the group version. A drill you run once is a story; a drill you re-run is a system.

One rule binds the whole exercise: the drill is about the system, never the person. If it produces a dossier on your engineer, you've failed it. If it produces a lighter pager and a plan that means they can finally take the growth project they've been deferring, you've run it right. The people your system leans on hardest are the ones a drill should protect first, and losing them has a price you'd rather compute than pay.

How you'd actually see it

The manual drill has a shelf life: ownership moves with every merge, and the map you drew in March quietly stops being true by June. The computed version runs continuously. Busfactor's Fire Drill lets you pick who's out, or lets the engine pick the worst case, then shows which areas orphan, the blast radius, a priced recovery range, and a pre-computed per-area handover checklist. It reuses the same ownership rule as the knowledge map, so the drill can never disagree with the map, and Continuity Watch keeps a tier on every solo-owned area between drills so the risk can't silently regrow.

The honest limits, stated plainly: the drill is leadership-gated, and anything shared or exported carries counts and area names, never a person. A fire drill that could be screenshotted into a rumor would be worse than no drill. Recovery ranges are computed at disclosed org-average assumptions, not anyone's actual salary. And git shows authorship and review, not pager wisdom or vendor phone numbers, so the computed map is a strong, receipt-backed starting point that still deserves one conversation with the team.

The door

Every org runs this drill eventually. The only variable is who schedules it - you, this quarter, with coffee and a whiteboard, or a resignation letter, on a Friday, with two weeks on the clock. The free version above costs an afternoon. If you'd rather the map, the orphan simulation, and the handover checklists draw themselves - and re-draw themselves every week - connect your repos and run the drill on your terms.