Capturing Tribal Knowledge Before Your Expert Walks Out the Door

Every team has one. The person who knows why the Henderson account gets invoiced differently, which step of the month-end close silently breaks if you run it before noon, what the workaround is when the vendor portal rejects the upload. None of it is written down — it doesn't need to be, because you can just ask Dana.

Then Dana gives notice, and you have two weeks to extract a decade.

I've run operations and training teams long enough to have lived both endings of this story: the scramble that loses the knowledge, and — much more painful to admit — the successful-looking scramble that produces forty pages nobody can use. This playbook is the version that works, and the part that matters most happens before anyone resigns.

Why the exit-interview download fails

The standard move — book the departing expert into "knowledge transfer sessions," point a junior person at them with a notebook — fails for three predictable reasons.

Timing: the expert is checked out, the calendar is short, and the new job has their attention. Format: experts can't enumerate what they know — expertise is recognitional. Ask "what should I write down?" and you get the official process, which everyone already knows. The gold is what they do when the official process fails, and they can't recall that in a conference room because they only know it in the moment of doing it. Audience: notes written during a panicked download are notes to the person who wrote them, useful for about six weeks, then a knowledge-base graveyard entry.

So the playbook splits in two: the emergency protocol when the notice has already landed, and the system that means the next departure isn't an emergency.

The emergency protocol (notice given, two weeks left)

Triage by ask-frequency, not org chart. Day one, fifteen minutes: list the things people actually come to this person for. Check their sent mail and Slack DMs if you can — recurring inbound questions are the map of the tribal knowledge. Rank by how badly the team bleeds if it walks out. You will not capture everything; capture the top ten well instead of forty things badly.

Shadow-and-narrate, don't interview. For each of the top ten, have the expert do the task one more time while narrating, with a recorder running (a meeting tool's transcript is fine). Doing-while-talking surfaces the recognitional knowledge that conference-room recall cannot: "oh, and see this status flag? if that's yellow you have to wait, the sync lies for about ten minutes" — the sentence that will save the team at 2am, and the sentence that never appears when you ask someone to write the procedure.

Ask the ten questions that extract. Where the task can't be performed live, use questions aimed at failure modes and judgment, not process:

1. What breaks most often, and what do you check first?
2. What does the official doc get wrong or skip?
3. What do you do when X fails anyway?
4. Who do you call, for what, and what's the magic phrase?
5. What would a smart new person definitely get wrong here?
6. What do you check before you trust the number?
7. What did the last incident teach you that isn't written anywhere?
8. Which steps are load-bearing and which are habit?
9. What's the workaround everyone uses but nobody documents?
10. What question do people ask you every single month?

Record now, structure later. The expert's job is to talk; turning talk into documents is your job, after they're gone if necessary. Transcripts plus AI make this the cheap half now — a transcribed hour of shadow-and-narrate converts into a draft SOP in minutes (the SOP-people-actually-follow format is here). The capture window is the scarce resource; spend every minute of it capturing.

Last day minus one: the verification run. A different person performs the top three tasks from the drafts alone, expert silently watching, speaking only when something's wrong. Every interruption is a gap in the doc. This hour finds the missing steps while the person who knows them is still in the building — it is the single highest-value hour of the whole protocol.

The system (so the next one isn't an emergency)

Document on the second ask. The rule that builds the library without a documentation project: the second time anyone asks you the same question, the answer gets written where the third person will find it. One rule, applied by everyone, compounds into coverage of — by definition — the things people actually ask.

Make the expert the reviewer, not the writer. Experts hate writing docs and are mediocre at it (curse of knowledge: they skip the steps they no longer see). Have the junior person write from the transcript and the expert correct it. Faster, better docs, and the junior person learns the task as a side effect — which is knowledge transfer happening twice.

Watch your bus factor on purpose. Twice a year, one question per critical process: "if this person won the lottery tomorrow, who does this next month?" Every process with a one-name answer goes on the capture list now, while the expert is happy, present, and narrating without a countdown. Capturing from someone with notice is salvage; capturing from someone with tenure is maintenance, and maintenance is cheaper.

(KnowledgeByDesign automates the mechanical layer of this — transcript-to-draft capture, ask-frequency signals from your channels, staleness flags before docs rot. But the second-ask rule and the verification run cost zero dollars, and they're the spine.)

Closing

Tribal knowledge isn't a documentation problem, it's a timing problem. The knowledge is most extractable while it's being used, by someone with no reason to leave — and nearly inextractable in a conference room during a two-week notice period.

So: run the emergency protocol when you must — triage by ask-frequency, shadow-and-narrate, structure later, verify on day thirteen. But install the system so you stop needing it — second ask gets documented, experts review instead of write, bus factor checked twice a year.

Dana was never the problem. The problem was that everything Dana knew lived only in Dana — and that was fixable for years before it ever became a two-week fire drill.

— Tom