WEBVTT

1
00:00:00.000 --> 00:00:23.599
Speaker 1: Remember when our payment system crashed last month? The post-mortem felt like a witch hunt.
Speaker 2: Right! That's exactly what we want to avoid. Today we'll learn how to turn failures into learning opportunities instead of finger-pointing sessions. We'll practice staying curious about how our process let the issue happen so we can fix it together.

2
00:00:23.599 --> 00:00:49.999
Speaker 1: Psychological safety means no one gets punished for admitting an honest mistake.
Speaker 2: Exactly! When teams feel safe, they surface the real issues quickly. Remember how Sarah skipped the deployment checklist? Instead of firing her, we improved the process so it's impossible to skip.
Speaker 1: Think of it like a confession booth for code—people need to feel safe admitting their digital sins.

3
00:00:49.999 --> 00:01:16.399
Speaker 1: When something breaks, the first instinct is often "Who messed up?".
Speaker 2: But blaming shuts the conversation down. Instead of asking "Why did you delete the database?" try "What led you to run that command?".
Speaker 1: Great example! We focus on how the process allowed the mistake, not who pushed the button. The goal is debugging the system, not making someone cry.

4
00:01:16.399 --> 00:01:39.199
Speaker 1: Invite everyone who was involved—engineers, managers, and even customer support.
Speaker 2: Right, because each role sees a different part of the picture. Junior devs might notice missing tests, while support teams capture real user impact.
Speaker 1: And drawing out quiet participants makes sure the action items reflect reality, not just the loudest voices.

5
00:01:39.199 --> 00:02:03.599
Speaker 1: Let's start every post-mortem by reviewing the ServiceNow ticket and the exact timeline of events.
Speaker 2: Then we map each step to the ITIL incident-management flow and dig into root causes with the five-whys technique.
Speaker 1: Document action items as GitHub issues so we can track them. DORA metrics like MTTR show if our fixes actually work.

6
00:02:03.599 --> 00:02:25.999
Speaker 1: One big pitfall is rushing to solutions before we really understand the problem.
Speaker 2: Absolutely. Another is letting one "hero" take all the blame or glory. We need the whole team learning, not just one person.
Speaker 1: And of course the blame game spiral—once finger-pointing starts, people shut down and hide information.

7
00:02:25.999 --> 00:02:51.199
Speaker 1: Here's a scenario: the website crashes right after a big marketing blast.
Speaker 2: I'd pull in the on-call engineer, the database admin, and support to map the timeline. Then we'd ask what in our process allowed the traffic spike to take us down.
Speaker 1: Exactly. Keep the questions neutral so we discover the real gaps instead of assigning blame.

8
00:02:51.199 --> 00:03:23.599
Speaker 1: When tensions rise, try saying, "Help me understand what led up to this" instead of "Who did it?"
Speaker 2: Right. Redirect accusations toward the workflow. Ask, "What monitoring failed us?" or "What review step was missing?"
Speaker 1: Inviting quiet voices with "Anything we missed from your side?" keeps everyone engaged and prevents defensiveness.
Speaker 2: Over time, using phrases like these shows you're ready for leadership roles because you focus on improving the system, not blaming people.

9
00:03:23.599 --> 00:03:39.999
Speaker 1: To dig deeper, check out Google's post-mortem template and Amy Edmondson's book The Fearless Organization.
Speaker 2: We also have ServiceNow guides and a DORA metrics cheat sheet linked in the notes. Use them to strengthen your next post-mortem.

10
00:03:39.999 --> 00:03:53.599
Speaker 1: A blame-free post-mortem lets the whole team grow from setbacks.
Speaker 2: Treating incidents as learning opportunities builds a culture of continuous improvement—one supported by ITIL processes and tracked with DORA metrics.