
Tiny Big Spark: The Engineering Leadership Podcast
Stop Explaining the Incident. Start Changing the System.
Donnerstag, 15. Oktober 2026 · 3 min
Kapitelklicken springt direkt hin
Shownotes
A postmortem is only valuable when it leads to real change. Discover why engineering leaders should focus less on explaining what went wrong and more on implementing meaningful fixes that prevent the same incidents from happening again.
Learn how to turn incident reviews into lasting improvements through automation, clear ownership, and actionable follow-ups. Because real progress happens when lessons become changes in the system, not just notes in a document.
Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin
After your last incident, what actually changed? As an engineering manager, you might remember the details of the postmortem, but can you pinpoint one specific change that came from it? The real measure of a review is not just telling the story, but ensuring something in the system is different afterward.
Michael Heape emphasizes that after an incident, the focus should shift from explaining what happened to discussing what will change. He shares an experience where a senior executive wanted to skip the details and instead focus on the changes needed. This perspective encourages us to look beyond the why and ask, "What can we change to prevent this from happening again?"
Heape suggests that many organizations fall into the trap of agreeing on the reasons behind an incident, which can slow down progress. Instead, he urges leaders to examine the system and consider changes that would reduce the likelihood of similar incidents. For example, instead of just asking people to double-check their work, we should implement automated checks that catch errors before they cause issues. He also warns against relying too heavily on people for fixes.
Actions that depend on human memory or effort are less reliable than systemic changes. A strong fix might involve redesigning processes or automating checks, while weaker fixes often just ask for more diligence from the team. As engineering managers, it's crucial to prioritize these changes on the roadmap.
Follow-up actions should be treated as real work, placed alongside product features, and given due dates and ownership. A focused approach with one or two meaningful changes per incident is more effective than a long list of vague actions. Heape encourages us to look across multiple incidents to identify patterns and systemic issues.
After implementing a fix, it's important to verify its effectiveness and keep track of any accepted risks, ensuring they don't become forgotten over time. Finally, trust is key. As an engineering manager, openly express your trust in your team and lead with the changes you're implementing. This sets a positive tone for discussions and encourages accountability.
So what can you do starting Monday? Move the change list to the top of your review template, grade your past action lists, limit the number of actions per review, log accepted risks, and practice leading with trust. By making these adjustments, you can foster a culture of continuous improvement and ensure that your team learns and grows from every incident. Keep pushing forward, one small spark at a time.