Far fewer than you think. Document the handful of activities where a mistake made while you are not looking would be expensive or hard to reverse, and leave the rest alone. For each of those, the useful thing to write down is not the happy path, which a competent person can work out, but the exceptions and the decision rules, which they cannot.
The test is not whether something is documented. It is whether another person could start the work, finish it, and know when to stop and ask, without a conversation with you.
- Documenting everything before hiring is usually a way of postponing the hire.
- Rank by what a mistake costs in your absence, not by how often the task happens.
- Write the exceptions. The happy path is the part people can infer.
- Your approvals are the bottleneck. Replace them with a decision rule and a threshold.
- If a process has no definition of good, nobody can tell whether the new person is doing it well.
Documenting everything is a way of not hiring
The plan to write down the whole business first sounds responsible. In practice it postpones the decision indefinitely, because the business keeps changing while you document it, and there is always one more process.
It also produces the wrong artefact. Comprehensive documentation written in advance describes the version of the work that exists in your head, which is the tidy version. The messy parts, the exceptions and the judgement calls, are exactly what does not get written down, because you do not notice yourself making them.
You are not trying to make the business runnable by a stranger. You are trying to make one person's first month useful instead of a series of interruptions.
That is a much smaller target and it is achievable in a few days rather than a few months.
Rank by what it costs when you are not there
The instinct is to document the most frequent work. Frequency is the wrong axis, because frequent work is also the work you can most easily demonstrate once and let someone copy.
Rank instead by the cost of it going wrong while you are unavailable. Three questions, quickly:
- Is the mistake reversible? A wrongly formatted internal file is cheap. An invoice sent to the wrong client, a customer promised something you cannot deliver, or a release that breaks a live tool are not.
- Would anyone notice? Errors that surface immediately are self correcting. Errors that surface in three months, when the numbers are already in a report, are the expensive kind.
- Does it touch someone outside the company? Anything a customer sees carries reputational cost on top of the direct one.
Whatever scores high on all three is your documentation list. It is usually three or four activities, not thirty.
Eight fields per activity
For each one, write these. Most fit on a single page.
| Field | Question | What goes wrong without it |
|---|---|---|
| Trigger | What starts this? | Work happens only when someone remembers |
| Owner | Who is responsible for it being done? | Everyone assumes the other person has it |
| Inputs | What is needed before starting? | Half finished attempts waiting on missing information |
| Steps | What happens, in order? | Dependent steps done in the wrong sequence |
| Output | What does done look like? | Work handed back repeatedly for changes |
| Exceptions | When should someone stop and ask? | Confident guessing, which is the expensive failure |
| Metric | How do we know it went well? | Nobody can tell whether the new person is any good |
| Review date | When do we look at this again? | The document quietly becomes fiction |
If you have written a specification for a machine before, this will look familiar. It is close to the same artefact, and our guide on writing a process a model can follow covers the precision side in more detail. The difference is that a person will ask when something is unclear, so you can be less exhaustive and more honest about where judgement is required.
Write the exceptions, not the happy path
This is the part most process documentation gets backwards, and it is where nearly all of the value sits.
A competent person given the goal and the tools will work out the ordinary sequence. What they cannot work out is what you do when the input arrives in the wrong format, when two rules both apply, when the client asks for something slightly outside the agreement, or when the number looks wrong but not obviously wrong.
Those moments are where a new person either stalls, which costs a day, or guesses, which occasionally costs a great deal more. Every one of them is a decision you have made many times without writing down the rule.
For the next two weeks, whenever you deviate from the obvious sequence in a documented activity, write one line: what happened and what you did about it. Do not try to recall them in advance, because you will not. Two weeks of this produces a better exceptions list than an afternoon of trying to imagine every case, and it is the section a new person will actually read twice.
The same habit surfaces the steps you do not know you are doing, which is also what makes mapping a workflow before automating it worth the effort.
Your approvals are the bottleneck
In most one person companies the founder is not the bottleneck on doing the work. They are the bottleneck on approving it, and hiring somebody makes that worse rather than better, because now there is a person waiting on you as well as a queue.
The fix is not to approve faster. It is to write down the rule you are applying when you approve, along with the boundary where you want to be consulted.
A rule has a threshold in it. "Use your judgement on refunds" is not a rule. "Refund without asking under fifty pounds and inside thirty days, escalate anything above either" is. The first keeps you in the loop forever. The second removes you from most of it while keeping you in control of the cases that matter.
Writing these is uncomfortable because it forces you to commit to a number you have been holding loosely. That discomfort is the work.
Six systems, and which one usually comes first
| System | Covers | Usual priority |
|---|---|---|
| Customer support | Intake, prioritising, response standards, escalation, follow up | Usually first, it is customer facing and constant |
| Financial admin | Invoicing, expenses, tax records, monthly review, access | Early, because errors here are expensive and delayed |
| Quality assurance | Test cases, bug reports, severity, release approval, rollback | Before anyone else can ship anything |
| Sales and onboarding | Qualifying, demonstrating, proposal, payment, onboarding | Only if someone else will touch customers |
| Content production | Topics, research, drafting, review, fact checking, publishing | Later, unless content is the product |
| Product development | Idea capture, validation, prioritising, building, testing, release | Last, and mostly stays with you |
Support and financial administration come first for the same reason: both are customer facing or externally consequential, both happen on a schedule you do not control, and both produce errors that are awkward to unwind. Product development comes last because deciding what to build is the founder judgement that a first hire is least likely to be taking over.
What to leave undocumented on purpose
Documenting the wrong things is not neutral. It creates maintenance and, worse, it creates documents people trust that are no longer true.
Leave alone, for now:
- Anything changing weekly. You will spend more time updating the document than following it.
- Early creative exploration. Writing a procedure for a thing whose whole value is that it is unconstrained will make it worse.
- New product discovery. Same reason. The process here is genuinely different every time.
- Founder level strategy. Not a process, a set of decisions.
- Genuinely rare situations. If it happens twice a year, handle it together the next time it happens and write it down then, when it is concrete.
Saying explicitly that something is deliberately not documented is itself useful, because it tells a new person that the absence is a decision rather than an oversight.
The metric nobody has
Of the eight fields, the one most often left blank is the metric, and it is the one that decides whether the hire looks like a success.
Without a definition of good, feedback becomes personal. You end up saying that something feels off, the other person cannot act on that, and both of you conclude the fit is wrong. With a metric, however rough, the conversation is about the work.
These do not need to be sophisticated. Support requests answered within a day. Invoices out by the fifth. No release without the checklist completed. Articles published with sources recorded. The value is in existing at all, not in precision.
The hiring readiness test
Six questions. Answer them about one specific activity you intend to hand over, not about the business generally.
- Can they tell when the work has started? Is there a trigger they can see, or does it currently arrive because you noticed something.
- Can they get what they need? Accounts, files, permissions, context. Access is the most common week one blocker and the easiest to fix in advance.
- Do they know what finished looks like? Ideally an example of a good one, not a description.
- Do they know when to stop and ask? The exceptions list, with the boundary stated.
- Can you review it without redoing it? If checking takes as long as doing, you have not delegated anything.
- Is there a way for them to tell you the process is wrong? The new person will see problems you stopped noticing years ago, and that is worth capturing deliberately.
Any question you cannot answer is a piece of work to do before the start date, and each one is small.
A worked example, honestly
This site is a one person operation and it is a reasonable illustration precisely because it is uneven.
Documented and handover ready. Publishing an article has a written checklist covering the page, the redirects, the index, the sitemap, the feed and a verification step. There is a script that rebuilds parts of the site and a comment stating exactly when it must be re-run, because forgetting it once shipped pages with almost no internal links. Those exist because a mistake was made, which is generally when documentation gets written.
Still founder dependent. Deciding what to build next, and the editorial judgement about whether a piece is honest enough to publish. Neither has a written rule, both are genuinely judgement, and a first hire would not be taking them over.
Intentionally informal. Topic selection and early design exploration. Writing procedures for those would cost more than it returns at this size.
Would need work before hiring. There is no metric on anything, and no automated test suite, so quality currently depends on one person remembering to run the checks. That is the honest gap, and by the argument above it is the thing to fix first, because it is exactly what makes a second person's work impossible to evaluate.
Built by one person, on purpose
Nine free browser tools, each narrow enough for a small operation to maintain properly. No accounts, nothing stored, and the pages say what each tool cannot do.
See the toolsWhat this will not do
Documentation does not make a hire succeed. It makes the first month less wasteful, which is worth a lot and is not the same thing. Fit, communication and whether the role was real to begin with all matter more, and none of them are solved by a process document.
It also will not tell you whether you can afford somebody, which is a financial question rather than an operational one, and one where a professional is worth more than an article.
Finally, there is a real risk of over formalising a two person company. Process exists to replace conversations that are too expensive to keep having. At this size most conversations are cheap, so write down only what fails when it is left implicit.
Frequently asked questions
How much should I document before hiring?
Enough for the specific activities you intend to hand over, prioritised by what a mistake would cost while you are unavailable. That is usually three or four processes and a few days of work, not a manual for the whole business.
What is the most important thing to write down?
The exceptions, and the point at which someone should stop and ask you. A competent person will work out the ordinary sequence on their own. They cannot work out the unwritten rule you apply when something unusual turns up.
Should I document before hiring or with the new person?
Some of both. Write the high cost processes in advance, then have the new person document the rest as they learn it. That produces better documents, because they notice the gaps you have stopped seeing, and it gives them something useful to do in the first week.
Should a contractor or freelancer get the same treatment?
The exceptions and the definition of done matter even more, because you have less time to correct course and usually less shared context. The parts about access and feedback loops matter less for a short engagement.
How do I stop the documents going stale?
Put a review date in each one and keep them where the work happens rather than in a folder nobody opens. A document nobody trusts is worse than no document, because people follow it anyway and then discover it was wrong.
What if the process is still changing every week?
Then leave it alone and say so. Documenting something unstable produces fiction that has to be maintained. Note that it is deliberately undocumented and revisit when it settles.
Where to start this week
Pick the one activity you would hand over first. Write the eight fields for it on a single page, spending most of your effort on exceptions and on the threshold where you want to be asked.
Then run the six readiness questions against it. Whichever you cannot answer is your actual to do list, and it will be shorter than the plan to document the whole business that you have been postponing.
How this was put together: this is drawn from running a small operation and from the places where its own processes have failed, including the specific one described above. It is not research and there is no dataset of first hires behind it. We have quoted no figures on hiring success because we have none. The ordering of the six systems is a judgement about what tends to be externally consequential first, not a finding, and anything touching employment or finance is general information rather than professional advice.