You document a process you've done two hundred times, send it to the new hire, and three days later they're back with a list of questions — not because they weren't paying attention, but because you wrote a doc that's missing exactly the things they needed most. The steps you know cold are the ones you describe in a single confident sentence. The steps that trip up a beginner are invisible to you because you automated them so long ago they no longer register as steps at all.
This is the gap at the center of most process documentation, and it doesn't close by writing more carefully or more thoroughly. The gap exists because of where most docs get created: at a desk, from memory, long after the task is done.
| Type of invisible knowledge | Why it gets left out | How to capture it |
|---|---|---|
| Shortcuts from past mistakes | Feels obvious after you've learned it | Narrate live: "I check X first because that's where things break" |
| Exception handling | Only surfaces in edge cases the writer isn't thinking about | Walk through 2-3 real examples, including the unusual ones |
| Timing dependencies | Writer assumes reader knows what has to happen first | Trace back: "This step only works after..." |
| Judgment calls | Operate below conscious thought for experienced people | Ask "when would I NOT do this step?" and write the answer |
| Tribal expertise | Too attached to one person to document in the abstract | Record the expert doing the task and narrating as they go |
💡 The core problem: Experts don't write bad docs because they're careless. They write bad docs because expertise makes invisible knowledge invisible. The fix isn't more effort — it's a different capture method.
Why Experts Write the Worst First Drafts
The knowledge that looks obvious from the inside
When you sit down after the fact to document a process you've owned for years, you reconstruct it from memory — and memory is selective in a particular way for people who know something well. You can recall the official sequence without much effort, but what you can't reliably surface are the conditional branches, the timing dependencies, and the learned adjustments that took months of doing the job to internalize, because you're no longer consciously aware of performing them. That gap between what you know and what you write down isn't negligence; it's the way expertise works.
The new hire reading your document has none of that background. They have your process, which describes a clean linear flow that works reliably right up until the moment it doesn't — and when reality diverges from what the doc describes, they have no framework for understanding why.
The five kinds of steps your doc is probably missing
Every process contains multiple layers of knowledge, and written documentation almost always captures only the top layer: the official, linear sequence. The table above maps the five types that most commonly disappear.
The shortcut discovered after something went wrong is one of the most valuable pieces of process knowledge in any organization, and it almost never gets documented. Someone learned the hard way that step four creates a downstream problem if step two was done in a particular way, and now they check automatically — but the check never made it into the doc because it doesn't feel like a step, it feels like common sense.
Exception handling is a close second: the "if the account is older than ninety days, skip this step" logic that someone picked up from repetition and never thought to formalize. And deepest of all is the judgment layer — the sense of when something needs escalation versus when it's safe to proceed, which operates entirely below the level of conscious thought for anyone who has done this work long enough to do it fluently.
Capture the Process While You're Inside It
Document live, not from memory
The most reliable fix is to document the process while actively performing it. Walk through the task in real time and narrate what's happening as you go — including the things you'd normally leave unspoken because they seem too obvious to mention. The remark "I'm doing this before that because if you reverse the order, the system doesn't update correctly" is exactly the kind of note that would never appear in a reconstructed write-up, but it's what a new person needs to avoid an hour of confusion that leads them straight back to your inbox.
This works whether you're recording your screen, speaking into a voice memo, or taking step-by-step notes as you work. The common thread is proximity: you're documenting from inside the process, not from a reconstruction of it.
💡 The fastest first draft: Walk through the process on a call or screen share with live narration. That ten-minute recording contains more invisible knowledge than an hour of writing from a blank doc — because you'll say things out loud you'd never think to write down.
Screen recordings as source material
Screen recordings work particularly well because they capture both the actions on screen and the spoken explanation of why you're taking them. The live narration tends to surface the judgment calls and conditional branches that a post-hoc doc consistently leaves out. Some teams use tools like Stepika to convert a screen recording directly into a structured, step-by-step guide: the recording is parsed into ordered steps with screenshots, which becomes the first draft rather than a video nobody rewatches. The approach doesn't require any new behavior from the person doing the work — it just turns something they were going to record anyway into something structured and findable.
When a colleague is better than a camera
Sometimes the most effective capture method isn't a recording at all — it's a walkthrough with a colleague who asks questions as you go. A person who doesn't know the process yet will naturally pause at the points where the doc would be confusing, ask why you're doing something in a particular order, or notice when you've skipped a step you're performing automatically.
Ten minutes of walking a teammate through a process — with them asking "wait, why?" at every unclear moment — will surface more invisible knowledge than an hour of solo documentation. Afterwards, the person who asked the questions often writes a better first draft than the person who owns the process.
How to Write Steps a Beginner Can Actually Follow
The beginner read-through test
Once a draft exists, there's a useful check for each step before the doc is called done: read it as if you've never touched this process before — not as if you've forgotten the specifics, but as if you have no background at all. At that level of unfamiliarity, most process docs show their gaps quickly: vague references to resources that aren't linked, actions described without enough specificity to execute, conditional logic that's implied but never stated outright.
📋 The test: For each step, ask: "Could a person who has never done this follow this step without asking anyone a question?" If the answer is no, that's your gap — a missing link, condition, dependency, or exception.
Specificity checklist for each step
Before finalizing each step, run through this quick check:
- The action — Is it specific enough to execute? "Check the dashboard" is not a step. "Open the Fulfillment dashboard and confirm the order status shows 'Processing'" is.
- The condition — Does this step only apply in certain situations? State them explicitly: "If the account type is Enterprise, skip this step."
- The dependency — Does something need to be done first? Note it: "This only works after the confirmation email has been sent."
- The exception — What could go wrong, and what should the person do if it does? A one-line fallback is better than silence.
What to Do When the Expert Has Already Left
Reconstruct from recordings you already have
Most teams have already captured their processes in some form — they've just captured them as events rather than documents. Onboarding calls, screen shares during ticket reviews, "cover me while I'm away" recordings: all of these contain real process walkthroughs, including the live narration of why things are done a particular way.
Before scheduling documentation sessions, check what's already in your call library, your screen recording folder, and your team's shared storage. The fastest route to a first draft is often a recording made without documentation in mind but containing exactly the knowledge the doc needs.
Interview the person before they go
When someone who owns a critical process is leaving the team — a contractor wrapping up, an employee moving to a new role, a founder stepping back from operations — there is a narrow window where their knowledge can be captured through a structured exit walkthrough.
The most useful format: ask them to walk through each process they own as if they're training a replacement on their last day. Record it. Ask "what would go wrong if someone did this without knowing X?" at each step. The urgency of the situation tends to surface the judgment calls and edge cases that get omitted from documentation written without that deadline.
Pick one process you've explained out loud more than three times in the last month. Do it live, narrating what you're doing as you go. The difference between that draft and the one you'd write from memory will be obvious the first time someone else tries to follow it.
Frequently asked questions
Why do experts write poor first drafts of their own processes?
Expertise makes invisible knowledge invisible. When you've done something hundreds of times, the shortcuts, exceptions, and judgment calls that took months to learn no longer register as steps — they feel like common sense. A draft written from memory captures the official sequence but misses the real process. Documenting live, while actually performing the task, is the reliable way to surface what gets left out.
What's the fastest way to write a process doc?
Walk through the process in real time, narrating what you're doing and why. A voice memo, screen recording, or a colleague taking notes as you work will produce a more complete first draft in ten minutes than an hour spent at a blank doc. The goal is to capture the process from inside it, not from a memory of it.
What kinds of knowledge are hardest to capture in a written SOP?
The hardest to capture are the things that no longer feel like steps: shortcuts learned after something went wrong, exception handling for edge cases, timing dependencies between steps, judgment calls about when to escalate, and expertise so attached to one person that the team has stopped trying to document it. These are exactly the things that trip up new people following a doc for the first time.
How do I know if a process step is written well enough?
Read it as if you've never done this before and have no context. If you'd pause, that's a gap. A practical test: can the step be followed without asking anyone a question? If not, add the missing link, condition, dependency, or exception that would make it self-contained.
What's the best format for an SOP?
It depends on the process. Simple linear workflows work well as numbered steps with brief descriptions. Complex processes with branching logic benefit from clear conditions: "if X, do Y; otherwise, do Z." Any process with visual steps benefits from screenshots alongside the text. The format that works is the one a new person can follow without asking for help.
How often should SOPs be updated?
Any time the process changes — immediately, not at the next quarterly review. Outdated SOPs are worse than none because they create confident mistakes. A practical system: the first person to notice a step is wrong flags it, and the process owner updates it within a week. The doc should reflect what actually happens, not what used to happen six months ago.
Can existing recordings be turned into SOPs?
Yes, and it's often the fastest route to a first draft. Onboarding calls, screen shares, how-to recordings made for a single colleague — all of these contain real process walkthroughs with live narration. Tools like Stepika parse a screen recording into ordered steps with screenshots, meaning a recording made without documentation in mind can become a structured, hosted guide without starting from scratch.