The piece critiques the effectiveness of post-mortem reviews in tech teams, arguing that many fail to produce actionable outcomes. While it’s commendable that these reviews prioritize psychological safety and blame-free discussions, the suggested actions often remain vague aspirations rather than concrete steps. Phrases like “proactively communicate design decisions” or “write tests” lack clarity and accountability. The author emphasizes that without changing the underlying system, asking engineers to simply try harder is ineffective. A litmus test is proposed for evaluating post-mortem actions: if neglecting an action doesn't lead to mechanisms that prevent future bugs, then it's just a meaningless checkbox. Examples illustrate this point. For instance, ensuring all code is tested before merging is merely an aspiration unless backed by a system change like a coverage ratchet. The piece outlines several effective post-mortem actions that do change the system, including automated guards like CI gates, environmental changes such as improved test environments, and structural adjustments to team responsibilities. To enhance post-mortem processes, the author suggests adopting a structured template that demands specificity. Each action should detail the specific change, identify a responsible person, set a due date, outline the enforcement mechanism, and establish how success will be measured. This framework eliminates vague suggestions like “be more careful” and instead focuses on tangible changes that can lead to real learning and improvement. Ultimately, the article stresses that learning from failures must lead to system changes, or else the same issues will likely recur.