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.

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.

1. 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.
2. 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.
3. 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.

Why do the odd accounts renew. Which vendors actually bend, and how far. What plan B was, the last time something went sideways at the worst possible hour.

Then count how many answers come back as a name.

"I don't know, John knows that."

That sentence is the whole problem, said out loud. It is also the cheapest diagnostic any company has, and almost nobody runs it on purpose.

The names are the map

Most organizations have a mental model of themselves that looks like an org chart. The real map looks nothing like it. It is a much smaller diagram, maybe eleven people in a company of two hundred, and every hard question in the building routes to one of them.

Those eleven are not always senior. They are frequently not managers. The most load-bearing person in a manufacturing business is often a scheduler nobody has promoted in nine years, because she is the only one who knows which of the three suppliers will actually take a Friday call.

You can find them in an afternoon. Sit with the questions your team escalates and mark who they get escalated to. The concentration will be worse than you expect.

What the handoff actually captures

When one of those eleven resigns, a process starts. It has a name, usually "knowledge transfer", and it usually consists of two weeks, a shared document, and a series of meetings with whoever is inheriting the work.

Here is what that process reliably captures: the systems the person logs into, the recurring meetings they attend, the reports they produce, the files they own, and the names of the external contacts they deal with.

Here is what it reliably misses: why they stopped trusting one of those contacts in 2021, which of the recurring meetings is theatre, what they do when the report looks wrong, and the four exceptions to the process that are not written in the process because the process would be unreadable if they were.

The handoff document is not a lie. It is an inventory. Inventories are useful. They are just not the thing you are losing.

Three kinds of knowledge, and only one gets written down

It helps to separate them, because organizations spend almost all of their effort on the first one.

The procedure. The steps, in order. This is what an SOP is for, and SOPs are genuinely good at it. If your business has documented procedures, this part is probably fine.

The context. Why the procedure is shaped that way. Which step exists because of a bad experience nobody wants to repeat. This is occasionally written down, usually in a comment thread on a document from four years ago, and it is effectively unfindable.

The judgment. What to do when the procedure does not apply. Which rules bend, for whom, under what pressure, and what it costs to bend them. This is never written down, because it is not a rule. It is a disposition, built out of a few hundred small cases, and the person holding it usually cannot articulate it unprompted. Ask them to "document what you know" and they will hand you the procedure, because the procedure is the part they can see.

Judgment is the part that walks out the door. It is also the part that took twenty years to build.

The part where it is worth something

There is a version of this argument that leans on scary numbers. We are not going to make it, because the honest data on knowledge loss is thin and most of the figures in circulation do not survive contact with their own footnotes.

What we can say is what one firm told us about their own experience.

A 74-year-old operator sat for a structured voice session. It ran about three and a half hours. Afterwards the firm's own estimate, on their own work and their own criteria, was that over 80 percent of what he knew was now captured.

That is their number, not ours, and it describes one person at one company. We report it because it is the only public proof we have, and we would rather have one real account than a page of borrowed statistics.

What it suggests is narrower than a headline and more useful. The knowledge is not unreachable. It is not so vast that a person cannot get it out. It is just that nobody ever sits down and asks properly, for long enough, with the right questions.

What would have to be true

If you wanted to fix this, and not just feel better about it, three things would have to change.

It would have to happen before the resignation. Two weeks' notice is not a knowledge transfer window, it is a scramble. The capture has to be routine, done on people who are staying, or it is only ever done in an emergency.

It would have to be a conversation, not a form. People cannot fill in what they know, because they do not know they know it. They can, however, answer a question about a specific hard case. The format has to do the work of asking.

And it would have to be worth something to the person answering. A system that asks people to write down everything that makes them hard to replace, with nothing offered back, gets exactly the participation it deserves. This is the part most knowledge management projects never solve, and it is why most of them fail quietly.

Start with the question

You do not need a system to run the diagnostic. You need one afternoon and the willingness to hear an uncomfortable answer.

Ask the hard questions. Count the names. Look at how short the list is.

Every company runs on a few heads that were never written down. The only real variable is whether you know whose they are before you find out the hard way.