Knowledge management in business: write less, retrieve better

The short version

• Most of what a company needs to know is already written down somewhere nobody can find it, which makes this a retrieval problem before it is a writing problem.
• A wiki fails on trust before it fails on content: once a reader has been burned by a stale page, they stop reading pages and start asking people.
• The unit to measure is not pages published. It is questions answered without interrupting a specific named person.
• Buy the place documents live, because it is a commodity. Spend your real effort on retrieval across the systems you already run.
• Every vendor demo runs on content somebody tidied first. Ask to see it run on your worst shared drive, with real permissions applied.

What problem does knowledge management actually solve?

It solves the cost of answering the same question twice. Every business accumulates knowledge that lives in a few heads: why the pricing works that way, which supplier to call when the usual one is late, what happened last time a customer asked for a custom report. When somebody needs that and cannot get it, you pay in one of three ways. You interrupt the person who knows, you wait, or you guess and get it wrong.

None of those three costs appear on a line item, which is why this work is usually funded after something breaks. A key person leaves and takes the only copy of a process with them. Two people give a customer different answers in the same week. A new hire takes a quarter to become useful instead of a month. The cost was always there. The incident just made it visible.

The turnover part is not speculation, but its size depends on your market rather than on an industry average. If you want a national baseline for how long people stay in a job, the US Bureau of Labor Statistics publishes a tenure supplement to its household survey. The more useful exercise is local: for each process that matters, count how many people could run it unaided. Everywhere the answer is one, you have found your backlog, already in priority order.

Why do internal wikis stop being used?

Because nobody can tell which page is still true. A wiki fails on trust before it fails on content. Once a reader has followed a page that described last year's process, with nothing on it to signal that the process had changed, they stop trusting pages in general. After that the wiki is a graveyard you are still paying for, and it keeps growing, because writing a new page is easier than finding the old one.

The mechanics are always the same. Pages have no owner, so nobody is responsible for retiring them. There is no review date, so a page from 2023 looks exactly like a page from last week. The same topic gets written three times by three people and search returns all three without ranking them. Search matches words rather than meaning, so a page titled 'Refund authorisation thresholds' never comes back for 'can I give this customer their money back'.

'Just ask in the channel' then becomes the real knowledge system, and it mostly works, which is the trap. It works because a human is doing the retrieval: they know who knows, they know which document is current, they translate the question into the words the document uses. That human is the single point of failure you were trying to remove, and the answer they give leaves no trace for the next person who asks.

What makes a page worth trusting?

• •An owner by name, not by team. Teams do not delete things.
• •A last reviewed date next to the title, not buried in page history.
• •One page per question, with the duplicates deleted rather than cross linked.
• •A line saying what the page does not cover, so a reader knows when to stop reading.
• •A link to the system of record for anything that changes weekly, instead of a copy of it that will drift.

What should you write down, and what should you leave alone?

Write down decisions and the reasons behind them, plus anything you have now explained twice. Leave alone anything a live system already holds and keeps current, and anything that changes faster than you will review it. The second rule is the one people break. A page duplicating the price list will be wrong within a month, and wrong is worse than absent, because somebody will act on it.

Reasons matter more than steps. Steps can be reconstructed by a competent person with access to the system. The reason a step exists cannot, because it usually encodes a problem you hit once, a customer requirement, or a constraint somebody negotiated. A document that gives the what without the why gets abandoned the first time the situation differs slightly from the one described, and the person abandoning it has no way to know what they are breaking.

The trigger for writing something down is repetition, not importance. If the same question has arrived twice from different people, write the answer once and send the link the third time. That keeps the corpus proportional to real demand, which keeps it small enough to actually review. Sixty pages that are all current beat six hundred of unknown vintage, for retrieval as much as for trust: fewer near duplicate pages means fewer ways for a search layer to return the wrong one.

How is knowledge management different in IT companies?

The knowledge is already written down, just not in a form that answers a question. In a software business the real documentation sits in pull request discussions, ticket comments, incident channels and the code. All of it is searchable in the narrow sense that the text is indexed, and none of it is retrievable in the sense that matters, because answering 'why is this queue retried three times' means finding a conversation from two years ago that nobody would think to look for.

That changes the shape of the work. There is less to write from scratch and more to connect: a repository, an issue tracker, a chat archive and a document tool, each with its own permission model. The friction is also measured at scale in this industry rather than being anecdotal. Stack Overflow's annual developer survey asks professional developers how often they hit friction in their daily workflow, and that single question drew 28,462 responses in its 2024 run.

If you want to put money against it, use a wage figure you can defend. The Bureau of Labor Statistics publishes occupational wage data for software developers and QA analysts, which gives you an hourly number a finance team will not argue with. Then multiply it by hours you have actually observed, not by hours a calculator assumes. A smaller number you can source survives review. A larger one you cannot does not.

Can you trust the numbers knowledge management vendors quote?

Check who paid for the survey and who was in the sample, then decide. The figure repeated most often in this market is that 42% of information fails employees. It comes from a report commissioned by Coveo, a search vendor, based on a survey of 4,000 US and UK adults working at companies with 5,000 or more employees.

Neither of those facts makes the figure false. Together they make it useless as a basis for a decision in a thirty person company, because the sample is drawn from organisations two orders of magnitude larger, where the information problem is genuinely a different one: more systems, more duplication, more people who have never met. A number from a five thousand seat enterprise tells you nothing about whether your own team can find the onboarding checklist.

The same caution applies to every survey in this field, including the ones cited here. Atlassian's State of Teams work covers a genuinely large group, 12,000 knowledge workers and 200 executives across six countries, and it is still a vendor's own survey published by a company that sells collaboration tools. Read the sample, then ask whether it describes you. The cheapest evidence available is your own: one week of logged questions from your own team beats any published percentage.

How do you choose between knowledge management vendors, providers and building something?

Separate the two purchases first. One is a place for documents to live, with editing, permissions and version history. The other is retrieval across content you already have, scattered over tools that cannot see each other. The first is a commodity and you should buy it. The second is specific to your content and your permission model, which is why no product arrives already knowing it.

The first purchase is cheaper than people expect. Slab, to take one published example, lists its paid tiers at 6.67 and 12.50 per user per month on annual billing. For a team of twenty that is small against a single engineer week, which is a useful reference point when a knowledge management platform quotes a figure with a comma in it. Ask what the extra buys, and ask it per answered question rather than per feature.

For the second purchase, the only demonstration worth your time runs on your own content. Every demo you will be shown runs on a corpus somebody cleaned first. Point the thing at your messiest shared drive with real permissions applied, ask ten questions whose answers you already know, and count three categories: right, confidently wrong, and citing a document the asking user is not allowed to open. The third category is the one that ends projects after launch.

What are you actually buying?

When is knowledge management not worth doing?

When the team is small, stable and in one room, formal knowledge management is overhead you will not recover. Five people who have worked together for three years are a functioning knowledge system. They know who knows, and the cost of asking is a turn of the head. Writing that down produces documents nobody opens. Say so plainly and spend the week on something that pays.

The signals that it has started to matter are specific rather than vague. You hire somebody who was not there for the original decisions. The same question arrives from two people in a week. Somebody with unique knowledge gives notice. A customer gets two different answers from two of your people. Any one of those turns a theoretical cost into a real one, and the usual mistake is to answer it with a platform purchase instead of ten pages.

There is also a version of this project that is never worth doing, at any size, and it is the one that starts with migration. Moving six hundred unreviewed pages into a better tool gives you six hundred unreviewed pages in a better tool, plus a migration bill. If you are not willing to delete, start instead by answering this week's questions properly and let the corpus grow from demand.

How do you tell whether it is working?

Count questions answered, not pages published. The honest measure is the share of questions resolved without interrupting a specific named person. You can collect it by hand in a week, with no tooling: log every question asked in chat, mark whether the asker got there through a document, a search tool or a human, and read the list at the end. It will tell you whether your problem is content or retrieval.

After that, three numbers are worth tracking, all of them yours rather than borrowed. The share of questions a new hire can answer from documents alone in their first month. The count of pages whose review date is older than your review policy. The count of questions asked that an existing document already answered, which measures retrieval rather than content, and usually points at search instead of writing.

If a tool is answering questions, add one more. How often is it wrong? An assistant that is right most of the time and silent otherwise is useful. One that is right most of the time and confidently wrong otherwise is worse than nothing, because the reader cannot tell the two cases apart. Require a citation on every answer, then judge the citations rather than the prose around them.