The Knowledge That Never Gets Written Down

Every organisation has documentation covering some of what it does. The problem is that the documented part is rarely the part that matters when somebody leaves.

Once the minimum record described in “The Knowledge That Never Gets Written Down” is defined, the practical challenge is keeping it current as work changes. A coordinator can use daily work tracking to plan review time, compare the effort attached to recurring processes and identify work that still depends on one person, without confusing activity visibility with proof that the underlying knowledge has actually been transferred.

For an independent benchmark, compare the local approach with Atlassian knowledge-sharing guidance; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

What gets written

Steps that are stable, repeated and easy to describe.

Things somebody was asked to document.

Things required by a client or a regulator.

All of which are the parts a competent person could work out anyway.

What does not

Why. The procedure says to do it this way; nobody wrote down what happened the time it was done the other way.

Exceptions. The client who is invoiced differently, the supplier who needs chasing on a Thursday, the machine that needs restarting before the sequence runs.

Judgement. When to escalate, when to let something go, what a bad sign looks like early.

Relationships. Who at the client actually decides, who is difficult, who left and who replaced them.

And history. Why the contract has that clause, what was agreed verbally, which approach was tried and failed.

Why it stays unwritten

It is not procedural, so it does not fit a procedure template.

It is invisible to the person who holds it. Knowing which supplier to chase does not feel like knowledge; it feels like ordinary competence.

It surfaces only when needed, which means it cannot be captured by asking somebody to write down what they know.

And it accumulates in fragments rather than in blocks.

What this changes

Documentation projects aimed at capturing procedures do not address it, which is why they leave organisations still dependent.

The useful capture is different in form: short notes attached to specific things, made at the moment the knowledge surfaces.

Its own note covers writing the minimum that actually helps.

The two-kinds test

For each thing on your dependence map, ask: is what is missing the steps, or the reasons?

Steps are cheap to write and rarely the gap.

Reasons and exceptions are the gap, and they need a different method: capture as it happens rather than capture as a project.

What cannot be captured at all

Relationships, partly. You can note who decides what; you cannot transfer fifteen years of trust.

Judgement built on many cases.

Which is the honest limit and has its own note. Some knowledge is transferred only by working alongside somebody, and the answer there is pairing rather than writing.

The practical implication

Stop trying to document everything and start capturing exceptions and reasons as they arise.

One line, attached to the thing it concerns, written when somebody asks a question nobody had asked before.

Over a year that accumulates into something far more useful than a procedure manual.

What to check

Does your documentation contain any reasons, or only steps?

Where is the exception knowledge — the client who is different, the machine that misbehaves?

Who would know why a particular decision was made three years ago?

And when somebody asks an unusual question, does the answer get written anywhere?

The point

What gets documented is the part a competent person could work out anyway.

What is missing is the reasons, the exceptions, the judgement and the relationships.

Underlying all of this

Everything in this collection reduces to four habits: know where the dependence sits, do the cheap fixes first, use the absences that already happen as rehearsals, and decide deliberately about what remains. None of it requires a framework, a tool or a consultant, and an organisation that does those four things consistently is substantially harder to damage than one with a succession document nobody has read.