The things only you know how to do
In most small service businesses, the operating manual lives entirely in the owner's head. That works right up until you want a day off, a hire, or an exit. Here's why writing it down keeps stalling — and a starting point that doesn't begin with a blank page.
It's a Saturday in October, the first morning off in a long stretch, and the owner of a landscaping company is standing at the edge of a field at his kid's game with a phone against one ear. On the other end is a crew lead who has been with him a long time and is entirely capable of doing the work. The question is which key opens the back gate on the Hollis property, because there are two on the ring that look the same and one of them sticks unless you lift the handle. Then a second question: the customer four houses down wants the dog let inside before the mowers start, she isn't home to do it herself, and the spare key is under the planter.
The call takes four minutes. Then it happens again at 9:40, and at 10:15, and once more right after the game ends.
The crew isn't failing. They're not careless and they're not undertrained. They have no way to know any of this except by asking, because the only place it exists is inside one person's head.
the manual that was never written
Every service business runs on an operating manual. In most small ones, that manual has never been typed or saved anywhere. It's a set of things the owner simply knows. Which customer wants a text before arrival and which one finds that intrusive. Which supplier to call when the usual one doesn't have the part. How an estimate actually gets priced — not the arithmetic on paper, but the adjustments made without noticing they're being made, because the driveway is steep, or the last job at that address ran long.
People who study operations call this tribal knowledge: unwritten, experience-based know-how that lives in people's heads rather than in anything shared. It isn't a defect. It's what builds up when a competent person solves problems at speed for a long time and never has a reason to stop and record the solution. Writing it down was never the job.
And here's the part worth sitting with: it works. For a long stretch of a business's life, keeping the manual in one head is genuinely more efficient than keeping it anywhere else. That head is fast, it's already in the room, and it updates itself for free.
The trouble starts the first day the head wants to be somewhere else.
the bottleneck is almost never trust
When an owner can't hand things off, the explanation usually reached for is trust. He's a control freak. She can't let go. Sometimes that's true. More often it isn't, and the owner in the parking lot is the proof — he trusts that crew with expensive equipment and other people's property, unsupervised, all week.
The real constraint is narrower. To hand off a task, you have to transmit the context with it. When none of that context is written down, transmitting it means narrating it live, from memory, while someone waits. Narrating a task you could finish in ten minutes reliably takes longer than ten minutes.
So delegating shows a loss on the day you attempt it. Every time. The sensible move on any given afternoon is to do it yourself — and each time you do, the manual grows a little longer and stays exactly where it was. The concentration deepens through ordinary, reasonable decisions. Nobody ever chooses it.
why "write everything down" never survives contact
The standard advice is to document your processes. It's correct, and it almost never happens — not because owners are lazy, but because the instruction as given is unworkable.
A project to document everything has no edges. No obvious first entry, no definition of finished, no deadline, and it competes against work that pays. It starts on a blank page, which is the worst possible condition for someone already short on time.
Worse, it asks you to see something you can't. Make the same judgment call a thousand times and it stops registering as knowledge; it registers as obvious. So the attempt begins with the parts that are already easy to state — the parts nobody was interrupting you about — and stalls long before it reaches the key that sticks and the dog under the planter, which are the entries that actually cost you your Saturday.
let the interruptions write it
The way in is smaller than it sounds. You don't have to work out what to document. You are already being told, several times a day, by the people who need the answers.
Every interruption is a bug report filed against the manual. Someone hit a gap and routed around it by calling you. That's your list. It already exists — it's just being delivered by phone and then thrown away.
So keep it. Answer the question the way you always do, and then, before the phone goes back in your pocket, write the answer where the person who asked can find it next time. Not a document. A line.
A rule that makes the decision for you: the second time you answer the same question, write it down. The first time might be a one-off. The second time is a pattern, and a pattern will keep billing you indefinitely.
What accumulates looks nothing like a corporate procedure library. It's gate codes, key quirks, the dog, the backup supplier, which customers want a heads-up and which don't. Unglamorous and specific, and worth more than any binder, because every entry has already proved it was needed.
One caveat decides whether this works: it can't live in a notes app only you open, or you're still the lookup service with a step added to your own job. The test is whether the person who needs it could find it without knowing it exists, while standing at the gate. That usually means attaching the answer to the thing rather than to a handbook — the customer's record, the job, the equipment. People don't consult manuals; they look at what's in front of them. And a photo of the gate with the right key circled beats a paragraph describing it.
the delegation test
If you want to know where the business depends on your memory, there's a direct way to measure it, and it takes one day.
Pick a normal working day and hand it over. Don't prepare — preparing is the thing you're testing the absence of. Brief everyone the night before and you've done the narration again and learned nothing. Go somewhere you can be reached but not present.
Then count the calls. The number is your diagnosis and the content is your table of contents. Each interruption is exactly one entry the manual is missing. Write them down as they arrive, because you won't remember them afterward — for the same reason you never wrote them down before. From the inside they don't feel like knowledge. They feel like Tuesday.
Run it once and the calls usually turn out not to be about judgment or skill. They're about facts. Facts are the cheap part. That's the good news buried in the exercise.
what this doesn't fix
Judgment doesn't document well. You can write down the formula for an estimate; you can't write down the instinct that this customer will be difficult and the number should reflect it. What you can write are the inputs you actually weigh, including the ones that never made it onto the form. That won't transfer the skill — it gives someone learning it something concrete to be wrong against, which is how the skill eventually transfers.
Written things go stale, and a confidently wrong entry is worse than a missing one. So whoever hits the wrongness has to fix it on the spot rather than route it back through you, which means letting other people write in the manual. That's a harder ask than starting it.
And it's slow. It won't make you replaceable in a season. It means that in a year, the Saturday calls are about things that are genuinely hard, instead of about a key.
Start anyway, because this constraint arrives no matter what you eventually want. Hiring is limited by how fast you can narrate. Time off, you've read the opening. And if you ever sell, buyers and appraisers already have a name for it — owner dependence, or key person risk — and they treat it as a discount, and as a reason to structure a deal so you stay attached long after you meant to leave. A business whose manual lives in one head is, from the outside, a business that partly evaporates when that head walks out.
We run into this from our own side. When Catalyst picks up a front desk for a new client, the early stretch of onboarding is a real person on our team answering by hand, and that person spends the first days absorbing exactly this — which customer wants what, which question means what. Sarah, our front-desk assistant, replies over text rather than voice today, with voice still on the roadmap, and live texting switches on once carrier approval for business texting clears. Even then, the automated part is only ever as good as the answers somebody bothered to write down.
the point
The owner in the parking lot doesn't have a trust problem or a discipline problem. He has an inventory problem: the most valuable operating asset in the business has never been written on anything, so the only way to retrieve it is to interrupt him.
You don't fix that with a documentation project. You fix it by noticing that the manual is already being read aloud, in pieces, every working day — and writing down the pieces as they're asked for. It's the only version of this that can compete with the work, because the work is what generates the list.