I have written that a good onboarding document is one of the four that every project should have. People asked me to go deeper on that one specifically, because it is the document with the most immediate, visible payoff — the difference between a new hire who is contributing on day one and one who spends their first fortnight quietly lost, afraid to admit how little they have been told.
This is that deeper look. It applies whether you are onboarding a developer into a codebase or a new shop assistant into a business. The principle is identical: the knowledge a newcomer needs already exists, scattered in experienced people's heads, and the onboarding doc is simply the act of writing it down once instead of explaining it badly forever.
What onboarding actually fails on
When a new person is slow to become useful, it is rarely because they are incapable. It is because they are missing a hundred small pieces of context that everyone around them assumes is obvious. Where things are. Who to ask. How we do this particular thing. The password to the thing. The unwritten rule that everybody knows and nobody said.
Each of these is tiny. Together they are a fog, and the new person spends their first days groping through it, interrupting busy colleagues for fragments, afraid that asking too much will make them look foolish. The cost is enormous and almost entirely invisible, because it shows up as a vague slowness rather than a single fixable problem.
The onboarding doc dissolves the fog by writing the hundred small things down in one place, so the new person can absorb them at their own pace without having to extract each one from someone's memory through awkward questions.
A new hire is rarely slow because they are incapable. They are slow because they are missing a hundred tiny pieces of context everyone assumes is obvious. The onboarding doc is those hundred things, written once.
What goes in it
The onboarding doc answers the questions a new person actually has in their first days, in roughly the order they hit them. For most businesses that means:
- The orientation. What this business does, who its customers are, and how the new person's role fits. Short — a few sentences — but it grounds everything else.
- The access list. Every tool, account, system, or key they will need, and how to get into each. This is the single most practical section and the one most often missing. A new person who cannot get into the thing they are meant to use is stuck on day one for no good reason.
- The "how we do X" procedures. The handful of routine tasks they will do repeatedly, written as steps. Not everything — the common things. How to record a sale, how to handle a delivery, how to get the project running, whatever the daily work actually is.
- The people map. Who does what, and who to ask about which kinds of question. New people waste enormous energy figuring out who to approach. Tell them.
- The unwritten rules, written. The things "everyone knows" that no one ever says — how we talk to customers, what we never do, the cultural norms. Making these explicit is a gift, because they are exactly what a newcomer gets wrong and feels terrible about.
The test hidden inside writing it
Here is the part founders underestimate. Writing the onboarding doc is also a test of whether you actually understand your own business — and you will often discover that you do not, quite.
When you sit down to write "how we do X," you frequently find that there is no clear answer. Different people do it differently. The "process" is actually three people's improvisations that happen to mostly agree. You cannot write down the steps because the steps were never decided — they were just absorbed.
This is uncomfortable and extremely valuable. The act of documenting forces you to either find the real process or admit there isn't one, and to make it consistent. As I have said before in a different context: if you cannot write down how something is done, you do not really know how it is done — you have just memorised a path. The onboarding doc surfaces every place where your business runs on memorised paths rather than actual systems.
Keeping it true
An onboarding doc that has gone stale is worse than none, because it actively misleads. The discipline that keeps it accurate is the same one that keeps all documentation alive: keep it close to the work, keep it short enough to actually read, and give it a clear moment of maintenance.
The "newest person maintains it" habit above is most of the solution. Beyond that, glance at it whenever something it describes changes — a new tool, a changed procedure, a reorganised team. The doc does not need a heavy review process. It needs to be small, central, and touched by every new arrival, which keeps it honest through constant low-grade correction.
What to do this week
If you have ever onboarded someone and watched them flounder, you already have the raw material. Open a document and start with the access list — every account and tool a new person needs and how to get into each. That alone will save the next hire their worst day. Then, over a few sittings, add the procedures and the people map and the unwritten rules, writing for the specific person you most recently hired and the questions they actually asked.
You are not writing a manual. You are writing down the fog, once, so that the next person walks in instead of groping. It is among the highest-return hours a small business can spend, and the return arrives the very first day someone new uses it.