In September 2007, the English-language Wikipedia passed two million articles. It had been built in six years by unpaid volunteers with no assigned owners, no editorial hierarchy and no budget. Every knowledge manager in every large company looked at that number and drew the obvious conclusion: if strangers on the internet will do this for free, our own employees will certainly document our processes. They did not. Enterprise wiki adoption in the years that followed produced one of the most consistent failure patterns in corporate software — fast initial enthusiasm, a burst of pages, then silence, then a slow accumulation of content that is worse than having nothing because people still believe it.
What the Technology Promised
The intellectual case had been made the year before. Andrew McAfee's "Enterprise 2.0" article in MIT Sloan Management Review argued that the mechanics that made the public web productive — search, links, lightweight authoring, tags, extensions and signals — could be turned inward, letting structure emerge from use rather than being imposed by an information architect. The tooling arrived to match. Socialtext had been selling a commercial enterprise wiki since 2002 and raised a further funding round in November 2007 with SAP's venture arm among the investors. Atlassian's Confluence, launched in 2004, was becoming the default for technology organizations. Plenty of companies simply installed MediaWiki, the software behind Wikipedia, and pointed staff at it. Compared with the alternative — documents on a shared drive, or an intranet where publishing required a request to the communications team — it was a genuine improvement. Anyone could create a page. Anyone could fix an error. Every change was versioned and attributable.
Why the Wikipedia Analogy Was Wrong
The comparison failed on four points, all of them structural rather than technical. Scale. Wikipedia's model depends on enormous numbers of readers producing a small number of contributors. The familiar rule of thumb from web usability research — roughly ninety percent of users read, nine percent edit occasionally, one percent create most content — is survivable at internet scale. In a 400-person company, one percent is four people, and they have day jobs. Motivation. Volunteers edit Wikipedia because they want to. Employees maintain documentation because it is in their objectives, or they don't. Almost no organization put it in anyone's objectives. Visibility of error. Correcting a stranger's article is costless. Correcting the page your director wrote, in public, with your name attached to the change, is a political act. Enterprise wikis suppress exactly the correction mechanism that makes public wikis self-healing. Stakes. A wrong Wikipedia article is embarrassing. A wrong internal procedure page causes someone to close a month-end incorrectly, misconfigure a firewall rule, or quote a client a price that no longer exists.
The Predictable Lifecycle
The pattern repeated across thousands of organizations with almost no variation.
- Launch. A champion installs the platform and evangelises it. Contribution spikes.
- Sprawl. Pages accumulate without structure, because emergent organisation requires more participants than exist.
- Duplication. Search is poor, so people cannot find the existing page and write a second one. Now two pages disagree.
- Decay. The champion changes role. Nobody owns the content. Pages describe a process that changed eighteen months ago.
- Distrust. Someone is burned by out-of-date information and tells colleagues not to rely on the wiki.
- Replacement. A new platform is selected to solve the problem, and the cycle restarts with the content migrated wholesale, stale pages included. Note what is absent from that list: any technology failure. The software worked. What failed was documentation ownership — the assignment of a named person who is accountable for whether a specific page is correct today.
Why Stale Content Is Now Actively Dangerous
For most of the last twenty years, an out-of-date internal page was a passive hazard. Someone had to find it, read it, and choose to believe it. That changed when organizations began pointing AI assistants at their knowledge bases. A retrieval system does not know that a page has not been touched since 2019. It reads the page, synthesises an answer, and presents it with complete confidence and no visible age. Stale content has been promoted from something you might stumble across to something the company's own tooling will quote back at you. This makes knowledge-base hygiene an operational risk control rather than a housekeeping task. Organizations deploying AI search across internal content without first addressing ownership and currency are automating the distribution of their worst pages.
What Actually Works
The organizations with functioning internal knowledge bases are not the ones with the best platform. They are the ones that imposed the discipline wikis were supposed to make unnecessary.
- Assign an owner to every page — a named individual, not a team or a department. Unowned pages get archived, not orphaned.
- Set review dates and enforce them. A page past review displays as unverified, or it is removed from search. Both work; silence does not.
- Document decisions, not just procedures. A record of what was decided, when, by whom and why ages gracefully. A step-by-step procedure rots the moment the system changes.
- Write where the work happens. Documentation that lives beside the process it describes gets maintained. Documentation in a separate destination does not.
- Delete aggressively. Most organizations need a fraction of what they have. Volume is not an asset; findability is.
- Make maintenance visible in objectives. If keeping a runbook current is nobody's measured responsibility, it will not happen, regardless of how easy the editor is to use.
- Curate before you connect AI. Retire, merge and date-stamp the top-traffic pages first, then expose the corpus to assistants. The uncomfortable conclusion from 2007 is that knowledge sharing is not a tooling problem and never was. Wikis removed the friction of publishing, which was the easy part. The hard part — someone being accountable for whether a statement is still true — has no software solution.
Questions Operators Ask
Why do enterprise wikis fail?
Because they assume voluntary contribution and self-correction at a scale that does not exist inside a single company, and because nobody is made accountable for keeping specific content accurate.
How much internal documentation should a company keep?
Only what someone is accountable for maintaining. A small, current, well-owned knowledge base outperforms a comprehensive one that cannot be trusted.
What is the difference between a wiki and a knowledge base?
In practice, governance. A wiki is an editing model; a knowledge base is a managed collection with owners, review cycles, lifecycle rules and a defined scope. The same software can be either.
Should we connect an AI assistant to our internal content?
Only after auditing currency and ownership. Retrieval tools present old content with the same confidence as new content, so unmaintained pages become authoritative-sounding answers.
Knowledge Platform Review — Outpace audits what your teams actually reference, identifies unowned and out-of-date content, and puts ownership, review cycles and retirement rules in place — particularly before internal AI search makes stale pages authoritative.