Institutional Knowledge: What It Is and How to Keep It
It is what your company knows but never wrote down. The usual fixes depend on someone writing it. The work itself keeps a better record.
What institutional knowledge is
Institutional knowledge is everything an organization knows about how it works: its processes, its customers and suppliers, its history, its unwritten rules, and the reasons behind past decisions. A small part of it sits in procedures and files. Most of it lives in people's heads, in email threads and in habits nobody remembers starting.
It is easier to recognise than to define. Some everyday examples:
- The sales rep who knows that a key customer's buyer only answers on Thursdays, and that their procurement team wants three quotes even for small orders.
- The accounts clerk who knows that one supplier's invoices always arrive with the wrong tax code and need a phone call before payment.
- The plant manager who knows which line needs a slower setting in summer.
- The office manager who remembers that a contract was renewed by email with a different notice period from the one in the signed copy.
- The project lead who knows why an offer was priced below list two years ago, and that the discount was meant to be temporary.
Knowledge researchers split it into explicit knowledge, which is written down, and tacit knowledge, the know-how that is hard to put into words. Institutional knowledge is a mix of both. The tacit part is the one that walks out of the door.
Why it leaves with people
Institutional knowledge is fragile for a few plain reasons:
- It was never anyone's job to write it down. People are paid to do the work, not to describe it.
- It is scattered. Half of it is in the CRM, a quarter in someone's inbox, the rest in a phone call from last spring.
- It depends on context. Knowing the rule isn't enough. You need to know when the rule gets bent, for whom, and why.
- People move. Retirements, resignations, internal transfers, long leave. Every move takes a piece with it.
The cost rarely shows up as one big loss. It shows up as many small ones: a new hire repeats an old mistake, a customer has to explain their situation again, a decision gets made a second time because nobody remembers the first, and the two or three veterans who still know become a bottleneck for everyone else.
The usual ways to capture it
Companies that take the problem seriously usually try some combination of these:
| Method | Good for | Where it falls short |
|---|---|---|
| Documentation and wikis | Stable procedures, policies, templates | Written once, rarely updated; exceptions never make it in |
| Handover documents and exit interviews | A snapshot before someone leaves | Late, rushed and partial: people describe the rule and forget the cases |
| Shadowing and mentoring | Tacit know-how, judgment, relationships | Slow, one person at a time, and gone when the mentor leaves too |
| Recorded walkthroughs and videos | Showing how a task is done | Hard to search, out of date as soon as the tool or the process changes |
| Internal Q&A and communities of practice | Answers to recurring questions | Depends on the same few experts answering, again and again |
All of them help. None of them is wrong. Mentoring in particular does something nothing else does: it passes on judgment.
What they have in common, and where they fail
Look at the table again and one thing stands out. Every method depends on someone stopping their work to write, record or explain it.
That single dependency explains most of the failures:
- They are late. Handover happens in the last two weeks, when the person leaving has the least time and the least motivation.
- They are partial. Asked to describe their job, people describe the official process. The exceptions, which are the valuable part, come back only when a situation reminds them.
- They go stale. A page written in January describes January. By the summer the supplier, the threshold or the contact has changed.
- Nobody owns them. A knowledge project lives as long as the person who championed it.
The knowledge that matters is created by the work, every day, in small decisions. Any method that runs beside the work, asking people to describe it after the fact, will always be behind it.
Letting the work keep the record
So turn it around. Instead of asking people to describe the work, let the work describe itself.
When a recurring process runs on a system that remembers, every run leaves a trace: what came in, what was checked, which exception turned up, who approved it and why. Nobody writes a page. The record builds up as a side effect of doing the job.
That is what a company brain is for. In Knowlee, processes run on the brain. Before a run, the process reads what the company already knows about the customer, supplier or document in front of it. After the run, it writes back what it saw. When a person approves something, the approval and its reason are recorded too.
A simple example from a mid-sized distributor's back office. A process checks supplier quotes against contracts. On its first run it flags a transport surcharge that isn't in the contract. The buyer approves it with a note: agreed by phone with the supplier for this year only. Next quarter the same surcharge appears. The process already knows it was approved, by whom and until when, so it doesn't raise the alarm again. In January, when the agreement has expired, it raises it at the right moment. The buyer never wrote anything down. If the buyer leaves, the knowledge stays.
What changes when the work keeps the record:
- Knowledge is captured when it is created, not at handover time.
- Decisions keep their reasons. The record shows who decided, when and why.
- It stays current, because it is as recent as the last run.
- It is shared. The next person and the next process start from it, instead of from zero.
It doesn't solve everything. Parts of the company where no process runs yet stay as they are, and judgment still has to be passed from person to person. The practical way to start is with the processes where the most knowledge sits in the fewest heads. If you're weighing this against a wiki, our comparison of company brain vs knowledge base goes through the trade-offs, and the glossary explains the knowledge graph that holds the record.
Frequently Asked Questions
What does institutional knowledge mean?
Institutional knowledge is the knowledge an organization holds about how it works: its processes, customers, suppliers, history, unwritten rules and the reasons behind its decisions. Much of it is never written down and lives with the people who do the work.
What is an example of institutional knowledge?
Knowing that a key customer's procurement team always wants three quotes, that a supplier's invoices need a check before payment, or why an offer was priced below list two years ago. None of it is in the official procedure, and all of it matters when someone new takes over.
How do you capture it before someone leaves?
Handover documents, exit interviews and shadowing help, but they come late and miss the exceptions. The more reliable approach is to capture it continuously: run recurring processes on a system that records what each run saw and what people decided, so the knowledge is kept while it is being created.
Is institutional knowledge the same as organizational memory?
They are close. Organizational memory is the broader term from management research for how an organization stores and retrieves what it knows over time. Institutional knowledge is the content of that memory, especially the unwritten part that people carry.