Postmortems have a branding problem: the name implies something died. We write them after quiet, uneventful launches too, because those are exactly the ones where the reason for success is easiest to misattribute.
The question a good launch does not answer on its own
Nothing broke. Was that because the process worked, or because nothing happened to go wrong this time? Those are different situations that feel identical from inside a launch that went smoothly, and only one of them predicts the next launch will go the same way.
What we ask in a success retrospective
- What did we specifically do that we think prevented a problem, named concretely — a load test that changed a design, a rollback plan that turned out not to be needed but was ready.
- What did we get away with, honestly — a step skipped under time pressure that happened not to matter this time, a dependency we didn't check that happened to hold up.
- What would have caught the near-misses, if any surfaced during the retrospective conversation that nobody flagged as an incident at the time.
Why the second question is the valuable one
Teams are reasonably good at celebrating what worked and reasonably bad at admitting what they skipped and got away with, because admitting it after a success feels like undermining a win rather than learning from one. We ask it anyway, specifically because the gap between "worked" and "got away with it" is where the next failure is quietly waiting.
A launch with no incidents is evidence the process worked only if you can say specifically what the process did. Otherwise it is just evidence nothing went wrong yet.
What this surfaced on a recent project
A launch we considered clean turned out, in the retrospective, to have skipped the rollback rehearsal because the team was confident and short on time — confidence that was justified this time, on a rollback path that had in fact never been exercised. We ran it the following week, found a real gap in it, and fixed the gap before it was ever needed under pressure.
The habit this builds
Treating success as worth investigating, not just failure, keeps a team honest about the difference between a good process and a good outcome, which are correlated but not the same thing, and only one of them survives contact with a launch that goes differently.