Knowledge that doesn't walk out the door with an employee

At a fifty-person company, a colleague who handled invoicing and the relationship with the two biggest suppliers leaves after seven years. The handover takes two weeks and follows the standard playbook: her successor sits with her, takes notes, goes through the folders on the drive. Three months after she's gone, a complaint comes in that nobody knows how to handle, because for years it was resolved as a one-off exception agreed over the phone. Five months in, it turns out one contract has a silent addendum only she knew about. And a year later, the company is once again dealing with a question this colleague had already resolved the year she started — except there's no record of it anywhere, so it gets solved from scratch, and differently.

This isn't a story about a careless employee. It's the normal state in most organizations. Knowledge has a strange property: as long as the people who hold it are still at the company, it's invisible that none of it is written down. It looks like the company knows. In reality, specific heads know it — and the company is just borrowing it.

Company knowledge is what remains once people leave. Everything else is personal knowledge that happens to be sitting in your building. This installment of the series is about how to turn the second into the first — and why that's not a tool-rollout project, but a change in a handful of small habits. The previous chapter ended on the point that a decision nowhere recorded behaves exactly like a decision that never got made. Here we build a whole system on top of that.

Why companies keep reinventing the same thing

Repeated work in organizations doesn't arise from stupidity, but from three very human mechanisms.

The first is the mismatch between the cost of writing something down and the cost of searching for it. Writing down how I did something costs me twenty minutes today. Someone else will benefit from it, eventually, maybe. The individual's economics and the company's economics directly contradict each other here — and without pressure from the system, the individual's economics wins. That's why documentation never gets written "when there's time." By definition, there's never time for it.

The second mechanism is the curse of knowledge. Once you understand a problem, you stop seeing what was hard about it. You describe a process in three steps, because the fourth feels obvious to you. The newcomer then gets stuck at exactly the step missing from the document, and concludes it's not worth reading documentation. They're not wrong — the fault isn't in their judgment, it's in whoever wrote the document without having someone unfamiliar with it test it first.

The third is unfindability. In many companies, the knowledge exists, it's just that nobody can find it. It sits in three versions on a shared drive, in a chat archive, in an email attachment from a year most of the current team wasn't even there. When searching takes longer than asking a colleague, people will rationally ask the colleague. And if it's knowledge only one person has, that person will keep getting interrupted.

The cost of these three mechanisms never shows up on any balance sheet, because it's made up of small amounts: half an hour of searching, the same question asked twice, a project redone in a slightly worse version. Summed over a year, it's usually more than it would have cost to establish order in the first place.

Three layers of company knowledge

Knowledge isn't one pile. It has three layers, which get documented differently, have different lifespans and different value — and companies almost always take care of only the first.

Processes and procedures describe how something gets done: closing the books, onboarding a client, publishing an article, handling a complaint. This layer is the easiest to document and has immediate payoff — the more recurring things take the form of a checklist, the less gets forgotten and the smoother the handover. But it has a short shelf life. A procedure nobody has reviewed in a year usually describes a company that no longer exists.

Decisions and their reasons are a layer we'll cover on their own further down, because it's by far the most valuable. A procedure says what to do. A decision says why exactly this way, and what was tried before you got here. Without this layer, a company regularly cancels things that had a good reason and reintroduces things that already failed once.

Tacit know-how is what a person can do but can't describe: when it's worth calling a specific supplier instead of emailing, how to tell a project is starting to come apart, which exception the boss will approve and which they won't. This layer can't be extracted from someone's head by any form. It only transfers through working together — pairing, shadowing, mentoring, commented feedback on finished work. Companies that don't grasp this think they're done once they have a wiki. Then someone leaves, and they find out the wiki only ever captured the easiest-to-write-down third.

A useful practical consequence: you can get at least partway into the tacit layer with questions. Not "describe your job," but "when did this last not work, and what did you do," "what would you tell a newcomer so they don't mess it up," "what would you do if time were the priority." The answers to these questions can be written down. A job description can't.

Documentation people actually read

Most company documentation fails not because of what's in it, but because nobody trusts it. Distrust builds fast: a person finds an outdated procedure twice, and won't try looking a third time. Trustworthy documentation needs three things that can be put in place in an afternoon.

An owner. A specific name in the document header, not a department. An owner doesn't mean they write the whole text themselves — it means they're accountable for its accuracy and get a reminder to review it. A document with no owner is, in practice, a document with no guarantee.

Date of last review, and the interval until the next one. Not the creation date, which tells the reader nothing, but a line like "verified February 3rd, reviewed every six months." A reader can then judge for themselves whether to trust the text or check with someone. An outdated document pretending to be current does more damage than none.

One source of truth. For every piece of information, there's exactly one place where it lives. Everywhere else, there's a link, not a copy. This is the hardest rule in this whole chapter to hold, because copying is convenient and feels harmless at the moment you do it. But two copies mean that, six months from now, they'll differ, and nobody will know which one is right. The cheapest prevention is zero tolerance for duplicates, from the start.

Two things about form come with this. Short, actionable phrasing — documentation doesn't get read, it gets scanned. Headings, steps, the key bit bolded. A flowing five-paragraph text is a description, not a how-to. And the newcomer test: a procedure is finished the moment someone who's never done the task can follow it and succeed without needing to ask anything. As long as they need to ask, the document is missing exactly the thing they asked about.

Writing up procedures, incidentally, is work that AI supports well today. A dictated description of "how I do this" can be turned into a structured checklist, a long policy into a summary for new hires, an email conversation into a decision record. But the same rule still applies: AI proposes, the human approves. Especially for policies and procedures people then follow, there has to be a person at the end who read the text and put their name to it. And sensitive company documents belong exclusively in a paid account with contractual data protection, not in whatever tool happens to be handy.

Metadata: the condition for being able to search at all

Once a company has more than a few hundred documents, the question stops being whether the knowledge exists and starts being whether anyone can find it. And that's where most attempts at a company knowledge base break down.

The functional minimum is boring and hasn't changed in twenty years: consistent file naming (a date format that sorts correctly, document type, client or project, version), a clear folder or workspace structure that follows how people think, not the org chart, and tags on documents that can be filtered: department, type, validity, sensitivity. On top of that, one thing that gets forgotten most: sensitivity classification. Public, internal, confidential. Without it, a company doesn't know what it can share externally, what can go into a cloud service, and what must never leave its own system.

This unglamorous tidying now has a new and very concrete reason behind it, too. Metadata is the precondition for AI being able to search company data at all. A language model connected to company storage is only as good as the order in that storage. When there are three versions of a contract sitting in a folder with no date and no validity label, the model will happily pull the expired one — and do it confidently. When a document has an owner, a review date, and a "current" tag in its header, the model has something to distinguish by. This is exactly why companies that want to use AI for more than writing emails start with the data foundation, not with buying licenses. This is covered fully in the guide AI at the company, which starts with metadata and data classification.

The same principle applies at a smaller scale, for individuals and small teams too: a notes archive connected to AI only turns from a pile of text into a searchable knowledge base once it has minimal hygiene — consistent names, dates, topics. The tip on building your own second brain that answers back walks through the how-to; the second-brain principle itself is developed in the chapter Your second brain, preceded by Capturing information.

One warning to close this section: a knowledge base isn't an archive of everything. Companies that let their search index include fifteen-year-old unused files end up with a tool that confidently answers according to rules that no longer apply. Having fewer documents in the system, but valid ones, is worth incomparably more than having everything.

Onboarding as a litmus test

Want to know what state your documentation is in? You don't need an audit. Just look at your most recent new hire.

Onboarding is the one moment when a person with no context moves through the company — and so unerringly finds every gap. When they ask about something during the first month that's already in the documentation, it means it can't be found. When they ask about something that isn't in the documentation, you have a list of what's missing. When they don't ask at all and just do things wrong, that's the worst variant of all: the documentation exists, it's outdated, and they believed it.

A practical approach that costs almost nothing: give the newcomer the job of fixing the documentation. Not once they're settled in — from day one. Whatever they can't find, they track down and add. Whatever's outdated, they fix or flag. It's the one period when a person has a genuinely fresh eye on the company, and at the same time the fastest way for them to learn the material. The company gets a regular review for free, every single time someone new starts.

The second lever is letting a system answer the newcomer's questions instead of colleagues. This is exactly where AI pays off the most today: a Project that answers on your behalf describes how to load company documents into one place, write instructions, and get a newcomer asking it before they ask a living person. The side effect is diagnostic — the moment the AI answers wrong or doesn't know, it points exactly to where the company has a gap in its documentation. The same principle works for temp staff, contractors, and for handing off a role when someone leaves.

Decision records: the most valuable artifact nobody keeps

If a company could take away just one thing from this whole chapter, let it be this: keep decision records, and write down why in every one of them.

Decisions get made constantly in companies and vanish without a trace. The outcome remains — a setting, a supplier, a rule, a pricing structure — but the reason evaporates. A year later, someone new looks at it, says "this makes no sense," and changes it. Sometimes they're right. Often they just don't know about the constraint that led to it in the first place, and the company pays for the same lesson twice. The most expensive question in an organization is "why do we actually do it this way?" — and the most common answer is: "Nobody here remembers anymore."

A good decision record fits on half a page and has five parts.

This format comes from software development, where it's called an architecture decision record, but it works exactly the same for picking a supplier, changing a price list, or setting a work-from-home policy. The key part is the rejected options. It answers the question future colleagues actually have: "Did they even think of this?"

Decision records also have a natural source: meetings. Most decisions get made in a meeting, and most meetings today can produce a transcript. A decision record with action items can be built from a transcript in a minute — and more importantly, it can separate the decision from the discussion. Discussion is material, and it ages. A decision is a product, and it holds until someone changes it. When decisions get stored in one well-known place in a consistent format, over the course of a year you end up with the most valuable document the company has — and nobody had to do any extra work for it.

An employee's departure as a planned process

Knowledge handovers get triggered, at most companies, at the worst possible time to start: after a resignation, during the two-month notice period, when the departing person's head is on their new job and nobody has the capacity. The result is a handover that covers routine operations and misses exactly the exceptions that made the person irreplaceable.

A more sensible approach is to treat departure as a normal event you can prepare for in advance. It's not about distrust, it's about operational resilience — the same approach handles a long illness, parental leave, or a move to a different role.

The most valuable part is the last one, and it's the one most often skipped. Questions like "what would you tell a newcomer so they don't mess it up," "what here only works because you're watching over it," "who has to be talked to even though it's not in the process" pull out exactly the tacit layer no list of areas will ever capture. The conversation can be recorded (with consent) and transcribed — the result is a piece of material more valuable in the archive than an entire folder of policies.

And one last thing: a knowledge system isn't a project with an end. It's upkeep, like a tidy warehouse. A company that builds a wiki once and doesn't open it again for three years is no better off than a company with no wiki — it just has the added false sense of being covered. Regular review, an owner on every document, and a clear rule for where decisions get stored are boring habits. But they're exactly what decides whether, when someone leaves, their work leaves with them, or just they do.

Key takeaways

• Company knowledge is only what remains once people leave. Everything else is personal knowledge you happen to have on hand right now.
• Knowledge has three layers: processes, decisions, and tacit know-how. Companies take care of almost exclusively the first — and yet the second is the most valuable and the third the most fragile.
• Documentation people trust does three things: names a specific owner, states the date of last review, and has one source of truth with no copies.
• Metadata and sensitivity classification aren't bureaucracy. Without them, neither a person nor an AI can find the answer — and a model connected to a mess answers confidently according to invalid documents.
• Onboarding is the best documentation audit you have. Let the newcomer fix what they can't find, and let a system, not colleagues, answer their questions.
• Decision records that explain "why this way" and list the rejected options are the most valuable and most neglected artifact in a company. They come almost for free — straight out of meeting minutes.
• Plan a person's departure in advance: a knowledge-risk map, backup on critical areas, and a closing conversation about the exceptions that were never in the documentation.