How we use post-mortems to build a quality culture

Post-mortems can be a game-changing tool to uncover the root cause of the incident, learn from mistakes, and shape a quality culture.

What would happen in your team if someone updated 300K rows of production data when she meant to read it? Or if someone upgraded a library to a backwards-incompatible version, which broke the login? Or if someone deployed an unproperly versioned backend change that the clients were not able to handle? When such errors happen in my team, we fix them immediately. It is what we do now, just like we did 3.5 years ago. The crucial change is what we do afterwards. These days we hold a post-mortem as well. It is a learning event, a blameless conversation about the cause, the impact and the required follow-up of an incident. Post-mortems are a game-changing tool for my teams. They help us uncover the root cause of the incident. Such conversations led to enhanced tests, better interaction with other departments, and improved communication during and after the incident. Here is the before and after: - “oopsie, we’re down” -> organised incident resolution steps. - “YOLO, I’m shipping this” -> more sustainable and testable features. The impact of this simple process has expanded beyond my team or the engineering department. Post-mortems changed the quality culture in my organisation, helping us shape an environment where it matters. In this talk, I will share my experience with this technique: - how to organise truly blameless post-mortems, while getting to the bottom of it; - how to follow up on the lessons learned, and turn them into actions; - how to aggregate the changes into impactful initiatives. I hope that by the end of the talk, you feel inspired to try it out and prepared for your first post-mortem.