Why knowledge management failed and transactive memory did not

Every firm over a certain size has the remains of a knowledge management programme. A wiki with a 2019 timestamp. A precedent library with good coverage of three practice areas and nothing else. A capability database that was populated once, by an analyst, from a spreadsheet, and never again.

The usual explanation is cultural: people would not adopt it, partners would not lead by example, incentives were wrong. That explanation is comforting because it implies the next attempt could go better with more executive sponsorship. It is also wrong, or at least it puts the cause at the wrong level. The programmes failed because of an economic property of the approach itself, and no amount of sponsorship changes it.

The cost structure that killed it

Knowledge management, in its classic form, asks experts to externalise what they know. Write up the case study. Fill in the capability profile. Document the lesson learned. Tag the precedent.

That instruction has a cost, and the cost is proportional to the knowledge. To capture twice as much, someone has to do twice as much work. The work is skilled, so it can only be done by the expensive people, and it is not billable, so in a firm it competes directly with the thing the expensive people are measured on.

Transactive memory asks something different. It does not ask anyone to externalise knowledge. It asks only that the group can find its way to whoever holds it. The cost of that is proportional to the index, not to the knowledge, and an index is enormously smaller than the thing it indexes.

Writing down what a partner knows is a project. Recording that they know it is a line.

This is the whole argument, and everything else follows from it. A system whose maintenance cost scales with knowledge will always lose to billable pressure. A system whose maintenance cost is near zero can survive indefinitely, including through the quarters when nobody is thinking about it.

Four specific things classic KM got wrong

It treated tacit knowledge as compressible. The most valuable thing a partner knows about a client is not a document. It is a sense of how a board actually decides, which of two sponsors carries real weight, why an approach that looks obvious was tried and abandoned in 2021. Asking for that in a template produces a paragraph that is true and useless. The literature has called this the tacit knowledge problem for decades and the honest conclusion is that most of it does not survive the transfer.

It optimised for retrieval by browsing. Repositories are organised by taxonomy: practice area, sector, document type. That structure assumes the searcher already knows where to look. The questions firms actually have do not arrive in taxonomy form. "Who has worked with this person" cuts across every folder in the system.

It made freshness someone's job. A repository is only as good as its most recently updated corner, and there is always a corner nobody owns. Once a searcher finds one stale answer, the whole thing loses credibility, and credibility is not recoverable at reasonable cost.

It asked the wrong people. The person best placed to record what an engagement taught the firm is the person who ran it, who is also the person with the least available time and the strongest incentive not to. Every KM programme discovers this and responds by hiring a knowledge manager to chase them, which converts a knowledge problem into a compliance one.

Why the AI version of the same mistake is now being made

The current cycle is repeating this with better tools. Point a language model at the firm's document store, index everything, let people ask questions. The pitch is that AI removes the capture problem, because nobody has to write anything up.

It removes part of it. What it does not remove is the two harder problems.

The first is that the documents are not the knowledge. A firm's shared drive contains the artefacts of work: the deliverable, the final report, the signed proposal. It does not contain the reasoning, the relationships, or the reason a thing was done a particular way. Most of that happened in email, which is not in the document store, and in conversation, which is nowhere.

The second is credibility. A retrieval system that answers fluently from an undifferentiated pile will sometimes be confidently wrong, and in a firm, being confidently wrong once about a client is disqualifying. This is the same credibility dimension that killed the wikis, arriving faster.

What a transactive approach does instead

Three changes, and none of them require anyone to write anything up.

Build the index from work that already happened. Proposals, reports and the threads where the actual reasoning took place already exist and are already written. The only question is whether anything assembles them into a directory while the people involved are still there. In OrgAtlas that assembly happens from material the account team sends deliberately: forwarded threads, blind copies, and documents dropped in the browser. Nothing is scraped and nothing is filled in.

Index people and capability, not just documents. The unit that matters is not the report. It is the fact that a named colleague led that work, for that client, in that sector, and the report is the evidence. Search that returns a document leaves the searcher with reading to do. Search that returns a person ends the search.

Show the evidence, and show its absence. Every fact carries the document behind it, so a reader who does not trust it can check in one click. And where the firm has no experience, the record says so, drawn as a gap rather than filled with something plausible. A directory that is honest about its holes is one you can rely on about the rest.

The reason wikis died is that nobody could tell which parts were still true.

The honest limits

This approach does not capture everything, and it should not claim to. It will not preserve a partner's judgement, their sense of a room, or the twenty years of pattern matching behind a good instinct. Those genuinely leave when the person does.

What it preserves is the layer beneath: who was involved, what was delivered, for whom, when, with what evidence, and who else in the firm has done the same. That layer is unglamorous, and it happens to be exactly what someone needs three years later when they are preparing for a meeting with a stakeholder they have never met, at a client the firm has served for a decade.

Knowledge management aimed higher and delivered nothing. This aims lower and can actually be maintained.

Next: why adoption is the only feature that matters in firm-wide software