How to write a post-mortem without killing anyone?
By: Özgür Özdemircili
Tags: Startup, DevOps, Management, Programming, PostMortem

Post-mortem, as fancy it sounds now it is really not a piece of cake when it comes to putting it into action. And although it does not involve any corpses it surely can be blamed for having caused heart attacks and broken feelings all throughout its history.

Let’s get one thing right “we all do fail”. The one humanly thing we do that separate us from the incoming invasion of never failing/ always right bots and robots is that we do make mistakes. It actually is the way we learn things.

A very example we all touched a hot object when we were young which we have never done(at least knowingly) again. It is the very meaning of a proverb we have:

Once bitten twice shy

So it taking into consideration we learn by doing mistakes and we will continue making them (Unless you are Chuck Norris, of course, he never does fail!) the best thing we can do is to really learn from our mistakes. One of the partly best ways of doing it is what we call post-mortem analysis.

Let’s have a look at what does it mean literally:

According to wiki: A project post-mortem is a process, usually performed at the conclusion of a project, to determine and analyze elements of the project that was successful or unsuccessful.

According to Google SRE book: The primary goals of writing a post-mortem are to ensure that the incident is documented, that all contributing root cause(s) are well understood, and, especially, that effective preventive actions are put in place to reduce the likelihood and/or impact of recurrence.

As you can see none of these explanations involve any name calling, finger pointing or any pen to head throwing which takes us to another term called “blameless post-mortem”. In blameless post-mortem culture, the main idea is to find out what happened rather than who did it. This kind of culture, although at first will feel awkward or will be impossible in companies where the culture itself is not ready/prepared for it, it is always a great great way of educating your teams as well as taking out lessons from it for your team and for yourself.

Although there are many different versions and templates of post-mortem analysis as in here https://gist.github.com/mlafeldt/6e02ea0caeebef1205b47f31c2647966 or here https://gist.github.com/juliandunn/52b4fbde451628e0fe48 taking into consideration what we do and how is our internal culture (Methodology Kanban, Scrum, Lean), systems are architected (AWS vs datacenter vs in-house servers) and the applications we use (Jira, Trello, Kanban board, Wiki) my strong suggestion would be to sit down and create a postmortem sheet that is suitable for your company.

Be sure to include 3 things:

What happened?

How did you resolve it?

What will you do in the future from repeating again?

It is one of the most powerful tools you have to discover the parts of your architecture hidden in the shadow, as well as a great opportunity to give your team chance to learn from one mistake rather than failing and learning themselves. It is also a great way to leave a great in-depth knowledgebase to the future generations that will take place in your team.

Good luck and happy postmortem sessions without any corpses!