On reading other people's postmortems

The engineering profession produces one genre of writing that is reliably honest: the public postmortem. Marketing does not review it, the deadline has passed, and the author has nothing left to sell. The great ones, and every senior engineer keeps a private anthology, read like structural surveys of buildings that fell.

Read them for structure, not for the fault. The fault is always locally reasonable: a certificate, a config, a query plan. The structure is the interesting part: how long the failure ran before anyone believed it was real, which dashboard lied, who had authority to stop the bleeding and whether they knew it, what the system did while its operators argued about what it was doing. Those patterns transfer across companies and decades. The certificate does not matter; the fact that renewal was owned by a calendar reminder in a departed engineer's mailbox matters everywhere, forever.

A reading discipline, briefly. Read the timeline twice: once forward, feeling the confusion, once backward from the fix, noticing when the decisive information first appeared. It is nearly always visible early, disbelieved, and rediscovered an hour later with ceremony. Then ask the only question that makes the exercise pay: which of our systems would produce this same document, and what would our equivalent of the lying dashboard be?

I have sat through tabletop exercises that cost a week and taught less than forty minutes with another company's worst day. Their tuition, your education. It is the best trade in the industry, and it is free.