Tool Sprawl: When Single Source of Truth Collapses, and a Theme-Level Aggregation Design

• Intended readers: IT, knowledge management, and organizational change leads at companies where Notion, Confluence, Slack, Drive, and GitHub wiki are all in play at once
• Assumed background: A working understanding of Pattern G in “Building Your Organization’s Context Supply Capability: An Implementation Guide”
• Reading time: Full read about 13 minutes / skim about 4 minutes

Overview

Notion, Confluence, Slack, Google Drive, GitHub wiki, Quip — in the typical knowledge stack of a large enterprise, documents on the same topic end up scattered across all of them. Searching doesn’t surface what you need, and you fall back to “ask that one person.”

This article expands Pattern G from the sister piece “Building Your Organization’s Context Supply Capability: An Implementation Guide” into a standalone deep dive. Rather than chasing tool consolidation, the focus is a “single source of truth at the theme level” — together with a deprecation obligation when adding new tools, and federated search as a complement.

Symptoms: the reality of tool sprawl

Typical symptoms:

• The same project’s information is spread across Notion, Confluence, Slack, and Drive
• “Where is the latest version?” is a permanent question
• Federated search returns old or alternate-version content at the top
• “I wrote it on the wiki / shared it on Slack / sent it by email” — three versions of the same information
• Each department uses different tools, creating friction in cross-team work
• At separation time, “that doc is in the marketing team’s Notion / no, it’s in Drive” happens constantly
• The location of context to feed into AI is unclear (connects with Pattern C)

These get worse the larger the company. Productiv’s SaaS Management Index¹ and Okta’s Businesses at Work report² show that the average enterprise SaaS count routinely exceeds the hundreds. Panopto’s survey³ found that 81% of employees experience frustration when they can’t find the information they need.

Mechanism: tools accumulate because no one owns the consolidation decision

Tools proliferate by department, by era, by acquisition, and by individual leader preference. The decision to consolidate sits in nobody’s mandate, so it doesn’t get made:

• Departmental optimization: Engineering uses GitHub and Notion, Sales uses Salesforce and Confluence, HR uses something else
• Era drift: Five-year-old tools persist while new ones get added
• Acquisitions: Acquired companies’ tools run in parallel without integration
• Leader preference: A new CTO brings in their preferred tool; the predecessor’s stays
• Nobody is empowered to consolidate. “Standardize across the company” collides with departmental autonomy and provokes pushback. So nobody decides

Why “one tool for the whole company” doesn’t solve it

The intuitive answer is “standardize on one tool company-wide,” but that almost always fails:

• Department-specific needs don’t get met, leading to inefficiency
• Migration cost is enormous (thousands of person-months)
• During migration, the old tools remain anyway, so things still run in parallel
• Even after consolidation, folder and page structures stay inconsistent and searchability doesn’t improve
• “Where is that page?” survives standardization

Federated search isn’t a complete solution either

Federated search tools like Glean, Notion AI, or Slack’s built-in search help, but they aren’t the full answer:

• Buried information stays buried, even in search
• Old and new content are hard to distinguish
• Per-department access controls produce inconsistent results
• AI summarization can’t resolve contradictions across multiple sources

Federated search is a complement, not the core.

Directions for the fix

1. A single source of truth, at the theme level

Don’t try to consolidate tools. Decide a single source of truth per theme:

Theme	Single source
Code-level decisions (ADRs etc.)	GitHub (in the repo)
Strategy and executive direction	One of Notion or Confluence
HR policies and regulations	Confluence or a dedicated HR system
Customer information	Salesforce
Sales contracts	Drive or a contract management system
Incident response	PagerDuty + GitHub

For each theme, declare clearly: “If it’s here, it’s official; anything else is reference material.” Slice by theme, not by tool — that is the key.

2. Make deprecation mandatory when introducing new tools

A rule for new tool adoption: bring one in, retire one out.

• Every new-tool decision must include “what gets deprecated as a result”
• The deprecated tool needs a migration plan and timeline
• Responsibility for migrating existing data has to be explicit
• Set a read-only period for the old tool after deprecation

This deliberately slows down the organization’s tool adoption pace. It is also the only structural defense against runaway SaaS sprawl.

3. Federated search (as a complement)

In parallel with theme-level aggregation, build out federated search:

• Glean, Notion AI, Slite, or a dedicated enterprise search
• Show “source theme” and “last updated” on every result
• A UI that distinguishes old from current content
• Alerts on AI summaries when sources contradict each other

Federated search complements theme aggregation; it does not replace it.

4. Continuously surface “what couldn’t I find last week?”

In 1-on-1s, keep asking: “Was there anything you tried to find last week and couldn’t?”

• Aggregate monthly, classify by theme
• When the same theme repeats, run a focused aggregation review
• Use it to prioritize searchability fixes

This is ground truth. Recording the cases where real organization members actually got stuck reveals the real bottlenecks in searchability.

5. Document tool change history and migration guides

Even deprecated tools deserve a record of their existence, role, and replacement:

• “2024: Quip → Notion migration. Mapping table from old Quip URLs to new Notion URLs”
• A path for new hires to inherit information that retirees knew lived in a since-deprecated tool
• A way to reference past decisions (ADRs) that still live in deprecated tools

This is your organization’s tool archaeology, and long-term operations require it.

Anti-patterns

Pattern	What happens	Fix
Push for one company-wide tool	Migration cost and departmental resistance kill it	Theme-level aggregation
Add new tools without deprecation	SaaS sprawl compounds	One in, one out
Lean on federated search alone	A complement gets treated as the core	Pair with theme aggregation
Don’t record tool change history	Old documents become unfindable	Document migration guides
Avoid consolidation discussions in the name of departmental autonomy	The cross-company view disappears	Theme-level aggregation coexists with departmental autonomy

Summary

• Tool sprawl grows because consolidation sits in no one’s mandate
• “One company-wide tool” and “federated search” are not complete solutions
• Fixes: single source of truth per theme / mandatory deprecation when adopting new tools / federated search as a complement / surfacing search failures in 1-on-1s / documenting tool change history
• The point is to slice by theme, not by tool

Related articles

• Building Your Organization’s Context Supply Capability: An Implementation Guide — Parent article
• Documentation Theater — Searchability and the life and death of documents
• The Myth That “AI Will Read Context for Us” — Where AI’s input sources actually live
• ADR / Pitch / Kickoff Memo Implementation Guide — Designing for searchability

References

1. Productiv Q2 2024 SaaS Management Index Report — Productiv (2024). Average enterprise SaaS count and trends. [Reliability: Medium-High] ↩︎

2. Businesses at Work 2024 — Okta (2024). Enterprise SaaS adoption trends. [Reliability: Medium-High] ↩︎

3. Inefficient Knowledge Sharing Costs Large Businesses $47 Million Per Year — Panopto + YouGov (2018-07). 81% of employees feel frustration at being unable to find the information they need. [Reliability: Medium-High] ↩︎