How to capture what a subject matter expert knows before they leave

Why "write it down" never works

The standard response is to ask the expert to document what they know. This fails reliably, for reasons that have nothing to do with willingness.

Experts cannot enumerate their own knowledge. The whole point of expertise is that most of it has become automatic, and automatic knowledge is not available to introspection. Ask someone with fifteen years in a role to write down how they decide, and you will get the official procedure — which they will describe accurately and which is not what they do.

The knowledge you need is the exceptions, and exceptions surface in response to cases, not to blank pages. So stop asking for a document and start asking about cases.

Ask about cases, then chase the judgments

The productive interview is a sequence of concrete instances, interrogated for the decisions inside them.

Start with recent work. What came in yesterday. What took longer than it should have. The last one somebody escalated. Concrete cases put the expert back in the situation, where the tacit knowledge is retrievable.

Then, at every point where they made a call, ask how they knew. This is the entire technique and it feels almost rude by the third repetition. Push anyway. The first answer is usually the official rule. The second is the real rule. The third is often "well, you can tell because…", which is the thing you came for.

Ask about the ones that go wrong. What makes a case go sideways, what the early warning is, what they check when something feels off. Failure knowledge is denser than success knowledge and is almost never written down anywhere.

Ask what they'd tell a new starter that isn't in any document. Experts answer this one directly, and it is the single highest-yield question in the set.

Interview three people, not one

Interviewing only your best expert produces one person's model, including their idiosyncrasies, and you will not be able to tell which is which.

Talk to two or three people doing the same work. Where they agree, you have a rule. Where they diverge, you have found something more valuable: either an undocumented decision that different people make differently — a quality problem you did not know you had — or a genuine judgment call where reasonable people differ, which you need to know before you try to automate it.

Include somebody relatively new. They still remember what was confusing, and they will name gaps the expert cannot see because the expert has not experienced confusion about this in a decade.

Capture in a form that survives

A transcript is not capture. It is raw material, and a folder of transcripts decays into something nobody opens within about two months.

What survives is structure: the workflows named, the systems they touch, the decisions with their criteria, the exceptions with their triggers, and the person each is attached to. Structured this way, the knowledge is findable by somebody who does not know it exists — which is the actual requirement, since the person who needs it in eight months will not know what to search for.

The link between a piece of knowledge and its source matters too. When somebody later disagrees with a documented rule, you want to know it came from a specific interview with a specific person on a specific date, rather than having appeared in a wiki with no provenance.

Turn exceptions into a written rule

The specific artifact worth building, if you build only one, is the exception list.

For each exception the expert named: what triggers it, how you recognize it, what to do, and who to ask when it is unclear. That is four lines each. Twenty exceptions is a page and a half, and that page and a half is usually the difference between a process a new person can run and one they cannot.

It is also exactly the input an automated version needs. Every serious attempt to automate a judgment step eventually runs into the exceptions, and the teams that did this interview first are months ahead of the ones discovering them from production failures.

Do it before there's a deadline

The worst time to run this is the notice period, which is when it usually gets scheduled. The expert is disengaged, distracted by handover logistics, and the work goes shallow.

Run it when nothing is happening. One workflow a quarter, on a rotation, and within a year you have covered the concentrations that actually worry you. Pick the first one by asking a simple question: which process would we struggle with if a specific named person were unavailable for a month? Everyone already knows the answer.

Before you call it captured