Home / Company brain / Preserving institutional knowledge
Concept

Preserving institutional knowledge when people leave

In a company of twenty, a resignation does not remove a headcount. It removes a function, and most of what that function held was never written anywhere.

The loss is not visible on the last day. Nothing breaks in the first fortnight, because the handover covered the things everyone could think of: the file locations, the passwords, the calendar of standing calls. It breaks in the third month, when a partner asks why the endpoint was changed and the room goes quiet, or when an invoice arrives against a cost split nobody in the building can explain, or when the successor discovers that four of the eleven diligence questions everyone believed were closed were never answered at all.

That delay is what makes this problem so easy to underestimate. By the time the cost shows up, it does not look like a departure. It looks like a bad quarter, and it gets attributed to the market, the partner, or the new person.

What actually leaves with a person

Almost never the documents. The documents are on the drive, and they were the easy part. Four other things go out with them, and each has a different failure signature.

Every item there is context wrapped around an artifact rather than the artifact itself, which is why an exit checklist built around artifacts comes back full and still leaves you exposed.

Why documentation drives fail

The standard response is a writing push: give the person their last fortnight to document everything they know. It fails for four reasons that compound. It is written by somebody who has already left in every sense but the legal one. It is written to a template that does not match the questions anybody will later ask, so it answers process and omits history. It has no reader for six months, so no one catches what is missing while the author is still reachable. And it captures a moving thing as a still image, which means that when it finally is read, part of it is out of date and nothing marks which part.

There is a fifth reason, and it is the one nobody says out loud. People document what they found difficult or impressive, not what is load-bearing. The agreement that quietly extends itself unless somebody gives notice ninety days out does not make the document, because to the person who has watched it for two years it is not interesting. It is just something they happen to remember every quarter.

A test worth running on the last departure, not the next one. Name three questions your company has had to send to someone after their final day. Most companies can name them instantly, and they are always the same species: why did we do it that way, what did we agree, and where did that actually land. Those three questions are the specification for what preservation has to hold.

Preserving institutional memory when the record was already current

Everything changes if the record was not written for the departure. If it was being kept from the correspondence and the meetings as they happened, then the reasons already sit next to the decisions, the commitments already carry dates, and every open thread already carries the last thing the other side said. The exit stops being an act of extraction and becomes a read. The mechanics of keeping a record that way, day by day, are covered in institutional knowledge capture, and the wider case for a record that holds state rather than files is AI institutional memory.

One thing this does not preserve, and the honest version of this page has to say so: it does not preserve the relationship. The alliance lead at the partner trusted a specific person, took their call, and told them things they would not put in an email. No file transfers that, and a successor who walks in believing the record makes them equivalent will find out in the second month. What the record does buy is that the successor is only rebuilding the relationship, rather than rebuilding the relationship while also reconstructing the facts from a shared drive.

What this looks like when a deal lead leaves mid process

Take the version that hurts most in a small drug developer: the one person who runs partnering resigns in the middle of an out licensing process. What leaves is not the data room. It is which of the diligence questions are genuinely answered and which were deferred with a promise. It is the comparable deals behind the number that was quoted, which existed as a judgment rather than a spreadsheet. It is what was conceded to get the second redline of the term sheet, and why the slower second interested party is deliberately being kept warm rather than being ignored. And it is the plain fact that the counterparty has not written for eleven days, which means something specific to whoever has been reading them for six months.

The program side has the same shape with different nouns: a program lead leaves during IND enabling work, and what goes with them is which risks on the log were quietly retired without a mitigation, and what was traded away in the change order that consumed the contingency. In both cases the preservation that matters is not a document, it is a set of live items carrying dates and reasons. If the person is already on notice, the checklist for the two weeks you have is offboarding knowledge transfer, the concept level version is institutional knowledge transfer, and the definition underneath all three is what an AI company brain is.

WILL THE ROOM GO QUIET IN MONTH THREE?

A working record that keeps the why beside the what

Real software runs on one person's correspondence, filing the reason next to each decision, holding what Tuesday's call promised on each side with a date on it, and keeping the last thing every counterparty said. Watch the demo to see what a successor would walk into.

See the demo