What to Do When Your Expert Won't Document Their Work
Your best person will not log in, is "too busy," or quietly guards what they know. This is a people problem, not a documentation problem, and you can capture the knowledge without ever winning the argument.
Key Takeaway
When your expert will not document their work, stop trying to win the argument and change the method. Most resistance is not defiance. It is that writing is a second job piled on top of the first, and a smaller share is quiet job-security protection you will never argue your way past. Either way the fix is the same: stop assigning documentation and start capturing it. Have them talk instead of write, record the work instead of requesting a write-up, and put someone else between the expert and the blank page so their only job is to correct a draft, not create one. Then cut key-person risk by capturing the highest-stakes process first and training a second person from what you captured, so the business stops depending on one person's cooperation.
The Real Problem Is Not the Document, It Is the Person
Almost every owner who tells me their expert "won't document their process" is describing a people problem wearing a process costume. The blocker is not a missing SOP. It is a human being with a reason, spoken or not, to keep the knowledge where it is, and until you deal with that reason, no template, deadline, or new tool fixes anything.
This is one of the most common patterns we see. Across a recent set of owner-operated companies we assessed, the average amount of work documented anywhere was about 27 percent, and half had written down essentially nothing. The reason is rarely that owners do not know they should document. It is that the knowledge lives inside a few key people, and those people are the hardest to get it out of. We flag this internally as knowledge that is "trapped": real, valuable, and locked in one head.
So before you fight over formatting, get clear on what you are facing. The expert who says "I'll get to it" and never does is not the expert who goes quiet and guards their login. One is a scheduling problem, the other a leverage problem, and the tactics below handle both once you stop treating this as a documentation task.
What do you do when an employee won't document their process?
You capture the knowledge without requiring them to write it, because the write-up is almost never the part they are actually refusing. What they are really refusing is a second unpaid job: producing paperwork they see no reward in. Take that job away, switch from assigning documentation to capturing it, and the fight usually disappears.
This is the same bind owners hit with the delegation paradox: the person who could finally hand off the work is too buried in it to stop and explain it. The way out is not more willpower, it is a smaller ask. You do not need a technical writer. You need about an hour of them talking, or permission to record work they already do, plus a second person to turn it into a document. When the ask shrinks from "write the manual" to "keep working while we film," the resistance mostly evaporates.
These are the processes that live only in someone's head, and the mistake is assuming the head has to do the transcribing. Move the knowledge out by whatever route meets the least resistance, not by turning your best operator into a documentarian they will never willingly be.
Why do experts resist writing things down?
Experts resist writing things down for three reasons that usually have nothing to do with laziness: writing is a second job, the knowledge is tacit and hard to put into words, and in a smaller number of cases the knowledge feels like job security. Name which one you are dealing with and you know exactly which lever to pull.
| What you hear | What is often underneath | What actually moves it |
|---|---|---|
| "I'm too busy" | It is real. Writing is a second job on top of the one they were hired for, and it always loses. | Remove the writing. Capture by talking or recording, in the flow of work. |
| "It's all in my head, it's hard to explain" | The work has gone automatic. They genuinely cannot see the steps anymore, let alone write them. | Have someone interview it out of them with questions. Talking is easy where writing is not. |
| "Every job is different" | There is a stable 80 percent they cannot see because it is second nature. | Capture several real cases. The repeatable pattern shows up on its own. |
| "I'll get to it" (and never does) | No deadline, no owner, no reward. It sinks under everything urgent. | Book a single recording session. Attendance is the only ask. |
| Vague answers, quiet stalling, guards the login | The knowledge feels like leverage. Being irreplaceable feels safer than being documented. | Stop negotiating for it. Capture around them and reduce the dependence (see below). |
The first four rows are the common case, and all are solved by changing the method. The last row is different: that is tribal knowledge held as leverage, a real risk but a management issue, not a documentation one. You will not template your way past someone who has decided that what they know is the reason they cannot be let go. We come back to that below.
"You do not get documentation out of an expert by assigning them documentation. You get it by removing every reason they had to resist."
How do you capture knowledge from someone who won't cooperate?
You capture it by removing every reason they had to resist and then recording what is left. Do not hand them a template or give them homework. Meet the knowledge where it lives, in the work itself and the expert's own voice, and put someone else in charge of the document. Here is the method we use with every client, in order. We call it Zero-Homework Capture, because the expert never touches a blank page.
- Stop assigning writing. Assign talking.Nobody resists talking about work they are proud of. Replace "please write the SOP" with a loose, unscripted interview: a few questions, a recording running, and the expert talking through how they do the thing. There is no blank page to stare at, and restarts are fine because it gets edited down later.
- Record the work instead of requesting the write-up.The richest capture is the work happening in real time. Screen-record them running the task while they narrate, or have someone shadow them with a camera for one real job. You can then turn that screen recording into an SOP without the expert writing a word.
- Put a scribe between the expert and the blank page.Documentation stalls because the one person who knows the work is also the one asked to write it. Break that. Let a second person, an assistant, an ops lead, or us, own the drafting: the expert supplies the knowledge by talking, someone else supplies the sentences. This one move solves most "won't document" problems on its own.
- Capture in the flow of work, not as a separate project.A "documentation project" is a thing busy people postpone forever. Capture that rides along on work already scheduled cannot be postponed, because it is not extra. Record the next real client call. Film the next install. The expert's week never gets heavier, which is the point.
- Make their only job the red pen, never the first draft.People who will never write a page will happily fix one. Once the scribe drafts from the recording, the expert's role is to correct it, not create it. Forcing them to author from scratch is what produces thin, resentful pages, which is why so many forced SOPs collect dust the day they are written.
- Close the loop fast so they feel the relief.Get the finished document in front of the expert quickly, and show what it buys them: fewer interruptions, a new hire who stops asking the same question, a vacation where nobody calls. The first capture has to pay them back, or there will not be a second.
This never requires the expert's enthusiasm, a login, or a change of heart, because the ask has shrunk from a months-long project to a single hour. Which format you reach for depends on the work.
| If the work is... | Capture it by... | All the expert has to do |
|---|---|---|
| Done on a screen (software, CRM, spreadsheets) | Screen recording with live narration | Talk out loud while they work, once |
| Physical or hands-on (a build, a repair, a walkthrough) | Handheld video or a filmed shadow of one real job | Let someone film. Keep working. |
| Judgment and exceptions ("it depends," pricing calls) | Recorded conversational interview, no script | Answer questions for about an hour |
| Already happening on calls and meetings | Record the real client call or meeting | Nothing new. Just hit record. |
"Treat your best expert like a witness, not an author. Nobody writes their own deposition, and nobody should have to write their own SOP."
Find Out How Exposed You Are to One Person
If one expert holding out can stall the whole company, that is key-person risk. Our free scorecard shows exactly where the business still depends on people instead of systems, in about five minutes.
Take the Owner Dependence ScorecardHow do you reduce the risk of one person holding everything?
You reduce the risk of one person holding everything by capturing their highest-stakes process first and using that capture to train a second person, so the knowledge lives in more than one place. You do not have to document their entire job, only break the single point of failure on the one or two things that would genuinely hurt if they quit on a Friday. Do it in this order.
- Rank by damage, not by volume. List the processes only this person can do, then sort them by one question: what does it cost us if they quit tomorrow? Start with the scariest, not the easiest.
- Capture the top one using the method above. Talk, record, scribe, approve. One process, done properly, moves you from total exposure to real coverage on the thing that mattered most.
- Train a second person from the capture. The recording and the document are now a teaching tool. A second person learns from the system, not from years of shadowing, and the knowledge stops being single-threaded.
- Make the captured version the default route. Point new questions at the document first, not at the expert. Every time the answer comes from the system instead of the person, the dependency gets weaker.
This is the heart of solving the one-person problem with a key employee. It is not about making the expert dispensable out of spite. It is that a company that can only function while one specific person is reachable does not have an employee. It has a hostage situation it has learned to call normal.
When the Resistance Is a Red Flag, Not a Reflex
Most resistance is benign, but a small slice is a warning you should not work around quietly. Being "too busy" is a scheduling problem you solve with a smaller ask. Deliberately withholding knowledge to stay indispensable is a leadership problem no capture technique fixes. The tell is the difference between "I keep meaning to" and a pattern of vague answers, missed sessions, and a guarded login.
If it is genuine hoarding, change your posture. Stop asking the expert to volunteer the knowledge, because every request just confirms how much power the withholding gives them. Capture around them instead: record the work you can observe, interview the people they hand off to, and rebuild the process from the artifacts it leaves behind. Then cross-train a second person on purpose. The moment the business can run without them is the moment their leverage stops being a risk, and a fair conversation about their role finally becomes possible.
The Trap to Watch For
Do not let one person's refusal become company policy. Owners often decide that because the expert will not cooperate, the knowledge cannot be captured, so they stop trying, and one employee's preference quietly becomes a permanent, business-wide single point of failure. You do not need permission to capture the work they do in front of clients, on shared systems, and in recorded calls. Their cooperation makes it easier; their refusal does not make it impossible.
Start With the One Process That Would Hurt Most
Do not fix all of this at once, and do not wait for a change of heart. Pick the single process whose loss would hurt worst, the one that keeps you up at night imagining that person gone, and run the Zero-Homework Capture on just that. Book one hour. Record it. Have someone else draft it. Get the expert to red-pen it. Then train one other person on it. That is the whole first move, and it takes a week, not a quarter.
The capture is rarely the hard part once you stop demanding it in writing. The real blocker was the assumption that documentation had to come from the expert's own keyboard. Drop it, and the knowledge flows out through talking, recording, and someone else's pen. Your best people stay valuable, and the business stops being fragile every time one of them is unreachable. That is the difference between a company that runs on people and one that runs on systems, and it starts with one refusal you routed around instead of argued with.
Stop Betting the Business on One Person's Memory
Find out where a single expert, or you, is still the only thing holding a process together. Our free Owner Dependence Scorecard shows you in about five minutes, then we turn it into a plan.
Take the Owner Dependence Scorecard Or skip ahead and schedule a discovery call to get the knowledge out of your experts' heads with us.Frequently Asked Questions
What do you do when an employee won't document their process?
You capture the knowledge without requiring them to write it, because the write-up is almost never the part they are actually refusing. Stop assigning documentation as a task and switch to capturing it: have the person talk through the work while someone records it, or record the work itself as it happens, then let someone else turn that into the document. You do not need the expert's enthusiasm or even their full cooperation. You need about an hour of their talking, or permission to hit record, and a second person to do the writing they will never do.
Why do experts resist writing things down?
Experts resist writing things down for three reasons that usually have nothing to do with laziness. First, writing is a second job stacked on top of the first, and documentation always loses to the actual work. Second, the knowledge is tacit, meaning they have done it so long it has gone automatic and they genuinely struggle to put it into words. Third, in a smaller number of cases, the knowledge feels like leverage, and being the only person who can do the thing feels safer than being replaceable. The first two are solved by changing the method. The third is a management issue, not a documentation issue.
How do you capture knowledge from someone who won't cooperate?
You capture it by removing every reason they had to resist and then recording what is left. Do not ask them to write anything. Record them talking through the work in a loose, unscripted interview, screen-record them doing the task while they narrate, or record the real client calls and jobs they already run. Put a second person between the expert and the blank page so the expert's only job is to correct a draft, never to create one. This works even with a partly willing expert, because the total ask shrinks from a project they will avoid for months to an hour they can survive once.
How do you reduce the risk of one person holding everything?
You reduce it by capturing that person's highest-stakes process first and using the capture to train a second person, so the knowledge lives in more than one place. Rank the processes only they can do by what it would cost you if they quit tomorrow, capture the most expensive one, and turn it into something a second person can learn from. The goal is not a perfect library. It is to break the single point of failure on the one or two processes that would actually hurt, so the business no longer depends on one person's memory or their willingness to share it.
Is it ever okay to force an employee to document their work?
You can require it, but forcing someone to write documentation almost never produces documentation anyone can use. A resentful expert made to fill a template will give you thin, box-checking pages that skip the judgment calls that made them valuable, and those pages collect dust the day they are written. It is far more effective to make the ask small and remove the writing entirely: they talk, someone else writes, they approve. You still hold the line that the knowledge has to be captured. You just stop insisting it be captured in the one format they will fight.
How do you document a process when the expert is too busy?
Capture it in the flow of the work they are already doing instead of asking them to stop and write. Record the next real client call, screen-record the next time they run the task, or have someone shadow them with a camera for one job. None of that adds a separate project to their week, which is the thing they do not have time for. The expert keeps working, the capture happens alongside it, and a second person turns the recording into the document later, so the busy person is never the bottleneck for the write-up.
What if an employee is protecting their knowledge as job security?
Treat it as a leadership problem, not a capture problem, and stop negotiating for the knowledge. If someone is quietly hoarding what they know to stay indispensable, you will not argue, incentivize, or template your way to their cooperation. Capture around them instead: record the work you can observe, interview the people they hand off to, and rebuild the process from the artifacts it leaves behind. Then reduce your dependence on them deliberately by cross-training a second person. The moment the business can run without them is the moment their leverage stops being a risk to you.