liveBook · Manning

Postmortem

As explained in Think Like a CTO

A postmortem is a structured review conducted after an event to examine what happened, what went well, and what should improve.

A postmortem is a review held after an event to recognize what went well and learn what went wrong or could improve. It can follow a release or an operational failure. section 9.7.1 section 7.2.2

Judge decisions in context: what seems obvious after an incident may not have been clear beforehand. When a failure points to neglected planning, examine the responsible person’s actions and whether leadership decisions or missing authorization contributed. Document the event and consult the person responsible; repeated issues may call for better training or, as a last resort, a role change. section 7.2.2

Incidents worth examining include:

  • A security breach linked to an uninstalled or outdated firewall. section 7.2.2
  • Data loss after backups were not properly tested. section 7.2.2
  • Service loss after a payment-problem email was missed, or hardware failure without an upgrade or continuity plan. section 7.2.2

How Think Like a CTO covers it

How deep it goes
Distinguishes planning failures from hindsight, checks leadership authorization, and recommends documenting events and addressing recurring issues.
Examples
Uses release completion, security breaches, data loss, payment-related service loss, and hardware failure as review cases.
What you can do after
Apply it by documenting an event, consulting the responsible person, and considering training or role changes when problems recur.
How it connects
Connects outage releases with planning, security, backup testing, continuity planning, and role accountability.

Also explained in

Compare how 3 books explain postmortem →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a CTO. The section links point to the parts of the book it draws on.