Why organizations keep forgetting
Why do companies get "update amnesia"? We keep every record and lose the one thing that mattered: what we believed at the time. Read: "Everything starts looking like a toy" #308
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: traveling “by map” through a fictional journey. This site tracks geographic locations of fictional stories using Open Street Maps and shows you the result. It wouldn’t be hard to turn this into an Indiana Jones-style montage …
Edition 308 of this newsletter is here - it’s August 3, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Why organizations keep forgetting
Does this sound familiar? Someone in a meeting asks a question that the company already answered. Maybe it’s something simple like “why did we pick that vendor?” or “when did we stop offering that feature?” or “what were the other vendors we considered and didn’t pick?” And the room is quiet because nobody remembers. The decision was made, but the reasoning that produced that decision (the decision log or business brief) didn’t get written down.
This happens frequently in a world where we move really quickly. These days it’s often faster to create a feature and get feedback than it is to build a fully featured product requirements document, especially when the feature is reversible and can sit behind a feature flag.
The cost of moving that fast can be invisible. It manifests itself when we reopen decisions we already made and rediscover conclusions we reached a year ago. Companies that are improving their velocity of shipping should also be improving their fidelity of decision making. More often the company gets busier.
The good news is that we didn’t really lose the records or the decisions. They are there for the understanding, if we commit to a new pattern of writing down the decisions as they happen to store the most important context: what we knew at the time when we knew it.
The missing thing isn’t the record. It’s the reasoning behind it.
Persisting decisions for the future
Organizations don’t forget information. They forget what they believed.
When the question gets asked in the meeting and no one remembers, we think our memory is faulty. The real cause is that there are so many information streams at any one time that expecting our brains to recall the important bits is pretty risky. We need to remember what we do when we forget: find the last important thing we wrote down.
But it’s more than just writing down what we want to remember. We need to record what we expected to be true at that moment, and why.
Think of the org as a series of decisions where all the records exist on the technical side (thanks Github!) and every decision is made and then filed away never to be seen again. Except the filing system changes with almost every commit (or at least every quarter). This means that when we want to know what happened, we also need the context from that moment when the code was written or the decision made.
Let’s call this pattern update amnesia, and once you have the phrase you start seeing it everywhere.
The reasons are benign, but the results can be real. In January the team commits to an improvement (move activation +20 points by 4 months from now). This is a real number and a real commit, and we might even hit our goal. But at the end of the process, “activation” has changed. The original process is not the same as what we’re doing, so doubling down on a new goal is harder because it’s like making a brand new decision.
Here’s another example. A team is considering a “build vs buy” decision, goes through a process where it genuinely makes sense to select a vendor and go through a procurement process. A year later a new hire might look at the same system and reopens the problem from scratch because they found the what, not the why for the decision. There might be a really good reason for revisiting the problem (perhaps LLM improvement changed what was possible), but it’s really hard to compare then vs now.
Why can’t we remember the lesson?
Notice the common pattern here: in every case, the record of the change is available and the accumulated organizational learning is missing. The update told you the number moved, or the decision was made, or the thing shipped. It didn’t preserve the belief that the number was supposed to test, so there’s nothing to compare against later. A dashboard can tell you the number moved. It cannot tell you whether you were right. And “were we right” is the only question whose answer compounds.
This is why the amnesia pattern we’re describing is so hard to notice from the inside. History rhymes instead of repeating, so the moment you’re re-deciding never looks exactly like the last one. The vendor is different, the metric has a new name, the new hire has a fresh framing. It doesn’t feel like forgetting. It feels like fresh thinking. That’s the cruelest part — the amnesia disguises itself as insight.
A company in the grip of update amnesia doesn’t look sluggish. It ships, reviews, syncs, and re-aligns, and it argues the same three questions it argued last year, each time as if for the first time. All that activity generates records at a furious rate. None of it generates memory, because activity is not the same as belief, and only belief is worth remembering.
Here’s what we keep:
what happened — the ship, the launch, the number
what was decided — the choice, minus the reasons
what was done — the meetings held, the tickets closed
And we lose, almost completely:
what we expected to happen, and why
what would have counted as being wrong
what we actually learned when reality disagreed
The first list is receipts. The second list is the experiment. We are great at storing the “what” and not so good with the “why” and then we’re surprised the organization can’t seem to learn.
We’re keeping the answers and throwing away the questions, and an answer with no question attached is just trivia.
Failing to learn is learning to fail
If the update is the atomic unit through which an organization learns, then update amnesia isn’t a filing failure: it’s a learning failure. When we record events and miss the “why”, the drop is invisible because the event is right there looking complete. We don’t notice this because we anchor on an outcome that we can measure, which lets us know that we’ve finished or reached the goal. We end up missing the improvement that future us is going to need to go beyond a simple goal.
The organizational memory problem is not that we fail to write stuff down. It’s about writing down the part that decays — the expectation, the reasoning, the bet — in the one artifact we produce often enough for it to matter. The update is where the forgetting happens, which means the update is also the only place the forgetting can be fixed.
We’ve been calling this a discipline problem, then a definition problem, and now a memory problem, and they keep turning out to be the same problem wearing different clothes. Each time it points back to the update itself, and to a shape we haven’t described yet — one that would still hold the belief long after the moment that produced it had passed.
What would an update that resists amnesia actually look like?
What’s the takeaway? Organizations don’t lose their records — they lose the beliefs those records were testing, one receipt-shaped update at a time. Fix the forgetting where it happens: write down the expectation and the reasoning, not just the outcome.
Links for Reading and Sharing
These are links that caught my 👀
1/ Notes for me and my agent - A pattern I’ve been noticing is the need to capture persistent threads between a human author and an agent. You can use VS Code or Cursor for this pretty easily — it’s a file explorer + chat. But what if you made it more elegant? Hubble.md is chasing this vision to have real time conversations in markdown and html between humans and agents.
2/ The orchestrator’s tax - Rahul Garg writes a guest post on Martin Fowler’s blog about the problem posed when the Agent harness takes more time to answer a question than a much simpler method. When are we adding too much complexity to get a simple job done, and when does the agent harness add value?
3/ The aesthetics of AI - Linkedin recently launched a feature to help you label generative content as “Seems like AI slop” and it made me wonder what are the visual tells of AI that won’t seem that obvious 3, 6, or 12 months from now? Jim Nielsen writes about the design choices of AI and what iconography, colors, and fonts are becoming more popular.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.