"You'll have to ask Mr. Berger, he's been doing this for twenty years." If that sentence gets said in your company, you are looking at a knowledge silo. The knowledge exists in exactly one head, with no documentation and no second person who could step in. That is a bus factor of 1.
The same thing happens one level up. Sales knows why a customer gets special terms, and order processing only sees the discount. The service team has solved a recurring fault a dozen times, and production keeps building the part the same way. Here the knowledge sits in one team and does not reach the next.
Both forms can be broken up well, in a way the knowledge holders benefit from. Their knowledge is secured and appreciated, and they can finally take a vacation in peace. This guide explains what a knowledge silo is, how to spot one, five strategies that have proven themselves in practice and how to prevent silos between teams.
What Is a Knowledge Silo?
A knowledge silo is knowledge about a process, a system or a customer that stays with one person or one team and is not shared with the people who need it. It appears in two forms:
| Form | What it looks like | Typical risk |
|---|---|---|
| One person | Only Mr. Berger knows the customs handling or the old production line | The process stops during a longer absence or after a resignation |
| One team | Sales, service or production each hold knowledge the neighbouring team needs | Errors and duplicate work at the handover between departments |
Knowledge silos form quite naturally. Someone takes on a task, does it well, and because everything runs smoothly, nobody asks exactly how. Teams build their own routines, lists and shortcuts, and each of them makes sense locally.
Ten years later, the pricing calculation depends on one person and the customer history lives in the sales team's spreadsheet. Day to day that is barely noticeable. During a longer absence, a reorganization or when an employee resigns, it becomes very noticeable, and the notice period is short for a thorough handover.
Much of the knowledge in a silo is tacit knowledge: experience that the people involved hardly notice as knowledge any more. That is why silos rarely dissolve on their own.
How to Spot Knowledge Silos
You spot a knowledge silo by the questions that always go to the same place. These signals are worth watching for:
- Questions about a topic always go to the same person, even across departments.
- Colleagues are called during their vacation because nobody else can finish a job.
- Work piles up as soon as one particular person is out sick.
- Sentences like "only Schmidt knows that" or "ask the sales team, they have a list" come up regularly.
- Handovers between teams run by word of mouth, and the receiving team keeps asking follow-up questions.
- Two teams keep separate lists of the same customers, parts or suppliers.
A quick check per core process is the question "Who else can do this?" Wherever the answer is missing or comes hesitantly, there is a silo. The guide on the bus factor has a matrix to work through this systematically, and a skills matrix adds levels from "knows the process" to "can train others".
Strategy 1: Systematically map who is the only one who knows what
What to do
It starts with a map. Walk through your core processes, such as order handling, purchasing, complaints, invoicing and IT. A process map gives you the list. Ask two questions per process: Who can do this? And who else can do this?
Wherever the second question has no answer, there is a silo. Also note how critical the process is and how likely an absence is. A retirement in two years counts differently than a 30-year-old on a permanent contract. That gives you a simple priority list in which critical processes with a foreseeable departure come first.
Include the people who do the work every day, and not only the managers. They know which Excel sheet in sales holds the figures that count and how the vacation backup in accounting works in practice.
Typical mistake
The mapping grows into a major project with several workshops and a 40-page risk matrix. By the time the first measure starts, a fair amount has already changed. Keep the mapping deliberately rough. A list of twenty rows where you tackle the top five moves you forward faster than a complete analysis.
How you know it's working
For your five most critical processes, you can answer the question "What happens if person X is out starting tomorrow?" in one sentence. The answer contains a name and a plan.
Strategy 2: Interviews instead of "just write it down"
What to do
The obvious idea with knowledge silos is: "Ms. Krause, why don't you document your area?" This usually yields little, because experts hardly perceive their own knowledge as knowledge any more. Anyone who has done a job for fifteen years considers much of it obvious. Exactly that is what the successor will need.
Asking questions works well. Have the interview conducted by someone who doesn't know the process and asks open, curious follow-ups. "And what do you do when the supplier doesn't respond?" "Oh, then I just call Meier directly, he sits right..." Sentences like that rarely end up in self-written documentation, and yet they hold the actual knowledge.
A comparison of interviews, workshops and observation is in the guide on as-is process mapping, and more knowledge transfer methods are compared in a separate guide.
The snowball principle helps here, because every conversation brings up names. "Invoice approval is actually done by Max and Hanne." So Max and Hanne are the next people to talk to. That way you follow the people who actually hold the knowledge through the company, including where work is distributed differently from what the org chart shows.
If nobody internally has time for these conversations right now, there are tools for this today. With wissa.ai, an AI conducts the interviews via chat, around 15 to 20 minutes per conversation. It suggests colleagues who are mentioned as the next people to talk to and builds process documentation in which every statement can be traced back to its conversation. Try one interview for free
Typical mistake
If the conversation feels like an exam, knowledge holders understandably hold back. So say openly from the start what it is about: safeguarding and appreciating the person's knowledge. Anyone who shares their knowledge stays just as important to the team. They can also take a vacation without being called three times a day.
How you know it's working
Someone outside the field reads the documentation and can explain the process in broad strokes, including the edge cases that previously existed only by word of mouth. Contradictions often surface along the way. The boss says "it runs through SAP", and the team says "through three spreadsheets on the department drive". Such contradictions are a good sign, because in that moment you see for the first time how the workflow actually runs.
Strategy 3: Name backups and run through the process once
What to do
Every critical process needs a name in the second row, and that backup should have carried out the process once themselves. What a deputy arrangement that holds up during vacation looks like is covered in its own guide. During the first run, the knowledge holder sits next to the backup, watches and steps in only when things get stuck.
Concretely, the backup runs the month-end close, enters the customer order or files the customs declaration. They do it once, end to end, with real data in the real system. Afterwards everyone involved knows whether the documentation holds up and whether the backup could act in an emergency.
A proven occasion is the knowledge holder's vacation. Two weeks in which the backup takes over and only calls in a genuine emergency show reliably how well the handover went.
Typical mistake
The backup appears on the org chart but has never done the process. When it matters, system access, password and routine are missing. So schedule a run-through together with every nomination, so that the backup works in everyday practice.
How you know it's working
The knowledge holder was gone for two weeks, and the work carried on. The vacation stayed undisturbed, and no pile labelled "we'll sort that out when he's back" was waiting on their return.
Strategy 4: Document knowledge where the work happens
What to do
Documentation helps where the team finds it at the moment the question comes up. A process manual in the "QM_final_v3" folder on the file server helps little if nobody knows it exists. So keep knowledge where the work happens: in a shared knowledge base the whole company uses, linked from the ERP transaction or as a checklist right at the workstation.
A shared knowledge base matters most for silos between teams. When sales, service and production write into the same place, each team can read what the others know. How to build a knowledge base that people like to maintain is covered separately.
Usable documentation covers more than process steps. It also answers which systems you need and who knows them, where the credentials are and whom to call when case X happens. A tool register with access details and contact people spares a backup a long hunt for passwords on their first day. Screenshots help enormously too. "Then click the Billing tab" is unambiguous with a picture and often a guessing game without one.
Typical mistake
An additional tool gets introduced for the documentation, with its own login and its own place to check. After three months hardly anyone opens it. Use what you already have, or at least make sure there is one single entry point everyone knows.
How you know it's working
New employees and backups find answers themselves. It becomes measurable during onboarding. When the new colleague says in week two, "I found that in the documentation," the system works. If she still often stands at a colleague's desk, it is worth looking at what the documentation is missing.
Strategy 5: Institutionalize keeping it current
What to do
The real work begins after the first version. Processes change all the time, with a new supplier, a new ERP module or a new Word template, and the documentation should grow along with them. If it stands still, after a year or two everyone is back to asking Mr. Berger.
Staying current comes from a fixed routine. Proven options are:
- a review slot every quarter, with roughly 30 minutes per core process as a guideline,
- a documentation update as a fixed item in every process change,
- recurring short interviews that ask what has changed.
How living process documentation is structured is covered in the process documentation guide. It helps when changes become visible. Whoever can see what has changed since the last version can also tell that the documentation is alive.
Here too, the effort can stay small. wissa.ai updates the documentation after every conversation and shows the difference from the previous version, so you see at a glance what changed.
Typical mistake
When "everyone" is responsible for keeping things current, nobody tends to feel responsible day to day. Give it a name and a date: one person per area who doesn't write everything themselves but makes sure it happens.
How you know it's working
When questions come up, employees open the documentation first of their own accord. They do that when they trust it, and that trust stays as long as wrong entries are corrected promptly.
Preventing Knowledge Silos Between Teams
You prevent knowledge silos between teams by making the handovers visible and giving teams regular occasions to share what they know. The five strategies above work for single people. Between departments, a few additional habits help:
Document cross-functional handovers. A lot of knowledge gets lost where work moves from one team to the next, for example from sales to order processing. Write down for each handover what the receiving team needs: which information, in which system, in which state. Both teams sign off on it together.
Make knowledge sharing part of regular meetings. Ten minutes in an existing meeting are enough. One team explains a recurring problem it has solved, or a customer case with an unusual solution. That way insights travel between teams without an extra event.
Rotate and shadow. A day in the neighbouring team shows more than any document. A purchaser who has spent a day in production understands why the delivery date matters so much. Short rotations or job shadowing also create the personal contacts people use later when a question comes up.
Share insights in one place. Findings from projects, complaints and customer conversations belong in the shared knowledge base, visible to all teams. A short note with the date and the contact person is enough.
Agree on the same terms. Silos also grow from language. When sales means something different by "released" than production does, handovers go wrong even with good intentions. A shared glossary in the knowledge base keeps the terms aligned.
How these habits fit into a wider knowledge management approach is covered in the guide on implementing knowledge management.
Conclusion: start small, but start
The five strategies can be tackled well one after another. A realistic order starts with the map (strategy 1). Then come interviews for the two or three most critical silos (strategy 2) and run-throughs with the backups (strategy 3). Where things live (4) and the update routine (5) follow from that almost by themselves. For silos between teams, add the handover documentation and a fixed slot for knowledge sharing.
If you would like support with the interview part, wissa.ai is happy to take it on: AI-led conversations with your employees, around 15 to 20 minutes per conversation, with hosting in Germany and AI processing in the EU. The conversations describe workflows, roles and systems. They produce process documentation with an org chart, knowledge risks and onboarding plans, which grows with further conversations and update checks.
The page on knowledge management software shows how this works across teams. A free trial package to start with (10 credits, once per company, terms) usually covers a first interview, and interviewees don't need an account of their own. Try one interview for free
FAQ
What is a knowledge silo?
A knowledge silo exists when knowledge about a process, a system or a customer stays with one person or one team and does not reach the people who need it. If a single person holds it, the process stops during their absence. If a team holds it, errors and duplicate work appear at the handovers between departments.
What causes knowledge silos?
Knowledge silos usually grow out of good work. A person or a team solves a task well, and because it runs smoothly, nobody asks how. Other causes are high workload that leaves no time for documentation, separate systems per department, different terms for the same thing and handovers that run by word of mouth.
How do I spot knowledge silos in my company?
For each core process, ask "Who else can do this?" Wherever the answer is missing or comes hesitantly, there is a silo. Everyday signs are calls during vacation, sentences like "only Schmidt knows that" and tasks that pile up as soon as one particular person is out sick. Between teams, watch for repeated follow-up questions at handovers.
How do you prevent knowledge silos between departments?
Document every cross-functional handover with what the receiving team needs, and have both teams approve it. Give knowledge sharing ten minutes in existing meetings, use short rotations or job shadowing, and keep insights and a shared glossary in one knowledge base that all teams can read.
Why does "just write down what you know" so rarely work?
Experts no longer fully see their own knowledge. What has been routine for years gets left out as obvious, and that is exactly what the successor needs. Interviews with open follow-up questions draw out this implicit knowledge, which self-documentation rarely manages.
How do I convince knowledge holders to share their knowledge?
Be open about the purpose: it is about securing the knowledge and relieving the person. Convincing points are undisturbed vacations, fewer interruptions and fewer routine questions. Make participation voluntary and commit clearly that the conversations involve no evaluation of individual performance or behavior, which matters to the works council as well. If you use software for this, involve the works council early where one exists.
How long does it take to break up a knowledge silo?
For a single critical silo, a few weeks can be enough: one or two interviews, the documentation built from them and one run in which the backup does the process themselves. It is best to prioritize and start with the two or three most critical silos.
Sources
- ISO 9001:2015, clause 7.1.6 "Organizational knowledge": the knowledge necessary for the operation of processes has to be determined, maintained and made available.
- ISO 9001:2015, Annex A.7: explicitly names safeguarding the organization from loss of knowledge, for example through staff turnover or failure to capture and share information.