Skip to main content

> blameless_postmortems_&_counterfactual_'should_have'_fallacies

Blameless Postmortems & Counterfactual 'Should Have' Fallacies

Why do counterfactual statements ('The engineer should have checked...') sabotage postmortem investigations, and how do systems-thinking facilitators refocus on latent environmental traps?

Staff/Principal (L6+)

THE SHORT ANSWER

Counterfactual reasoning—speculating about what people 'could have, should have, or failed to do'—is the most pervasive anti-pattern in incident postmortems. It is fueled by hindsight bias: knowing the outcome makes the failure seem obvious in retrospect. When an incident report states 'the developer should have tested the migration on staging,' it terminates systemic inquiry and pins blame on individual human fallibility. True blameless postmortems ban counterfactual language. Instead of asking why an engineer made an 'incorrect' decision, facilitators ask: 'Given the information, dashboard signals, time pressure, and organizational tools available to the engineer at that exact second, why did their action make complete sense to them at the time?' This shifts remediation from scolding individuals to eliminating systemic booby traps.

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

Human error is the starting point of an investigation, never the conclusion. Sydney Dekker's Safety Differently and SRE postmortem frameworks enforce four linguistic and analytical rules: (1) Ban counterfactual words: Scrub words like 'could have', 'should have', 'failed to', 'carelessly', and 'inadvertently' from postmortem drafts. (2) Reconstruct the local rationality: Map out the exact UI screens, alert notifications, and architectural assumptions present during the action. (3) Identify latent organizational traps: Fragile deployment scripts, missing database safety guards, unreadable error logs, or unrealistic product deadline pressures. (4) Systemic action items: Implement guardrails (e.g. automated schema validation, read-only DB replays) rather than 'remind developers to be more careful.'

2. Appropriate Use Context

All post-incident reviews (PIRs), outage postmortems, security near-miss retrospectives, and architecture failure audits.

3. Production Failure Modes

A company firing an engineer who dropped a production database table; three months later, another engineer drops a different production database table because the underlying database lacked a confirmation barrier or drop-table protection policy; developers hiding incidents out of fear of public humiliation.

4. Diagnostic Signals & Telemetry

Postmortem documents listing action items such as 'Train team to follow runbook' or 'Remind engineers to check replication lag before deployments'; engineers terrified to volunteer for on-call rotations.

5. Prevention & Safeguards

Appoint trained postmortem facilitators outside the impacted team; establish automated linting rules on postmortem markdown templates to flag words like 'should have' or 'human error'; require all action items to be technical preventions (e.g., CI/CD gating, IAM permission scoping).

6. Architectural Trade-offs

Blameless postmortems require emotional maturity and cultural discipline from executive leadership, but represent the only method to transform catastrophic failures into permanent organizational immunity.

Case Study (TinyCTO In-Field Example)

A junior engineer accidentally truncated a production user table using a migration script with no `WHERE` clause. In a blame culture, the engineer would be reprimanded. In a blameless postmortem, the team investigated why the CLI permitted raw unbounded `TRUNCATE` against production without a multi-party approval token, why staging credentials matched production, and why backups took 4 hours to restore. They added query guardrails, database IAM barriers, and automated instant point-in-time recovery.

Interactive Concept Drills

2 Cards
Q1

Why is the phrase 'The engineer should have...' considered harmful in a postmortem?

It is a counterfactual statement driven by hindsight bias that blames an individual instead of identifying the systemic design flaw.
Q2

What makes an incident action item effective vs ineffective in a blameless postmortem?

Effective action items create technical guardrails that make the failure impossible; ineffective items merely tell humans to 'be more careful.'

Blameless Postmortems & Counterfactual 'Should Have' Fallacies — Technical FAQ

Does a 'blameless' postmortem mean engineers are never held accountable?

No. Accountability in SRE means engineers are responsible for explaining their mental model, identifying systemic traps, and implementing robust technical safeguards—not being punished for honest mistakes.

How does psychological safety impact incident mean time to detection (MTTD)?

High psychological safety dramatically reduces MTTD because engineers immediately raise alarms when they suspect an issue, rather than hiding anomalies out of fear.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸Counterfactual language ('should have', 'could have') sabotages root-cause analysis.
  • ▸Hindsight bias makes past decisions look obvious when the outcome is known.
  • ▸Postmortems must investigate why the action made sense to the engineer at the time.
  • ▸Remediation must build technical guardrails rather than demanding humans be more careful.

Common Misconceptions

  • ✗Misconception: Blameless postmortems mean there are no consequences (False: The consequence is engineering investment in architectural safeguards).
  • ✗Misconception: Human error is a root cause (False: Human error is a symptom of poorly designed tools and interfaces).

Decision & Governance Guidance

Audit postmortem drafts to eliminate counterfactual language. Reject all action items that rely on human memory, vigilance, or refresher training.

Authoritative Sources & Standards