Knowledge Silos: Breaking Them Is Necessary, Not Enough

A grain farmer with three silos has a particular kind of headache. The corn is dry and sound, the wheat is in good order, the barley is fine, and not a kernel of any of it is feeding the cattle waiting in the yard. Full silos, hungry animals. The problem was never storage. The grain was stored beautifully. The problem was that nothing carried it from the tower to the trough.

Companies have the same towers. Sales holds the renewal play in a private channel, support holds the real objection in a ticket queue, one tenured rep holds the workaround in their head, and a doc nobody opens holds the rest. We call these knowledge silos, and the standard advice is to tear down the walls between them. That advice is right. It is also half the job, and the half that gets skipped is the one that feeds the cattle.

What are knowledge silos?

Knowledge silos are bodies of know-how trapped inside one team, tool, or person, where the answer exists but cannot cross to the people who need it. The expertise is real and the cause is rarely malice. A team builds a fix and keeps it in its own tools. A specialist solves something hard and never writes it down because writing it down is not their job. Over time the company holds a great deal of hard-won expertise and depends, for any given answer, on whoever happens to sit near it.

The cost is not abstract. When the answer is walled off, the people outside the wall do one of three things: interrupt a colleague, rebuild work that already existed, or guess. The McKinsey Global Institute estimated that knowledge workers spend close to a fifth of the workweek searching for and gathering information (McKinsey Global Institute). A silo turns a one-time discovery into a recurring tax, paid every time someone hits the wall and starts over.

So far the conventional story holds, and the conventional fix follows from it. If the problem is walls, take down the walls. Pull the scattered know-how into one place, give it an owner, make it searchable. That is what most teams mean by breaking knowledge silos, and they are not wrong to do it.

Here is where we part from the conventional account. Breaking the silos is necessary and it is not enough. Even perfectly un-siloed knowledge, every tower emptied into one searchable store, still goes unused if it never reaches the person at the moment of the work. You can trade many small unused stores for one big unused store and call the project done. The walls are gone. The cattle are still hungry.

Why is breaking knowledge silos not enough?

Because tearing down the walls fixes where the answer lives, and the failure was never only about where it lives. It was about when it arrives.

Picture the rep on a renewal call when the buyer hints at leaving. In the old siloed world the retention play sat in another team’s tools, unreachable. So the company runs the silo project, consolidates everything into one shared store, and now the play is right there, findable in seconds. The rep is still on the call. They will not put the buyer on hold to go search a store, however well organized. They answer from instinct, the same as before. The wall came down and the answer still did not reach the corner where the decision was made.

This is the part the org-chart framing misses. Consolidation solves finding. It does not solve using.

Memory finishes what timing starts. Hermann Ebbinghaus showed more than a century ago that we shed most of what we learn within days unless something brings it back at the moment of need. A team trained on the consolidated playbook in a Monday session is running on a fading copy by Thursday. Panopto’s workplace knowledge study found employees lose about 5.3 hours every week waiting on knowledge a colleague holds or rebuilding expertise that existed somewhere already (Panopto, Valuing Workplace Knowledge). Those hours do not disappear when you merge the silos. They move from “I cannot find it” to “I found it last week and cannot recall it now.”

There is a second trap inside the win. A consolidated store feels like progress because it is measurable: one place, full of articles, with a search bar. Volume of stored answers and amount of answers used are different numbers, and only the first one shows up on the dashboard. So the team mistakes a full store for a working one, the same way the farmer might admire three brimming silos and forget to look at the yard.

None of this means the consolidation was wasted. It means the project was scoped to half the distance.

What does it take to make un-siloed knowledge get used?

Pair the silo project with delivery and adherence, or you have only moved the unused knowledge to a tidier address. The moves are concrete, and they pick up exactly where breaking the walls leaves off:

• Consolidation. Break the silos into one home with a named owner. This is the necessary first step the standard advice already covers, and skipping it leaves the answer scattered and stale.
• Delivery in the work. Carry the answer to the person inside the tools where they work, the instant the situation calls for it, instead of waiting for them to remember it exists and go search. This is the step the silo project leaves out.
• Curation to one step. Surface the single move the person needs now, not the whole consolidated library. A precise answer in the moment beats a complete store they have to triage mid-call.
• Inspection of use. Measure whether the answer changed the next action, not whether the store is full. The number that matters is adherence to the right move, and it is the one nobody counts when the project ends at “consolidated.”

That last move is the one that separates a team that consolidated from a team that improved. A store measured on article counts rewards filling it. A system measured on whether the answer changed the next action rewards use. This is the same shift behind a well-built internal knowledge base and behind capturing the tribal knowledge your best people carry off in their heads: the value was never in the storing, it was in the arrival.

Treat knowledge sharing as a delivery problem and the org-chart questions soften. People are usually willing to share, and the tools to consolidate are everywhere, as we argue in the case for knowledge sharing as a behavior problem rather than a culture one. The wall was real and worth removing. It was not the last wall between the answer and the person.

The evidence that delivery is the lever, not storage, is in our own data. The State of Sales Enablement found teams whose guidance reaches them in the flow of the work hit quota at 49 percent against 15 percent for teams whose knowledge sits in a separate destination (The State of Sales Enablement). Same content, same people; the difference was whether the answer arrived where they stood or waited to be fetched. Tearing down the walls put the answer in one place. It did not put it at the corner.

What we recommend

Two ways to run a knowledge-silo project. You can scope it to the walls: consolidate the scattered stores into one searchable home, give it an owner, declare the silos broken, and keep losing hours to a team that now has one tidy archive nobody acts on in the moment. Or you can scope it to the whole distance: break the walls, and then deliver the answer into the work, curate it to one step, and inspect whether it changed what the person did.

We recommend the second, because the numbers point one way. Knowledge workers lose close to a fifth of the week to information they cannot find or recall. Institutional knowledge that sits in a consolidated store still decays without a prompt at the moment of need. And answers delivered in the flow more than triple quota attainment over knowledge parked in a separate place. Breaking the silo was the necessary half. Getting the answer to arrive when it counts is the half that feeds the cattle.

So tear down the walls, and then keep going. The store is the start of the work, not the end of it. Begin with where that knowledge should live in the internal knowledge base, the expertise worth capturing first in tribal knowledge, and the sales-specific version in the sales knowledge base.