Knowledge Management: Why Storing It Was Never the Problem

A company’s knowledge settles in two places. Some of it is written down, in a wiki, a shared drive, a folder of slide decks somebody made for an onboarding two years ago. The rest walks around on two legs, in the head of the person who has done the thing four hundred times and is, at any given hour, the one person you cannot interrupt.

That second kind has a name. The philosopher Michael Polanyi called it tacit knowledge, and summed it up in a line worth keeping: “we can know more than we can tell” (Polanyi, tacit knowledge). The bicycle rider cannot explain how she balances. The veteran closer cannot say how he knew to wait. The knowledge is real, it is doing work, and it will not sit still long enough to be written on a card.

The whole discipline of knowledge management grew up around a sensible hope: get that walking-around knowledge onto cards, store them safely, and let anyone pull one when they need it. It is a good hope. It is also, in 2026, aimed at a problem we already solved, while the real problem stands untouched in the corner.

What is knowledge management, and where did it come from?

Knowledge management is the practice of capturing what an organization knows and getting it to the person who needs it. As a named discipline it is young, a creature of the 1990s, when two Japanese scholars, Ikujiro Nonaka and Hirotaka Takeuchi, asked why some companies kept inventing and others did not, and found the winners were good at turning private know-how into shared know-how.

Their answer was a model with a tidy acronym, SECI, worth a slow look because it names the move everyone else skips. Knowledge, they said, converts through four steps (Nonaka and Takeuchi, SECI model): socialization, tacit know-how passing person to person, the apprentice at the master’s elbow; externalization, someone writing the tacit thing down so it becomes explicit; combination, written pieces assembled into a playbook; and internalization, a person practicing the explicit thing until it sinks back into instinct and becomes tacit again.

Read that last step again, because it is the one the next thirty years forgot. Writing the know-how down was the middle of the journey, not the end. The point was for it to climb back into a human being and change what that human did. The card was never the destination. The behavior was.

The software industry kept the parts a database can do, and dropped the part it cannot. The 1990s gave us the first wave of knowledge management systems, big repositories meant to hold the corporate brain: Lotus Notes, intranets, document stores with taxonomies. The pitch never changed, capture it once, store it safely, retrieve it forever. A knowledge management system, in that telling, was a warehouse with good shelving, and by now the warehouse is a superb one.

Why did storing and finding stop being the hard part?

Because the tools got cheap, and then nearly free. Writing knowledge down used to take a project. Now anyone opens a doc and types, and the company wiki grows by the hour. Finding it used to mean knowing the right folder. Now you ask a search bar a plain-English question and it hands back a cited paragraph in a second or two. Tell a knowledge officer in 1998 that retrieval would one day be this good and they would have declared the problem won. For storing and finding, they were right.

So here is the puzzle. The systems are excellent and the knowledge still does not get used. Reps answer from memory on the call that matters. The new hire reinvents an answer that lives three clicks away. The policy everyone agreed to is honored in the meeting and forgotten by the work.

The warehouse is full. The floor empty.

The reason is not laziness, and reading it as laziness is the costly mistake. Consider the real moment. A person is mid-task, a buyer on the line, a deadline pressing, and the right answer is one tab away. Getting it means stopping, searching, scanning, and switching back, while the buyer waits. Pushing on without it keeps things moving. So they push on, without feeling it as a decision.

The tax on that detour is measured. The McKinsey Global Institute estimated that employees spend close to a fifth of the workweek, on the order of 1.8 hours a day, searching and gathering information (McKinsey Global Institute, 2012). A fifth of the week spent looking is a fifth not spent doing. No wonder a person would rather guess than go looking again.

What problem is left once storing and finding are solved?

Use. Getting a person to act on the right answer while they work. This is the third job, the one the warehouse was never built to do.

A library is a wonderful thing and a passive one. It waits. It is organized for the person who has already decided to walk in, climb the stairs, and pull a book. It does nothing for the person who needs the answer in their hands and cannot stop to fetch it. A recipe in a closed cookbook on a high shelf has never once seasoned a pot. The knowing was there. The doing was not.

There is a second leak, built into the human brain. We forget. Trained on a new objection script in January, a rep is running on a worn copy by March, not from carelessness but from being a person. So the system holds the right answer, the human half-remembers a worse one, and the gap never closes.

This is why a good knowledge management strategy can produce so little. It chased the wrong two jobs. It measured the warehouse, counted the articles, and never once asked the only question that pays: did the answer reach a person in time to change what they did?

The claim sits at the center of everything that follows. When documented knowledge goes unused, that is a system failure, not a people failure. The system put the answer somewhere that costs attention to reach, and asked a busy human to pay that cost at the worst moment. Blame the design. You would skip the stairs too.

How do you fix knowledge management for the moment of work?

Stop sending the person to the knowledge. Send the knowledge to the person. The fix is a change of direction, pull to push.

Pull is the library model. The answer sits in its building and waits to be fetched, and fetching it is a detour off the road the work is traveling. Push is the opposite. The answer arrives in the lane, in the tool where the work already happens, surfaced by what the person is doing. Same answer, opposite physics.

The moves that make it real are few, and they are structural:

• Deliver the answer in the flow of work. The next step, the objection response, the pricing rule should appear inside the tool the person already has open, so consulting it costs no detour.
• Curate to the next action. One right answer beats ten plausible results. A person mid-task needs the single next move, not a page of links to triage.
• Trigger by context, not by memory. The system should notice the situation, a renewal, a security review, a stalled deal, and offer the matching answer unasked.
• Inspect whether it was used. Count whether the guidance changed what the person did, not whether the document got a view. You can only improve what you inspect, so inspect the behavior.

That last move is the one teams tend to leave out, and it decides the rest. A program measured on article counts is measuring its own size; a program measured on whether the answer changed the next action is measuring the only thing the business feels. Inspection is also what lets a manager stop chasing and start coaching.

When the answer arrives in the moment, curated and triggered by context, the library has become a behavior system, the layer that meets a person in the flow and guides the next move rather than waiting on a shelf. This is what Nonaka’s forgotten fourth step pointed at: knowledge climbing back into a human and changing what they do. Inside revenue teams, we build that as the Behavior Layer, where knowledge sharing stops being a filing exercise.

The evidence that delivery is the deciding variable is not subtle. Our own State of Sales Enablement found that teams whose guidance lives 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 people, same content. The difference is whether the answer reached them where they were standing. When a century of memory research and our own field data agree that the timing of delivery decides outcomes, the argument is about as settled as it gets.

What we recommend

A leader looking at flat knowledge usage has two roads. The first is to keep improving the warehouse: write more, organize better, bolt on smarter search, and wonder why behavior does not move. It is the comfortable road, and it leaves the real problem where it was.

The second road treats use as its own job and builds for it. Deliver the answer in the flow, curate to the next action, trigger by context, and inspect whether the guidance was followed. We recommend this one, and not as a hedge, because the evidence runs one direction. People lose close to a fifth of the week to searching. Memory decays on its own. And guidance delivered in the flow more than triples quota attainment over guidance parked in a separate tool. Use is the work that moves the number.

So build the library if you must, then go past it. Nonaka told us forty years ago that the destination was the knowledge climbing back into a person and changing what they do. To go deeper, start with the tool the answers live in, the internal knowledge base, then how knowledge moves between people in knowledge sharing, the expertise that resists capture in tribal knowledge, the revenue-specific version in the sales knowledge base, and the tool field mapped by job in the best knowledge base software.