Lessons I Have Learned About Past Postmortems at N26

I want to share a few things I learned over the last two years at N26, kickstarting postmortems and trying to figure out the best approach to get to do them, as well as trying to maximise their benefits.

Time to think

Postmortems are sessions scheduled to stop and think retrospectively about the events and the timeline that led to a specific incident. Usually, when something goes wrong, it’s due to previous bad conditions or assumptions.

The bad conditions which allowed -or increased the likelihood for- this specific incident to happen are the roots of the problem, just waiting to be discovered. It’s important to acknowledge the lack of direct intuitive conclusion between cause and effect in most cases, which warrants us to stop and take our time to analyse and trace back problems to past bad conditions.

Book sufficient time

Consider the point “Time to think.” There have been cases where most teams time-box postmortems and try to rush out action items to fix the bad conditions that led to an incident. Consider, though, that there may be more to postmortems than actually churning action items and recording them in a backlog somewhere.

Uneasy feeling about them

Setting up postmortems can give this uncanny feeling of re-living the same incident or assuming that it’s a meeting to bring people down and/or point fingers.That is not the case! It is important to understand that postmortems are in place with the assumption that people are good and the most important part of any organisation. Obviously people will avoid making mistakes if they can, and postmortem sessions are not a place to point out how flawed people are but to provide a safety net for secure workflows within teams and across the entire organisation.

The goals of postmortems

“Anything that can go wrong will go wrong.” The ultimate goals of a postmortem-incident cycle is to minimise and eliminate as many root causes of failures as possible , and to be able to share with different teams so as to be able to judge if the current task is going to lead to bad conditions in the future. They are a safe, incremental way to understand big and small issues slowly and curate a sane workflow as well as systems which are robust and durable in case of failures.

The process of postmortems begins with reviewing the timeline of the events that occurred during the incident until resolution. Because people are the most important part of the organisation, it’s equally important to ensure that everyone in the postmortem understands the events, their triggers and their impact. This is the primary goal of postmortem sessions.

The secondary goal of the sessions is to readjust and refine the process of working — our workflows — to enable us to account for such system failures in addition to potentially recognise possible failures during the implementation phase.

Wisdom cannot be imparted but knowledge can

The next logical step is to maximise the benefits of postmortems and to try and push this procured knowledge to as many people as possible.

Postmortems usually are exclusive to those who attend the sessions, shared in a documentation format in a few cases. The missing part here is to actually push this knowledge and broadcast it somehow. It is of value that we ensure that those issues we discovered are understood and acknowledged by all engineers. This knowledge will accumulate over time, raising the bar of engineering practices for the entire organisation, and leading to the ultimate goal of not only minimising the number of failures but avoiding them to begin with.

Interested in joining one of our teams as we grow?

If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at some of the roles we’re looking for here.