The engineer with the runbook was over Greenland
Production went down on a Saturday. The only engineer who knew the fix was on a plane. Two hours of revenue burned waiting for him to land.
Two hours of revenue burned on a Saturday afternoon while the one engineer who could fix the outage sat in airplane mode over the Atlantic. When his flight landed and he opened his laptop, the repair took eleven minutes.
The runbook for that subsystem lived in one place: his memory of the last four times he had fixed it. There was a wiki page with the system's name on it, written eighteen months earlier, wrong in three ways that would have misled anyone who trusted it. The on-call engineer had that page and could not use it. He had the phone number of the one person who could, and that person was at 38,000 feet.
Every company runs on a few of these. They stay invisible until the Saturday they fail. Tribal knowledge reads as an asset on every ordinary day — the senior engineer is fast, reliable, on Slack — and reveals itself as a liability the one quarter it matters. The asset framing is what kills you, because it makes the documentation feel optional. Nobody writes down what one person already knows cold.
The cheapest audit is unsentimental: send the senior person on a real week off. Phone off, no Slack, unreachable. Whatever breaks while they are gone is the documentation map. Whatever the on-call team has to escalate, route around, or hot-patch is the exact list of runbooks that need to exist. The exercise is uncomfortable, and it surfaces things the senior person did not know only they knew. That discomfort is the deliverable.
The document that comes out is not a system overview. It opens with the symptom, not the system: checkout 500 error on the Stripe webhook, the phrase a tired on-call engineer types into Google at three in the morning, not payment infrastructure subsystem. The next three lines are the diagnostic commands, in order. The test is whether someone who has never seen the system can resolve the incident from the page alone. If they cannot, the page is wrong, however comprehensive it looks.
The hire who knows everything is a feature only while they are reachable. The day they are not, the feature bills you at the worst possible moment. What you want is not a clone of the engineer; it is an engineer you can lose for a week without losing money. That is what every engineer claims to want in principle and quietly resists in practice, because the knowledge in their head is also their quiet source of leverage. Make them resist it less. Make them resist it through their next vacation, the same way a founder learns what the company can't run without them by leaving. The feature was a single point of failure the whole time. The vacation is when it finally admits it.