Learning from Incidents: What to Do After Writing a Postmortem

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.