By Sarah Burgen — Instructive Edge
Let’s be direct about something.
A lot of companies don’t actually have a documentation problem. They have a no one uses it problem.
The SOP exists. The process is written down. The training materials are technically “there.”
And yet – people still Slack each other for answers. They still do things differently every time. They still rely on that one person who just knows how it works.
So what’s going on?
A story that might sound familiar
A few years ago, we started working with a healthcare client who had done everything “right.” Their team had spent real time building out process documentation. They pulled in subject matter experts. Everyone contributed their tips and tricks. The result was a detailed, 15-step document that covered the process from start to finish.
Then legal got involved.
What started as a lean, usable 15-step guide became a 35-step compliance document – dense, defensive, and written to protect the organization rather than guide the person doing the work. It wasn’t bad documentation. It was documentation written for a lawsuit, not for a frontline employee in the middle of a shift.
Nobody read it. Nobody used it. And the organization had no idea how to fix it.
When we got involved, we didn’t rewrite it – we restructured the thinking behind it. The compliance content moved into a separate training module where we asked for tested for understanding. The process document stayed lean, clear, and built for the person actually doing the work. A few years later, when AI systems started surfacing knowledge articles, we converted it again – this time into an AI-friendly format that could be retrieved accurately and in context.
Same information. Completely different outcome. The difference wasn’t the content – it was the design.Why documentation fails (even when it exists) It was written for compliance, not for humans
A lot of documentation exists because it has to – for audits, for leadership, for the moment someone said “we should probably have this written down.” So it gets created. But it doesn’t get designed. The result is dense, formal, and written for a reviewer – not for the person trying to get work done at 2pm on a Tuesday.
If your documentation feels like homework, people will avoid it. Write it for the person who is new, busy, or slightly overwhelmed. If they can’t follow it quickly and confidently, it’s not doing its job.
It doesn’t match reality
Documentation often reflects what should happen, not what actually happens. Employees can spot that gap immediately. The moment someone opens a guide and thinks “yeah, we don’t actually do it like this,” trust is gone. And once trust is gone, usage is gone.
Build documentation from real workflows, not ideal ones. Talk to the people doing the work. Watch the process. Capture the actual decisions, exceptions, and workarounds. Imperfect and real is always more useful than perfect and wrong – and you’ll often surface operational inefficiencies in the process.
It’s too hard to find
Even good documentation fails if no one can locate it. If people have to dig through SharePoint folders, search three systems, or guess what something might be named – they won’t bother. They’ll ask someone instead. Over time, that becomes the default behavior.
Centralize where documentation lives. Use clear, predictable naming. Link directly to resources inside workflows, not just in a library. If it takes more than a few seconds to find, it’s already too hard.
It’s not built into the workflow
Documentation lives “over there” while work is happening “over here.” Using it becomes an extra step – and extra steps are the first things people skip when they’re busy. Bring documentation into the flow of work. Link guides inside tools. Embed steps where actions happen. Use job aids instead of long documents when possible. The goal isn’t to have documentation. It’s to make it usable in the moment it’s needed.
It’s never maintained
Outdated documentation is worse than no documentation. Once something is wrong – even slightly – people stop trusting all of it. And most teams don’t have a clear owner or update process, so documentation slowly becomes irrelevant. Treat it like a living system. Assign ownership. Build in regular reviews. Update it when processes change – not months later.
What actually works
Good documentation isn’t just written – it’s designed. And design starts with analysis, not output.
Before anything gets built, the right question isn’t “what do we need to document?” It’s “where is the process actually breaking down, and for whom?” That diagnostic step – understanding the real gap before prescribing a solution – is what separates documentation that gets used from documentation that gets ignored.
Most internal teams skip this. Not because they don’t care, but because the pressure is to produce something – a guide, a training, a module – rather than to first understand why the current thing isn’t working.
Got 20 minutes?
If you recognized your organization somewhere in this post, that’s worth a conversation.
We’re not going to show up with a proposal and a timeline. We’re going to ask questions – about where your process breaks down, who’s affected, and what’s actually been tried. If we can help, we’ll tell you how. If we can’t, we’ll tell you that too.
No pitch. No deck. Just 20 minutes to figure out if there’s a real problem we can solve together.
