The reason first hires often fail isn't that the wrong person was hired. It's that the business had nothing to hand them. Everything lived in one head, transfer happened by interruption, and after six weeks of answering questions the owner concluded it was faster to do it themselves.
Documenting before you hire changes the shape of the first month entirely. It also does something more immediately useful: it forces you to look at processes you've never examined, and a meaningful fraction of them turn out to be unnecessary.
Capture first, structure later
The reason most documentation projects stall is that people try to write polished procedures from a blank page. That's writing, and writing is slow.
Capture is different. Capture means recording what you do while you do it, and cleaning it up afterwards. Three methods, roughly in order of speed:
Narrate while working. Do the task, talking through it — voice memo on your phone, or a screen recording with audio. Fifteen minutes of talking produces more accurate content than an hour of writing, because you're describing reality rather than reconstructing it. Transcribe afterwards and edit down.
Screen-record the click path. For anything software-based, record the screen once while doing the task normally. You'll capture the six small steps you'd have forgotten to write — the setting you always change, the filter you always apply.
Keep a running log for a fortnight. Every time you do something, add one line to a text file: task name, roughly how long, and any step that's non-obvious. At the end of two weeks you have an inventory of what your business actually does, which is more useful than any list you could write from memory.
Do the cleanup pass within a few days while you can still remember what you meant. Capture without cleanup produces an archive of recordings nobody watches.
Document in this order
You cannot document everything, and trying is the failure mode. Priority order:
1. What only you know. Every process where you're the single point of failure. Start here regardless of whether it's what you plan to delegate first, because this is the risk to the business, not just to the hire.
2. What you'll delegate first. Whatever the new person will actually do in week one. This is what makes hiring work.
3. What breaks repeatedly. Recurring errors are usually process gaps, and documenting one is often enough to fix it.
4. What happens rarely but matters. Year-end close, a client dispute, a system failure, an annual renewal. Rare processes are the ones you re-derive every time, badly.
Category four is counterintuitive and high value. You do it once a year, which means you've forgotten it by the time it comes round, which means you rebuild it annually from scratch.
What each document needs
Keep the format identical, and keep it short — a page. The essentials:
- Trigger — what event means someone should do this
- Steps — numbered, one action each
- Access needed — which accounts, tools, and permissions
- Decision rules — what to do at the points where judgment is required
- Exceptions — the cases that break the standard path
- Who to ask — when something isn't covered
Decision rules are the part that distinguishes real documentation from a click-path. Anyone can follow steps. What separates a useful hire from a dependent one is knowing what to do when the situation doesn't match the steps.
Write them as thresholds where you can:
Client asks for a change mid-project:
- Under 30 min and in scope → just do it, note it in the README
- Over 30 min or out of scope → quote it as a change order, use template
- Client pushes back on the change order → escalate to meThat's ten seconds to write and it's the difference between a person who can work and a person who has to ask.
Capture the tacit knowledge too
Documentation usually captures process and misses everything else. The things that don't fit a numbered list:
Client quirks. Who approves, who only says they approve. Who prefers a call. Who goes quiet in August. One line each in the client README.
Vendor and tool knowledge. Which supplier is reliable, which needs chasing, which support channel actually gets answered.
History and reasoning. Why you do it the odd way. Undocumented reasoning is why new people "improve" processes back into problems you already solved. One line — we invoice on delivery not milestones because two clients disputed milestone billing in 2023 — prevents a whole category of well-intentioned mistake.
The judgment calls that define quality. What makes work good enough to send. This is the hardest to write and the most valuable. Examples work better than rules: three past deliverables marked "this is the standard" teach more than a page of criteria.
Documenting reveals what to fix
Roughly a third of what you document will make you uncomfortable, and that discomfort is the second return on the exercise. Watch for:
Steps you can't justify. "Then I export it and re-import it because" — and there's no because, just history. Delete the step.
Processes with no owner and no trigger. Things that happen when you notice. These fail silently and they're the first candidates for a calendar entry.
Everything routing through you. If seven documented processes all include "check with me," you've found the reason you can't delegate. Convert those checkpoints into written decision rules.
Undocumentable steps. If you can't write it down, either it's a judgment call requiring experience — which means it isn't delegable yet — or it isn't actually a process, just a habit.
The two-week plan
Realistic, and it gets you most of the way:
Week one — capture. Keep the running log of every task. Screen-record or narrate the five biggest. Don't write anything polished. About twenty minutes a day.
Week two — structure. Turn the log into a list of processes. Pick the eight highest priority. Write each as a one-page document in the same template. Two to three hours total.
Eight documents is enough to hire against. It won't cover everything, and it shouldn't — the gaps get filled by the new person as they hit them, which is both faster and produces better documentation than you writing it alone.
Make the new hire finish the job
Their first month should include: read the eight documents, do the tasks, and correct the documents where they're wrong.
This works for three reasons. New people are the only ones who notice the missing steps, because everyone else fills them in unconsciously. Rewriting is far easier than writing from nothing. And a person who has edited a procedure will follow it, in a way that a person handed a finished manual will not.
Say it explicitly on day one: the documents are drafts, and improving them is part of the job.
Where it lives
All of it goes in your SOP library — 01 Admin/SOPs/ — with the same numbering, owner, and review date as everything else. Documentation that lives in a special "for the new hire" folder becomes stale the moment onboarding ends. Documentation in the working library gets used and therefore maintained.
And keep it on your own drive, in a plain format, not locked inside a tool you might stop paying for. This is the most concentrated knowledge asset your business has. If you ever sell the business, it's a meaningful share of what's being bought.
Next in this series: A Quarterly Business File Audit Checklist