Teams change. People move on, priorities shift, and the person who understood why a system was built a certain way is often gone before that reasoning gets written down anywhere. What's left is the code — correct, running, and mute about its own history.
Why this cost is hard to see
Losing organizational knowledge rarely shows up as an incident. It shows up as a slow tax: the same investigation happening twice because nobody remembered it had already been done, a constraint being "rediscovered" the hard way, a fix being applied to a symptom because the root cause was documented only in someone's memory. None of this triggers an alert. It just makes everything slightly slower, indefinitely.
Code versus context
Knowing how a system works is table stakes. Knowing why it was built that way — what was tried and discarded, what constraint shaped the current design, what tradeoff was made under a deadline — is a different kind of knowledge, and it's the one that actually compounds. I wrote about this directly as one of six principles in how I think about systems: knowing how something works is useful, knowing why it works that way is leverage.
This is also the subject of the Code → Context case in my impact notes, and it's closely related to a piece I wrote elsewhere on why the person who knows how the company works has more leverage than the person who knows the most.
“Knowing how something works is useful, knowing why it works that way is leverage.”
What I try to do about it
Practically, this means treating the history behind a system as part of the system — worth asking about, worth retaining, worth passing on deliberately rather than assuming it'll survive on its own. It's a small habit, but over enough time it's the difference between a team that re-investigates the same problem and one that recognizes it on sight.
Read the related case
Code to Context is one of four patterns in what changed because I worked on it.
What Changed Because I Worked On It · How I Think About Systems