In the world of SRE, incidents are unplanned investments in reliability. Why? Because they are valuable opportunities to learn and grow. This perspective can be difficult to communicate to other stakeholders. Some may be upset about the cost incurred or the affected customers. Others might not understand why incidents happen in the first place. It is important to show how the lessons of an incident are relevant to each stakeholder role.

One of the most valuable tools in sharing these lessons is the incident retrospective or postmortem. These documents are built after the incident response process and reviewed in internal meetings. Sometimes an edited version is shared with external stakeholders. In this blog post, we’ll show how to coordinate incident retrospectives across different stakeholder groups, how to cultivate a culture of blamelessness during the process, and how to drive change from key findings.

Crafting an Incident Retrospective That Connects With Each Stakeholder

Many stakeholder groups will want to see and discuss incident retrospectives. When writing them, keep in mind a few key pieces of information that each group will be most interested in. This can save you time answering questions later on. Modular documents with moveable sections can be especially helpful for this.


The Secret of Communicating Incident Retrospectives
1.60 GEEK