A Wiki Can Store Knowledge, But That Doesn’t Make It A Knowledge System
Governance matters, but so does tool category — and confusing collaboration with controlled content management is where many documentation teams get into trouble
A reader named Byron (aka The Grumpy Sociologist) left a thoughtful comment on my recent post about Confluence, wiki sprawl, and what happens when organizations start treating collaborative workspaces as if they were governed content systems.
His comment was fair — and also useful. The kind of useful that stings a little at first, which is often how useful arrives.
I believe Byron’s main point was this: the symptoms I described are familiar to anyone who has watched a wiki mature, decay, multiply, contradict itself, and eventually become the place where institutional knowledge goes to develop several competing personalities.
Contradictory pages. Stale search results. Important information hiding in old Slack threads. Authoritative guidance living in three places, each one slightly different and all of them confident.
He agreed those problems are real. Where he pushed back was on my diagnosis.
He argued that wiki rot is not really a property of the tool. It’s a property of the organization (or lack thereof, as the case may be). Replace Confluence with a component content management system, a docs-as-code pipeline, or a shiny knowledge delivery platform, and a team without governance will still produce scattered, contradictory, half-maintained content.
He’s right about that.
A bad ownership model will damage any system. As will a missing review cadence, weak or non-existent taxonomy or a lack of discipline. Authoring incentives that reward speed over maintainability invite challenges, and software doesn’t fix organizational misbehavior — because tools don‘t typically attend meetings, resolve accountability issues, or gently remind someone that copying the same warning into twenty-seven places is not a sustainable reuse strategy. It is a future incident report, at best.
That part of Byron’s critique lands.
But there’s another part of the argument that still matters, especially for tech writers. Governance matters. Culture matters. Ownership matters. But so too does tool category.
A collaborative wiki is not the same thing as a component content management system (CCMS).
And pretending those two categories are interchangeable is one reason documentation teams end up disappointed.
I Could’ve Been More Precise
Byron also called out my use of “knowledge management system” to describe Confluence. He said that was sloppy. He’s right.
I didn’t intend to say Confluence is a knowledge management system. What I meant is that many organizations use Confluence as though it were one.
That distinction matters.
Confluence is a collaborative wiki and team workspace. Atlassian describes it as “your team workspace for creating and sharing knowledge” and also markets it under wiki use cases as “The original Wiki.” Additionally, the company has a page that describes Confluence as knowledge management software, which helps explain why organizations often blur the categories in the first place.
So yes, I should have said this more clearly: Confluence can support some knowledge management practices.
That doesn’t make it the same category of tool as a purpose-built component content management system.
The Problem Isn’t ‘Confluence Bad, CCMS Good’
Let’s get the lazy argument out of the way. The problem is not “Confluence bad, CCMS good.”
A well-governed wiki may outperform a poorly governed CCMS. No argument from me. I’ve seen expensive systems become beautifully structured disasters because no one wanted to make hard decisions about ownership, authority, metadata, workflow, reuse, review, or retirement.
A CCMS without governance can become an expensive structured mess.
But the reverse is also true: a wiki, even a well-governed one, does not automatically become a CCMS because people write good rules around it.
That’s the point technical writers need to hold onto.
Governance determines whether the system succeeds.
The platform determines which governance model is practical, enforceable, scalable, and economically sustainable.
Those are not the same claim.
A Wiki Usually Manages Pages — A CCMS Manages Content Components
A collaborative wiki usually organizes content as pages. Teams create pages, edit them, and link them to other pages. They may also use the wiki to comment on pages, search them, and sometimes archive them if the organization using the wiki is unusually disciplined (or frightened by auditors).
That page-based model works well for many kinds of collaboration. It’s great for meeting notes, project planning, informal docs, lightweight processes, internal updates, and shared workspaces where the main goal is to get people contributing quickly.
But tech docs often requires different content models.
A component content management system manages content in smaller, structured, reusable units. Paligo describes a CCMS as software for “creating, managing, and publishing technical documentation through reusable content components,” where content is built from individual elements that can be assembled and reused across publications.
That difference is not academic. It changes what a system can do.
In a CCMS, a warning, prerequisite, troubleshooting step, safety statement, API parameter description, legal disclaimer, product specification, or reusable procedure can be managed as a component rather than as copied text scattered across a collection of hypertext-linked pages.
When the source component changes, the change can flow to every publication where that component appears. That’s not just “better governance.”
That’s a dramatically different technical capability.
Transclusion Isn’t ‘Exactly’ The Same Thing As Systematic Reuse
This is where the conversation gets more interesting. Someone might say, quite reasonably: “But wikis can do reuse. They can transclude content.” That’s true.
Transclusion is a mechanism. It allows one piece of content to appear inside another piece of content by reference. The source content lives in one place, and other pages display or publish it as though it lives there too.
That’s useful. It is much better than copy and paste. It can reduce duplication. It can help teams maintain shared content more consistently.
In the book, The Language of Technical Communication, Eliot Kimber explains that
“Systems that support transclusion also bring unavoidable complexity in terms of authoring effort, hyperlink management, configuration management, quality assurance of reused content, and so on. Tech writers need to understand the cost that comes with the power of transclusion so they can choose when to accept those costs. It is easy to transclude yourself into serious trouble. However, used correctly, transclusion enables more efficient authoring and management of information.”
Transclusion is not exactly the same thing as systematic reuse.
Ann Rockley’s concept of systematic reuse is broader. In Managing Enterprise Content, Rockley distinguishes systematic reuse from opportunistic reuse. Systematic reuse is planned.
“It requires teams to identify reusable content, design it intentionally, manage it consistently, and deliver it where it is needed. The content management system helps insert the right reusable content in the right place.”
That distinction matters.
Transclusion asks: “Can I include this content over there?”
Systematic reuse asks: “How do we design, govern, track, update, assemble, translate, and deliver reusable content across the entire content lifecycle?”
Those are related ideas, but they are not identical.
A wiki with transclusion can include content by reference. A CCMS is usually built around systematic reuse as an operating model.
That means reusable components aren’t just snippets that appear in multiple places. They are governed units of content with structure, metadata, ownership, version control, lifecycle state, translation status, and publishing behavior.
For tech writers, that difference matters because reuse isn’t just a convenience. It’s a control strategy.
Copy-and-Paste Reuse Isn’t Efficient Reuse
This is one of the places where the wiki-versus-CCMS distinction becomes obvious.
In a wiki, reuse often happens through copying, linking, embedding, transcluding, or manually referencing another page. Depending on the wiki and configuration, teams may create clever reuse patterns. Some teams do this well.
But in many organizations, not so much. Reuse becomes copy-and-paste focused. Someone writes a warning in one place. Another writer copies it into a second procedure. A third person revises it for a different product.
Six months later, support asks which version is correct. Nobody knows. Someone says, “Check Slack.” A small bird flies into a window. 🪟
A CCMS approaches reuse differently. It can track the source component, where that component is reused, which version appears in which publication, and what must be updated when the source changes.
That matters for documentation pros because we are rarely managing one page at a time. Typically, we’re managing content across products, versions, audiences, channels, languages, regions, and release cycles.
A page-based workspace can help teams write. A component-based system can help teams govern content as an asset.
Those are related activities, but they are not the same activity.
Structure Isn’t Decoration
Another difference is structured authoring. In a wiki, structure is often social. Teams agree to templates, labels, page hierarchies, naming conventions, and review practices. That can work, but much of the — a-hem — enforcement depends on human discipline.
In a CCMS, structure can be built into the authoring model. This means the system can enforce rules about what kind of information belongs where. A task can require steps. A concept can be kept separate from a procedure. A warning can use a defined structure. Metadata can be required before publication. Content can be validated before it goes downstream.
That matters because structure is not decoration. Structure carries meaning.
For tech writers, this is especially important in AI-enabled environments. When our content is ambiguous, inconsistent, duplicated, or poorly typed, AI systems have to infer what the content means. They have to guess whether something we typed is a concept, task, warning, exception, prerequisite, policy, release note, workaround, or obsolete instruction.
Sometimes the system guesses correctly. Sometimes it produces confident nonsense.
The more explicit the structure, the less the system has to infer. And the less it has to infer, the better chance we have of getting accurate, grounded answers.
Delivery Is Part Of System Design, Not An Afterthought
Collaborative wikis are often strong at internal authoring and knowledge sharing. They help people easily create and find pages. They support quick collaboration, comments, permissions, search, and history.
Those are useful capabilities. But documentation often has to go further.
A CCMS is usually specifically designed not just to store content, but to publish it in multiple forms: help sites, PDFs, portals, knowledge bases, release packages, training materials, in-product help, support content, and other outputs.
Related reading: Multi-channel publishing
That publishing model matters.
A tech docs team may need to deliver different versions of the same core content to different audiences. Administrators get one version. End users another. Partners get a slightly different version. Regulated markets need region-specific language. Enterprise customers need content for supported versions. Internal support teams may need additional troubleshooting details that should not appear in public documentation.
In a wiki, those variations often become separate pages, labels, manual conventions, or permission schemes.
In a CCMS, those variations can be managed through structured reuse, profiling, filtering, conditions, metadata, and publishing rules.
Again, this is not just governance. It’s governance made operational through system capability.
Localization Exposes The Difference Quickly
Localization is another place where the distinction becomes hard to ignore.
If your docs lives as pages, translation often happens at the page or document level. When content changes, you may need to determine what changed, where it changed, whether the change affects translated content, and which language versions need updates.
In a component-based system, the unit of management can be (and typically is) smaller. If only one reusable component changed, only that component may need translation. If the same component appears in multiple outputs, the translation can be reused as well. That can significantly reduce cost, improve consistency, and shorten translation cycles.
It also reduces the risk of slightly different versions of the same instruction appearing across products, regions, or languages. For global tech docs teams, that’s not a minor feature — that’s operational infrastructure.
Byron Is Right About The Organizational Problem
The strongest part of Byron’s argument is the part documentation teams should not ignore: Documentation problems are often organizational problems.
I agree.
Tools cannot:
👉🏼 decide who owns a procedure
👉🏼 decide when content becomes obsolete
👉🏼 force product managers to stop treating documentation as a release-day garnish
👉🏼 create a culture that rewards maintainability, clarity, and reuse
If an organization doesn’t value documentation governance, a CCMS won’t save it. Neither will docs-as-code or an AI chatbot with a soothing interface and a suspiciously cheerful answer to everything.
Doc teams need ownership models and review cadence. They need taxonomy and metadata discipline. and rules that govern content throughout its lifecycle. And, they need to put in place incentives that reward reuse and maintenance, not just new content production.
That is the foundation. Byron is right to insist on it.
But Tool Category Still Matters
Where I differ from Byron is that I don’t think tool category is secondary to the point of irrelevance. Platforms shape what’s easy, what’s difficult, what’s enforceable, and what is likely to happen under pressure.
And pressure is where documentation systems reveal themselves.
👉🏼 When the release is late, do writers reuse approved content or copy and paste from the nearest page?
👉🏼 When support finds an error, can the team update one source component or hunt down every duplicate?
👉🏼 When legal changes a required statement, can the team trace every place it appears?
👉🏼 When a product has three supported versions, can the team publish version-specific content without maintaining three separate page forests?
👉🏼 When AI retrieves content to answer a customer question, can it tell which content is current, authoritative, audience-appropriate, and product-specific?
Governance defines the desired behavior. The system determines how much effort it takes to behave that way. That’s why tool category matters.
Hopefully, A Better Way To State The Argument
After reading Byron’s comment, I’d restate my argument this way:
The problem is not that Confluence causes documentation chaos. The problem is that many organizations use collaborative wikis as if they were something they aren’t — governed content supply chains.
Then they act surprised 😱 when those systems cannot provide the same control, reuse, traceability, lifecycle management, localization support, and multi-channel publishing capabilities as systems built for those purposes.
Confluence can be a good fit for small teams, internal collaboration, project knowledge, lightweight documentation, and shared workspaces. A self-hosted wiki may also be a good fit for organizations with the engineering capacity to maintain it, customize it, secure it, and govern it properly.
Byron is right to point out that SaaS platforms bring real costs, including per-seat pricing, vendor roadmap dependency, migration complexity, and data control concerns. Those tradeoffs deserve serious discussion. But none of that changes the underlying distinction.
A collaborative wiki and a CCMS are different categories of tools. One is primarily optimized for collaborative knowledge creation and sharing. The other is designed to manage structured, reusable, governed content components through complex creation, review, translation, versioning, and publishing workflows.
You can govern a wiki well. You can also govern a CCMS badly. And, you can use transclusion in a wiki and still not have a systematic content reuse strategy you can depend on. 🤠