Institutional memory. Turning what's in your team's heads into a base.
by Luis Gomes, Founder & Growth Lead
The third job from the four-jobs menu is the one that owners pick when somebody is leaving. Or about to leave. Or has been at the company too long to be irreplaceable, and the owner has finally noticed.
Institutional memory is the install that turns what lives in people's heads into something the rest of the team can query. Not a wiki nobody updates. Not a Notion page that gets stale by month two. A queryable system that reads the company's own documents and answers the questions a junior person on the team would otherwise be asking the senior person.
This is the box that compounds the most over time. It is also the slowest to feel. The first install pays back in months, not weeks. Owners who pick this box are usually playing a longer game than the others — they have already lived through losing someone and seeing knowledge leave with them.
What institutional memory is, in practice
Three categories of knowledge. Each one is a separate sub-install, and most teams pick one at a time.
The first category is brand and product knowledge. The voice rules the senior marketer has been holding for five years. The product decisions that explain why the product works the way it does. The reasons certain features exist and others were rejected. The customer-segment patterns the senior account manager has internalized. This is the knowledge a new hire takes six months to absorb informally and a senior person takes to lunch every week to teach.
The second category is process and pricing. The pricing logic the founder explains to every new salesperson. The reason the discount thresholds are set where they are. The escalation paths. The internal SLAs that are not written down anywhere but everyone knows. The supplier relationships and what each one is good at.
The third category is customer-specific. Why this account uses the product in an unusual way. The history of past escalations. The personalities on the buying committee. The internal advocates. The reasons the contract is structured the way it is.
In all three, the install is similar in shape. We sit with the senior person who holds the knowledge, capture it in writing, structure it, and connect it to a queryable layer the team can ask questions of.
Why "we already have a wiki" is not the same thing
Most teams that have knowledge problems do not lack a wiki. They have a wiki nobody updates, or a Notion the senior person abandoned in 2024, or a Google Drive with five generations of conflicting versions. The knowledge is technically written down. It is unfindable, unverified, and untrusted.
The install we run is not a better wiki. It is three things the wiki is not.
It is queryable in plain language. The junior person types "what do we do when a customer asks for net-90 terms" and gets a useful answer in a sentence — not a link to a page they then have to read.
It is versioned and dated. Every answer the agent gives names the source it came from and the last time the source was updated. Old documents do not silently override new ones. Stale knowledge is visible.
It has a feedback loop back to the senior person. When the agent does not know an answer, or guesses, the question goes to a queue the senior person reviews. They answer once. The answer becomes part of the base. The next time someone asks, the agent answers — and the senior person was interrupted exactly once.
That third part is the operating discipline that makes the install actually compound. Without it, the base degrades. With it, the base improves every time it gets asked something it did not know.
What 30 days looks like
This is the install that is hardest to fit into 30 days, so we shape it as a focused first sub-install rather than a full institutional capture.
Week 1 is choosing the slice. With the owner, we pick the one body of knowledge that is most at risk and most useful. Most often: brand voice plus the named accounts the senior person carries. Sometimes: pricing logic plus the discount rationale. Rarely on the first install: the full product knowledge, because that one is too big for 30 days.
Week 2 is capture. We sit with the senior person and run interviews — not workshops. The output of an interview is a structured document the agent can read. We do not ask the senior person to write the document; we write it from the interview, then they edit. The shape that works: question → answer → source if available. Hundreds of these, organized by topic.
Week 3 is install. The captured documents go into a queryable layer the team can use. The team starts asking it questions. We watch what the agent gets right, what it gets wrong, and what it does not know. The answers it does not know go to the senior person's queue. Their answers fold back into the base by end of week 3.
Week 4 is measurement. We track: queries per day, questions the senior person used to get interrupted with that the team is now asking the system, accuracy on a sampled audit, the number of "I don't know" answers shrinking over time. Numbers are the numbers.
Where it goes wrong
The first failure mode is the senior person not having time for the capture. The interviews are unskippable, and they take real hours. We have learned to scope around this — pick the smallest meaningful slice, schedule the capture in the senior person's calendar before week 1 starts, do not begin without their commitment. If the time is not there, the install fails before it begins.
The second failure mode is treating the system as a wiki replacement. Teams that lift their old wiki into the agent and stop there get a queryable wiki, which is mildly better than a wiki, and not what they were paying for. The install only works when the senior person's hand-coded knowledge is in the base, not just the documents that already existed.
The third failure mode is no feedback loop. Without the queue that captures unknown questions and routes them to the senior person, the base ossifies. Within a quarter the agent is answering 2024's questions while the company is asking 2026's.
What you get back when it works
Three things that are visible immediately. New hires ramp in weeks instead of months. The senior person stops being interrupted with the same five questions a week. When someone leaves, the knowledge does not leave with them.
One thing that is visible only over time, and matters more. The team's collective intelligence becomes legible. You can read what your company knows. Other people on the team can read it too. The thing that used to live in two people's heads becomes a thing the company has, instead of a thing two people have.
That is the closest thing to a moat a small services company can build. It compounds with use. It survives turnover. It is the asset that gets more valuable every quarter you keep operating.
What we install
We pick the slice with the owner. We run the interviews with the senior person. We capture, structure, and connect. We watch the system run for two weeks. We hand it off, with the feedback loop set up so it keeps improving without us.
Bounded install. 30 days for one slice. If it paid back, the next install is the next slice — and most teams find the second one is half the work because the capture method is now familiar.