It's Time We Throw Out the Usage of 'Postmortem'

To put it bluntly, did someone die?

In engineering, let’s hope your answer is a resounding no. So why do we continue to use the word ‘postmortem’?

I’ve dealt with incidents with every company I’ve had the pleasure of working for. At each of them we called the work the proceeds an unexpected downtime a postmortem. Odds are, if you’re reading this, you know what they are. One hour of staring at a document (usually a Google doc or Confluence page) on a monitor in a conference room where one person talks about what happened. You fill out a few fields only to never read that document ever again. If you’re a mature incident organization, everyone speaks, but the concept is the same. Then you have a folder or repository somewhere called “postmortems.”

But again, there’s just one problem with the name of these reports… no one died.

What is a postmortem, anyway?

Postmortem - noun Medicine/Medical. a postmortem examination; autopsy. (Source)

As an industry, we seem to have settled on this term to describe the work that happens after an incident. We’re dissecting and examining our logs, metrics, Slack chat, only to come out with our postmortem report. Or, in medical terms, “The time and cause of death.” We do these reports to better understand what contributed to the incident in the first place. But words are important, and using a word that is common in CSI: Miami may not be the best one for learning from an unplanned downtime. (As much as we’d all love to be this badly badass).

So, how do we rebrand the postmortem?

I believe that it’s critical that we do away with this term in order to change the perception of incidents. Incidents at many organizations are considered the worst thing possible, however we all know “incidents are unplanned investments” (~250 words until I quoted John Allspaw, not bad).

In any other job, conducting a postmortem means someone perished, so we need to switch to another phrase to lessen the gruesomeness of software incidents. I wanted to provide some ideas that your organization could possibly run with as a replacement to “Postmortem”:

1. Incident Retrospective

2. Incident Research

3. Incident Review

4. Hindsight

5. Downy Oopsie

6. Lessons Learned (This is what calls it)

7. Downtime Review

8. Site Séance

Beyond the last one, these could all be dropped in as a replacement to our calendar events, folders, and nomenclature your business uses on a daily basis.

Postmortems Retrospectives at FireHydrant

At FireHydrant, we’re changing our usage of postmortem to incident retrospective.

We’re already starting to remove the terminology “postmortem” from our app, our website, and in conversations. And while we’re excited to make this change, we know it won’t be quick - unfortunately there’s just no magic switch to flip when it comes to shifting culturally. Even within our own solutions we offer a ‘Postmortem’ feature which was aptly named because that’s just what we called them. It was just where we, as software engineers, came from, and what the software industry largely calls it. But after speaking with tons of companies, meeting people at conferences, and reading more and more about incidents, it has become clear this term needs to change.

The fortunate reality is incidents don’t have a time of death, and that we’re only trying to understand what happened. If something or someone dies, they don’t come back. But incidents, as we all know, will inevitably arise again and again.