↓Skip to main content

The benefits of postmortems

·1 min
Management Software Engineering
Cover image

Postmortems are a well established process followed in the aftermath of an incident. Often the most visible output from the process is a structured document, with some or all of the following components:

  • Overview of what happened
  • The impact
  • What triggered the incident
  • When/how did we detect the issue
  • How we fixed it
  • Timeline
  • Root cause analysis
  • Learnings
  • Actions
  • Internal email
  • External message

That’s all well and good, but in my opinion not the primary reason we do postmortems.

The real benefits of a postmortem process are the discussions we have following the incident, and the follow up investigations and investment work. The process forces a group of people to look critically at the incident, identify what should have been better, and make decisions on how we can improve the system to prevent future incidents. We then follow that up with clear and well-defined actions that are prioritised at the very top of our backlog.

A postmortem process is great to have. It gives you the time and space to have these discussions. And the document does help to capture and share knowledge and is certainly worth doing. But it’s important to remember what the primary objective is, and it isn’t to write a document.

Cover image from Unsplash.

↑