The organisational memory leak: why lessons disappear between teams

There is a sentence I have learned to dread in a debrief. Someone leans back, exhales, and says, "we already knew this."

They are not wrong. The organisation did already know. It knew in the incident report nobody reopened after the next planning cycle started. It knew in the architecture decision record that quietly stopped being linked from anywhere useful. It knew in the deploy guide that warned, in tactful language, that the deployment process depended on luck. It knew in the support tags. It knew in the flaky test people learned to rerun without thinking. It knew in the on-call channel where the same two names kept appearing at 02:00.

Then the failure happened, and the organisation behaved as if the lesson had arrived for the first time.

I have watched this play out across more teams than I would care to count, in shapes that look superficially different but rhyme underneath. It is not ignorance. It is not even simple negligence. It is organisational memory failure: the break between what a company has already discovered and what it is capable of using when a decision is being made under pressure, on a Wednesday, by someone who was not there last time.

NASA's 2026 Starliner investigation is the kind of public artefact that gets passed around in engineering Slacks for a week and then forgotten in two. The agency described combined hardware failures, qualification gaps, leadership missteps, and cultural breakdowns, and classified the crewed flight test as a Type A mishap even though the crew survived and the spacecraft returned without injury.¹ More than two decades earlier, the Columbia Accident Investigation Board had treated the loss of Columbia not merely as a foam-strike problem, but as an accident shaped by NASA's history, budgets, programme culture, compromises, and changing priorities.² Different vehicle. Different decade. Familiar shape.

Software teams produce versions of this every week, less spectacular and almost never investigated by a national board. The failure arrives as a repeat outage, a rewrite everyone predicted, a security exposure hidden in a dependency graph, or the resignation of the one person who could still explain why the billing system works the way it does.

This is not another warning about speed, burnout, documentation, post-mortems, or technical debt. Those are symptoms, and I have written about most of them at one point or another. The deeper mechanism is the channel between them. Organisations keep producing knowledge, then losing the path from that knowledge to anything that resembles action.

Memory is a system, not a document

The first mistake I see, almost everywhere, is treating memory as storage.

A document is not organisational memory. A ticket is not organisational memory. A Confluence space, a Slack history, an incident database, an architecture diagram, and a folder full of post-mortems are not organisational memory. They are possible memory stores. They become memory only when the organisation can retrieve them at the moment they matter, and let them change a decision that has already half-formed in someone's head.

Walsh and Ungson's classic organisational memory model separates memory into acquisition, retention, and retrieval.³ That distinction matters because software organisations often leave more traces than they can use. Every deployment produces logs. Every incident produces a timeline. Every pull request leaves comments. Every migration leaves scars in the code. Every lost customer leaves some record, even if it is buried in a CRM note that engineering has no access to.

Retention is harder. Retrieval is where the failure becomes visible, and where I have learned to listen most carefully.

The knowledge exists, but it is not available in the workflow where decisions happen. A team planning a migration does not see the incident history attached to the subsystem. A manager allocating headcount does not see the bus-factor risk hiding inside code review patterns. An executive asking for an aggressive deadline does not see the defect history that makes the date fictional. A new engineer reads the runbook, but the runbook describes the happy path while the real system lives in the exceptions that only two people know — and one of them has just put in notice.

That is why the useful metaphor is not the library. It is the channel.

Memory has to move from event to interpretation, from interpretation to artefact, from artefact to retrieval, from retrieval to decision, and from decision to funded change. Every handoff can leak. The organisation can fail to capture the lesson. It can capture it but store it somewhere nobody searches. It can store it correctly but make retrieval socially unsafe. It can retrieve it and treat it as optional context. It can accept it and refuse to fund the change it implies. Most organisations leak at more than one point, which is impressive efficiency in the wrong direction.

de Holan and Phillips argue that forgetting is not one thing; organisations can lose established knowledge through decay, fail to capture new knowledge before it becomes embedded, or forget intentionally as well as accidentally.⁴ Some forgetting is healthy. Teams need to unlearn bad habits, obsolete procedures, and assumptions that no longer match the system. But when an organisation forgets the conditions that made its last failure possible, it is not adapting. It is resetting the trap.

The uncomfortable part is that forgetting can look like maturity from the inside. A leader says the team has moved on. A product manager says the incident is behind us. An engineer says the old system is too messy to understand. A director says there is no value in relitigating the past. Sometimes that is true. More often it is a polite way of severing the memory channel before it reaches budget, staffing, or roadmap.

The archive remains. The organisation forgets anyway.

Where memory leaks in software teams

Software has a peculiar memory problem because knowledge lives in too many places at once.

Part of it lives in source code. Part of it lives in tests. Part of it lives in deployment scripts, dashboards, alerts, incident timelines, product decisions, legal constraints, old customer promises, and the mental maps of people who have spent years inside the system. Some of the most valuable knowledge is tacit and stubbornly so: why a component is shaped strangely, which customer workflow breaks if a schema changes, which alert is noisy but dangerous, which apparently obsolete branch still matters at quarter-end.

Management literature has been studying versions of this outside software for decades. Darr, Argote, and Epple found learning, transfer, and depreciation in service organisations, and later empirical work by David and Brachet found that both labour turnover and skill decay can drive organisational forgetting.^{5 6} Argote and Ingram's work on knowledge transfer is especially relevant because they frame knowledge as embedded in relationships between people, tasks, and tools rather than in people alone.⁷ That is exactly how codebases work. The engineer is not the knowledge store by themselves. The knowledge is the fit between the engineer, the system, the task history, the tests, the operational context, and the toolchain.

Break enough of those links and the organisation forgets while the repository stays intact, which is the version of forgetting that engineering management is least prepared to notice.

Documentation decay is the visible version. A 2023 empirical study of open source projects found that, in its top-1000 GitHub dataset, 19.2% of documents had at least one outdated code-element reference, and 28.9% of projects had at least one outdated document.⁸ That finding does not mean documentation is useless. It means documentation is alive only while it remains coupled to the system it describes. Once it drifts, it becomes memory-shaped debris — the kind you trip over while looking for something that still works.

Turnover is the human version. Microsoft Research's study of one large professional software organisation begins from a simple fact: large-scale software is built by teams whose composition changes continuously, and employee turnover can be costly to team morale and productivity.⁹ The study is not every company, but the mechanism is recognisable. The risk is not merely that a person leaves. The risk is that nobody knows which memory left with them until a decision needs it, by which point the person is two jobs further on and not returning anyone's LinkedIn message.

Code ownership is the code version. Research on Microsoft products connected code ownership to knowledge and responsibility, and a 2015 replication study found that ownership metrics correlated with quality in four major Microsoft products.¹⁰ The finding deserves a careful read. Strong ownership is not a defence of territorial code fiefdoms, and collective ownership is not inherently reckless. The narrower, more useful lesson is this: when responsibility and knowledge become too diffuse, nobody is clearly positioned to notice decay, defend quality, or explain trade-offs.

The bus factor is the risk-management version. The 2022 ICSE SEIP paper on bus factor surveyed 269 engineers and found the bus factor was perceived as an important problem in collective development, while also noting that version-control data alone misses other channels of knowledge generation and distribution such as reviews and meetings.¹¹ Its validation context was bounded, so I would not wave the number around as a universal yardstick. The broader warning still holds. Many organisations measure memory risk by asking who last edited a file. That is a start. It misses the person who reviewed every risky change, debugged every production incident, or quietly knew which customers depended on undocumented behaviour and would notice immediately if it stopped.

So software organisations leak memory in ways dashboards rarely show. A module may have tests and no owner. A runbook may be current and undiscoverable. An incident action item may be "closed" in Jira and entirely live in production. A senior engineer may still be employed but no longer invited to the planning meetings where their memory would matter. A team may have plenty of documentation and no habit of checking it before making the same decision again.

The memory leak is not absence. It is disconnection.

When retrieval becomes political

Most companies imagine retrieval as search. Can people find the document? Can they query the incident database? Can the new engineer locate the right onboarding page?

Those questions matter, but they are too small. The harder question — the one I now ask first in any organisational diagnosis — is whether the organisation can retrieve uncomfortable knowledge when it threatens a decision someone powerful already wants to make.

This is where psychological safety is often misunderstood. Edmondson's original work linked psychological safety with learning behaviour in teams, but the construct was never meant to replace ownership or performance expectations.¹² Later research complicates the folk version further by showing that psychological safety interacts with felt accountability over time rather than acting as a standalone guarantee of performance.¹³

That nuance matters because organisational memory is not retrieved by a search engine alone. It is retrieved by people willing and able to say: we have seen this failure mode before, this deadline conflicts with known constraints, this architecture duplicates a previous mistake, this vendor has unresolved risk, this test gap is not theoretical, this incident action item was closed without changing the system.

If those people are ignored often enough, they stop acting as memory channels. This is one of the quietest, most expensive failures I see, and almost nobody charts it.

Conscientious people — the ones who actually pay attention — quietly become the informal storage layer for everything the formal system fails to retain. They remember which migrations went badly. They remember which estimates were fantasy. They remember which product promise made the data model awkward. They remember who needs to be consulted before a release. They remember the difference between the dashboard that looks healthy and the customer workflow that still fails in practice.

Then the organisation teaches them that remembering is socially expensive.

It does this in small ways, usually with good intentions. The engineer who raises a risk is labelled negative. The manager who asks for remediation time is told to be pragmatic. The staff engineer who insists on writing down architectural rationale is treated as slowing delivery, which is how organisations describe people who are correct in advance. The incident reviewer who asks whether the action item actually removed the failure mode is told the team has already moved on. After enough of those conversations, the memory channel becomes less reliable not because the people forgot, but because the organisation has made retrieval costly enough that they have learned to keep their mouths shut.

That is why repeated failure often feels mysterious from the executive layer and completely unsurprising from the floor. The warnings existed. They just never survived the climb.

Public investigations keep finding versions of this pattern, and the rhymes are uncomfortably close. The Boeing 737 MAX investigations and reviews do not reduce cleanly to one mistake or one person. Official records describe flawed assumptions, production pressure, oversight weaknesses, and communication breakdowns around MCAS and certification.¹⁴ The Post Office Horizon scandal can be read through the same memory-channel lens. The High Court found Horizon had bugs, errors, and defects with the potential to cause discrepancies, while the public inquiry's first final-report volume concluded that senior and other employees knew, or should have known, that Legacy Horizon could error.^{15 16}

The cheap version of both stories says somebody should have known. The harder, more honest interpretation is that many parts of the organisation did know something, but the knowledge did not travel with enough force to change conduct.

That is a memory-channel failure. Software teams produce smaller versions of it every quarter, with less press attention and the same underlying mechanics.

Architecture becomes archaeology

Every ageing codebase I have worked on eventually becomes an archaeological site.

There are layers of old incentives in it. The hurried launch. The compliance requirement nobody remembers by name. The customer contract signed before the product had multi-tenant support. The acquisition that brought in another authentication system. The performance fix that became the default path. The migration abandoned at 80% because the team was reassigned to something more strategic. The feature flag that should have been removed after a week and is now load-bearing in three regions.

None of these decisions was necessarily irrational when made. That is what makes the archaeology so difficult. The code is often full of local decisions that were reasonable under the constraints of their moment. The failure comes later, when the constraints vanish and the decision remains, stripped of context, looking like negligence to engineers who were not there.

Architecture is where memory loss becomes expensive. Without rationale, every future team has to infer intent from shape. A strange abstraction might be a brilliant compression of domain complexity. It might also be a scar from an old workaround somebody wrote in a hurry on a Friday afternoon. A missing constraint might be deliberate flexibility. It might also be an omission nobody noticed. A service boundary might reflect a real organisational boundary. It might also reflect a reorganisation from three VPs ago that the org chart has long since walked away from.

When memory fails, engineers become archaeologists under deadline. They dig through commit history, ticket comments, old incident notes, and half-remembered Slack threads. They ask around until they find someone who was there. Sometimes that person remembers. Sometimes they left. Sometimes they remember the decision but not the reason. Sometimes the reason was never written down because the team intended to refactor it later, and "later" turned out to be a synonym for "never".

Research on transactive memory helps explain why this is so damaging. A transactive memory system is not simply shared knowledge; it is a team's shared understanding of who knows what, whose knowledge is credible, and how the group coordinates around that specialisation.¹⁷ Ren and Argote's review shows how these systems are dynamic and vulnerable to changes in membership, tasks, and context.¹⁸ Software teams rely on transactive memory constantly. They know who understands billing, who understands deploys, who understands the edge cases in identity, who remembers the migration, who can explain the scary Terraform module that nobody else wants to touch.

When those maps decay, the team does not merely lose facts. It loses routing. People stop knowing who to ask, which is worse than not knowing the answer, because at least the answerable question used to have a person attached to it.

This is why architecture diagrams, decision records, and runbooks are necessary but insufficient. They document some of the terrain. They do not guarantee that the next team will know when to consult them, whether to trust them, or how to escalate when the documented design conflicts with the production reality the on-call engineer is staring at.

The architecture autopsy usually starts years after the memory leak began. By the time people say the system needs a complete rewrite, the original problem is rarely code alone. The organisation has lost the capacity to distinguish intentional structure from fossilised accident. The rewrite proposal does not solve memory loss. It just buys five years before the next set of archaeologists arrive.

Post-mortems are not memory

Learning from failure sounds simple until it has to compete with the roadmap.

Cannon and Edmondson argue that organisations often endorse learning from failure in principle while struggling to build the practices that identify failures, analyse them, and experiment with changes.¹⁹ Madsen and Desai's study of the global orbital launch vehicle industry found that organisations can learn from failure, and that failure-derived knowledge can depreciate more slowly than success-derived knowledge, but their findings also point to conditions, prior experience, and failure magnitude as part of the learning process.²⁰ Failure is not magic. Pain does not automatically become wisdom. If it did, software would have been a solved problem some time around 2008.

This is where many software organisations confuse recordkeeping with learning. A post-mortem records an event. A learning system changes the future. They feel similar in the meeting and look identical in the wiki, which is part of the trap.

The distinction is practical. If an incident teaches that a service lacks safe deploy controls, the memory of that incident must appear in deployment policy, platform capability, ownership, and capacity planning. If a security review teaches that dependency ownership is unclear, the memory must appear in dependency update rules, package approval paths, and the team charter. If an architecture review teaches that one team owns a critical component nobody understands, the memory must appear in hiring, pairing, documentation, and roadmap sequencing.

The post-mortem is not the memory. It is one acquisition event. Treating it as the whole job is roughly equivalent to writing "I should drink water" in a journal and considering yourself hydrated.

A memory-preserving delivery system has a few plain properties. It names the owner of the lesson, not only the owner of the ticket. It defines what changed in the system, not only what was discussed in the meeting. It sets closure criteria that cannot be satisfied by writing a document nobody will use. It attaches recurring checks to the workflow where regression would happen. It records decision rationale in a place the next decision-maker is likely to encounter, not three subdirectories deep in a Confluence space last touched in 2022. It treats remediation capacity as delivery work, not as the thing engineers do in the gaps between "real" work.

This is also where documentation has to be rescued from its own reputation. DORA's documentation-quality guidance reports a clear link between documentation quality and organisational performance, and treats documentation as technical work that supports other capabilities rather than a side chore.²¹ That is the right frame. Documentation is not memory by itself, but without reliable artefacts the organisation becomes dependent on the continued employment and goodwill of two senior engineers who have quietly started replying to recruiter messages on the weekend.

The practical test is brutal in its simplicity: can the lesson still act after the meeting ends?

If the answer is no, the organisation has not learned from the incident. It has filed it.

What to measure so memory survives speed and AI

The measurement problem is uncomfortable because memory is easiest to notice when it has already failed, which is also the worst possible time to start measuring.

Executives see throughput. They see sprint completion, deployment frequency, feature count, cycle time, support volume, cloud spend, and incident duration. Some of these measures are useful. None of them proves the organisation is retaining the right lessons. Several of them actively reward forgetting, because a team that fixes the same incident quickly every quarter looks impressively responsive on a dashboard.

Memory health needs different signals.

Start with repeat-failure rate. Not incident count. Not mean time to recovery on its own. The sharper question is how often the same class of failure returns after it has been analysed. A team that resolves incidents quickly but never removes the failure mode is not learning. It is becoming efficient at reliving the same bad day.

Track action-item survival. How many incident or review actions remain open after thirty, sixty, and ninety days? How many are closed by changing a system rather than by changing the wording in the ticket? How many are reopened because the fix did not address the failure mode? How many are explicitly funded in the next planning cycle, as opposed to vaguely hoped for?

Track ownership concentration. Which services have only one credible reviewer? Which components have diffuse ownership with no responsible maintainer? Which critical paths depend on someone outside the team who is no longer in the planning loop? Bus factor is a crude tool, but the crudeness is useful if it starts the right conversation. The mature version layers in code, reviews, incidents, documentation, and customer context.

Track decision-retrieval quality. When a team changes an old subsystem, can it find the last major decision about that subsystem? Can it tell whether the reason still applies? Can it identify which incidents, customer constraints, and regulatory requirements shaped the current design? If not, every change begins with guesswork wearing the costume of engineering judgement.

Track documentation freshness where it matters. The 2023 documentation-decay study is useful because it gives teams permission to stop arguing abstractly about whether docs rot and start asking which documents are coupled to code elements, operational procedures, or safety-critical decisions.⁸ A stale onboarding lunch page is harmless. A stale recovery procedure is how Sunday becomes a national holiday for the on-call engineer.

AI makes these questions more urgent, not less. DORA's 2025 report frames AI as an amplifier of an organisation's existing strengths and weaknesses, with the highest returns coming from the underlying organisational system rather than the tools alone.²² That is the memory-channel point in a different costume. If a team already has strong ownership, good review habits, reliable docs, and clear follow-through, AI can accelerate work inside a system that remembers. If the team has weak ownership, shallow review, stale rationale, and no protected remediation capacity, AI will obligingly produce more artefacts for a memory system that already could not keep up.

The problem is not that AI writes code. The practical risk is what happens when code volume increases faster than comprehension, review capacity, ownership clarity, and operational memory. The deficit was already there. AI just compounds it on a tighter cycle.

The same was true before AI, just slower. Velocity targets, sprint overcommitment, premature service decomposition, heroic incident response, and documentation theatre all create the same failure shape: the organisation optimises visible motion while starving the memory channels that make motion safe.

The capstone lesson is therefore not sentimental. It is operational.

Memory must have owners. Memory must have retrieval paths. Memory must have budget. Memory must be allowed to contradict the roadmap. Memory must survive turnover. Memory must be embedded where work happens, not admired in the archive after the damage is done.

An organisation that cannot trace how yesterday's lesson changed today's architecture, backlog, ownership, and budget is not learning. It is archiving.

And the final test is blunt, and I have asked it in real rooms more times than I can count: can the system still do the right thing after the people who remember leave?

If not, you have a memory leak. Patch it before it patches you.

---

Footnotes

1. NASA. (2026). 'NASA Releases Report on Starliner Crewed Flight Test Investigation.' NASA. https://www.nasa.gov/news-release/nasa-releases-report-on-starliner-crewed-flight-test-investigation/ ↩

2. Columbia Accident Investigation Board. (2003). 'Columbia Accident Investigation Board Report, Volume I.' NASA Technical Reports Server. https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20030066167.pdf ↩

3. Walsh, J. P., & Ungson, G. R. (1991). 'Organizational Memory.' Academy of Management Review. https://doi.org/10.5465/AMR.1991.4278992 ↩

4. de Holan, P. M., & Phillips, N. (2004). 'Remembrance of Things Past? The Dynamics of Organizational Forgetting.' Management Science. https://doi.org/10.1287/mnsc.1040.0273 ↩

5. Darr, E. D., Argote, L., & Epple, D. (1995). 'The Acquisition, Transfer, and Depreciation of Knowledge in Service Organizations: Productivity in Franchises.' Management Science. https://doi.org/10.1287/mnsc.41.11.1750 ↩

6. David, G., & Brachet, T. (2011). 'On the Determinants of Organizational Forgetting.' American Economic Journal: Microeconomics. https://doi.org/10.1257/mic.3.3.100 ↩

7. Argote, L., & Ingram, P. (2000). 'Knowledge Transfer: A Basis for Competitive Advantage in Firms.' Organizational Behavior and Human Decision Processes. https://doi.org/10.1006/obhd.2000.2893 ↩

8. Tan, W. S., Wagner, M., & Treude, C. (2023). 'Detecting Outdated Code Element References in Software Repository Documentation.' Empirical Software Engineering. https://doi.org/10.1007/s10664-023-10397-6 ↩ ↩²

9. Hilton, M., & Begel, A. (2018). 'A Study of the Organizational Dynamics of Software Teams.' ICSE-SEIP 2018. https://doi.org/10.1145/3183519.3183527 ↩

10. Greiler, M., Herzig, K., & Czerwonka, J. (2015). 'Code Ownership and Software Quality: A Replication Study.' MSR 2015. https://doi.org/10.1109/MSR.2015.8 ↩

11. Jabrayilzade, E., Evtikhiev, M., Tuzun, E., & Kovalenko, V. (2022). 'Bus Factor in Practice.' ICSE-SEIP 2022. https://doi.org/10.1145/3510457.3513082 ↩

12. Edmondson, A. (1999). 'Psychological Safety and Learning Behavior in Work Teams.' Administrative Science Quarterly. https://doi.org/10.2307/2666999 ↩

13. Higgins, M. C., Dobrow, S. R., Weiner, J. M., & Liu, H. (2022). 'When Is Psychological Safety Helpful? A Longitudinal Study.' Academy of Management Discoveries. https://doi.org/10.5465/amd.2018.0242 ↩

14. House Committee on Transportation and Infrastructure. (2020). 'Final Committee Report: The Design, Development & Certification of the Boeing 737 MAX.' U.S. Government Publishing Office. https://www.govinfo.gov/content/pkg/GOVPUB-Y4_T68_2-PURL-gpo144993/pdf/GOVPUB-Y4_T68_2-PURL-gpo144993.pdf; Joint Authorities Technical Review. (2019). 'Boeing 737 MAX Flight Control System.' Federal Aviation Administration. https://www.faa.gov/sites/faa.gov/files/2021-08/Final_JATR_Submittal_to_FAA_Oct_2019.pdf ↩

15. Justice Fraser. (2019). 'Bates and Others v Post Office Limited: Judgment (No. 6) Horizon Issues.' Courts and Tribunals Judiciary. https://www.judiciary.uk/wp-content/uploads/2022/07/bates-v-post-office-judgment-1.pdf ↩

16. Post Office Horizon IT Inquiry. (2025). 'Post Office Horizon IT Inquiry Final Report, Volume 1.' Post Office Horizon IT Inquiry. https://www.postofficehorizoninquiry.org.uk/sites/default/files/2025-07/Post%20Office%20Horizon%20IT%20Inquiry%20Final%20Report%20Volume%201%20-%20Accessible%20Version.pdf ↩

17. Lewis, K. (2003). 'Measuring Transactive Memory Systems in the Field: Scale Development and Validation.' Journal of Applied Psychology. https://doi.org/10.1037/0021-9010.88.4.587 ↩

18. Ren, Y., & Argote, L. (2011). 'Transactive Memory Systems 1985-2010: An Integrative Framework of Key Dimensions, Antecedents, and Consequences.' Academy of Management Annals. https://doi.org/10.5465/19416520.2011.590300 ↩

19. Cannon, M. D., & Edmondson, A. C. (2005). 'Failing to Learn and Learning to Fail (Intelligently): How Great Organizations Put Failure to Work to Innovate and Improve.' Long Range Planning. https://doi.org/10.1016/j.lrp.2005.04.005 ↩

20. Madsen, P. M., & Desai, V. (2010). 'Failing to Learn? The Effects of Failure and Success on Organizational Learning in the Global Orbital Launch Vehicle Industry.' Academy of Management Journal. https://doi.org/10.5465/AMJ.2010.51467631 ↩

21. DORA. (2026). 'Documentation Quality.' DORA. https://dora.dev/capabilities/documentation-quality/ ↩

22. DeBellis, D., Storer, K., Harvey, N., Beane, M., Edwards, R., Fraser, E., Good, B., Kalliamvakou, E., Kim, G., Maxwell, E., D'Angelo, S., Inman, S., Murillo, A., & Villalba, D. (2025). 'DORA 2025 State of AI-assisted Software Development Report.' DORA, Google. https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/ ↩