structural-retrospective

Blameless postmortems focus on what the system allowed to happen rather than who made a mistake. Reconstruct the failure from logs and metrics first, identify the missing signal or structural gap, then assign each follow-up one owner and one due date as a tracked issue.

Convert each lesson into something that re-runs without the meeting: a regression test, assertion, alert, lint rule, schema constraint, or runbook entry. Prefer deleting the failure mode entirely over adding another guard, and feed every item back as a triage-ready issue.

Common red flags include confident memory outranking reproducible evidence, citing human error as the root cause, action items like 'be more careful', alerts added without an owner or false-positive control, and retros that end with prose but no tracked issues.

Follow-ups fail when they lack a single owner, a due date, or a tracked issue in the team's triage system. The retrospective report explains the work but is not the work itself, so every action must be converted into an owned, dated, triage-ready issue.

Prefer deletion when the failure mode itself can be removed, such as retiring a dangerous code path, config option, or dependency. Removing the failure mode is more durable than layering guards, alerts, or checks on top of a structure that keeps causing incidents.