The one idea
You are writing for someone who is not you and is not here.
Not a stupid person — a capable person without your context. They do not know which button, which folder, which of the two spreadsheets called "Monthly Final", or that the report has to run after 9am because that is when the overnight job finishes.
Every one of those is invisible to you because you know it. Making the invisible visible is the entire skill.
Write it so someone who has never done it can do it without calling you.
Name exact files, systems and people. Include what to do when it goes wrong. Then have someone else follow it while you say nothing.
You are externalising tacit knowledge. The expensive parts are not the steps but the preconditions, the failure modes and the decision points — precisely the parts an expert has automated and stopped noticing.
The curse of knowing
The reason experts write bad documentation is not laziness. It is that they can no longer see their own knowledge.
When you have done something two hundred times, the checks have become automatic. You do not experience "wait for the overnight job" as a step; you experience it as the time of day you do this. So you do not write it down, because it does not feel like information.
Three questions surface what you cannot see:
- What do I check without noticing? The glance at the row count. The date range. That the file is the right one.
- What goes wrong, and what do I do about it? Every recurring task has two or three known failures with known fixes. This is the most valuable content in any process document and it is almost always missing.
- What did I have to ask someone the first time? Whatever it was, the next person will have to ask it too.
What a usable process document contains
| Section | Why | Commonly missing |
|---|---|---|
| Purpose | Why this exists and who it is for | Rarely missing |
| When to do it | Trigger, timing, frequency | Often — "monthly" is not "second working day, after 9am" |
| What you need first | Access, files, permissions, information | Almost always missing. Costs the reader a day. |
| The steps | Numbered, in order, one action each | Present but too vague |
| How to know it worked | The check that confirms success | Usually missing |
| When it goes wrong | Known failures and their fixes | Almost always missing |
| Who to ask | A named person, and for what | Often missing |
| Last updated | Date and author | Usually missing, and it determines whether anyone trusts it |
The "what you need first" row is the one that most often ruins someone's day. Access requests take hours or days. Discovering on step four that you need permissions you do not have means the whole task stops — and it is the most preventable failure in documentation.
Be specific to the point of feeling excessive
The instinct is to write at the level you would explain it to a colleague. That is too high. Write it at the level you would explain to a competent person on their first day.
| Vague | Usable |
|---|---|
| Run the monthly export | In Finance Portal, go to Reports > Monthly Transactions. Set the date range to the previous calendar month. Click Export as CSV. |
| Check the totals | The CSV total in column H must match the Dashboard "Month Total". A difference under ₹100 is rounding and is fine. Anything larger, stop and see "When it goes wrong". |
| Upload it to the finance folder | Upload to SharePoint > Finance > Reconciliation > (current year). Name it recon-YYYY-MM.csv. |
| Let the team know | Post in the #finance-ops channel, tagging @Priya. If she is away, tag @Rohit. |
Notice what the right-hand column adds: exact names, exact paths, exact file naming, a tolerance for the check, an escalation route, and a named fallback person. None of it is complicated. All of it is knowledge that currently exists only in your head.
The "when it goes wrong" section that turns a document from decorative to useful:
The totals don't match Almost always the date filter. On the first working day of the month the portal defaults to the current month, not the previous one. Check the date range first.
If the range is right, the overnight job may not have finished — it usually completes by 8:30am but can run to 10am at month end. Wait and re-export before investigating anything else.
If it still doesn't match, do not adjust the figures. Send the export to Priya with the two totals and stop there.
The export downloads empty Usually a session timeout. Log out fully, log back in, retry once. If it is still empty, raise a ticket with IT — it has happened twice and both times it was a portal issue, not us.
That took four minutes to write. It is the difference between a colleague solving it in thirty seconds and calling you on your holiday.
The test that matters
Give it to someone who has never done the task, and watch them do it without helping.
This is uncomfortable, and it is the only reliable test. You will watch them stop at step three, and you will want to say "oh, it's the other spreadsheet". Do not. That moment is the finding. Write it down and stay quiet.
If nobody is available, the weaker substitute is to follow your own document literally — doing only what it says, in order, ignoring what you know. You will find one or two gaps. A real reader finds five.
Writing a process document
1 of 8Do the task once with the document open, writing as you go. Not from memory afterwards. Memory smooths over the small decisions, which are exactly what the reader needs.
Try this
You are leaving your job in two weeks. Your manager asks for a handover note.
You could write a list of your responsibilities. What should you actually write?
Your challenge
Level 3 · IndependentPick something you do regularly that someone has asked you about at least twice. Write the process document for it, with every section from the table.
Then give it to someone who has never done it, and watch them attempt it without your help. Note every point where they hesitate or ask a question.
You have succeeded when a person who has never done the task completes it correctly using only your document. Not when you think the document is good — those are very different bars, and the gap between them is the whole lesson.
What people usually get wrong
- Writing from memory instead of while doing it. You will skip the steps you have automated.
- Omitting the preconditions. The reader gets to step four and discovers they need access they cannot get today.
- Vague nouns. "The system", "the file", "the folder", "the team" — all meaningless to someone who does not already know.
- No failure section. The known failure with the known fix is the highest value content in the document.
- Never testing it on a person. Your own review cannot find what you know.
- No date and no owner. Undated documentation is distrusted, and rightly.
- Explaining why at length before the steps. A short purpose line, then the steps. Someone following it at 9am does not want an essay.
- Writing it once and never touching it again. A document that is wrong in two places is worse than none, because it destroys trust in all of it.
How someone experienced does it
Experienced people write documentation as a by-product of doing the task the first time, not as a project afterwards. The first time you do something you are the ideal author — you still notice everything and you have not yet automated any of it. A week later that knowledge is gone and you cannot get it back.
They also write to the question rather than the topic. Real people arrive at a process document mid-panic, searching for one thing, so headings say "The totals don't match" rather than "Troubleshooting". Someone using Ctrl+F finds the first and not the second, and this single habit does more for usability than any amount of polish.
The most valuable thing they do is treat the questions they get asked as a backlog. Asked the same thing twice? That is the next section to write. Do this for a year and interruptions fall noticeably, because the answer exists somewhere you can point to — and the reputation that follows is being the person whose work does not depend on them being reachable. That is what gets people promoted and, more usefully, what lets them take a holiday.
When not to use this
Do not document a process that is about to change. Writing a detailed SOP for a system being replaced next quarter wastes your time and creates a document that will mislead someone.
Do not document something done once. If it will not recur, a short note in the project file is enough.
And do not write a fifty-page manual where a checklist would do. Length is a cost paid by every future reader. If the task is nine steps, the document is nine steps — the temptation to make it look substantial produces something nobody reads, which is a worse outcome than not writing it.
Why the hour you spend now saves a week
The arithmetic is worth doing once, because it is the argument you will need when someone says there is no time for documentation.
A recurring task done by one person is a dependency. Every time that person is unavailable, the task either stops or someone interrupts them. Each interruption costs both people — the asker's blocked time and the answerer's lost focus, which is longer than the interruption itself.
Documented once, the same task costs the reading time and nothing else. And it compounds: the document also handles the person after that, the person covering during leave, and the auditor who asks how this is done.
There is a second effect that matters more for you personally. Undocumented knowledge makes you feel indispensable and actually makes you stuck. If you are the only person who can run the reconciliation, you cannot be promoted out of running the reconciliation. People who document themselves out of their current job are the ones who get given the next one.
Prove it
Write the process document from the Challenge and test it on a real person.
Record two numbers: how many times they had to ask you something, and how long it took them. Then fix the document so the next person asks nothing.
A document that survives its first real user is documentation. Everything before that is a draft.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned writing SOPs, handover notes and process documentation. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood writing SOPs, handover notes and process documentation. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at writing documentation other people can actually use — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.