How would you run a postmortem program across many teams so one team's outage produces learning and fixes beyond that team?

## The scaling problem At one team, a postmortem is a document that changes that team's system. Across fifty teams, the same practice can produce five hundred documents a year and change nothing structurally, because each team fixes its own instance of a problem that is actually shared. The job of an org-level program is to convert local incidents into three things a single team cannot produce: **cross-incident themes**, **platform-level fixes**, and **transferred learning**. ## Standardize just enough Comparability is the whole reason to standardize. If impact is always quantified, durations always derivable from a timestamped timeline, and action items always typed, then you can ask questions across the corpus: which failure classes are most expensive, where is detection time worst, which services generate the most repeat incidents. If every team invents its own shape, the corpus is a pile of prose. The counter-pressure is real: a heavy mandated template gets filled in ritually. Mandate the small comparable core, let teams add whatever else helps them, and keep the document short enough to be written in a couple of hours. ## One searchable repository One home, indexed, with consistent tags: service, severity, failure class, whether it was a repeat. The high-value query is not "find the postmortem for last Tuesday" — it is "show me every incident in the last year where a config change caused customer impact". That query is what turns a document store into an analysis tool, and it is why per-team wikis and scattered documents fail at this scale. ## Read across, then fund a platform fix This is the part that actually pays. When the same contributing factor appears in six teams' postmortems, each team's local fix is six times the cost and covers a fraction of the surface. The org-level move is to name the theme, pick an owner with a real budget, and build the capability once — staged config rollout, a standard rollback path, a shared saturation-alerting library. The uncomfortable corollary: that platform work has to be funded from somewhere, and the argument for it lives in aggregated incident cost, not in any single postmortem. Which is why quantified impact in the template is non-negotiable — without it the theme analysis produces an interesting observation and no money. ## Distribute selectively Mandating that everyone read every postmortem produces compliance and no learning. What works is curation: a small number of genuinely instructive write-ups circulated widely — a "postmortem of the month"-style newsletter is the pattern Google's SRE book describes — plus reading groups for teams whose systems resemble the one that failed. The selection criterion is transferability, not severity: a mid-sized incident whose mechanism exists in twenty other services teaches more than the biggest outage of the year in a system nobody else runs. Also make the repository the first stop during an incident. "Has anyone seen this before?" answered by a search rather than by asking in chat is where the corpus repays its cost most directly. ## Program metrics A handful, and be careful with each: - **Time from incident to published postmortem**, by severity. - **Action-item completion rate and aging**, aggregated but *never compared between teams as a leaderboard* — the moment a number becomes a ranking, teams manage the number. - **Repeat-incident rate**: the share of incidents whose failure class already appears in the corpus. This is the closest thing to a direct measure of whether the program works. - **Postmortem count per team is not a quality metric.** A team with more incidents may be running riskier systems or simply being more honest about declaring them, and rewarding a low count buys you under-declaration. ## Couple depth to severity A sustainable program has tiers: full document plus review for customer-impacting incidents, a short structured record for minor ones, nothing for routine noise. Over-mandating is the most common way these programs die — engineers write documents to satisfy a process, quality collapses uniformly, and leadership concludes postmortems do not work. ## What it costs Be honest in an interview about the cost side: a program of this kind needs someone whose job includes reading the corpus, curating the newsletter and chasing themes; it needs funded platform capacity to act on what the themes reveal; and it needs leadership willing to not use the data punitively. Without the third, teams under-declare incidents and soften their documents, and every other part of the program degrades from the inside — which is a far more expensive failure than having no program at all.