Decision Memory: Speed that Doesn't Forget

The room feels different now.

It's not louder. Not more urgent.
Just cleaner.

The plan is on the screen. The numbers behave. Your conversations are staying on the work instead of dissolving into politics. You can tell the team’s proud of the progress because they’re not defending themselves. They’re thinking. They’re moving.

Then someone says the sentence that shows up right when an organization starts to hit momentum.

“Wait. Didn’t we decide this last month?”

Silence.
Not uncomfortable silence. However, it is the sort of silence that echoes throughout the room.

Eyes move to the same few people. The ones who always remember. The ones who always know where the bodies are buried. Someone scrolls through old emails. Someone checks a Teams thread. Someone opens a slide deck that looks familiar but isn’t quite it.

A decision is sitting in the room like a missing tool.

Here’s the uncomfortable truth.

Fast decisions without the memory behind it don’t scale. They boomerang.

Week one we discussed boundaries. Give your people the room to move without asking permission every time. Week two was about escalation. When a threshold is crossed, escalation becomes a mechanical safety rail, not a personal failure.

Week three is what happens after you start to get that speed.

Because the moment the work gets faster, it starts forgetting.

Most organizations talk about decision speed like it’s the win. They optimize for cycle time. They celebrate fewer meetings. They brag about flatter approvals.

But speed is only half the game.

The other half is durability. Can the organization retrieve what it decided, why it decided it, and when that decision should be revisited?

When memory is social, the whole thing gets fragile. It depends on who’s in the room. It depends on who’s been around long enough to know the backstory. It depends on who has the patience to dig through old threads. That’s not governance. That’s survival by tribal knowledge.

And relying on tribal knowledge will always shrink autonomy.

Not because leaders want control. Because leaders stop trusting the work to hold steady without them. They’ve watched the same issue reappear three times, each time treated as new, each time burning time and credibility. So they tighten the reins. They add reviews. They ask for one more sign-off. They default to escalation for “safety.”

Drift doesn’t just show up as bad calls. It shows up as re-deciding.

Reruns will look harmless at first. It's that quick alignment. A short revisit. A “confirm we’re still good” meeting. Then it will start compounding. Re-deciding burns hours, but it also burns trust. It teaches a quiet lesson: decisions are temporary.

Temporary decisions create cautious teams. Cautious teams escalate more. More escalations slow the work. Slower work creates more exceptions. More exceptions demand more governance.

You end up right back where you started, except everyone’s more tired.

This is where a lot of transformation work quietly dies.

Not in strategy.
In the reruns.

Every decision has a half-life.

Conditions shift. Constraints change. Teams rotate. Systems evolve. A decision that was correct in October becomes risky in January. Or it becomes irrelevant. Or it becomes incomplete.

If you don’t acknowledge half-life, you end up with two succinct failure modes.

One, you treat every decision like permanent policy, even after the conditions have changed.

Two, you treat every decision like a temporary preference, so you keep re-deciding the same thing forever.

Decision memory is how you land in the middle. You capture the decision in a way that’s retrievable, and you set an expiration so the organization knows when to revisit it without drama.

Some may think that this is just knowledge management...however itt’s not “let’s store what we know.”

It’s decision engineering. It’s how you prevent the organization from paying for the same lesson again and again.

If you’ve ever watched a team try to solve this with documentation, you already know the trap. It's the meeting minutes nobody is reading. Or a library nobody trusts. Or that portal that requires a training class to navigate.

Then the record becomes performative.

People are only writing things to satisfy a process, not to help the next person move.

Decision memory is different.

It’s a short, durable record created at the moment a decision is made, stored where the work happens, and written so someone who wasn’t in the room can still use it.

That last part is the tell.

If it only makes sense to the people who lived it, you don’t have decision memory. You have a diary.

Let’s make it concrete, because this is where it gets real.

Pick a seam that shows up almost everywhere, whether you’re in operations, IT, data, or product.

“We need to change the committed plan.”

Sometimes it’s a production schedule. Sometimes it’s a release window. Sometimes it’s a forecast, a staffing plan, a customer delivery promise. Different details, but the same seam.

Here’s a threshold version:

If forecast error spikes above 12% for three consecutive days, the team can adjust the plan within a defined tolerance. If the change would impact customer ship dates, overtime, or a critical constraint, it escalates.

Now imagine the escalation happens. Leadership approves the change. Everyone moves.

The tradeoff is real, but often unspoken. Maybe you accept a 2% margin compression to protect ship dates for key customers. Maybe you pull forward premium freight. Maybe you burn overtime for two weeks to keep service levels intact. It’s a choice, with a cost, and it was worth it under those conditions.

Two weeks later, the same conditions show up again.

• Someone says, “We should do what we did last time.”
• Someone else says, “That was different. Leadership told us not to do that again.”
• A third person says, “No, they said do it if the error stays above the threshold.”

And now the organization is running a memory contest.

Not because anyone’s malicious. Because the decision was never captured with its tradeoff and its expiration. So the organization ends up paying for the same lesson twice.

Same pattern shows up in other seams too. In delivery, if escaped defects exceed a threshold, you freeze releases unless an escalation approves. In data, if exception volume or quality failures cross a threshold, you pause downstream refreshes or throttle automations until ownership is clear.

It's a different surface area, but has the same underlying problem.
The work can’t remember what it already learned.

This is the simplest format I’ve found that actually gets used.
One page. Tight enough to repeat. Specific enough to be worth reading.

1. The decision, in one sentence
2. The trigger and threshold
3. The owner, as a role
4. Options considered, briefly
5. The tradeoff accepted
6. The timebox
7. What changed in the work (process, rule, integration, standard work, comms)
8. Expiration date
9. Revisit question

If you’re thinking “this is more work,” that's an honest reaction.

But here’s the truth.

This is less work than that second time you'll re-decide the same thing. And dramatically less work than the third.

The lever that makes this real is simple:
an escalation decision should close with a record.

If you treat the record as optional, it will slip. It will become “we’ll do it later.” Later won’t come, not consistently. So tie it to the ladder.

Every escalation closes with a Decision Memory Record within 24 hours.

No record, no closeout.
No closeout, no “we solved it.”

It sounds strict. It’s also how you stop hero culture from becoming your operating model.

Without that record, escalation becomes pressure relief. It gets you through the day.

With the record though, escalation becomes a learning loop.
It turns a one-time save into a repeatable boundary. It turns “ask Tom” into “check the record.”

Now don’t ruin this by trying to centralize it too early.

A lot of teams build a single repository, a taxonomy, a workflow, and then nobody uses it because it’s not close to where the work actually gets done.

Keep the rule simple.
Store it where someone will actually look.

If it’s an operational threshold decision, store it with the runbook or standard work. If it’s a data exception decision, store it with the workflow that owns the exception, like customer master intake, issue management, or the data product backlog. If it’s a platform decision, store it with the architecture decision log, integration intake, or release governance record. If it’s cross-functional, store it where escalations are tracked, then link out to the local homes.

The goal is about retrieval, not centralization. A thin index can help, but don’t let the index become the product. The product is "remembering under pressure."

If you want this to be more than a good idea, measure it lightly. Three metrics is enough:

• Time to retrieve the last decision for a recurring seam.
• Rerun meetings avoided for the same decision type.
• Repeat escalations reduced because boundaries tightened from records.

If those don’t move, you’re writing records. You’re not building memory.

Here’s a way to test this in your own practice.

Pick one recurring decision that keeps coming back and draining the oxygen. Something that crosses seams. Something that triggers escalations or exceptions.

Run a 30-day Decision Memory Sprint.

Every time that decision is made, capture it within 24 hours. Every escalation closes with a record. Every record includes the tradeoff, an expiration date, and a revisit question.

At day 30, do a short pattern review.

Which decisions repeated? Which tradeoffs repeated? Which thresholds were wrong? Which expirations were ignored? Which records got used?

Then do the move that turns this from a habit into compounding improvement.

Convert the repeated records into updated boundaries.

If you want a head start, I’ve posted a one-page Decision Memory Record template on my site alongside the series. Artifacts for Weeks 1 and 2 are there as well if you want the full arc in one place.

Because the goal here isn’t to write better notes.
It’s to build a decision system that holds.

So here’s the field-test question I’ll leave you with.

What decision keeps coming back in your organization because nobody can retrieve what you already learned?

Sources

Duke, A. (2018). Thinking in bets: Making smarter decisions when you don’t have all the facts. Portfolio.

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution.