top of page
.png)
How to ask your team to write down what they know
This is the part owners get stuck on, and almost nobody says so out loud.
The reason you haven't asked
You've probably had the thought and moved past it quickly.
Your estimator has been here fourteen years. He's good, he's loyal, and the entire bidding process lives in his head. You know it's a risk. You've known for a while.
And every time you think about asking him to write it down, something stops you. It feels like you're saying he's replaceable. Or that you don't trust him. Or that you're adding one more thing to a week that's already full, for a project he never asked for.
So you don't ask, and another year goes by.
"
That hesitation is the most common reason this doesn't happen, and it's a reasonable one. It's also solvable, and mostly by changing what you're asking for.
Don't ask them to write anything
The ask that fails is "can you document your process?" It fails for three reasons: it sounds like paperwork, most people aren't writers and know it, and it lands as homework on top of a full job.
The ask that works is smaller, and it's true.
"
Show me how you do it.
Someone else does the writing. Their part is doing the job while somebody pays attention, and answering questions afterwards. That's an afternoon of being useful, not a project.
It also removes the sting. You're not asking them to make themselves replaceable.
"
You're asking them to teach.
Those feel completely different to the person on the receiving end, and only one of them gets a yes.
The version that works
Say why, before you say what. People fill silence with the worst available explanation, and the worst available explanation here is I'm being managed out.
Three reasons that are true, and any of them is better than none.
.png)
I want you to be able to take a holiday.
For the person who can't currently go anywhere without their phone, this is not a euphemism. It's the whole point.
.png)
I want to stop interrupting you.
If four people a day ask them the same question, they already know what this would be worth.
.png)
We're hiring, and I don't want to hand the new person to you as a full-time job.
Concrete, obviously true, and it makes them the expert rather than the subject.
Then say what happens to it. Who writes it, who checks it, who signs it off, and that nothing goes to the team until they've seen it.
The approval is the reassurance. A person who knows they get the final read stops worrying about what's being written.
Four things that go wrong
.png)
Don't call it documentation.
It sounds like compliance. Call it what it is: writing down how the job gets done so the next person can do it.
.png)
Don't ask everyone at once.
A company-wide announcement about documenting processes reads as a restructure. Start with one person and one job.
.png)
Don't ask for it "when you get a minute."
They won't get a minute, you both know it, and now it's an unkept promise instead of a task.
.png)
Don't skip the part where they sign it off.
If the first they see of it is the finished version on the intranet, you've confirmed every fear they had.
If someone digs in
Occasionally somebody resists hard, and it's worth being honest that this happens.
Sometimes the reason is fair. They've been burned somewhere before, or the last person who wrote everything down was gone within the year. Say so out loud and answer it directly.
Sometimes the reason is that being the only one who knows is the job security, and they're not going to say that. You don't fix that with a better conversation. You fix it by deciding what kind of company you're running, which is a bigger decision than a process guide, and it's yours to make.
The useful part is that you now know. A documentation project that stalls tells you exactly where the risk is, which was the thing you were trying to find out.
bottom of page