Team Knowledge
How to break down knowledge silos — a practical guide for teams and organizations where critical knowledge is trapped in specific people, teams, or systems, creating organizational brittleness, slowing decisions, and widening capability gaps between teams.
A knowledge silo is a pattern where expertise or information is concentrated in one person, team, or system such that others who need it can't access it reliably. The silo may be unintentional — an expert who simply never documented their knowledge — or organizational — a team that developed specialized expertise and shares it only when directly asked.
The costs are structural:
Organizational brittleness: When knowledge lives in one person, that person's absence — vacation, illness, resignation — breaks organizational capability. The team can't make the decision, resolve the incident, or complete the process without the one person who knows how. This is the most visible cost and the most frequently experienced.
Decision latency: Teams that need to consult a single expert for every decision in a domain slow every decision that touches that domain. Dependency on one person or team becomes a bottleneck. Meetings are blocked waiting for the expert; projects slip when they're unavailable.
Capability inequality: When knowledge is siloed by team, teams with access to the knowledge work faster and with fewer errors than teams without it. This creates observable performance differences that look like talent differences but are actually knowledge access differences. Teams that "know how things work" deliver better outcomes than teams that are constantly asking.
Institutional memory loss: When knowledge silos are built around individuals rather than teams, retirements and departures take the knowledge with them. Organizations that have relied on key experts for decades discover, when those experts leave, that the knowledge was never transferred or documented.
Breaking down knowledge silos is not about eliminating expertise — it's about making expertise accessible. The goal is not that everyone knows everything; it's that the knowledge needed to make decisions, resolve incidents, and complete processes is available to the people who need it, when they need it.
Understanding how a silo formed is necessary for addressing it, because different causes require different interventions.
The accidental expert silo: A person with specific expertise is the "go-to" for a domain because they know it, not because they've been designated the keeper. Over time, other team members stop learning the domain because the expert is always available. The knowledge concentrates further. The expert becomes the single point of failure for everything in their domain.
The tribal silo: A team or group that has developed working knowledge through experience — the way things are actually done, as distinct from the way they're documented. New employees or employees from other teams don't have access to this tribal knowledge because it's never been written down, only passed through informal socialization within the group.
The tool silo: Knowledge trapped in a tool that not everyone has access to — the CRM that only sales uses, the analytics dashboard that only data science can read, the proprietary system that only one team has training on. The silo is not intentional; it's a byproduct of access and training distribution.
The organizational silo: Teams that don't share knowledge with other teams because of competitive incentives, communication overhead, or simple lack of structure for cross-team knowledge sharing. Each team accumulates knowledge that would be useful to others but never shares it systematically.
Each type of silo requires a specific intervention. The accidental expert silo is addressed through knowledge documentation and cross-training. The tribal silo is addressed through making implicit norms explicit. The tool silo is addressed through access and training distribution. The organizational silo is addressed through structured cross-team knowledge sharing.
Before addressing silos, map them. A knowledge audit identifies where critical knowledge is concentrated and what the risk of loss is:
The dependency map: List the 10-15 decisions or processes in your team or organization that would be most impaired if a specific person were unavailable. For each, identify: who holds the knowledge? Who is the backup? How many people can execute this process without the primary person?
A dependency map that shows many processes flowing through one or two names is a silo map. The names with the most dependencies are the highest-risk concentration points.
The "hit by a bus" exercise: A structured (if morbid) question: if a specific person left tomorrow with no notice, what would break? What decisions couldn't be made? What processes couldn't be executed? What knowledge would be unrecoverable? This exercise, done honestly, surfaces the tacit dependencies that don't appear in org charts or job descriptions.
The knowledge age question: For critical knowledge domains, ask: how old is the most recent documentation? Is there documentation at all? Would a new employee be able to understand and operate in this domain with existing documentation, or would they need substantial oral transfer?
The output of the knowledge audit is a prioritized list of knowledge risks: the domains where concentration is highest, documentation is thinnest, and the potential impact of loss is greatest. These are the silos to address first.
The most direct intervention for the accidental expert silo: convert tacit expertise into explicit documentation.
This is harder than it sounds. Experts know things they don't know they know — implicit assumptions, heuristics built from experience, exceptions learned through mistakes. These elements of expertise don't surface naturally in documentation because the expert doesn't think of them as knowledge; they think of them as obvious.
The interviewer approach: Rather than asking the expert to write documentation (which elicits the structured, official account rather than the tacit knowledge), interview the expert while a non-expert observes and asks clarifying questions.
"Why did you choose X rather than Y there?" reveals a decision heuristic. "What would you do if Z happened instead?" reveals exception handling. "How do you know when this is working correctly?" reveals evaluation criteria.
The interviewer asks the questions a non-expert would have; the expert answers them; the documentation is built from the answers rather than from the expert's unprobed account.
The shadowing session: Have a non-expert shadow the expert through a task or process. Every place the non-expert doesn't know what to do next, or doesn't understand why the expert did what they did, is a documentation gap. The shadowing session is the fastest way to identify the gaps in existing documentation or in the expert's mental model of their own process.
The recorded walkthrough: For complex processes, have the expert record a screen or audio walkthrough. The recording is not the final documentation — it's raw material. Someone else transcribes the tacit knowledge from the recording into structured documentation that can be maintained.
Documentation makes knowledge accessible; cross-training makes knowledge distributed. Cross-training produces multiple people who can execute a critical process, not just one person who documented it.
The rotation model: Engineering on-call rotations are the most common example — everyone rotates through on-call, so everyone gains operational knowledge of the production system that would otherwise concentrate in the most experienced engineers. The same model applies to any process with a natural execution rhythm.
The "shadow and lead" model: For processes that can't be formally rotated, use a two-phase approach. Phase 1: the non-expert shadows the expert through three executions, asking questions. Phase 2: the non-expert leads the next execution with the expert available to support. After two lead executions, the non-expert can execute independently.
The buddy system for new capabilities: When a new system, tool, or process is adopted, assign learning pairs: two people learn it together rather than one person learning it and becoming the expert. The learning pair produces two people with the capability rather than one, and the learning conversation between them surfaces gaps and questions that solo learning doesn't.
The organizational silo — where teams accumulate knowledge they don't share — requires structural mechanisms rather than individual interventions.
The demo and teach session: A recurring slot (bi-weekly or monthly) where a team presents what they know that other teams might benefit from. Not a status update; a knowledge transfer. "Here's how we think about capacity planning." "Here's the debugging approach we use for this class of problem." "Here's what we learned from the last major incident."
The standard is 20-30 minutes of genuine teaching, not polished presentations. The audience asks questions. The session is recorded and the recording is linked from the knowledge base.
The cross-team rotation: Engineers who spend time embedded in another team — even for 2-4 weeks — return with knowledge of how that team works, what their constraints are, and what they've solved. Bi-directional rotation (A sends one engineer to B; B sends one to A) is even more effective.
The public postmortem: Incident postmortems that are shared across teams (rather than kept within the affected team) spread the lessons from an incident more widely. The team that experienced the incident has specific knowledge about a failure mode; making that knowledge public prevents other teams from encountering the same failure unknowing.
The "office hours" model: A domain expert makes themselves available at a specific time for questions from any team. The format — structured availability — is more effective than "ask me anytime" because it batches the interruptions, creates a ritual, and signals that the knowledge sharing is intentional rather than incidental.
The tribal silo — where a group's working knowledge is implicit and informal — is addressed by making the implicit explicit.
Every organization has norms that new employees and outsiders don't have access to:
These implicit norms can only be documented by people who have internalized them — but those people don't think of them as knowledge because they seem obvious. The interviewer approach (above) is effective here: ask people from outside the group to ask "why?" until the implicit becomes explicit.
The "how we work" document: A team-level document that makes implicit working norms explicit. "How we make decisions." "How we handle disagreements." "What information we expect in a status update." "What our working hours are and when we expect synchronous availability." "What context we want before agreeing to a meeting." These norms exist in every team; writing them down means new members don't have to learn them through months of implicit socialization.
Knowledge silos are broken incrementally. Useful measures:
The backup coverage ratio: For critical processes and decision domains, what percentage have at least two people who can execute them without the primary person? Increase this ratio over time.
The incident bus factor: "Bus factor" (or lottery factor) is the minimum number of people who must leave or be unavailable before a function breaks. A bus factor of 1 for any critical function is a priority risk. Target bus factor of 2+ for all critical functions.
New employee time to productivity: If knowledge silos are concentrated in people rather than documents, new employees take longer to become productive because they have to find and interview the experts. A decrease in time-to-productivity is evidence that knowledge is becoming more accessible.
Documentation age: Track the average age of documentation for critical knowledge domains. Older documentation indicates silos that haven't been addressed.
Setup: A 12-person team maintains legacy billing infrastructure that the rest of the company depends on. The system is 15 years old. Two engineers — both with 10+ years of tenure — hold most of the operational knowledge. They are both planning to retire within 3 years. There is almost no documentation for the billing system. The rest of the team knows the system superficially but couldn't operate it independently.
What they do:
Month 1: Structured knowledge interviews. A technical writer and a junior engineer interview each expert for 2-hour sessions, asking "explain what you're doing and why" for 10 critical operational scenarios. The sessions are recorded and transcribed. The junior engineer's questions — "what does that error mean?", "why wouldn't you use X instead?" — surface the tacit knowledge.
Month 2: Documentation sprint. The transcripts are converted into 20 operational runbooks. The experts review and correct them. The process surfaces 12 things the experts know that weren't in the transcripts — each becomes an additional document section.
Month 3-6: Cross-training. Junior engineers shadow experts on every operational task. The buddy system produces two engineers who can execute each task independently. The experts are still faster, but are no longer the only ones.
Ongoing: All system changes require updating the relevant runbook in the same PR. Monthly "billing system office hours" where other teams can ask questions, recorded and linked from the knowledge base.
Result: at the first expert's retirement, the remaining team can operate the system. The second expert's retirement is managed with confidence.
Knowledge silos are organizational vulnerability — they make the organization brittle to individual absence, slow to decisions that require specialized context, and at risk of catastrophic knowledge loss when key people leave. Breaking them down is an organizational design challenge, not a culture problem: it requires specific interventions for specific silo types — expert interviews for tacit knowledge, cross-training for operational knowledge, structured sharing for team-level knowledge, and explicit documentation for implicit norms. Teams that build these practices into their regular operations — not as a one-time project but as ongoing maintenance — build organizations that are resilient to individual departures and capable of growth without proportional scaling of expertise bottlenecks.
More WebSnips articles that pair well with this topic.
How to run a documentation audit — a practical guide for teams who want to systematically assess what documentation exists, what's accurate, what's missing, and what should be removed, producing a clear action plan for a knowledge base that's trustworthy and complete.
How to build a company handbook — a practical guide for founders, operations leaders, and HR teams who want a handbook that communicates what the company values, how it works, and what employees can expect, without producing a bureaucratic document no one reads.
How to build a company knowledge base — a practical guide for teams and organizations who want to capture institutional knowledge, reduce repeated answering, and make organizational context accessible to every employee regardless of when they joined.
How to build a decision log — a practical guide for teams and organizations who want a permanent, searchable record of significant decisions that makes the reasoning behind current practices visible and prevents repeated debating of already-resolved questions.
How to capture knowledge from departing employees — a practical guide for managers and HR teams who want to systematically extract institutional knowledge before it leaves with an employee, rather than discovering the gaps after they're gone.
How to create a knowledge-sharing culture — a practical guide for teams and leaders who want knowledge sharing to be a natural part of how people work, not a program that requires constant top-down pressure to maintain.