How do you run post-mortems and incident reviews? How do you ensure follow-through on action items?

Situation: At a SaaS company, we had a 4-hour outage that affected 15% of our customers. Our payment service went down due to a database connection pool exhaustion—a deployment had changed the connection settings. The team was stressed, and there was finger-pointing. Leadership wanted to understand what happened and how we'd prevent recurrence.

Task: I needed to run a blameless post-mortem, identify root cause and contributing factors, and ensure action items were actually completed.

Action: I scheduled the post-mortem within 48 hours, when memories were fresh. I set ground rules: blameless, focus on systems and process, not individuals. I used a structured format: timeline of events, root cause (Five Whys), contributing factors, and action items with owners and dates. We identified that our pre-deploy checks didn't validate connection pool config, our staging environment didn't match production, and we lacked circuit breakers. I assigned owners: one engineer for the pre-deploy check, another for the staging parity, and I took the circuit breaker work. I created a tracking doc and added post-mortem follow-up to our weekly sync. I shared a sanitized summary with leadership.

Result: All action items were completed within 4 weeks. We had no similar incidents in the following year. The team felt the process was fair and that we'd learned. I learned that post-mortems only work when action items are tracked and closed—otherwise they're just documentation.