The wiki was the right solution to a specific problem: how do you record institutional knowledge in a way that is persistent, organized, and searchable? For most of the 2000s and early 2010s, MediaWiki, Confluence, and their predecessors answered that question adequately. A team could create a page, organize it in a hierarchy, link related pages together, and build up a body of documentation that would persist beyond the tenure of any individual contributor.
The problem is that the way teams create and consume knowledge has changed substantially, while the wiki's fundamental architecture has not. What worked for a 20-person team building a relatively stable product in 2008 is straining under the demands of a 150-person product organization running six parallel product lines in 2025.
The Flat-Page Model's Structural Limits
A wiki page is a document. Documents have authors, creation dates, and hierarchical addresses (the path in the navigation tree). They are written at a point in time to capture knowledge as it existed then. They are revised - sometimes - when knowledge changes. And they are searched via full-text search that returns pages containing the query terms.
This model has three structural limits that become increasingly expensive as team size and documentation volume grow.
The first is that documents are written to be read, not queried. A well-written Confluence page explaining the authentication architecture is useful to an engineer who reads the whole page. It is much less useful to an engineer who wants to know specifically what happens when a token expires during a background sync operation. The page might contain that information, but finding it requires either reading the whole document or knowing which exact terms to search for.
The second limit is that wikis do not model the relationships between pieces of knowledge. The fact that the authentication architecture was rebuilt in response to a specific security incident is probably not captured in the authentication architecture page - that context lives in a Jira ticket or a Slack thread that nobody linked. The wiki page and the context that explains it exist in separate systems with no structural connection.
The third limit is that wiki maintenance does not scale with team growth. When a team has five engineers, it is feasible for two or three of them to take ownership of keeping documentation current. When the team has fifty engineers spread across multiple time zones, there is no practical mechanism for ensuring that documentation is updated when the underlying systems change. The ratio of documentation maintenance capacity to documentation volume is inversely correlated with team size.
Where Knowledge Actually Lives in 2025
The realistic picture of where a team's institutional knowledge actually lives is considerably messier than the wiki's tidy hierarchy suggests. In a typical engineering organization in 2025, knowledge is distributed across:
Confluence or Notion pages that range from meticulously maintained to years out of date, with no reliable signal indicating which is which. Jira or Linear tickets that contain decision rationale, edge case discussions, and implementation details in comments that were never promoted to documentation. Slack or Teams threads where architectural decisions were made, debugging sessions were documented, and institutional knowledge was synthesized in real time - and then became effectively unsearchable. GitHub or GitLab commit messages and pull request comments that explain why specific technical choices were made. Email chains for anything involving external parties, compliance questions, or decisions that needed a formal record.
None of these systems were designed to be a unified knowledge base. Each of them is optimized for a different purpose - project management, real-time communication, version control, structured documentation. The result is that institutional knowledge is distributed across six or more systems, indexed inconsistently, and accessible only to someone who knows which system to look in and what search terms to use.
The Confluence Search Problem Is a Symptom
When engineers complain about Confluence search, they are usually describing something more fundamental than search algorithm quality. They are describing the experience of knowing that the answer exists somewhere in the organization's documentation, and being unable to reliably get from the question to the answer.
Improving Confluence search would help at the margins, but it would not solve the underlying problem because a significant portion of the relevant knowledge does not live in Confluence at all. It lives in Jira, in Slack, in GitHub, in the heads of senior engineers who have accumulated context that was never written down in any system.
What Teams Are Actually Doing About It
The gap between what wikis provide and what teams need has generated a range of coping mechanisms, none of which fully close the gap.
Some teams assign dedicated documentation owners - engineers whose job includes maintaining the accuracy of specific sections of the wiki. This helps but does not scale and does not solve the multi-system problem.
Some teams adopt stricter documentation standards, requiring engineers to update relevant documentation as part of the definition of done for any ticket. This improves documentation consistency but increases per-ticket overhead and still does not address the knowledge that lives in non-documentation systems.
Some teams invest in knowledge management tooling that promises to improve search or organization. Most of these tools are still organized around the document-retrieval paradigm - they find pages that contain query terms, presented in a better UI.
The teams that have made the most progress are those that have shifted from a document-retrieval model to a question-answering model - systems that can synthesize information from multiple sources to answer a specific question, rather than returning a list of potentially relevant documents for the engineer to read and synthesize manually.
The Shift from Retrieval to Synthesis
The distinction between retrieval and synthesis is not subtle. Retrieval says: here are the five Confluence pages most likely to contain information relevant to your query. Synthesis says: here is an answer to your question, drawn from the authentication architecture page, the Jira ticket where the token expiry was debated, and the Slack thread where an edge case was resolved, with each source cited so you can verify the reasoning.
The synthesis model is more useful but substantially harder to build. It requires indexing knowledge across multiple systems, understanding the semantic meaning of queries rather than just matching keywords, and assembling answers from fragments rather than returning whole documents.
Advances in retrieval-augmented generation (RAG) and large language model reasoning have made the synthesis approach tractable for teams that would not previously have had the engineering resources to build it themselves. The tooling has matured enough that teams can now connect their existing knowledge sources - Confluence, Jira, Slack, GitHub - to a synthesis layer that answers questions rather than returning documents.
What This Means for Knowledge Management Investment
Teams evaluating knowledge management tooling in 2025 should be asking a different set of questions than they were asking in 2015. The relevant question is not "does this make our wiki better organized?" but "does this reduce the amount of time engineers spend searching for answers that already exist somewhere in our knowledge base?"
A tool that returns better-ranked document lists is a marginal improvement on a broken model. A tool that synthesizes answers from the actual sources where institutional knowledge lives - including the messy, unstructured sources like ticket comments and Slack threads - is a structural improvement that addresses the underlying problem rather than optimizing around it.
The wiki is not going away. It remains a useful place to store long-form reference documentation, architecture diagrams, and onboarding guides. But treating it as the primary mechanism for knowledge access in an organization of significant size and complexity is, in 2025, a decision to accept avoidable overhead as a permanent feature of how the team operates.
The teams that will build the most effectively are those that invest in knowledge infrastructure that meets engineers where they actually work - not where documentation theory says they should work.