I have sat in three different kinds of meeting this year where someone asked "does anyone remember why we built it this way," and the honest answer, every time, was that the person who remembered had left the company fourteen months earlier.
That is the middle management trap, and it is not a people problem. It is an incentive problem wearing a people costume.
An engineering manager two or three levels down from the CTO is measured, in practice, on one thing: did the roadmap ship. Everything else — the tradeoff you talked the team out of, the vendor call you sat in so an engineer didn't have to, the reason the checkout flow branches the way it does — is invisible on a delivery dashboard. It exists only in your head, and in Slack threads nobody will search six months from now.
You are paid, nominally, for judgement. You are measured, actually, for throughput. And judgement that isn't written down doesn't compound — it evaporates the day you change teams.
What the trap actually costs
The cost shows up late, which is what makes it a trap rather than an obvious mistake. A team ships fast for two years under a manager who is holding a hundred small decisions in working memory. Then that manager gets promoted, or poached, or just moves to a different part of the business, and the team's velocity doesn't drop gradually. It falls off a cliff, because the thing that was making them fast was never in the codebase or the wiki. It was in one person's head, retrieved on demand, and now the demand has nowhere to go.
I've watched this happen to a payments team I worked adjacent to. Excellent manager, genuinely excellent — the kind who could tell you why a particular retry policy existed by pointing at an incident from two years back that never made it into a postmortem doc, because by the time anyone thought to write it up the fire was out and there was a backlog waiting. When she left, three separate engineers independently reintroduced a bug that policy had been built to prevent. Not because they were careless. Because the reason had left the building and nobody had thought to leave a copy behind.
The organisation didn't lose a manager. It lost an undocumented dependency it didn't know it had.
Why writing it down doesn't happen on its own
Nobody sets out to hoard context. It happens because writing things down loses every time it competes with the next sprint commitment for the same hour. Documentation is real work with a payoff that lands on someone else's calendar, possibly a calendar that doesn't exist yet. Shipping the feature is real work with a payoff on Thursday. Under any reasonable set of incentives, Thursday wins.
The managers who avoid the trap aren't more disciplined people. They've just made the decision cheap to record, so it stops competing with delivery on delivery's terms. Three habits do most of the work.
The first is writing decisions down at the moment they're made, not afterwards as documentation. A two-paragraph note in the PR description — here's what we chose, here's the option we didn't take, here's why — costs almost nothing next to writing a design doc from memory a year later, because a year later nobody remembers the option that got rejected. That's usually the part worth keeping.
The second is treating "why" as a first-class citizen of the incident review, not a footnote. Most postmortems are excellent at the timeline and thin on the reasoning that produced the fix. The retry policy that saved my colleague's team should have had a comment linking straight back to the incident that justified it, sitting right there in the code where the next engineer would actually see it, not filed in a doc six clicks from where anyone needed it.
The third is smaller and gets skipped the most: naming a second person on every decision that would hurt if it were forgotten. Not a second approver — a second person who could explain it cold, without you in the room. If you can't think of who that would be, that's the signal the decision is still a single point of failure, and single points of failure don't announce themselves until they fail.
The trap is structural, so the fix has to be too
None of this is a character flaw in the managers who fall into it. It is what happens by default when an organisation rewards output it can see and stays silent about the judgement it can't. If you want managers who write the context down, you have to make that legible in the way you evaluate them — not as an extra virtue you hope for, but as part of what the job actually is.
The alternative is what I keep watching happen: teams that are fast until the person holding the context leaves, and then spend two quarters rediscovering, the expensive way, decisions someone already made once.