Pre: Post-mortem

Yeah yeah, I know it’s a funny header, but let’s start before we even deal with the post-mortem, let’s analyze what happens before the post-mortem process even starts…  we shall call this the “Pre-post-mortem phase”. 

1. Oh no!!!!  this happened: failure to deliver a feature close to the right time or something went wrong or Oopsie we made a booboo in production
2. Deal with it!!!! (whether deliver the feature late or resolve the issues… Processes are best after the fact and not during, at least this one is… thus the “post” part of the name. 
3. Schedule a post-mortem; my experience says that the sooner the post-mortem is booked after we’ve resolved the issue, the better! we lose information with time and our brain tends to make amends with things that went wrong.
4. To the post-mortem meeting try to invite the relevant people to that topic, Engineering manager, a team that worked on the issue, related product person… mainly the people that worked on the issues part, those that managed to find and respond to the issue and others that might share their perspective to that

Post-mortem meeting

Follow the 5 Whys or the Infinite How or whatever methodology you fancy, don’t be super religious about the rules (they basically just vary in execution, choose what’s right for you), the essential rules are always the same:

1. Search for the root cause of the problem!
2. Make clear statements on why/how it happened, do it by talking about artifacts and things, not about people…
3. Once you’ve answered why/how something happened, do try to verify that it really is the cause
4. Once you’ve analyzed the root cause, make sure that you can go upstream from the root-cause to re-enact the booboo 
5. In the room start suggesting ways to fix those lanes you’ve analyzed that caused the booboo
6. Each action item we suggest in the room should be traveled upstream and make sure it’s airtight
7. Learn, Learn, Learn – The entire concept of a post-mortem is to learn for the next time, to know how to avoid this, try to have a paper trail of the results.
8. Publish the learnings within the department/organization, print it on a wall of the team
9. When a new project starts, go over all of the post-mortems learnings you’ve accumulated and please share it with those starting to work

Some thoughts

So after we discussed the “How To” (yeah yeah I know that’s the appeal of the post and in the title, I would still like to talk about the why…

• Learnings are essential, no one like to make mistakes, making mistakes are human… what is essential is to learn from mistakes and evolve…
• It’s an excellent spot to recognize/assess missing skill-set in the organization and maybe to surface that to the management team
• Sometimes blame in a team is built as an undercurrent and by implicit ways, without fully understanding the root cause, we tend to blame people, by assessing the difficulties that led to a scenario we can explicitly clear people from being targeted by colleagues/managers without knowing all the details

Also, I want to make sure you understand that a post-mortem meeting is not a retrospective! if you want to read about retrospectives, click here