Every small business has an operating manual. In most of them, it is not written anywhere. It lives in the heads of two or three people, usually including the owner.
It covers how pricing really works, which clients need a phone call instead of an email, what to do when a particular system fails, and which vendor actually delivers on time. It is the most valuable document the company has, and nobody can read it.
That works until one of those people is on vacation, out sick, or gone. Then the business finds out how much it did not know it depended on them.
Why it never gets written
Owners know this is a problem. Most have said at some point that they need to get things documented. Very few do, for understandable reasons.
The people who hold the knowledge are the busiest people in the company. Writing it down feels slower than just doing the task. And documentation projects have a reputation for producing thick binders that are out of date the day they are finished.
So the knowledge stays where it is, and the risk grows quietly as the business does.
Start with what would break
The way out is not to document everything. It is to document the right things first.
I ask a version of the same question we use in our quarterly scorecard: what would break if a specific person disappeared tomorrow? Not in theory. In the next two weeks.
The answers are usually specific. Payroll would not get processed correctly. A key client would not know who to call. Nobody else knows the login for a critical system. A certain kind of quote would go out wrong.
That list is your documentation plan. Start at the top, with the thing that would hurt most.
Write for the person doing it, not for an auditor
The documentation that gets used looks very different from the documentation that gets written for compliance.
Short. A one-page checklist is used. A twenty-page procedure is not.
Written at the moment of doing. The best time to document a task is while doing it. Record your screen, or talk through it while someone else takes notes. Then clean it up.
Focused on judgment, not just steps. The steps are often obvious. What matters is the decision points. When do you make an exception? What does a problem look like before it becomes one? Who do you call when it goes wrong?
Findable. One place, with a simple structure. If someone has to ask where the instructions are, they will just ask for the answer instead.
Test it by handing it over
Documentation that has never been used is a draft.
The real test is having someone else follow it while the author watches and stays quiet. Every place the new person hesitates, guesses, or asks a question is a gap. Fix those, and the document becomes useful.
Vacations are an underrated opportunity here. Before a key person takes time off, have someone else run their critical tasks for a week using only what is written down. It is uncomfortable the first time, and it reveals more than any review meeting.
Keep it alive
The other reason documentation fails is that it goes stale. The process changes and the document does not.
A few habits help:
- Assign each document an owner who is responsible for keeping it current.
- When something goes wrong because instructions were missing or wrong, fixing the document is part of fixing the problem.
- Review the most critical documents on a schedule, even if it is only once or twice a year.
- When someone new joins, have them flag anything that was confusing or outdated. Fresh eyes catch what experienced people skip.
The owner goes first
Most of the undocumented knowledge in a small business belongs to the owner. That is uncomfortable to admit, because it is also part of what makes the owner feel necessary.
But a business that cannot run without its owner for two weeks is not an asset. It is a job with overhead. Writing down what you know is one of the most practical ways to start building something that stands on its own, which is the whole point of building a company in the first place.
It is also a relief. The things you no longer have to hold in your head free up room for the work only you can do.
A practical first step
Pick one person, including yourself. Ask what would break if they were gone for two weeks. Write down the top three answers, in plain language, on one page each. Then hand those pages to someone else and see what happens.
That is not a documentation project. It is an afternoon. Do it every month, and within a year the most important parts of the operating manual will finally exist somewhere other than in someone's head.