Back to blog
Handoffs

What Is Institutional Knowledge? Mostly It Is This Week's Answers

5 min read
institutional knowledgetribal knowledgetacit knowledgeknowledge losspreserve institutional knowledge

The short version

  • Institutional knowledge is what a company knows that is not written in its systems. In small firms, most of it is in the answers people give each week.
  • It has three parts: reasoning behind past choices, relationship history, and the current state of things.
  • The documentation instinct catches the first part and misses the other two, which is why thorough companies still lose a great deal when someone leaves.
  • You can find yours in a week by logging what people ask each other. No workshop required.

The definition

Institutional knowledge is the accumulated understanding a company holds about how it works, why it works that way, and what has already been tried. Tribal knowledge is the same thing said less formally. Tacit knowledge is the academic term for the part that is hard to put into words at all.

The common thread is that none of it is in the systems. Your CRM holds the deals, your repository holds the code, your finance tool holds the numbers. What is missing is why any of it is the way it is, and what is happening with it right now.

In a company of two hundred, a good deal of this is written somewhere. In a company of twenty, almost none of it is, and it moves around as conversation.

Its three parts

Part What it is Cost of losing it
Reasoning Why a choice was made and what was rejected Repeating work that was already done and abandoned
Relationships What was promised, what went wrong once, who to approach how Damaged customer and supplier relationships
Current state Where everything actually stands this week Work stopping, and every question routing to one person

Documentation efforts nearly always target the first row, because it is the one that feels like knowledge. The second and third rows are where the day to day cost sits, and they are much harder to write in advance.

Plain examples

A services firm. A client's finance director will not accept an invoice without a purchase order number in a specific field, because of an incident in 2023. One person knows. Every invoice that person does not touch gets bounced, and nobody understands why.

A product company. The second largest customer is on a legacy pricing plan that was never migrated, and there is an understanding that it will not change without a conversation first. Written down nowhere. The person who gave that undertaking has left.

An agency. One client's brand lead approves everything on a Thursday and nothing on a Monday, because Mondays are their internal review day. Knowing this is the difference between a two day turnaround and a one week one.

None of these are complicated. None of them are in any system. All of them are expensive to rediscover, and all of them are the kind of thing someone would never think to include in a handover document.

Finding yours in a week

Skip the knowledge audit. For five working days, log every question someone asks a colleague that they could not answer from a system. Three fields: what was asked, who was asked, and whether anyone else could have answered.

That log is your institutional knowledge, made visible, in the vocabulary people actually use. It is also ranked by frequency, which tells you what to write down first.

Nearly every team is surprised by the same two things: how much of it is current state rather than reasoning, and how concentrated the answering is on two or three people. See how to find key person dependency.

Keeping it without a documentation programme

Each part needs a different mechanism, and only one of them is documentation.

Reasoning goes in a short decision entry at the moment of the decision, including what was rejected. Ten minutes, next to the work. See the decision log template.

Relationships go in the account record, in specific sentences rather than general impressions. "Will not accept invoices without a PO in field three, since the 2023 dispute" is useful. "Detail oriented client" is not.

Current state cannot be documented in advance, because it changes weekly and nobody will maintain it. This is what StandIn is built for. Each day a person spends about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work itself. When they are unavailable, their StandIn answers from that brief, in their words, with a source under every answer. It never guesses, and when the answer is not in the record it says so and names who to ask. A company that has been doing this for a year has an institutional memory of its current state, which is the part that otherwise walks out of the door. See how teams use it and capturing tribal knowledge without a documentation project.

Common Questions

Is institutional knowledge the same as tribal knowledge?

In practice yes. Tribal knowledge tends to describe the informal, unwritten version held by a group. Institutional knowledge is the same material spoken of as a company asset. Neither is in your systems.

Can we put a value on it?

Not credibly in the abstract, and quite easily in the specific. Take the last departure and count the weeks of rediscovery, rework and repaired relationships. That number is concrete and it is usually larger than the recruitment cost people do measure.

Does long tenure protect us?

It concentrates the risk rather than reducing it. A company with an average tenure of six years has deep institutional knowledge held by very few people, which is comfortable right up until one of them retires.

Where should we start?

With the week long question log. Every other approach starts with a guess about what matters, and the log replaces the guess with evidence in five days.

90 seconds, then it's on.

Engineers publish a brief before they log off. The next timezone starts with full context, not a reconstruction of what happened while they slept.

You might also like