Don't Document The Process Until Somebody Has Done The Work
Standard advice says get it out of people's heads and write it down. That's right about the destination and wrong about the timing, and the wrong timing freezes the improvised version with authority.
Standard advice says write it down. Get the process out of people's heads, make it repeatable, stop depending on the one person who knows how it goes.
That advice is right about the destination and wrong about the timing, and the wrong timing is expensive in a way that's hard to see later.
What happens when you document too early
Here's a sequence I've watched more than once.
A company has been doing something informally for years. They hire someone experienced to own it. Sensibly, they want it documented, so they gather everything that's been done before, feed it through a model or a consultant or a long meeting, and produce a clean process document.
Then they hand it to the new person and ask them to follow it.
What they've just done is take the accumulated habits of people who were improvising, freeze them, and put them in front of the one person in the building most likely to know a better way.
The document is now the process. It has authority. It was made deliberately and it looks official, and the new hire's actual read, which is that two of these steps are in the wrong order, now arrives as a complaint about something the company just built.
The version that works
Skip the document. Let them do the work.
The good case looks like this. The new person asks whether they can build the process themselves rather than inherit one. Then they don't build it either. They get into the work, run it live a few times, and find something the old way was structurally hiding.
In one case the finding was that two kinds of training had always been delivered together, and separating them meant customers could get value from the first one while still waiting on a dependency for the second. That's not a refinement. It changes what the process is, and it's only visible from inside the work.
Now you write it down, and what you're writing down is the better version.
What the document is actually for
Here's the part that makes this expensive rather than merely wasteful.
Ask what you're documenting. A process. Fine. Now ask what you do with the documentation once it exists, because nobody writes a process document to have a process document. You write it so you can build on it. You train people against it. You put it in the onboarding pack. You turn its steps into stages in the CRM, fields on a form, triggers in a workflow, an agent that runs the middle of it.
So the sequence is: describe a process nobody has run, then build systems on the description.
Everything downstream inherits the guess. The automation encodes it. The reporting measures against it. New hires are taught it as how we do things. And every one of those is more expensive to change than the document was, which means the document stops being a draft the moment anything is built on it.
And it feels like work. That's what makes it hard to catch. Writing the process, mapping the stages, configuring the tool, they all produce visible artifacts and a real sense of progress. Nobody looks at a week spent building a workflow and thinks that was avoidance. But if the process underneath it was invented rather than observed, the week produced motion and no information.
The best case is that you wasted the effort, because the process changes and probably changes a lot. The worse case is that it doesn't change, because now too much is built on it to be worth revisiting, and you've operationalized around a version nobody ever tested. That one doesn't announce itself. It shows up two quarters later as a workflow everybody routes around and nobody will admit is wrong.
I build agentic workflows for a living and this is the failure I watch for hardest in my own work. Not because automation is risky. Because automation is so good now that it will faithfully execute a bad process forever, at scale, without complaining, and the complaining is what used to tell you something was wrong.
The condition
This isn't an argument against documentation. Undocumented process is a real liability and it gets worse as you grow.
It's a condition on when. The person doing the work has to have done the work before you write it down. Not observed it. Not been trained on it. Done it, enough times to have hit the parts that don't go the way the description says.
Before that, what you're documenting is a description of a process rather than the process. Those look identical on paper and diverge immediately in practice.
Why it's tempting to go early
Because documenting feels like progress and doing feels like chaos.
There's a stretch at the start of anything where nobody can point to a finished artifact, and that's uncomfortable, especially if someone senior is asking how it's going. A process document resolves the discomfort. It's a thing you can show. It just isn't a thing that's true yet.
The other reason is that experienced people can usually write a plausible version of a process they haven't run. It'll be structurally reasonable, correctly ordered, and wrong in exactly the places where reality is going to bite, which are the places nobody can predict from the outside.
So the sequencing is do it, then write it, then automate it. That order isn't bureaucratic caution, it's the only order in which the thing you automate is known to be right. Getting it backwards produces documents everybody ignores and, worse, systems that reliably execute a version nobody would have chosen if they'd run it once first.