Nobody’s knowledge base has too little content.
Every one I’ve inherited has too much, usually by a factor of about 3.
Hundreds of articles, several versions of the same procedure, material describing a system that was decommissioned in 2021.
The complaint is always that people don’t use it.
The diagnosis is usually that it needs better search, or a migration to a new platform.
It rarely needs either.
It needs someone willing to delete things.
📚 Volume is why nobody trusts it
Here’s the mechanism.
A person searches for how to process a refund.
Four results come back.
One is current, one is from the old system, one is a draft somebody never finished, one contradicts the other three.
They can’t tell which is which, because all 4 look equally official.
So they pick one, get it wrong, then never search again.
They ask the person next to them instead, permanently.
That’s not a search problem.
Search worked perfectly, returning everything matching the query.
The problem is that 3 of those 4 documents should not exist.
🗑️ What’s actually in there
Run an audit on any mature knowledge base, then you’ll find roughly the same categories.
- Procedures for systems no longer in use
- Duplicates created because someone couldn’t find the original
- Drafts published accidentally, never finished
- Project-era documents that were never meant to be permanent
- Articles nobody has opened in 2 years
- Material that was wrong when written, never corrected
None of that is harmless.
Every stale document dilutes the credible ones by making the reader do the sorting.
A set of 40 accurate procedures outperforms 300 mixed ones, every time.
🔍 A workable way to cut it down
Deleting feels risky, so most people avoid it.
Make it systematic instead of brave.
- Pull view counts, then look hard at anything unopened in 12 months
- Check every article against the systems currently in production
- Find duplicates by title similarity, keep the most recent, redirect the rest
- Ask 3 frontline people which articles they actually rely on
- Archive rather than delete, if that makes approval easier
Then apply a simple test to each survivor.
If somebody followed this today, would it work.
If nobody’s sure, it goes.
Uncertain documentation is worse than none, since it wastes time before failing.
🏷️ Ownership prevents it happening again
The reason knowledge bases bloat is that nobody owns anything.
Documents get created by projects.
Projects end.
The articles stay, unowned, ageing quietly.
Two things fix this, both boring.
Name an owner for every article, a person rather than a team.
Put the owner plus the last review date visibly at the bottom of the page.
That second one changes reader behaviour immediately.
Someone seeing a review date from last month treats the content differently to one from 2022.
You’ve given them a way to judge trustworthiness without reading the whole thing.
Set a review cycle that’s realistic.
Every 6 months for high traffic articles, annually for the rest.
An unrealistic cycle gets ignored, which is worse than a modest one that happens.
🚪 Have a front door
Once the set is smaller, structure becomes possible.
Most people search rather than browse, so titles matter more than folders.
Write them the way people speak, not the way the project charter does.
“Process a refund” beats “Refund Management Procedure v2”.
Add the process ID to the top of each article, so it links back to the task on the process map.
Then test it properly.
Ask 5 people from different teams to find a specific procedure, then watch what they type.
Twenty minutes of that will tell you more than a month of taxonomy debates.
✅ The uncomfortable bit
Deleting documentation feels like destroying work.
Somebody spent time on those articles.
Their name is on them.
Worth remembering that the purpose was never to have documents.
It was to give people accurate answers quickly.
Every article that doesn’t do that is working against the ones that do.
So the most valuable thing a knowledge manager does in year 2 isn’t writing.
It’s removal.
Fewer articles, higher trust, more use.
That’s usually the whole fix.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
