For folks who’ve made post mortems more meaningful at your company, it is important that you spread that learning around. A lot of companies have teams that do postmortems really well and a lot of engineering managers (EMs) want to spread it organically, but writing and following postmortems is the kind of practice that a lot of devs really just don’t think about or care about and it can get extremely hard to force this practice, especially without support from upper management. So what can you do as an engineering manager?

Retrospectives

A lot of the best gains that most EMs made were either through word of mouth or providing a good example. First off, give people the time to actually do a good job with the retrospective process. Don’t make it sound like people need to rush things out the door to move on to “real” work. Second, you also must highlight how well-done postmortems are affecting how you’re thinking and approaching the work you’re looking at for the next month or quarter. John Allspaw has a lot of text on this basically saying that you know you have a healthy retrospective culture when you see teams attending other teams’ retrospectives.

Rethinking “Action Items”

One must also keep in mind that postmortems shouldn’t be about action items per se, but what you learned about how things work from a postmortem. It might appear to be a hard sell if your organization has a fixed mindset on intelligence or ability and might require conquering any inclusion and psychological safety issues at first, but it’s easier than it looks. Saying “we’re doing X because it was an action item from last month’s postmortem” is less interesting than “I understand why this thing we’re doing is important, because of how Cindy used this thing in the last incident”.

A common notion that you’ll have to dispel is that no one is going to want to participate in an honest retrospective if they think they are going to get screwed by doing so or if they think that the only thing anybody cares about is action. You need to make people realize that a retrospective with no action items was not a failure. Intangibles can be a hard sell.

#scrum #agile development #incident management #agile practices #incident response #site reliability