Postmortems

This week at work I made more mistakes than I usually do. One of those mistakes affected messaging to customers, and when mistakes affect customers, everyone who interacts with customers directly needs to be in the loop with equal access to information about the issue.

My reaction timeline looked something like this:

2:39 PM

Recognized somethin' wasn't right

2:43 PM

Alerted customer-facing colleagues of the known issue and the estimated impact via Slack

2:48 PM

Started troubleshooting

2:55 PM

Identified and corrected the root cause (with the help of an awesome chat support agent for one of the services we use)

3:03 PM

Collaborated via Slack with two people in my job family to determine an approprite customer-facing response

6:14 PM

Shared internal documentation in a Google Doc outlining the status, cause, solution, and impact

6:39 PM

Delivered the customer-facing response via email to impacted customers, and

6:45 PM

Updated the shared internal documentation to close the loop, including a copy of the customer-facing response


Making mistakes is a real bummer, and it'll probably take a few more days to shake off the icky feeling entirely.

While I wasn't consciously thinking about it at the time I started writing it, the internal documentation that I put together ended up looking a lot like a postmortem.

I first became aware of postmortems when I was working in technical support. When I hear the word "postmortem" I typically think of a public-facing document, often supplied by some engineering managers, when a bug is really big and bad. Technical postmortems usually include things like:

  • Description of a problem
  • Status
  • Description of the root of a problem
  • Description of the impact
  • Breakdown of response with a specific timeline
  • Summary of the solution to a problem
  • What we learned
  • What we'll do next time to prevent it from happening again, and
  • How to contact support for more information

Sometimes they even include screenshots and supporting data. Sometimes they include an apology.

We often talk about mistakes or failures as personal learning opportunities, and they can also be teaching opportunities. When we take the extra time to describe the solution and document it clearly, we're not just learning from our mistakes; we're teaching others how to avoid similar mistakes in the future.

So, next time you flub it up, don't panic and don't keep it to yourself. Communicate, document, and share.