# Turn the way I do something into an SOP A repeatable procedure someone else can follow, built from a rough explanation and an interview for the steps you left out. **Time:** 15 minutes **What you'll have when you're done:** A repeatable procedure someone else can follow. ---You do a task the same way every time and have never written it down, because you don't need to read instructions to do your own job. The problem shows up the day someone else needs to do it and you're not there to explain the parts you never thought to mention. --- ## Do this 1. **Explain the task the way you'd tell a new hire**, out loud or typed, in whatever order it comes out. 2. **Ask to be interviewed**, using the prompt below, before asking for the finished document. The gaps in a first explanation are exactly what an SOP has to cover. 3. **Answer the follow-up questions specifically.** "It depends" is a real answer; say what it depends on. 4. **Ask for the final SOP** once the interview stops turning up genuinely new information. ``` I'm going to explain how I do [task]. Before writing an SOP, interview me: ask about anything unclear, any decision points where "it depends," any tools or access required, and any step I likely skipped because it's automatic to me. Here's my rough explanation: [explain the task as you'd tell a new person] Don't write the SOP yet. Ask your questions first. ``` Once the interview feels thorough: ``` Now write this as an SOP: 1. Purpose (what this accomplishes and why it matters) 2. What's needed before starting (access, tools, information) 3. Numbered steps, one action each 4. Decision points, stated as "if X, do Y; if Z, do W" 5. What "done" looks like ``` --- ## Check this before you trust it - **Every decision point.** "It depends" answers are where an SOP either becomes genuinely useful or becomes a document nobody trusts, because it doesn't match reality on the cases that actually come up. - **Whether a new person could actually follow it without you in the room.** Read it as if you've never done this task. - **Any step that assumes access, a tool, or knowledge the document doesn't mention.** That's the invisible-to-you part this method exists to surface. --- ## If it goes wrong **The interview doesn't ask about something you know is tricky.** Bring it up yourself: "there's a tricky part around X, ask me about it." It can't ask about a gap it has no signal exists. **The finished SOP reads right but doesn't match what actually happens on an edge case.** Walk through your last three exceptions to the normal process and check whether the SOP's decision points cover them. If not, that's the next round of interview questions. **Someone follows it and gets stuck anyway.** That's real feedback, not a failure of the method. Add the gap they hit as a new decision point and update the document; an SOP that never changes after someone actually uses it probably isn't being used. **The task turns out to be too judgment-heavy for a clean procedure.** Some tasks are like that. Document the parts that are procedural, and be honest in the SOP itself about which parts still require experience rather than pretending a checklist covers everything. ---

Related