Postmortems: The single most important keystone habit for a team (step-by-step guide)

I’m an undisciplined person. My habit of reading books about habit-formation is stronger than any of the habits they’ve helped me form.

Perhaps because of this, I’m interested in the idea of keystone habits - “a small and manageable shift or change that acts as a catalyst for success in many other areas of your life”. For example, sleep and exercise tend to have positive knock-on effects, and make it easier to keep to other habits.

What do you think is the single most effective keystone habit for a team, i.e. the team habit that catalyses the most positive knock-on effects?

My vote goes to the Postmortem.

Every time something goes wrong, or could have gone better, run a blameless, five-whys-inspired Postmortem to figure out how you could improve going forwards.

Though it's not exactly fun to ask how we can improve when something goes wrong, it can be a very cathartic experience. Done well, you can simultaneously reinforce psychological safety and continuous improvement, both of which are central to becoming a high-functioning team.

Here’s how to run a Postmortem well.

Before the session

1. Wait for something to go wrong:

• If it’s an emergency, put out the fire first.
• Then schedule a 90-minute session soon after. Invite the people involved with fixing it, anyone affected by the problem, and someone senior enough to make major decisions who is bought into the process. It's better to be inclusive, but it’s also harder to create a safe environment with a large group.

2. Create a Google Doc based on this public read-only Postmortem template, with the following main sections:

• What happened?
• Why did it happen?
• How do we improve?
• Who are we going to tell?

3. Read Blameless PostMortems and a Just Culture to set the right emotional tone.

4. Read Lessons Learned: Five Whys to get people mulling about root causes.

5. Point invitees to the Postmortem GDoc you just created, and ask them to contribute to the 'What happened?' section, so that you have a full description. Chase them before the meeting to make sure it’s a clear and full description of the incident or problem.

In the session itself

1. Open by reiterating the principles of the Blameless Postmortem:

Our goal is not to point the finger of blame at anyone, or to spend much time regretting what we wish we had done differently. Our goal is to understand how our overall system and process as a team broke down, and what we can learn from this so that we can improve going forwards.

The Postmortem magic only works if you and everyone else actually live by this, so I intone it out loud at the beginning of every single Postmortem like a mantra.

2. Review the 'what happened' section quickly out loud

Tweak it until everyone agrees the description is accurate and complete. Defer any discussion about why it happened or what to do next.

3. Now it’s time to understand why

• Ask everyone to silently scribble down their ideas about why the incident or problem happened into the ‘Why’ section.
• Then silently review everyone’s suggestions, merge duplicates together, and move important suggestions towards the top. See: Idea Stampede.
• In each case, ask them to try and burrow down to the root causes, taking inspiration from Eric Ries’s article about Five Whys (but you don’t have to be a purist about it).
• Now ask someone to present each point briefly, and allow a short discussion.

4. Identify ways you can improve things going forwards

• This tends to follow quite naturally from a good understanding of why things went wrong. For this reason it may be easier to combine the ‘why did this happen?’ and ‘what should we do going forwards?’ discussions.
• For example, if there was a bug in the code, you can discuss how to make your software engineering process more reliable in future. Or if it was a rookie error, you might need to improve your training. If it fell between the cracks where two teams share responsibility, you might need to improve your communication/coordination.
• As Eric Ries points out, burrowing into root causes often shows you that technical problems are people/organisational problems deep down. Try and pick a mix of actions to address the superficial and the root causes.
• Decide which of the potential actions are important enough to definitely take. Assign people to act on them, with a process for making sure that things get done.

5. Decide who you’re going to tell

• If this was a customer-facing incident, contact them to acknowledge the problem, apologise, and let them know what you’re doing to improve things going forwards. Just as a good waiter can turn a minor snafu into a positive experience, this can be an opportunity to improve your relationship with the customer.
• It can be a great idea to share the results of the Postmortem with the rest of the company. It rebuilds confidence, and you may need their help. But remember that the participants in the Postmortem need to feel psychologically safe to be honest about what went wrong and why, so you may choose to protect some details, depending on the situation.

A good Postmortem is one of the very most valuable discussions a team can have.

As Eric Ries says, they compound over time. They direct your attention to the recurring problems that need to be prioritised. If you make even a few improvements after each Postmortem, you’ll be surprised how quickly you end up pretty bulletproof.