I don't try to write a standard operating procedure the first time I do a task, because I'm still figuring it out. I write it the second time, while I'm doing the task again and already know the real steps. First time is for learning the process. Second time is for documenting it, so a new hire, a volunteer, or a VA can do it without me.
For years everything lived in my head, which meant I could never really take a day off. Even on vacation I was the person a teammate texted when a workflow broke, because the process for fixing it existed nowhere except my memory. I told myself that was just what running a small business looked like. It was a habit I hadn't fixed yet.
This is hack 14 in my "30 Hacks From Dahlia" series, one of the least flashy and one of the ones that changed the most about how my business runs. The fix wasn't a new tool. It was timing: I stopped documenting a process the first time I did it, and started documenting it the second time.
Why everything living in your head is the bottleneck
Many organizations, including businesses of one, stay stuck because everything runs through the founder's head, so nothing runs without the founder in the room. Hiring the right person doesn't fix that. A sharp new hire, a capable VA or a motivated volunteer can't do a task whose steps only exist in your memory.
I used to think I just hadn't gotten around to writing things down, like a to-do item I kept bumping. I was actually documenting at the wrong moment, so it never stuck, and I quietly gave up every time.
Why the first time is the wrong time to document
The first time you do a task, you're discovering a process, not executing one. You try a step, it doesn't work the way you expected, you backtrack, you find a workaround. Write the SOP right then and you document the confusion, not the process. You don't yet know which steps were necessary and which were you feeling your way.
I learned this by writing things down right after finishing a task for the first time, while it was still fresh. The documents were always messy and wrong in some small but important way, because I was recording what I remembered doing, not what needed to happen. Nobody could follow them without hitting a step that didn't match reality.
How I actually capture it the second time
The second time, the path is proven. So instead of reconstructing a document from memory afterward, I write the steps down as I go, while I'm doing the task again.
I keep a plain note open next to whatever I'm working in and jot each step the moment I take it: what I clicked, what I typed, where the file went, what the setting was called. Sometimes I screenshot a specific screen instead of describing it, because a picture of the actual login page or settings tab is faster to write and easier to follow than a paragraph. For something visual, I narrate out loud as I click through, the way I'd explain it to someone sitting next to me, and turn that into written steps afterward.
The rule is to capture it during the task, not after. Writing from memory always loses something: a step gets skipped because it felt obvious, or the order shifts to how I remember it.
What a good lightweight SOP actually contains
It doesn't need nice formatting, a table of contents or every edge case. A lightweight SOP that gets used beats a comprehensive manual that sits unopened.
How to know a task is SOP-worthy
If I'm sitting down to do a task for the second time, that repetition is the signal. A one-off task doesn't need a written process. A task I'll touch again next week, next month, or in a recurring client workflow shouldn't only exist in my head. The second pass is also when I can write it down correctly.
The first time is for learning. The second time is for writing it down so someone else can do it.
Keeping SOPs from going stale
A wrong SOP is worse than none, because it sends someone confidently down the wrong path. I don't use a quarterly review. The moment anyone hits a step that no longer matches reality (a moved login, a renamed tool, a skipped step), it gets corrected right then, not added to a fix-later list. Leave it a week and it stays wrong for months, and nobody trusts it.
The version I write on the second pass is a working draft. If a VA or a new hire follows it and gets stuck, that tells me where to fix it. I'd take a rough SOP corrected in real use over a polished one nobody has tested.
Key takeaways
- Everything living in the founder's head is what blocks delegation and real time off.
- The first time you do a task, you're discovering the process. Don't try to document discovery.
- The second time, capture the steps as you go: screenshots, real-time notes, or narration, never a reconstruction from memory afterward.
- A good lightweight SOP has four parts: the goal, the steps in order, where things live, and the common mistakes to avoid.
- If you're doing a task again, that repetition is the signal it's worth writing down.
- Fix an SOP the moment it's wrong, not on a schedule. A stale SOP is worse than no SOP.
Frequently Asked Questions
The first time you do a task, you're still figuring out the steps. You take wrong turns, backtrack, and find the real path through trial and error. If you write the SOP during that first pass, you document the confusion, not the process. The second time, you already know what works, so you can write down the actual sequence instead of the messy discovery version of it.
The simplest test is repetition. If you're sitting down to repeat a task you already did once, that repetition is the signal. A one-off task doesn't need a formal process. A task you'll touch monthly, weekly, or as part of a client workflow is exactly the kind that should live outside your head.
A useful SOP does not need to be a polished manual. At minimum it needs the goal, so whoever reads it knows what the task is for. The steps in order, one action per line. Where things live, meaning the exact tool, folder, or login involved, named specifically. And the common mistakes to avoid, the thing that trips people up the first time they try it.
Update it the moment someone using it hits a step that no longer matches reality, not on a fixed schedule. A tool changes, a login moves, a step gets skipped, and the SOP should be corrected right then, by whoever noticed it. Waiting for a quarterly review means the document is wrong for months before anyone fixes it.
