You're One Engineer Away From Disaster. Here's Why.

TL;DR: If there's a system only one person on your team truly understands, you don't have a documentation gap - you have a standing outage with a start date you don't know yet. Research puts a third of studied codebases at exactly this exposure. The free fix starts this week: map the person's real footprint from git, rank it by blast radius, and put a second reviewer on everything critical. And notice the flip side: being the only one is a trap for them too. Protecting the org and protecting the person are the same project.

There's a name you say in your head every time a certain system comes up in planning. You approve their vacation requests with a small, private flicker of fear. When they're out sick, a slice of the roadmap just goes quiet, and everyone pretends that's normal.

You have a plan for an outage. A plan for a security incident. A plan, somewhere, for the office flooding. For this - the risk you think about most often - you have a feeling in your stomach and a hope that they're happy here.

This isn't rare, and it isn't anyone's fault

Avelino et al. (2016) measured truck factors across 133 popular GitHub systems: 34% sat at exactly 1, one departure away from orphaned code, and around 65% at 2 or lower. These are healthy, thriving open-source projects. Concentration is the default state a codebase drifts into when nobody is counter-steering. The 2024 Stack Overflow survey shows the day-to-day cost of the same pattern: 45.2% of developers agree knowledge silos prevent ideas from crossing the org, and 30% say silos hit their productivity ten-plus times a week.

Understand the mechanism, because it decides the fix. Nobody hoarded anything. The person who fixed the system last is the fastest to fix it next, so the next ticket routes to them, which makes them faster still. Expertise compounds; routing follows expertise; the loop tightens every sprint. Your expert didn't build a moat - the system dug one around them while everyone watched and called it efficiency. That's key-person risk, and it's a property of the system, never a verdict on the person.

And spare a thought for the view from inside the moat: real vacations are impossible, every incident is theirs, and moving to new, career-growing work would "leave payments uncovered," so they never do. Bus factor 1 is how orgs quietly exhaust their best people. It's a burnout risk factor and a retention risk you're probably underpricing, wearing a productivity costume.

Do this first, free, this week

1. Say it out loud, without blame. In your next team conversation, name it as a system property: "we've concentrated payments on one person, that's fragile and unfair to them, we're going to spread it." Framing decides whether this lands as rescue or as accusation.
2. Map the real footprint. From the last 12 months of git history, list the areas where your expert authored or reviewed most of the meaningful changes; the honest, authorship-weighted method is in how to calculate bus factor. Then add what git can't show: the deploys, migrations, vendor quirks, and pager duties that always route to them. Ask the team what they'd have to ask them next; the answers surface the map fast.
3. Rank by blast radius, pick two. You can't spread everything at once. What stalls the business if it goes dark, and what's actively changing? That triage (the same one in the bus-factor-1 inventory) gives you the two areas that matter. The rest can wait, explicitly.
4. Start review rotation on those two areas today. This is the strongest move available, and it's free. 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. A second reviewer on every PR builds working context on live code, unlike the documentation sprint, which mostly produces documentation nobody reads. Pair it with deliberately routing a ticket or two to a successor with the expert navigating; the full playbook is in how to reduce bus factor.
5. Pre-write the departure plan. One page: if this person resigned on Friday, what happens Monday? Writing it while it's hypothetical is calm work; writing it during a notice period is triage.

What "good" looks like: every critical area has two people who can review it confidently, and your expert takes a two-week vacation during which nobody messages them. That last sentence is the actual acceptance test.

How you'd actually see it

The map you just built by hand goes stale the sprint after you build it: ownership shifts with every merge. The durable version is computed continuously from git history: real ownership per area (authorship-weighted, review-aware), which areas sit at bus factor 1, and the consequence simulation that makes it land in a leadership meeting: it takes two people not showing up, and eight areas become orphans.

That is precisely what Busfactor's knowledge map does: it renders the moat while there's still time to build bridges over it, and re-renders it every week so the risk can never silently regrow. The honest limit: git shows authorship and review, not what's in heads or on pagers. Undocumented operational knowledge is invisible to any tool, ours included. Treat the computed map as a strong, receipt-backed estimate and verify it in one conversation with the team.

The door

The disaster in the title has a scheduled date - you just don't know it yet, because it's on someone else's calendar. The fix is two-sided and both sides are mandatory: spread the knowledge so no area depends on one human being, and protect the human who's been carrying it - with recognition, with real vacations, and quite possibly with money. Do the audit this week. If you'd rather the map draw itself, with the orphan simulation attached: connect your repos and it's the first thing you'll see.