The Vacation Test: Finding Out What Only One Person Knows Before It Hurts

Every small company has a Dana. Dana knows which vendor actually answers the phone, why the March invoice always needs the PO number in the memo line, what the workaround is when the scheduling system double-books, and which customer's file has the note that explains everything. None of this is written anywhere. It doesn't need to be — Dana's here.

Then Dana takes two weeks in September, and the office discovers, in real time and in front of customers, exactly how much of the company was stored in one head. The billing run stalls on a step nobody can find. A vendor dispute waits twelve days because the history lives in a mailbox nobody can search. Everyone performs the ritual: we'll ask when she's back. And when she's back, the backlog gets cleared, the lesson evaporates, and the company returns to its default architecture — one person, no backup, everything fine until it isn't.

Here's the reframe: that vacation was a free disaster drill, and most companies waste it. A two-week absence is the gentlest possible version of a question you will eventually be asked harshly — by a resignation with two weeks' notice, a medical leave with none, or a departure that goes badly and takes the goodwill with it. The vacation test is running the drill on purpose, while the answer key still works there.

Find the single points of failure in one meeting

You don't need a knowledge audit; you need one honest hour with the whole team and a whiteboard. Ask three questions. What tasks can only one person here do? Not "does best" — only. What questions does everyone route to the same person? The human FAQ list — whoever gets interrupted most is holding the most unwritten documentation. If each of us vanished for a month, what breaks first? Go person by person, including you — owner-held knowledge is usually the worst cluster in the building: banking access, vendor relationships, pricing logic, the password to the thing behind the other thing.

Score each item two ways — how often it comes up, how bad it bites when it's missing — and you have a ranked list by the end of the hour. The top of that list is never a surprise to the room, which is itself the finding: everyone already knew where the fragility was. It had just never been anyone's job to fix it.

Capture the judgment, not just the steps

The standard fix — "Dana, go write documentation" — fails in a specific, predictable way. Experts write down the procedure and leave out the judgment, because the judgment doesn't feel like knowledge to the person carrying it; it feels like common sense. The resulting document says submit the invoice by the 25th and omits unless it's Q4, when accounting closes early, which is the thing that actually burns you.

Two capture methods beat the blank page. Interview instead of assigning: someone else — ideally the person who'd inherit the task — walks through it with Dana and writes while she talks, asking the questions a document never answers: what goes wrong most often? how do you know when it's off the rails? who do you call, and what's the magic word when you call them? Thirty minutes of interview produces what three assigned-but-never-started documentation weeks don't. Capture at the moment of use: every time someone interrupts your expert with a question this quarter, the answer gets a home — a shared doc, a wiki page, anywhere searchable — before the interruption is over. It's fifteen seconds at the point where the knowledge is already out of the head, and it converts your interruption pattern into your documentation roadmap, in exact priority order, automatically.

Then prove the backup works: the shadow week

A document nobody has run is a hypothesis. The verification is a shadow week: the designated backup does the task — actually does it, hands on keys, with Dana available but silent unless asked — once per quarter. The gaps that surface ("the doc says approve it in the portal, but the portal needs an access role nobody requested") are precisely the ones that would otherwise surface during the real absence, with the expert unreachable and the customer waiting. Access is its own audit item, and it's the one that bites hardest in a crisis: the runbook is useless if the login, the approval role, or the vendor account recovery all terminate at the person who's gone. For every critical system, someone second needs standing access — not a promise that access could be granted, which during an abrupt departure it often can't.

Make it structural, not heroic

None of this holds if it depends on a burst of documentation enthusiasm — the enthusiasm has a half-life of one busy week. It holds when it's wired into things that already happen: every vacation request triggers the question "what does your backup need before you go?"; every quarter, one shadow week per critical function; every new-hire onboarding assigns them to write down what confused them, because the newest person is your best detector of knowledge everyone else stopped seeing. And the register of who-backs-up-what goes somewhere visible, because its real function is cultural — it announces that being replaceable for two weeks is a professional accomplishment here, not a threat. Dana, who has been answering the same questions for three years, is usually the most relieved person in the building.

The bottom line

The vacation test is the cheapest resilience audit available to a small company: one hour to find the single points of failure, interviews and capture-at-use to pull the judgment out of heads, a quarterly shadow week to prove the backups are real, and vacation itself rewired into the trigger that keeps it all current. Run it before September does it for you — because the difference between a knowledge system and a Dana is that only one of them is allowed to be unreachable.

— Tom