The Real Reason Nobody Deletes Old Documentation

Every knowledge base I’ve inherited has the same problem.

Too much content, not too little.

Hundreds of articles, several versions of the same procedure, material describing systems decommissioned years ago.

Everyone agrees it needs cleaning up.

Almost nobody actually does it.

The interesting question is why, since the fix is obvious plus nobody’s arguing against it in principle.

🧠 Losing feels worse than gaining

There’s a well established pattern in how people weigh decisions.

A loss registers as roughly twice as significant as an equivalent gain.

Applied here, that means deleting an article feels like a definite loss, while the benefit of a cleaner knowledge base feels abstract plus distant.

You can picture the moment someone needs that page.

You can’t picture the 40 people who’ll find the right answer faster next quarter.

So the calculation, emotionally, always favours keeping it.

That’s not irrationality.

It’s just how the weighing works when 1 side is concrete, the other is statistical.

🔨 People overvalue what they built

There’s a second effect stacked on top.

People consistently rate things they made themselves as more valuable than an outside observer would.

Assemble the furniture yourself, you’ll value it more highly than the identical item bought pre-built.

The same applies to documentation.

Someone spent 3 hours writing that article.

Their name is on it.

Asking them to delete it isn’t asking them to remove content, it’s asking them to write off their own effort.

Which is why cleanup projects stall at exactly the point where you need the original author’s agreement.

🤷 Nobody owns the decision

The third reason is structural rather than psychological.

Most articles have no owner.

They were created by a project, the project ended, the article stayed.

So when cleanup comes around, there’s nobody with clear standing to say “yes, remove it”.

Deleting someone else’s work without permission feels presumptuous.

Getting permission requires finding someone who’ll take responsibility.

Since nobody will, the article survives by default.

Default survival is how knowledge bases grow to 3 times the size they should be.

💸 What keeping it actually costs

The case for deletion only works if the cost of keeping becomes visible.

Here’s what a stale article does.

  • A search returns 4 results, only 1 correct, with no way to tell which
  • The reader picks wrong, then does the task incorrectly
  • A second ticket gets raised to fix the first mistake
  • That person stops trusting search, asking a colleague instead, permanently
  • Every accurate article gets diluted, since the reader now has to sort

That last point is the one worth arguing with people.

Stale content isn’t neutral.

It actively degrades the content you want people to use.

Forty accurate procedures outperform 300 mixed ones, every time.

🗑️ How to make deletion feel safe

Since the resistance is emotional plus structural, the fix has to address both.

Practical approaches that work.

  • Archive rather than delete, since reversibility removes most of the fear
  • Frame it as retirement, not removal
  • Run it as a systematic audit, so no single article feels personally targeted
  • Use view counts as the trigger, since a number is harder to argue with than an opinion
  • Never name the original author in the decision
  • Do the first pass yourself, then ask for confirmation rather than permission

That last point matters.

“I’m archiving these 40 unless you object by Friday” gets a very different response to “should we archive these 40?”

One requires effort to stop, the other requires effort to proceed.

People respond to whichever direction the default points.

📉 Use a number, not a judgement

Make the criteria mechanical wherever possible.

  • Nothing opened in 12 months
  • Anything referencing a system no longer in production
  • Duplicates, keeping the most recently reviewed version
  • Drafts that were never finished
  • Anything nobody will claim ownership of

A mechanical rule takes the personal element out of it.

Nobody’s work is being judged, a policy is being applied.

That distinction does more for getting cleanup approved than any amount of reasoning about information architecture.

✅ Where it leaves you

The barrier to cleaning up a knowledge base is almost never technical.

The tooling makes it easy.

The barrier is that removal feels like loss, authorship feels like ownership, plus nobody wants to be the person who deleted something that turns out to matter.

So design around that.

Make it reversible, make it systematic, make the default point towards removal rather than retention.

Then the knowledge base starts shrinking towards the size it should have been.

Fewer articles, higher trust, more use.


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

Read More

Related Posts

The Real Reason Nobody Deletes Old Documentation

Every knowledge base I’ve inherited has the same problem. Too much content, not too little. Hundreds of articles, several versions of the same procedure, material describing systems decommissioned years ago. Everyone agrees it needs cleaning up. Almost nobody actually does it. The interesting question is why, since the fix is

Every Knowledge Base Has These People

Spend enough years around documentation work, you start recognising the same characters in every organisation. Different industries, different platforms, same cast. None of them are difficult people. They’re all responding sensibly to incentives nobody designed on purpose. Recognising which one you’re dealing with tends to be more useful than any

Generation Is Cheap Now, Judgement Isn’t

There’s a line I keep coming back to when people ask whether AI is a threat to technical writing. Producing text has become cheap. Deciding whether that text is right, whether it’s needed at all, whether it’s in the right place, has not. Those were always different skills. They just

Getting Time With SMEs Who Genuinely Don’t Have Any

Every knowledge base project runs into the same wall eventually. The person who knows the most has 40 meetings a week, an incident to manage, plus 3 other projects asking for their time. Your request sits in their inbox, unread, for a fortnight. This isn’t a motivation problem on their