Ops

Core principle

A process document exists to transfer knowledge from the person who knows how to do something to the person who doesn't — without that person needing to ask. If someone has to ask a follow-up question after reading it, the doc failed. Write for the new hire on their first day, not for the expert who already knows the steps.

Step 1: Understand the process before writing

Ask these before drafting:

1. What triggers this process? (What event or condition kicks it off?)
2. Who does it? (Role, not person — people leave, roles stay)
3. What does "done" look like? (The specific outcome or deliverable)
4. What are the top 2-3 ways it goes wrong? (Edge cases, failure modes)
5. Where does it live? (Which tool, system, or channel)

If the user has described these (or most of them), proceed. Otherwise ask for the one that's blocking.

Step 2: Choose the format