Single Point of Failure: Getting Process Knowledge Out of One Person's Head

How to interview the one person who knows how a process works, write it down, encode the rules in your tool, and test it with someone else.

Priya has run supplier payments for six years. She knows which suppliers need a purchase order number on the remittance, which one gets paid early because of a deal struck in 2021, and why the third column in the payment sheet must never be sorted. Priya is going on parental leave in five weeks. Suddenly, everyone is very interested in the third column.

Every business has a Priya. Often several. The knowledge is real and valuable, and it lives in exactly one place. Getting it out takes deliberate effort, and the best time to start is before the leaving date is set.

Why this knowledge is so hard to capture

The trouble with expert knowledge is that the expert no longer notices most of it. Ask Priya how supplier payments work and she will describe the five main steps in two minutes. The forty small judgements she makes along the way feel too obvious to mention.

That is why asking someone to “write up the process” rarely works. You get the outline, not the detail. And the detail is where the risk sits: the exception for one supplier, the reason a check exists, the thing that went wrong once and has been quietly prevented ever since.

The approach below works in four stages: interview, document, encode, test.

Stage one: interview, don’t ask for a write-up

Book two or three sessions of an hour each. Sit with the expert while they do the actual work, on a real cycle, not a hypothetical one. You are watching and asking, they are doing.

Useful questions to keep asking:

“What are you looking at right now, and why?”
“How did you know to do that?”
“What would happen if you skipped this?”
“Has this ever gone wrong? What happened?”
“Is there anyone or anything you treat differently?”

The last two questions are where the gold is. Past incidents explain why checks exist. Special cases reveal rules that exist nowhere else. When Priya says “oh, except for the logistics supplier”, write that down and ask three more questions about it.

Record the sessions if the expert is comfortable with it. You will miss things the first time.

Stage two: write it down in a usable shape

Turn your notes into a short process document. Process First, Tool Second: Documenting a Workflow Before You Build It has a template for the overall structure: trigger, steps, owners, handoffs. For expert knowledge, add two sections that template might not stress.

Rules and reasons. A list of every “always” and “never”, with the reason next to it. “Never sort column C, because the row order matches the bank file and the bank rejects mismatches.” A rule without a reason gets deleted by the next person who finds it inconvenient.

Special cases. A list of every supplier, customer or situation that gets treated differently, with what to do. This list is often the single most valuable thing you capture.

Then ask the expert to review it, and ask a colleague who has never done the work to read it and list what they do not understand. Their questions show you the gaps.

Stage three: encode the rules in the tool

Documentation helps, but people under pressure skip it. The more rules you can move into the tool itself, the less depends on anyone remembering.

Go through your rules list and ask of each: can the tool enforce this or check it automatically?

Rule in Priya’s head	Encoded as
Supplier X needs a PO number on remittance	Required field when supplier is X
Logistics supplier is paid within 7 days, not 30	Payment terms field on the supplier record
Payments over a threshold need a second approver	Approval step triggered by amount
Never pay a supplier with unverified bank details	Payment blocked until “verified” is ticked

Special cases often become fields on a record rather than lines in a document. Once the logistics supplier’s payment terms live on their supplier record, nobody has to remember them. Required Fields and Validation: Stopping Bad Data at the Door covers the mechanics.

Some knowledge will not encode neatly. Judgement calls, relationship context, “call this person before you chase them”. That stays in the document, linked from the relevant record so it is in front of people when they need it.

Stage four: test with someone else at the wheel

This is the step teams skip, and it is the only one that proves the work succeeded.

Pick someone who has not done the process before. Have them run a real cycle using only the tool and the document, with the expert in the room but sitting on their hands. The expert may only speak when the newcomer is about to make an actual mistake.

Every time the expert has to intervene, you have found a gap. Note it, fix the document or the tool, and carry on. Expect plenty of gaps on the first run. A second run a cycle later should need far fewer.

Ideally, the newcomer then runs a cycle with the expert unavailable but reachable. That is the closest rehearsal you will get to the real absence.

Keep it from drifting back

Once the knowledge is spread, it can concentrate again. A few habits help:

Rotate the work. Have a second person run the process at least every few cycles.
Update the document when rules change, as part of making the change, not afterwards.
Name an owner for the process, distinct from the person doing it. Who Maintains the Tool? Assigning Ownership After Launch covers this.

Where to start this week

List the processes in your area that would stall if one particular person were away for a month.
Book the first observation session with that person for the most critical one.
Start a rules-and-reasons list and a special-cases list during the session.
Pick the colleague who will run the first test cycle, and put a date in the diary.