Every tech company claims to have a blameless culture. It’s in the values deck. It’s mentioned in interviews. Post-mortems are labelled “blameless” by default.
And yet, when something breaks, people get blamed. Not officially. Not in writing. But in subtle ways that everyone notices.
True blamelessness is rare because it’s genuinely hard. It requires fighting human instincts, changing organisational incentives, and maintaining discipline when emotions run high.
What Blame Actually Looks Like
Blame isn’t always obvious. It hides in language and behaviour:
The pointed question. “Why didn’t you test this before deploying?” The question has an answer - there’s a reason. But the tone implies the person should have known better.
The disappointed sigh. No words needed. Body language does the work.
The “learning opportunity.” “This is a learning opportunity for the team” often means “someone screwed up and we’re being polite about it.”
The reassignment. After an incident, someone quietly gets moved off the project. No explicit blame, but everyone knows.
The repeated story. “Remember when that deployment took down production?” becomes organisational folklore, forever associated with whoever made the change.
The hiring filter. “We need someone more senior for this system” after an incident. The current engineer was fine last week.
These aren’t firings or formal reprimands. They’re subtle signals that shape behaviour far more than any official policy.
Why Blame Feels Right
Blame is instinctive. Something broke. Someone did something. Cause and effect. Holding people accountable seems reasonable.
But this instinct is wrong for complex systems.
Complex systems fail for complex reasons. The engineer who pushed the bad config didn’t create the system that allowed bad configs to be pushed. They didn’t write the inadequate tests, design the missing guardrails, or create the time pressure that led to skipping review.
Blaming the individual ignores the system. And if the system doesn’t change, the same failure will happen again, just with a different person.
The question isn’t “who screwed up?” It’s “what allowed this to happen, and how do we prevent it?”
The Cost of Blame
Blame cultures pay hidden costs:
People hide problems. If reporting an issue gets you blamed, you learn to stay quiet. Small problems become big problems because nobody wants to be the messenger.
Risk aversion kills velocity. Every change is a potential career threat. People deploy less, experiment less, and move slower. “Don’t break anything” becomes the unspoken priority.
Post-mortems become useless. When blame is possible, people protect themselves. They minimise their involvement, blame external factors, and avoid saying anything that could be used against them. You learn nothing.
Good people leave. Talented engineers have options. They don’t stay where mistakes end careers.
Learning stops. Organisations that blame don’t improve. They just get better at hiding failure.
What Blamelessness Actually Requires
Creating a blameless culture isn’t about declaring it. It’s about building systems and behaviours that make it real.
Language discipline. Ban “why didn’t you” questions. Replace with “what made this possible” and “how might we prevent this.” It sounds pedantic, but language shapes thinking.
Assume competence. The person who made the mistake was trying to do their job well. If they made a mistake, the system failed to prevent it. Start from this assumption.
Separate the person from the action. “The deployment caused an outage” not “John caused an outage.” The action happened. It’s not someone’s identity.
Leadership models behaviour. When leaders take blame, others do too. When leaders deflect, others learn to deflect. You get the culture you demonstrate.
Consequences for blaming. If someone publicly blames a colleague, address it. Blamelessness requires active maintenance.
Post-Mortems as Practice
Post-mortems are where blamelessness is tested. Every incident is a choice: learn or blame.
Structure post-mortems to make blame hard:
Focus on timeline, not people. “At 14:32, the deployment completed” not “At 14:32, Sarah deployed.”
Ask systemic questions. “What process allowed this?” “What safeguard was missing?” “What information would have changed the decision?”
Explore counterfactuals. “If a different person had been on call, would the outcome differ?” Usually the answer is no - which proves it’s systemic.
Name contributing factors, not culprits. Time pressure, missing documentation, inadequate testing environments. These are systemic issues with systemic solutions.
Distribute the post-mortem widely. Transparency signals that this is about learning, not punishment. If you’re hiding the post-mortem, ask why.
The Accountability Objection
“But people need to be accountable!” This objection comes up every time.
Accountability and blamelessness aren’t opposites. You can hold people to high standards without blaming them when complex systems fail.
Accountability means:
- Clear expectations communicated in advance
- Feedback on performance patterns over time
- Development plans for growth areas
- Consequences for repeated negligence or malice
What it doesn’t mean:
- Punishment for single incidents in complex systems
- Career damage for honest mistakes
- Public shaming after outages
The distinction: patterns versus incidents. Someone who repeatedly ignores warnings, skips reviews, and refuses to learn has an accountability problem. Someone who made a mistake in a system that allowed the mistake isn’t negligent - they’re human.
When Someone Really Did Screw Up
What about genuine negligence? The person who deployed drunk. Who ignored explicit warnings. Who deliberately bypassed safeguards.
These cases are rare. When they happen, address them directly and privately. Don’t use the post-mortem for discipline.
The post-mortem is still blameless: “The deployment bypassed the standard review process. We need to understand how this was possible and prevent it.”
Separately, HR handles the personnel issue.
Mixing discipline and learning corrupts both.
Building the Muscle
Blamelessness is a practice. You get better with repetition.
Start with small incidents. Practice on low-stakes failures. Build the habit before emotions run high.
Appoint a blamelessness advocate. In post-mortems, one person watches for blame language and redirects. Rotate this role.
Celebrate good post-mortems. When a post-mortem leads to real improvements, recognise it publicly.
Review past incidents. Look back at older post-mortems. Were they blameless? What would you do differently?
Train new hires. Explain the culture explicitly. Don’t assume they’ll absorb it.
The Long Game
Blameless culture takes years to build and moments to destroy. One public blame incident undoes months of trust-building.
It’s worth the effort. Teams with genuine blamelessness:
- Find and fix problems faster
- Experiment and learn more
- Retain better people
- Build more reliable systems
The irony is that blameless cultures have fewer incidents to be blameless about. The learning compounds.
Start today. Review your last post-mortem. Was it truly blameless? What would you change?
The answer tells you where you actually stand.