Every organization has one. The person everyone goes to when something breaks. The person who’s been running the process for six years, who can fix it blind, who trained half the department without anyone officially assigning them the job.
Ask that person to write down the process, and watch what happens. They stall. They write three bullet points and stop. Or they write forty steps and still leave out the one thing that matters most, because to them it isn’t a step. It’s just what you do.
This isn’t a willingness problem. It’s a structural one.
Expertise and Documentation Are Different Skills
Knowing a process cold and explaining it clearly to someone with zero context are not the same skill. One comes from repetition. The other comes from stepping outside your own head and reconstructing what a beginner doesn’t know yet.
Your best people got good by doing the work, not by teaching it. Documentation asks them to do something they’ve never been trained to do, on top of a job that already has no slack in it.
The Gaps Are Invisible to the Person Who Knows Too Much
Watch someone senior write an SOP and you’ll see the same failure pattern every time. They skip the step that’s become automatic. They assume the reader already knows the exception cases. They write for someone who thinks like they do, not for the new hire who’s never touched the system.
None of this is carelessness. It’s what happens when knowledge becomes so internalized that the person carrying it can no longer see its parts. You can’t document what you no longer notice yourself doing.
Bandwidth Is the Other Half of the Problem
Even a SME with strong writing instincts runs into the second wall: time. Documentation competes with the actual job, and the actual job always wins, because the actual job has a deadline and documentation doesn’t, until the day someone quits and the deadline arrives all at once.
That’s the moment most organizations discover their SOPs live in one person’s head. Not because nobody cared. Because the process for getting it out of their head and onto paper never existed in the first place.
What Actually Gets a Process Documented
The fix isn’t asking your SME to try harder or block out more time. It’s changing who does the writing. Pair the SME with someone whose job is specifically to ask the dumb questions, watch the work happen, and turn it into a document a stranger could follow. The SME’s job stays answering questions and correcting drafts, work that plays to what they’re actually good at. The documentation itself gets built by someone trained to catch the gaps a subject matter expert cannot see in their own process.
This is the difference between an SOP that gets written and one that gets used. A document built by interviewing the SME once and writing from memory reads like it was written by someone who wasn’t in the room. A document built by watching the actual work, asking what happens when it goes wrong, and testing the draft against someone who’s never done the task before reads like instructions a new hire can actually follow on day one.
Start With the Process That Would Hurt the Most to Lose
You don’t need to document everything at once. Start with the process only one person can run. If that person left tomorrow, what would break first? That’s the SOP that pays for itself the moment it exists, because it converts a single point of failure into something the rest of the team can actually pick up.
Your SME isn’t the problem. Asking them to be a technical writer on top of everything else they already do is.
Diagnose what’s stalling your documentation: hermothersdaughter.com/diagnose. Or see how HMD works with organizations through execution, not just strategy: hermothersdaughter.com/work-with-us.