The Things That Cannot Be Documented

Documentation has a boundary. Pretending otherwise produces long documents that leave the organisation just as dependent.

Once the minimum record described in “The Things That Cannot Be Documented” is defined, the practical challenge is keeping it current as work changes. A coordinator can use this useful page 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 does not transfer in writing

Trust with a client, built over years.

Judgement across many cases: knowing when a situation is going wrong before there is evidence.

Feel for a machine, a market, a difficult person.

Tacit skill of any kind — the difference between following the steps and doing it well.

And standing: the reason people listen to a particular person, which is not transferable at all.

What this means practically

Writing more will not close these gaps.

The transfer mechanisms are different: working alongside, doing the task with supervision, meeting people together, taking over gradually rather than at a point.

Which is why pairing and shadowing have their own notes, and why they are slower and more effective than any document.

The part that can be captured

Even for untransferable knowledge, the surroundings can be written.

Who the people are and what they care about.

What has gone wrong before and what the warning signs were.

The specific cases that formed the judgement, written as short accounts.

That is not the judgement itself and it shortens the time a successor takes to build their own.

Relationships specifically

You cannot transfer a relationship. You can introduce somebody, involve them over months, and let the relationship transfer partially and slowly.

Which takes a year and cannot be compressed.

Its own note covers client relationships held by one person, and the honest message there is that starting early is the only mechanism.

Accepting the residue

After everything writable is written and everything transferable is transferred, something remains that only the person has.

That is normal and not a failure.

The question is its size: a residue of a few percent is a risk you carry; a residue of half the operation is a problem.

What to do about the residue

Know what it is, specifically.

Decide whether it is survivable: what actually happens if it is lost.

And for the parts that are not survivable, use the slow mechanisms now rather than planning to use them later.

The note on succession without a successor covers the case where there is nobody to transfer to.

The mistake to avoid

Concluding that because some things cannot be written, writing is pointless.

The writable part is usually larger than people assume and cheaper than they expect.

Do the writable part, then work on the rest with the mechanisms that suit it.

What to check

Which of your dependencies are knowledge and which are relationship or judgement?

Have you written the surroundings for the untransferable parts?

Is anybody being brought alongside for those?

And do you know what the residue actually is?

The point

Documentation has a boundary.

Write what is writable, pair on the rest, and do not let the unwritable part prevent the writable part.

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.