Staff engineer and engineering leadership

Stage 2 · Lesson 8 of 8

Blameless postmortems

Leading projects and incidents

A explains how the system and process allowed an incident. It does not ask who made the mistake. People act sensibly given what they knew at the time.

So ask why the action seemed reasonable, what signal was missing and which safeguard failed. A good write-up has a timeline, the impact, the , what went well, and with owners and dates. Blame makes people hide information, and that makes the next incident more likely and harder to understand. Share postmortems across teams, because the same failure is often waiting elsewhere.

Common trapa list of vague action items like "be more careful" or "improve ", with no owner, which nobody ever finishes.

A question to check yourself, an AI practice session and 1 cheat sheet entry come with the full roadmap. Unlock

Resources for this stage

Start with· follow one of these

  • BookFree
    Shape Up

    Ryan Singer, Basecamp · Intermediate

    Free book on shaping and scoping work so projects actually finish

  • BookFree
    Google Site Reliability Engineering Book

    Google · Advanced

    The chapters on managing incidents and blameless postmortem culture

Keep handy

Also worth your time

  • Why adding people to a late project makes it later, and other coordination costs

Mark this stage as not done?