A client told us once that he was tired of explaining things that should be obvious. He said it felt like writing the instructions on a shampoo bottle. Wet hair. Lather. Rinse. Repeat.
We laughed, and then it stuck with us, because it points at something we see in almost every company we work with.
Teams get process wrong in two directions. They write way too much, or they write nothing at all. Both end up in the same place, which is people guessing. And guessing costs you money, consistency, and your sanity.
Problem one: the 350-page manual
Some teams treat documentation like a legal exercise. Every edge case, every exception, every "but what if" somebody raised in a meeting three years ago gets written down, with cross-references and disclaimers. That was my problem. I personally wrote every page of our original Ops Manual…all 350 pages of it. Guess what? I'm the only one who ever read the entire document. Beautiful, accurate, but completely useless.
Here's what goes wrong with it:
- It takes forever to write. Somebody spends six weeks on a document instead of doing the actual work. By the time it's done, the process has changed twice.
- It's outdated before it's finished. The process changed in month two. The manual didn't. Now it's misinformation, which is worse than no information.
- Nobody reads it. Be honest. Nobody has ever read page one hundred. Most people don't finish page ten. You've created a reference document that nobody references.
- It assumes your people are idiots. Spelling out every keystroke, every click, every decision tells a competent adult you don't trust them to think. They resent it. They ignore it.
If your process document needs a table of contents, it's not a process. It's a book nobody ordered.
The fix is usually just cutting. Key steps, decision points, and what a good outcome looks like. A one-page checklist gets followed. A binder gets shelved. The constraint forces you to choose what actually matters.
After we (I) got this right, our team re-wrote our manual. The entire manual, how to do every job in the business, was only 22 pages.
Problem two: it's all in somebody's head
The other extreme is more common and more expensive.
We set a goal with a client to get his core processes documented. Checked in a few weeks later and asked how it was going. He said great, he'd mapped them all out. In his head. He had it all memorized and knew exactly how things worked.
That's not documentation. That's a single point of failure.
A process in somebody's head isn't a process.
What it costs you:
- Everything stops when that person's out. Vacation becomes a business continuity event. Someone calls in sick and you're scrambling. That person's irreplaceable, which means they know it, and leverage isn't your friend. They're holding you hostage (intentionally or unintentionally).
- Nobody does it the same way twice. Three people, three interpretations, three different results. Quality variance goes up. Consistency goes down. Customers notice.
- You can't hire past it. Every new person needs the same person to explain the same thing. Your experienced person spends half their time training instead of doing their job.
- You can't sell it, either. Buyers pay for systems. They discount hard for key man risk. If your business stops when one person leaves, you've built a job, not a company.
The version that actually works
Somewhere between the huge binder and the vapor is the thing you want, and it's less work than people think.
Write the steps somebody would miss. Not every step. The ones where people actually go wrong. If the last three mistakes all happened at the handoff, document the handoff. If people always forget the compliance check, put it in bold. Focus on friction. Document the 20% of the work that gives you 80% of the results.
Say what done looks like. Most process documents describe activity and never define the outcome. Flip that. "Call the customer" isn't an instruction…"confirm they received the shipment and have no questions" is. Outcome clarity beats activity.
Name the owner. A process without a name attached belongs to nobody, which means it belongs to you. Name a person. They own it, they update it, they train on it.
Keep it to one page if you can. Two if you have to. The constraint forces you to figure out what actually matters and what's just noise.
Put it where the work happens. A document in a shared drive nobody checks is the same as a document that doesn't exist. On the wall. In the system. At the point where the decision happens.
Start ugly
The biggest reason companies have no documentation isn't laziness. It's perfectionism.
Somebody decides the process rollout needs a template, a review cycle, and a kickoff meeting. There's a steering committee discussion about standards and formats. Eighteen months later there's still nothing written down, and three people have quit because the process changed three times and nobody updated the documentation that doesn't exist.
Skip all that. Have the person who does the job write down how they do it, in their own words, in twenty minutes. It'll be rough. It'll have typos. It won't be beautiful. Fix it the second time somebody uses it and finds a gap. Let reality refine it instead of a committee.
An ugly process that exists beats a beautiful one that's still being planned. Every time. The imperfect document you actually use is infinitely more valuable than the pristine document that's still in draft form.
Bonus – record your instructions into AI and have it make a first draft for you.
Why this matters
You can't delegate what you can't describe. You can't scale what only one person knows. And you can't hold anybody accountable to a standard that was never written down.
Documentation isn't bureaucracy. Done right, it's the thing that lets you stop repeating yourself and lets your team stop guessing.
Bottom line: If the process only exists in somebody's head, it doesn't exist. Get it on one page this week, even if it's ugly. You can make it pretty after somebody's actually used it. The timing matters more than the polish.
Ryan Giles