The file survived. The explanation didn't.
A few months ago I needed to understand why one of our services was using Redis.
The engineer who made that decision had already left the company.
Finding the implementation wasn't difficult.
I found the Jira ticket.
Implement Redis cache.
I found the pull request.
The code was there.
I found the architecture document.
It mentioned caching.
I even found the Slack discussion where someone asked:
Why not Memcached?
The reply was one sentence.
Redis should be fine.
That was all.
The implementation survived.
The explanation didn't.
Nothing was missing
At first that felt strange.
Every artifact still existed.
Nothing had been deleted.
Git history was intact.
Slack history was searchable.
The documentation hadn't disappeared.
And yet the organization had clearly forgotten something.
Not what had been built.
Why it had been built that way.
We preserve artifacts better than reasoning
Most engineering organizations are very good at keeping records.
We keep tickets.
We keep code.
We keep documents.
We keep backups.
What we rarely preserve is the reasoning that connected them.
The ticket tells you what changed.
The pull request shows how it changed.
The architecture document describes what the system looks like.
None of them necessarily explains why one option was chosen over another.
That explanation often existed only during a conversation.
Context has a half-life
I've started thinking of context as something that slowly decays.
When a decision is made, everyone involved shares the same mental model.
The constraints are obvious.
The trade-offs are fresh.
Rejected alternatives are still remembered.
Six months later the code remains exactly the same.
The shared understanding doesn't.
A year later someone asks:
Why didn't we use Memcached?
Nobody knows anymore.
Not because the answer was lost.
Because it was never stored anywhere in a form that could survive the people who understood it.
This is how organizational memory disappears
It rarely happens all at once.
Nobody deletes a document.
Nobody wipes a database.
Instead, every small decision loses a little of its surrounding context.
A meeting ends.
A Slack thread sinks into history.
Someone changes teams.
Someone leaves.
Months later all the pieces still exist.
The explanation doesn't.
I stopped asking a different question
I used to ask:
Did we document this?
Now I ask:
Could someone explain this decision after everyone involved has left?
Those aren't the same question.
Documentation preserves artifacts.
Organizational memory preserves reasoning.
One can exist without the other.
Forgetting is usually invisible
Organizations don't usually notice they're forgetting.
Everything still looks healthy.
Repositories are there.
Documentation is there.
Search still works.
The problem only appears when someone asks a simple question:
Why?
And nobody can answer with confidence.
I've become less convinced that organizations lose knowledge because they delete information.
More often, they lose the relationships, assumptions, and reasoning that gave that information meaning.
The files survive.
The memory quietly fades.
Next time I'd like to explore something that surprised me while building retrieval systems: why the LLM often turned out to be the least interesting part of the pipeline.
Top comments (3)
The concept of "context having a half-life" really resonates with me, as I've seen it play out in my own experience with inherited codebases and technical debt. The idea that our ability to understand the reasoning behind a decision decays over time, even if the artifacts themselves remain, highlights the importance of capturing not just what was done, but why it was done. I've found that adding a "decision record" or a brief explanation of the trade-offs and alternatives considered can help preserve this context, but it's interesting to consider how this could be systematically integrated into our development workflows. Do you think there are any specific tools or practices that could help mitigate this loss of organizational memory?
This is why I like decision records that include the rejected options, not just the chosen one. The useful bit six months later is usually the boundary: what would have made Memcached win, or what changed that would make Redis wrong now? Without that, the artifact becomes a map with the roads erased.
The "why Memcached vs Redis" example lands because the explanation never had a home in the first place — it existed in the shared mental model of the people in the room, not in any artifact those people produced. Decision logs that capture the rejected alternatives are the document type that almost never gets written, because the decision is the thing that feels worth recording, and the reasons it beat the alternatives feel obvious in the moment and transient by next quarter. The decay rate is also not uniform: tactical decisions made under time pressure lose context faster than architectural ones, because architectural decisions get revisited and re-explained, while tactical ones just silently become load-bearing. Knowledge graph approaches to organizational memory try to make the reasoning structure an explicit artifact rather than a property of the people who hold it, but the hard part is capture at decision time, not retrieval later.