Documentation captures what people do. It misses how they decide.
Your SOPs are probably fine. They are also answering a different question than the one you need answered when the person who wrote them is gone.
There is a specific kind of disappointment that follows a documentation project.
The project goes well. People write things down. The wiki fills up. Six months later someone new joins, reads all of it, and still cannot do the job, and nobody can quite explain why.
The reason is not that the documentation was bad. It is that documentation is a record of procedure, and the thing that makes an experienced person valuable is not their procedure.
The SOP and the exception
Take any process document that has survived more than two years in a real company. Somewhere in it there is a step that reads like this:
If the order exceeds the threshold, route to Operations for approval.
Clear, testable, correct. Now ask the person who actually runs that process what happens in practice, and you get something closer to this:
Route it to Operations, unless it's Kowalski's account, in which case Ops will sit on it for a week and you should call Denise directly. If it's over the threshold but under about double, and it's a repeat customer, honestly just approve it and tell Ops after. If it's a new customer over the threshold, do not approve it, no matter how good it looks, because we got burned on exactly that in a way that took a year to unwind.
None of that is in the document. All of it is the job.
And notice that it is not disorganization. That is not sloppiness waiting to be cleaned up into a better SOP. It is a set of calibrated judgments about specific people, specific risks, and specific history. Write it into the process document and the process document becomes forty pages that nobody reads, which is a worse outcome than the one you started with.
Why process documents decay
Documentation has a structural problem that no amount of discipline solves. Three of them, actually.
It is written by the wrong person at the wrong time. Documentation is usually written by whoever has capacity, not whoever has the knowledge, and usually during a slow week rather than during the hard case that would have been worth recording.
It answers the question the writer thought to ask. A person documenting their own work writes down the parts they can see. The parts they have automated into instinct are invisible to them. Ask an expert to list what they know and you get a list of what a beginner would need, which is the procedure, which you already had.
It has no failure signal. A broken deployment tells you it is broken. A process document that has quietly stopped matching reality tells you nothing at all, right up until someone follows it and causes a problem.
The result is predictable. Documentation drifts toward describing the easy 80 percent of the work with increasing precision, while the hard 20 percent, which is the entire reason the role requires a person, stays in someone's head.
What a decision actually contains
It is worth being precise about what is missing, because "tribal knowledge" is too vague to act on.
| What documents hold | What the person holds |
|---|---|
| The steps, in order | Which steps are load-bearing and which are ceremony |
| The rule and its threshold | Which rules bend, for whom, and by how much |
| The approved vendor list | Which vendor actually answers on a Friday |
| The escalation path | When escalating makes it worse |
| The current process | The three incidents that shaped it |
| What to do | What to do when none of this applies |
Everything in the right column has the same shape. It is a judgment about an exception, learned from a case, attached to a reason. That is a different kind of object than a procedure, and it does not fit in a procedure-shaped container.
It also degrades differently. A procedure goes out of date. A judgment does not go out of date, it goes with the person.
The interview is the format
If people cannot write down what they know, and the reason is that they cannot see it, then the fix is not a better template. It is a better question.
This is not a novel insight. It is how oral history works, how expert elicitation in safety-critical industries works, and how any decent investigative interview works. You do not ask "what do you know". You ask about a specific hard case and then you keep asking why until the answer stops being about the case and starts being about the rule the person did not know they had.
Three things make the difference between an interview that surfaces judgment and one that produces another procedure.
- Ask about exceptions, not process. "Walk me through the approval flow" gets you the SOP. "Tell me about a time you approved something you probably should not have" gets you the actual decision boundary.
- Follow the reason, not the story. The anecdote is not the asset. The rule the anecdote taught is the asset, and it usually takes two or three follow-ups to get there.
- Do it out loud. Speaking is faster than writing by a factor of about four, and more importantly it is lower effort, so people keep going past the point where they would have stopped typing. The parts they would have edited out are frequently the parts worth having.
An hour of the right questions gets more out of a twenty-year operator than a quarter of documentation requests. That is not a claim about tooling. It is a claim about format, and it was true before software was involved.
How to tell if yours is working
A short test you can run on your existing documentation, without buying anything.
Pick your most experienced person in a given function. Pick a genuinely hard case from the last year, one where the outcome depended on someone making a call. Then read your documentation and try to determine what it would have told a competent newcomer to do.
If the documentation would have produced the same decision, you are in good shape for that case.
If it would have produced a defensible but wrong decision, you have found the gap, and it is exactly the size of the person you would lose.
Run it three times. The pattern will be obvious.
The point
Documentation is not the enemy here, and this is not an argument for having less of it. Procedures should be written down. Most companies should write down more of them.
It is an argument about scope. Documentation answers "how is this done". It was never designed to answer "how does this person decide", and the second question is the one that becomes urgent the week somebody resigns.
Those are two different projects. Most companies have only ever run the first one, and then wonder why the second problem is still there.