On-screen

Narration

Anna: Post-mortems can drift into rambling war stories if no one sets a clear agenda. A simple structure keeps the conversation productive and short.
Greg: In this segment we'll outline a repeatable agenda that teams of any size can follow. You'll learn who should be in the room and what each person contributes.
Anna: We'll also cover how thorough documentation helps future investigators understand what went wrong and why. By the end you'll have a framework you can adapt to your own organisation.
Greg: You might think it's overkill to formalise a meeting about one incident, but the agenda keeps everyone focused on facts instead of opinions. Without it, people tend to jump around the timeline or get stuck debating blame.

On-screen

Narration

Anna: Begin every post-mortem by walking through a concise timeline of events. Note when alerts fired, when the first responder acknowledged them and when service was restored. This sets a factual foundation and keeps speculation in check.
Greg: After the timeline, cover the business impact—how many users were affected and what the cost might be. Then move on to root cause analysis using a structured method like five whys or a fishbone diagram.
Anna: Capture action items as they're discussed and assign owners on the spot. End the meeting by confirming due dates and when follow-up reviews will happen. A typical agenda can wrap up in under 30 minutes when everyone sticks to these steps.

On-screen

Narration

Anna: A successful post-mortem needs the right mix of perspectives. Incident responders bring the technical details and know exactly what they tried in the heat of the moment.
Greg: Service owners speak to business impact and can decide which fixes are worth prioritising. A facilitator keeps the conversation moving and makes sure quieter voices are heard.
Anna: You'll also want a scribe to capture notes and action items in a shared document or ticketing system. Finally, invite at least one stakeholder from the business side so the discussion stays grounded in user impact rather than just technical details.

On-screen

Narration

Anna: Documentation is often the most overlooked part of a post-mortem. Use a central template so every incident report looks the same. Include the timeline, root cause details, impact assessment and action items.
Greg: Link your ServiceNow tickets or JIRA issues, plus any GitHub commits or pull requests that contain the fixes. This makes it easy for future teams to trace the history if something resurfaces.
Anna: Add metrics like MTTR and number of affected users. Summarise lessons learned in plain language so they can be reused in training or onboarding. Finally, store the report in a shared location and announce it to the team so knowledge spreads beyond those who attended the meeting.

On-screen

Narration

Anna: A consistent agenda turns post-mortems into a learning tool instead of a finger-pointing session. It ensures every incident gets the same level of scrutiny.
Greg: Documenting who attended and what was decided makes follow-up easier and helps new team members learn from past mistakes. Keep the reports concise and accessible so they actually get read.
Anna: With clear roles, a repeatable agenda and solid records, post-mortems become a catalyst for improvement rather than a dreaded meeting.
Greg: Set a calendar reminder to revisit unresolved action items every quarter. Nothing kills trust faster than open tasks left hanging indefinitely.