June 1, 2026

---

Hi Everyone,

Runframe documented a 40-person engineering team whose recent post-mortem ended with one action item: "Add config validation to the deployment pipeline." The action had a named owner (Maria), a deadline (Friday), and a ticket in the team's work tracker. It got done.

In most post-mortems, that's not what happens. The team identifies a few causes, agrees on a list of fixes, and someone types them into a document. By the next week, those action items are competing against feature work and whatever else is in the team's main work tracker.

Giva's incident-review guide states it directly. "A Post-Incident Review that doesn't produce implemented changes is just a meeting."

Here’s how to translate a post-mortem discussion into actual results.

Limit yourself to one to three actions

The first fix is at the meeting. Cap the action count at one to three per review. Beyond that, most items don't get done.

The second fix is to design each action so it gets done. Each action needs four things:

• A clear definition of done: the change should be specific enough to deliver, like "add config validation to the deployment pipeline."
  ​
• A named owner: Each owner is one individual, since teams don't count as owners.
  ​
• A due date: Atlassian sets the deadline range at 4 to 8 weeks for its priority actions.
  ​
• And the ticket lives where the regular work lives (Jira, Linear, Asana, your CRM). Anything in a separate Google Doc or Notion page gets ignored.

​
Google SRE (Site Reliability Engineering) codifies the same rule by treating every post-mortem action as a bug in its normal tracker.

Put it where you already look

The third fix is structural. Add the post-mortem action check to a meeting you already have.

Amazon runs a two-hour weekly operations review attended by senior leaders, service general managers, and engineers. Service teams rotate through a roster called the Ops Wheel and walk through their operational dashboards each week. Issues surface to leadership in the same forum, alongside performance metrics.

The same approach works outside engineering. PostHog runs customer-churn retros in a dedicated Slack channel as soon as an account churns. Whoever managed the account writes a short retro covering what happened and what the team learned. Those findings feed into the team's normal customer-success work.

For smaller teams, add a 5-minute slot to your existing weekly leadership review for checking any open post-mortem actions. Show them on a dashboard with completion status, and the named owner reports on progress.

Try this today

Open your last post-mortem document. Cut the action list down to one to three items, ranked by impact. For each item, assign a named owner and set a deadline within 4 to 8 weeks. Create a ticket in the team's normal work tracker. Then add a 5-minute slot to your next weekly leadership review to check completion.

Go deeper

👉 Runframe: Post-Incident Review Template – the 40-person team example and Runframe's case for capping action items at one to three

​
👉 Google SRE Workbook: Postmortem Culture – how Google treats post-mortem actions as bugs with the same priority and tracking as feature work

​
👉 Benjamin Charity: Effective Post-Mortems Definitive Guide – the diagnosis of why action items fail and the structural fixes

​
👉 AWS Cloud Operations Blog: Creating a Correction of Errors Document – Amazon's COE template, including how the document and the actions get structured

Coming up tomorrow

Tomorrow we'll cover why customer-facing AI is the worst place to start, and what to build instead.

​
Have a great week!

​
P.S. How long do post-mortem action items typically stay open at your company? A week, a month, a quarter?