Writing for the person who replaces you

Most workplace documentation gets written by someone who understands the process, for an audience that also already understands it — a quick reference, a reminder, a formality. It's rarely written with the specific, deliberate discipline of imagining someone who has never seen this process before, has none of the surrounding context, and needs to actually be able to act on what's written. That difference in audience changes almost everything about what good documentation looks like.

Why "written for someone who already knows" fails the one person who needs it

Documentation written for people who already understand the process tends to skip exactly the parts an outsider would need — the reasoning behind a step, what "normal" looks like versus what should trigger concern, what to do when the obvious approach doesn't quite fit. These get skipped not out of carelessness but because they feel too obvious to state to an audience that, in the writer's mind, already knows them.

The person who eventually replaces you is precisely the audience for whom none of it is obvious. They're reading the document not as a refresher, but as their only source of truth for a process they've never run. Every assumption the original writer made about shared context is a gap the successor has to fill in blind.

What changes when you actually write for that person

You explain why, not just what. A step described without its purpose invites a successor to skip it the first time it seems inconvenient, because they have no way to know it exists for a reason — see why it has always been done this way survives automation.

You describe the exceptions, not just the standard case. The standard case is usually self-evident once you're doing the job. What a genuine successor needs most is guidance on the situations that don't fit the standard case — because those are exactly the moments they'll have no instinct to fall back on yet.

You state what "wrong" looks like, not just what "right" looks like. Knowing the correct steps doesn't tell a newcomer how to recognise when something has gone off track. An experienced person notices a problem because a number looks unusual or a request feels off — describing that instinct, even imperfectly, gives a successor something to watch for that a pure step list never would.

Why this is hard to do in the moment, and worth doing anyway

Writing for a genuine outsider requires deliberately un-learning your own fluency with the process, which is uncomfortable and slower than writing a quick reference for a colleague who already gets it. It's tempting to skip this effort because most documentation, most of the time, is read by people who already have context — which makes the effort feel wasted right up until the one time it actually matters, when someone genuinely new is relying on it with nothing else to go on.

A practical test for anything you write down

Before finishing a piece of documentation intended to outlast you in a role, ask: could someone with zero prior exposure to this process follow this and get the same result I would? Not "could a competent colleague figure it out" — could someone starting from nothing actually succeed using only what's written here. If the honest answer is no, the document is written for people who don't need it, and the person who eventually does need it will find the gaps the hard way.

Where this matters most

Not everywhere — most day-to-day documentation doesn't need this level of care, and applying it universally would be exhausting and unnecessary. It matters specifically for the processes where a genuine gap in continuity would be expensive: the ones a single person currently owns, the ones with real judgement embedded in them, the ones where "ask the person who normally does this" is not a fallback that will always be available — see the manager who is the process.

Common questions

Why does most workplace documentation fail the person who actually needs it most?

Because it's typically written by someone who understands the process, for colleagues who also already understand it, which means the writer skips exactly the reasoning and context an outsider would need. Those omissions feel obvious to write around at the time, but they're precisely the gaps a genuine successor has no way to fill in on their own.

What's different about documentation written specifically for a successor?

It explains why a step exists, not just what the step is, describes exceptions rather than only the standard case, and states what "wrong" looks like so a newcomer has something to watch for, rather than only knowing the correct sequence of actions with no sense of how to recognise when something has gone off track.

How do you test whether documentation is actually good enough for a real successor?

Ask whether someone with zero prior exposure to the process could follow it and get the same result an experienced person would — not whether a colleague who already understands the job could figure out the gaps. If the honest answer is no, the document was written for people who don't actually need it.

Does every process need this level of documentation care?

No. It's worth the extra effort specifically for processes that a single person currently owns, that involve real judgement, and where there's a genuine risk of that person being unavailable with no other fallback. Applying this standard to routine, well-understood documentation everywhere would be unnecessary and exhausting.

Related: the manager who is the process · why it has always been done this way survives automation · what a notice period is actually for