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. Not a real one. 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 wasn't. It was a habit I hadn't fixed yet.
This is hack 14 in my "30 Hacks From Dahlia" series, and it's one of the least flashy ones I've shared, but it's also one of the ones that changed the most about how my business actually runs day to day. The fix wasn't a new tool or a system I bought. It was a change in timing: I stopped trying to document a process the first time I did it, and started documenting it the second time instead.
Why everything living in your head is the real bottleneck
Organizations, including businesses of one, stay stuck for a simple reason: everything runs through the founder's head, so nothing can run without the founder in the room. That's not a delegation problem you solve by hiring the right person. It's a documentation problem. A new hire can be sharp, a VA can be capable, a volunteer can be motivated, and none of it matters if the actual steps of the task only exist as something you remember and never wrote down.
I used to think I hadn't gotten around to writing things down yet, like it was a to-do list item I kept bumping. The real issue was that I was trying to document processes at the wrong moment, so the documentation never stuck, and I quietly gave up on it every time.
Why the first time is the wrong time to document
The first time you do a task, you're not executing a process. You're discovering one. You try a step, it doesn't work the way you expected, you backtrack, you find a workaround, you eventually land on something that works, but you got there by trial and error, not by following a known sequence. If you sit down and try to write the SOP right then, you end up documenting the confusion, not the process. The steps aren't stable yet. You don't actually know which parts were necessary and which parts were just you feeling your way through something new.
I learned this the hard way by trying to write things down immediately, right after finishing a task for the first time, while it was still fresh. The documents were always messy and always wrong in some small but important way, because I was writing down what I remembered doing, not what actually needed to happen. Nobody could follow them without hitting a step that didn't quite match reality.
How I actually capture it the second time
The second time I do a task, the path is already proven. I already know what worked. So instead of trying to reconstruct a polished document from memory afterward, I write the steps down as I go, in real time, while I'm actually doing the task again. That's the entire shift.
In practice this looks like keeping a plain document or note open next to whatever I'm working in, and jotting down each step the moment I take it: what I clicked, what I typed, where the file went, what the setting was called. Sometimes I take a screenshot of a specific screen instead of describing it in words, because a screenshot of the actual login page or the actual settings tab is faster to write and far easier for someone else to follow than a paragraph trying to describe it. If I'm working through something visual, I'll narrate out loud what I'm doing as I click through it, the same way I'd explain it to someone sitting next to me, and turn that narration into the written steps afterward.
The key rule is that I capture it during the task, not after. Writing from memory once the task is done always loses something: a step gets skipped because it felt obvious to me, or the order gets slightly rearranged because that's how I remember doing it, not how I actually did it.
What a good lightweight SOP actually contains
Notice what's missing from that list: it doesn't need to be beautifully formatted, it doesn't need a table of contents, and it doesn't need to cover every possible edge case. A lightweight SOP that actually 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 process written down for it. A task I'll touch again next week, next month, or as part of a recurring client workflow is exactly the kind that shouldn't only exist in my head. The second time I'm doing it is also, conveniently, the exact moment I'm capable of writing it down correctly.
The first time is for learning. The second time is for teaching the version of you that gets to delegate it.
Keeping SOPs from going stale
An SOP that's wrong is worse than no SOP at all, because it sends someone confidently down the wrong path. The way I keep mine honest isn't a scheduled quarterly review, it's a simple rule: the moment anyone using an SOP hits a step that no longer matches reality, whether that's a moved login, a renamed tool, or a step that got skipped, it gets corrected right then, not added to a list of things to fix later. A tool changes, a process shifts slightly, and if nobody updates the document the same week it breaks, it stays wrong for months and nobody trusts it anymore.
I also don't aim for perfect on the first write-up. The version I write during the second pass is a working draft. If a VA or a new hire follows it and gets stuck somewhere, that's useful information, not a failure of the document. I'd rather have a slightly rough SOP that gets corrected in real use than a polished one nobody has actually tested.
Key takeaways
- Everything living in the founder's head is the real bottleneck to delegation and to taking real time off, not a hiring problem.
- 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 whether you're doing it again. 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.
