Learning Organizations

A postmortem for a production incident runs ninety minutes, names a clean root cause — a retry loop with no backoff, missed in review because the runbook nobody had opened in eight months still described the old queueing system — and closes with three action items, one of which reads “update runbook with new backoff behavior.” The meeting adjourns. The incident channel goes quiet. Four months later, a different team, on a different service, ships a retry loop with the same missing backoff, because the runbook still describes the old queueing system, because the action item was assigned to the engineer who wrote the fix, who meant to get to it, and then changed teams before he did.

This is not a story about one distracted engineer. It is closer to the median outcome. The postmortem did its job — it found the cause, it named the fix, it even wrote down the exact document that needed to change. What it could not do on its own is guarantee the update actually happened, because nothing about the process made the update happen. It made the update someone’s job, and someone’s job is exactly the kind of thing that competes with the fifteen other things also on that person’s job this week.

What happens to a finding after the meeting ends

Google’s own internal guidance for postmortems, written by the team with more incentive than almost anyone to get this right, treats the gap as a known failure mode rather than an edge case. Its Site Reliability Engineering workbook states plainly that without a formal tracking process, action items from postmortems are often forgotten, resulting in outages, and that a postmortem without subsequent action is indistinguishable, to the people affected by the next outage, from no postmortem at all. The fix the team settled on is structural, not exhortative: every postmortem tied to a user-affecting outage requires an associated bug in the tracker, monitored the same way any other open bug is monitored — specifically because relying on the postmortem’s author to remember was not sufficient, even inside an organization built around blameless retrospectives and genuine engineering discipline.

To our users, a postmortem without subsequent action is indistinguishable from no postmortem.

Google Site Reliability Engineering — Postmortem Culture

The gap shows up outside Google too, and not only as an anecdote traded between SRE teams. A preliminary study of incident reports and practitioner interviews across multiple organizations — all of which already ran a defined postmortem process with real tool support — reaches a more careful conclusion than a single company’s internal guidance can: despite established processes, the researchers write, “it is not straightforward to take what was learned from a failure and successfully improve the reliability of the socio-technical system.” The study is early and its authors say so themselves; it is evidence of the shape of the problem, not a settled measurement of its size. But the shape matches what postmortem culture has been quietly acknowledging since long before AI-assisted engineering existed: writing a lesson down and a lesson changing what happens next are two different events, connected by nothing more reliable than a person’s follow-through.

Three channels, the same missing wire

The mechanism repeats well beyond incident response, and this volume names it in three different rooms because engineering organizations experience it in three different rooms. An incident postmortem finding a gap the runbook should have caught is one instance. Chapter 6 of this volume takes up the runbook and playbook side directly — codified practice as executable knowledge, current only for as long as something keeps it current. A production failure that does not just need a code fix but needs someone to reopen a choice already sitting in the project’s own decision archive — and ask whether the reasoning that made sense at the time still holds now that the system has demonstrated it does not — is the second instance, and Chapter 3 treats it as the decision graph’s own job: a record of what was decided, why, and what superseded it, precisely so that reopening the question does not require finding the person who happened to be in the room. And a support ticket that looks routine the first time, routine again the fourth time, and only on the fifth or sixth repetition reveals that the underlying bug is a documentation gap nobody has connected to the ticket queue, is the third, quietest instance — Chapter 4’s territory.

All three channels already exist, informally, in almost every engineering organization doing this work today. Someone, somewhere, has updated a runbook after an incident. Someone has gone back and revisited a decision after watching it fail in production. Someone has noticed the fourth identical support ticket and finally opened a documentation pull request. The honest problem this chapter is naming is not that these channels are absent. It is that all three run on the same fuel as the postmortem action item in the opening scene: whoever happened to be paying attention, remembering, and available, that particular week.

Why memory is not a mechanism

Volume VIII’s chapter on Organizational Systems already made the underlying case for why this keeps happening even to careful teams: organizational feedback loops are slow and diffuse enough that human intuition, tuned for fast and local consequences, is a poor instrument for closing them unassisted. That chapter’s fix, applied to a single decision, was Argyris’s double-loop learning — asking what governing assumption allowed the failure, rather than patching only the instance. This chapter is asking a narrower, more mechanical question about the same failure: even once a team has correctly diagnosed the governing assumption, what actually makes the artifact that encodes it — the runbook, the decision record, the documentation page — change? Double-loop learning tells a team what question to ask. It does not, by itself, make anyone go edit the file.

Nonaka’s older observation about tacit and explicit knowledge, introduced in this volume’s first chapter, supplies the missing half. An organization does not convert tacit understanding into an explicit, shareable record once and keep it current forever; the conversion has to happen again and again, because production keeps generating new tacit lessons faster than any one person remembers to feed them back in. Treated as a one-time act of documentation, a runbook or a decision archive is only ever as fresh as its last edit. Treated as a standing conversion process — something that runs every time production teaches the organization something new, not just when someone remembers to run it — it stays current by construction rather than by diligence.

None of this is solved by culture alone, though culture is a precondition, not a substitute. John Allspaw’s 2012 case for blameless postmortems at Etsy, foundational enough that it remains, more than a decade later, one of the most linked-to pieces in the field, argues that engineers who fear reprimand withhold exactly the detail an investigation needs, and that treating human error as a symptom of systemic vulnerability rather than individual failure is what makes people willing to give the honest account in the first place. That argument is correct and still leaves the harder problem untouched.

An organization can run genuinely blameless postmortems, get the honest account every time, and still never build the connection between that honest account and a document nobody has opened since it shipped. The two problems get solved by different mechanisms. An organization can have fully solved the first — psychological safety, honest incident reports, no fear of reprisal — while the second stays exactly as broken as the runbook in the opening scene.

What a structural loop actually requires

DORA’s research on learning culture, distinct from and narrower than the amplifier framing this volume has cited elsewhere, finds that a team’s climate for learning is a significant, independently measured predictor of both software delivery performance and organizational performance — and defines that climate substantially around whether failure is treated as an opportunity to improve process and systems rather than something to be punished or buried. A structural loop is what that climate looks like once it stops being only a norm and becomes a checkpoint nobody can skip: not “did the team discuss updating the runbook,” but “does closing this incident route, automatically, to a check of every artifact the incident touched, whether or not anyone remembers to ask.” The distinction is not a subtle one in practice. An informal loop depends on a specific person’s memory surviving a team change, a deadline, and several intervening priorities. A structural loop depends on none of those things, because the check runs whether or not the person who found the cause is still around to run it.

What the data would need to show

What to build

1. Make the artifact update part of the incident’s definition of done, not a separate action item — the incident does not close until the linked runbook, decision record, or doc page is either updated or explicitly marked not-applicable, by someone, on the record.
2. Link findings to artifacts at the moment they are discovered, not after the fact. A postmortem that names “the runbook was stale” should create a machine-readable link from the incident to that specific document, not a prose sentence a search will eventually surface, maybe.
3. Run a scheduled sweep, not just an event-triggered one. Google’s own aggregate-postmortem tooling exists because some patterns only show up across many incidents, not inside any single one — the same logic applies to documentation gaps surfaced by ticket clusters rather than any one ticket.
4. Assign the structural check to the process, not the person. A rule that fires on every incident close is worth more than a diligent engineer who fires on most of them, because the diligent engineer eventually changes teams.
5. Measure the gap between finding and fix, not just the count of findings. A shrinking median time from “discovered in production” to “reflected in the artifact” is the actual signal that the loop is closing; a growing backlog of open action items is the signal that it has quietly reverted to informal.

None of this requires a new platform or a new discipline invented for the occasion. It requires treating the connection between production and practice as infrastructure with an owner and a failure mode, the same way an on-call rotation or a deploy pipeline gets treated, rather than as a norm everyone agrees is a good idea and nobody is accountable for maintaining. The next chapter in this volume turns from closing the loop back into existing knowledge toward the harder question of transferring what one team learned to a team that has never faced the problem at all: reusable thinking, and what actually makes a pattern worth generalizing.