- What a personal SOP is and why remote work makes it especially valuable
- How to decide which tasks are worth turning into SOPs
- The minimum structure that makes an SOP actually usable
- Where to store SOPs so retrieval is fast, not forgotten
- How to keep the library alive instead of letting it rot
A personal standard operating procedure is a small, opinionated document that captures a decision you have already made so you do not have to remake it. The phrase comes from operations and manufacturing, where SOPs are usually long, formal, and written for someone else. A personal SOP is the opposite: short, informal, and written for yourself. The point is not thoroughness. The point is to stop spending attention on questions you have already answered.
In remote work, the case for SOPs is stronger than in the office. There is no colleague nearby to ask, no shared knowledge that comes from sitting next to someone, and the cost of context-switching into a forgotten decision is higher because the day has less structure. A small library of personal SOPs removes a class of small decisions from your day entirely, leaving more capacity for the work that actually requires thinking.
What a personal SOP actually is
A personal SOP is not documentation. Documentation describes how a system works for anyone who needs to learn it. A personal SOP is a decision shortcut — the minimum you need to repeat a recurring choice without reconsidering it from scratch. The two have different shapes:
| Documentation | Personal SOP |
|---|---|
| Explains how something works | Tells you what to do |
| Written for others | Written for yourself |
| Aspires to completeness | Aspires to brevity |
| Lives in a shared wiki | Lives wherever you search first |
| Updated when reviewed | Updated when the decision changes |
A good personal SOP fits on one screen. If it takes longer to read than to make the decision from scratch, it has failed its purpose.
What belongs in a personal SOP library
Not every recurring task deserves an SOP. The decision to write one should be based on two questions:
Tasks that pass both tests are strong candidates. Examples:
- Inbox triage rules — what gets answered now, what gets batched, what gets archived.
- Meeting prep checklist — the five things you do before any client meeting.
- Code review pass order — the sequence you follow when reviewing a pull request.
- Weekly report structure — the template you fill in, not the content.
- Tool selection criteria — the questions you ask before adopting any new tool.
Tasks that fail the test are usually too rare or too simple to justify documentation. Writing an SOP for something you do once a year, or for something that takes ten seconds anyway, creates maintenance load without saving attention.
The minimum viable structure
An SOP that is too short is useless; one that is too long never gets read. The structure below is the minimum that works in practice — four fields, none of them optional.
- Trigger: When does this SOP apply? A specific recurring situation, not a vague category.
- Decision: What is the default action? One sentence, not a paragraph.
- Exceptions: When do I deviate? Two or three cases that justify a different choice.
- Last reviewed: When did I last check this is still right? Date stamp for maintenance.
A completed example, for inbox triage:
Trigger: Opening email at the start of a batch window.
Decision: Answer anything that takes under two minutes immediately. Anything that needs thinking
goes to a “needs response” folder. Anything informational gets archived, not filed.
Exceptions: Messages from my manager or a client escalation bypass the rule and get answered first.
Last reviewed: 2026-06-12.
Notice what is missing. There is no preamble about why email matters, no list of tools, no background. Those belong in documentation. The SOP assumes the reader is you, already in the situation, and just needs the decision shortcut.
Where the library lives
The single most important rule of SOP storage: put them where you already are. A separate tool you have to remember to open is a tool that will rot. The right location is whatever you search first when you need information — usually a note-taking app, a wiki, or even a single document with clear headings.
Three properties matter more than the specific tool:
- Search speed. You should be able to find an SOP in under ten seconds. If it takes longer, you will skip it and rethink the decision.
- Single source. Do not split SOPs across multiple tools. One place, even if it is less organized, beats three places that are each tidy.
- Easy editing. If updating an SOP requires more than a minute, you will not keep it current. The tool has to make edits trivial.
Keeping the library alive
SOP libraries die quietly. The documents stay, but they stop being used because they go stale. Two habits prevent this:
- Review the date stamp quarterly. Any SOP older than six months gets a quick check: is this still how I make this decision? If not, update or delete.
- Review the trigger when you skip it. If you find yourself ignoring an SOP, the trigger is probably wrong. Refine it or retire the SOP.
A library of thirty SOPs where twenty are stale is worse than a library of eight where all are current. The stale ones train you to ignore the library. The current ones train you to trust it.
Five high-value SOP examples
| SOP | Trigger | Default decision |
|---|---|---|
| Inbox triage | Opening email | Two-minute rule, then batch |
| Meeting prep | Calendar reminder fires | Read last notes, write three objectives, prepare questions |
| Tool evaluation | Considering a new tool | Ask three questions before adopting: replaces what? migration cost? who else needs it? |
| Weekly review | Friday afternoon | Walk four perspectives, write three changes for next week |
| Code review | Pull request assigned | Read tests first, then diff, then style. Comment in that order. |
- A personal SOP is a decision shortcut for yourself, not documentation for others.
- Capture decisions that are both frequent and high-friction. Skip the rest.
- Four fields are enough: trigger, decision, exceptions, last reviewed.
- Store them where you already are. Retrieval speed matters more than sophistication.
- Review quarterly. A library of current SOPs beats a library of stale ones.
Frequently asked questions
What is the difference between a personal SOP and documentation?
Documentation describes how something works for anyone who needs to learn it. A personal SOP is a decision shortcut for yourself — the minimum you need to repeat a recurring choice without rethinking it. SOPs are usually shorter, more opinionated, and built for fast retrieval.
How many SOPs should I have?
Start with five to ten, covering the decisions you make most often. More than twenty usually means you are documenting decisions that do not recur enough to justify the maintenance. The value is in coverage of frequent decisions, not in completeness.
Where should I store my SOP library?
In whatever tool you already use daily and can search quickly. A note-taking app, a wiki, or even a single document with headings works. The wrong choice is a separate tool you have to remember to open — retrieval speed matters more than sophistication.