Your business runs on memory. Here’s what that costs.
Most of what a business knows lives in people's heads. Three costs of running on memory, and a four-step way to move it into the work.
Meera: The linen order for Friday. Should I place it with the usual supplier?
Arjun: Which usual? We stopped using Patel Textiles for linen last year.
Meera: Their name's still first on the sheet. Why did we stop?
Arjun: Late shipments, I think. Ravi made that call. Ask him.
Meera: Ravi's on leave until the 20th.
Arjun: Then try Sunita. She was running QC back then.
Sunita (two hours later): It was both. Monsoon delays, and their linen shrank after the first wash. We moved linen to Kumar. Patel's still fine for cotton.
Meera: And none of that is written down anywhere?
Sunita: It's written in my head.
What a business remembers, it has to ask for. What it records, it can look up.
Ask a plain question inside most companies: what did we charge this client last time, and why? The answer exists. It sits in one person's head, an email thread from March, and a spreadsheet tab called final_v3. Getting it means finding the person who remembers, waiting for them, and trusting their recollection.
What a business remembers
Written policy covers the rule. Memory covers everything around it: why the rule exists, who can bend it, and the cases where it doesn't apply. It comes in four kinds.
| Kind | Example | Who usually holds it |
|---|---|---|
| Decisions | Why this client gets 60-day payment terms when everyone else gets 30 | The founder or account lead |
| Procedures | The real order of steps, including the workaround at step 4 | Whoever does the task most often |
| Status | Where a request, order or invoice is right now | Whoever touched it last |
| Exceptions | Which supplier slips in monsoon, which fabric shrinks after the first wash | The person who has been there longest |
The rows get more expensive as you go down. Status is annoying to lose. Exceptions are where the money is, because they are learned from mistakes, and losing one means paying for the mistake again.
Cost 1: Every question routes to a person
When the answer lives in a head, the question waits for that person's day. Each wait is small. Together they are large, and they fall hardest on the people the business can least spare: whoever has been there longest.
From memory, a question takes four hand-offs and ends in an answer nobody can check. From a record, it takes one.
The status meeting is the same cost, put on a calendar. A status meeting is a database query run by people at 10am: everyone attends to read out something a record could show.
A worked example
The numbers below are illustrative. Run your own with the question log in Step 1 before trusting ours.
| Input | Value |
|---|---|
| Team size | 12 people |
| Questions per person per day that only someone else can answer | 4 |
| Asker's time per question: finding, waiting, re-explaining | 10 min |
| Answerer's time per question: the interruption and getting back | 5 min |
| Daily status meeting | 15 min, everyone |
Questions: 12 × 4 × 15 min = 12 hours a day. The meeting: 12 × 15 min = 3 hours a day. Over 21 working days that is 315 hours a month, roughly two full-time people spent asking, waiting and reporting.
Key insights
- The cost is paid twice: once in the asker's waiting, once in the holder's interruptions.
- It concentrates on the most experienced people, who become routers instead of doing their own work.
- It stays invisible because no single wait looks expensive. Only the total does.
Cost 2: Memory leaves
People resign, go on leave, change roles, or simply forget. Each time, part of what the business knows goes with them, and nobody notices until the next time it's needed.
Forgetting is the quieter loss. A decision made eight months ago is remembered as a conclusion without its reasons: "we don't use that supplier", not "we stopped after two late shipments during monsoon". Without the reason, the next person either repeats the old mistake or reverses a good decision because it looked arbitrary.
Handovers don't fix this. A handover note is written in someone's last week, by a person already halfway out, and it covers what they thought to write down. The rules make it in. The exceptions almost never do, because nobody remembers an exception until the case that needs it.
Signs it's already happening
- "Ask Priya" appears in your onboarding, or would if you wrote one.
- A process stops when one person is on leave.
- A new hire's first month is mostly finding out who knows what.
- The same mistake has been made twice, by two different people, a year apart.
Key insights
- The cost isn't the departure. It's the rediscovery that follows, and the mistakes made during it.
- Reasons decay faster than conclusions. A decision kept without its why is only half kept.
- Count the processes only one person can run. That number is your exposure, and it's usually higher than anyone guesses.
Cost 3: Memory can't be checked
A record can be wrong, but it can be found wrong. A memory can't. When two people remember a thing differently, there is nothing to settle it except who argues longer.
The client says the extra screen was agreed. The project lead remembers it as discussed. With no record of the decision, a ten-second lookup becomes a negotiation, and the business usually loses it, because conceding is cheaper than the argument.
Estimates suffer the same way. "It took about a week last time" is a memory, and memory keeps outcomes while dropping delays: the week is remembered, the three days waiting on a client's login details are not. Estimates built from recollection run short in a consistent direction, which is why the same overrun keeps coming back.
What it looks like in practice
| Situation | Answered from memory | Answered from a record |
|---|---|---|
| Was this change agreed? | Two versions, then a negotiation | The decision, its date, and who made it |
| How long will this take? | Last time's outcome, without the delays | Last time's actual stage times |
| Why is this client's price different? | "There was a reason" | The reason, and when to revisit it |
| Did the batch pass QC? | "I think so" | The checklist, ticked, with the failures noted |
Key insights
- An answer that can't show its source can't be trusted or corrected. That holds for a person exactly as it does for a language model.
- Disputes are cheapest before they start: a decision recorded at the moment it's made is never argued about later.
- Predictable delivery depends on records of how long work actually took, not on how long people remember it taking.
Moving memory into the work
The obvious fix is "document everything", and it fails for a structural reason. Documentation is a second job, done after the real one, by people who already know the answer. It's written late, read rarely, and stale within a quarter.
The fix that holds is to make the record a by-product of doing the work. A decision is logged where it's made. A checklist lives inside the task it governs. Status is whatever the tool shows, because the work happens in the tool. Nobody writes anything they weren't already doing.
Blueprint
- Step 1: Find the memory (log the questions for two weeks)
- Step 2: Price it (hours waited, single holders)
- Step 3: Move it into the work
- Decisions → a one-line decision record, where it's made
- Procedures → a checklist inside the task
- Status → the tool, so the meeting covers exceptions
- Exceptions → a field on the record, not a note
- Step 4: Check it (re-run the log after a month)
Step 1: Find the memory
You can't see memory directly. You can see the questions it causes.
For two weeks, everyone logs each question they had to ask a person because the answer wasn't anywhere they could look. One line each: the question, who answered, and roughly how long it took to get the answer. The template is in Resources below.
One rule decides what moves: anything asked twice gets recorded. Questions asked once are noise. Questions asked every week are memory the business depends on.
Step 2: Price it
Total the minutes waited from the log and turn them into hours a month. Then count the processes only one person can run. The first number is what memory costs you now. The second is what it could cost the week that person is away.
Rank the repeated questions by hours lost. Work from the top, and stop when the remaining ones cost less than recording them would.
Step 3: Move it into the work
Each kind of memory has its own home. Put it there, not in a wiki.
Decisions go in a one-line record at the moment they're made, attached to the thing they're about: the client, the project, the supplier.
DECISION 60-day payment terms for this client
WHY They pay on a fixed monthly cycle; 30-day terms made every invoice late
WHO Account lead · 12 Oct 2026
REVISIT At contract renewal
The WHY line is the one that matters. It's the part memory loses first.
Procedures become a checklist inside the task, not a document beside it. When someone finds a step is wrong, they fix the checklist in the same place they found the problem.
Status lives in the tool the work happens in. Once it does, a daily status meeting shrinks to the exceptions: three items, ten minutes.
Exceptions become fields on the record, not free-text notes. "Slips in monsoon" as a note is something one person reads. As a field, it can be filtered and counted: which suppliers slipped twice this year is a query, not a memory.
Step 4: Check it
After a month, run the question log again for two weeks and compare. Repeated questions should be down, and minutes waited with them. If they aren't, the records exist but aren't where the work happens, so nobody looks at them. Move them closer, don't add more.
Where memory is the right answer
Recording has costs too, and some knowledge belongs in people's heads. Four places to hold back.
- Judgment and relationships. "This client prefers calls to email" fits in a field. How to read a tense client on that call doesn't, and pretending otherwise produces a long document nobody follows.
- The first few months. A three-person team changing its process every week will spend more keeping records current than it saves. Wait until a question is asked twice; that's the signal something has settled.
- Every field is a small tax. Each one costs the person doing the work a few seconds, every time. Add a field only when it answers a question someone actually asked, and remove fields nobody reads.
- Stale records are worse than none. A missing record sends you to a person. A wrong one answers confidently and sends you the wrong way. Every record needs an owner and a date, and a record nobody owns should be deleted, not kept.
The trade we accept: some extra friction at the moment of work, in exchange for not paying for the same knowledge twice. Where the friction costs more than the question it answers, we leave it in someone's head.
Resources
Copy-paste these to run the four steps.
Memory audit: eight questions
A "no" to any of the first five, or a "yes" to any of the last three, is memory worth pricing.
- Can a new hire find the last price charged to a client, and the reason, without asking anyone?
- Do recorded decisions say why, not just what?
- Are exceptions stored as fields you can count, not notes you have to read?
- Do estimates come from recorded stage times rather than recollection?
- Does every record have an owner and a date?
- Is there a process only one person can run?
- Does a daily meeting exist mainly to report status?
- Is the handover note written in someone's last week?
Step 1: Question log
| Date | Question | Who answered | Minutes to get the answer | Asked before? (Y/N) |
|---|---|---|---|---|
Step 2: Memory price
| Measure | Formula | Your number |
|---|---|---|
| Hours lost per month | Total minutes in the log ÷ 60 × (working days per month ÷ days logged) | |
| Repeated questions | Rows marked "Asked before" | |
| Single-holder processes | Processes only one person can run | |
| Monthly cost | Hours lost × loaded hourly rate |
Step 3: Decision record
DECISION
WHY
WHO
REVISIT
Step 4: Before and after
| Measure | Before | After one month |
|---|---|---|
| Repeated questions per week | ||
| Minutes waited per week | ||
| Single-holder processes | ||
| Status meeting length (min) |
In brief
| Cost | Why it happens | The move |
|---|---|---|
| 1. Every question routes to a person | The answer is in a head, so the question waits for that person | Status and procedures go into the tool the work happens in |
| 2. Memory leaves | People leave and forget, and reasons decay before conclusions | Decisions recorded with their why, at the moment they're made |
| 3. Memory can't be checked | Two recollections have nothing to settle them | Exceptions and stage times as fields you can query |
None of this asks anyone to write documentation. It asks that the work leave a record as it happens, and that only questions asked twice earn one.
Once a business keeps those records, the next problem is reading them back: answering questions across thousands of them, with sources. That's what Designing a Data Query Engine covers.
What a business remembers, it has to ask for. What it records, it can look up.