Questions we answerProcess and ownership
Nobody has written our processes down. Is that a problem?
Only where a process runs regularly and one person knows it. Documenting everything is a project small teams abandon; documenting a broken process makes the bad version official.
Free · a few minutes · starts from “Something in the team isn't working”
The short answer
Only where a process runs regularly and only one person knows how. Documenting everything is a project small teams start twice and finish never. Write down the two or three where a single absence would stop work, and leave the rest undocumented on purpose. And if a process is currently broken, fix it before writing it down — otherwise the effort has been spent making the bad version official.
The advice available on this is mostly published by people who sell documentation — consultancies who write procedures, or tools that host them — so it concludes that you should document everything, starting now. For a team of twelve, that is a project that competes with the work and usually loses.
Triage is the actual question. Not whether documentation is good, but which few pieces are worth it, and whether the thing you are about to write down deserves to be preserved in its current form.
Is it really this?
Worth checking before you spend anything. These are the signals that tend to tell the two apart.
Signs it is
- You can name a process where one person's absence would stop work within days.
- The same questions get asked of the same person repeatedly, and the answers are stable.
- Something happens monthly or more often and is reconstructed from memory each time.
Signs it's something else
- The real risk is that one person holds everything, which is a dependency problem that documentation only partly addresses.
- The process genuinely differs every time, in which case what is worth writing is the decision, not the steps.
- Nobody has decided who owns the work, and writing down how it is done will not answer who does it.
What's usually behind it
- Somebody about to go on leave, and a quiet realisation that nobody else knows how.
- A new starter asking questions that only one person can answer.
- An audit, a client questionnaire or an insurer asking for something in writing.
What people usually get wrong
- Starting with a template and a plan to document everything. It is the reliable way to produce nothing.
- Having the founder write it, rather than the person who actually does it.
- Writing it once and never touching it, so that within a year it describes a process nobody follows and quietly misleads new starters.
The options, and when each one fits
In no particular order. Which of these fits depends on your situation, not on the question you typed.
Document the critical few
Two or three processes exist where a single absence stops work. Start and stop there.
Fix it first, then write it
The process is not working. Recording it now preserves the wrong thing.
Reduce the dependency instead
The real risk is one person holding it. A second person who can actually do it beats a document about it.
Leave it undocumented
The process runs rarely, or changes each time, and the effort would go stale before it was needed.
When doing nothing is the right call
Most processes in a small business genuinely do not need writing down, and deciding that deliberately is different from never getting round to it. The test is whether one person's absence would stop work — where it would not, leave it.
What the diagnostic asks
- What is going wrong and how long it has been like this.
- Who owns the work and how much of it is written down today.
- How repeatable the work is and how often it comes round.
- Whether one person is the common factor.
“I don't know” is always an answer. Nothing is assumed on your behalf.
The routes it weighs
Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.
Process improvement
Change how the work flows — remove steps, name an owner, fix the hand-offs.
Develop
Build the capability in someone already in the team, with time and support.
Redistribute
Move ownership of the work to where it fits, and make that explicit.
Do nothing yet
Record the issue, set a revisit date, and decide what would change your mind.
AI Assist
Keep a person in charge and give them AI for drafting, summarising, checking or analysis.
What changes the answer
- A process that runs weekly and is known by one person is the clearest case for writing it down.
- A process that is still changing every month is the clearest case for waiting.
- A process that is not working today should be fixed first, not recorded.
Get your own read
A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.
Related questions
- Too much depends on one person. What are my options?Reduce the fragility before it becomes a crisis: write the work down, develop a second person, move adjacent work off them, or decide it is acceptable for now with a date to look again.
- Should I document the process before automating it?Yes, and not because documentation is virtuous. Writing it down is how you find the steps that should not exist — which is most of the value automation ever delivers.
- Nobody owns this work. What do I do?Give it an owner. That is almost always the first move, and it is faster and cheaper than anything else on the list.
- Why do new starters take so long to get up to speed?Usually because the knowledge is in one busy person's head and nobody owns the first month — not because the induction is thin or the person is slow.
- Is my business too small for a CRM?Often yes, for now. A CRM solves a handoff problem, not a memory problem — and a half-adopted one is a worse record than the spreadsheet it replaced.
- How do I fix handoff problems?Work fails at the joins more often than in anyone's hands. Fixing it means agreeing what "ready" means at each boundary — and having someone own the outcome across it.