Facilitation is a learned and practised skill – hard to perfect but hugely rewarding when done right.The three desired outcomes as goals are:<ul><li>Time flies</li><li>Everyone stays engaged</li><li>Everyone grows, even the facilitator</li></ul>

Flex Your Facilitation Muscles

Another problem with the format was that it didn’t create natural openings in conversation for other engineers to jump in. By focusing on a single event with set questions, we often overlooked commonalities and trends across incidents. This made it difficult for other engineers to understand what they could take away from these meetings and how the lessons might apply to themselves and their team.

Unclear Takeaways

To make sure these techniques were working we started sending automated surveys to our incident review Slack channel after each review. The poll asked participants to anonymously agree or disagree with the following statements:<ul><li>This meeting was a good use of my time</li><li>I think we discussed the right things</li><li>This meeting felt safe and constructive</li><li>I learned something new in this meeting</li></ul>

Post Meeting Survey

You can’t build software without encountering incidents – from critical bugs to full-blown outages, dealing with incidents are an inevitable part of the process.As a result, you’ll find no shortage of articles telling you how to write a review – or as they’re commonly known, a post mortem – of your incident. These top tips are widely practised:<ul><li>Avoid blame</li><li>Focus on the details</li><li>Ask why multiple times</li></ul>

Get More From Incident Reviews

We decided to start experimenting.<ul><li>We looked at the main improvements we wanted to see:</li><li>We wanted everyone to feel truly safe</li><li>We wanted to open up the conversation, encouraging open dialogue and collective learning</li><li>We wanted to observe patterns and move beyond isolated incidents to observe recurring trends</li><li>We wanted our weekly meeting to feel valuable, to be a weekly highlight for engineers</li></ul>

The New Way: Updating The Incident Meeting Format

We set a goal to generate at least four strong talking points: two based on the particular incident under review and two that addressed common themes. At the start of every meeting we would launch a poll with each of our talking points and ask participants to vote for the topic they’d most like to discuss. We’d start with the topic that topped the poll and go from there.

Getting The Talking Points

The progress we’ve seen to date has been really promising. We still have our outstanding problems, like how to tie these learnings into actionable items on our roadmap, or how to keep attendance strong in particularly busy weeks. But the aim of our program is to build an honest, accountable, and constructive culture within teams that care about our customer experience. The way your organization processes failure is a mechanism of change – if that mechanism is broken, boring, or painful, then your organization can’t reach its full potential.

Building an Honest, Accountable and Constructive Culture

<ul><li>Do we know what happened?</li><li>Do we feel confident about how we detected this incident?</li><li>Was it easy and straightforward to mitigate, rather than difficult and slow?</li><li>Do we understand the takeaways, aka the lessons learned?</li><li>Do we feel confident that we can prevent this from reoccurring?</li></ul> the five-question format made presenters feel like they were on trial. They were in the hot seat, at the mercy of anyone with a question. This made the review a high-pressure, isolating experience for the engineer presenting. It’s hard to learn when you, or others around you, don’t feel safe.

The Old Way: Asking Five Key Questions

The question and answer format was not working, that was clear. So how could we guide constructive conversations that brought about real learning? It has always been team practice to assess submitted reports before each review, to make sure they meet our standards for a good report. We decided to capitalize on this process and use this review as an opportunity to extract common themes across multiple incidents.

Extracting Common Themes

You can’t build software without encountering incidents. We changed up our incident review, or post mortem, process to learn more every time.