Hanlon’s Razor: How Psychological Safety Makes Software Teams More Productive

Hanlon’s Razor says: never attribute to malice what is adequately explained by carelessness or stupidity. In software teams, you don’t even need carelessness or stupidity. Time pressure, unclear requirements, different context, and honest mistakes made by capable people are enough to explain almost everything.

When you pull up a commit and find code that seems absurd, your first instinct is often frustration. Something about this line of code, this choice, this approach feels wrong. Hanlon’s Razor is a useful corrective: the person who wrote this probably had a reason. Maybe they were under deadline pressure. Maybe they were working around a bug that’s since been fixed. Maybe they just didn’t know a better way yet.

The assumption of good intent changes how teams function. Agile and LEAN have formalized this intuition into practices that produce measurably better outcomes.

What Happens When Teams Skip This

Blame cultures are expensive. When post-incident reviews focus on who caused the problem, engineers become protective. They hide uncertainty rather than raising it. They don’t speak up in planning when they’re not sure about something. They avoid taking ownership of difficult problems.

The result: problems surface later, when they’re more expensive to fix. Technical debt grows because nobody wants to draw attention to areas of the codebase they’re associated with. Incidents repeat because the real systemic causes never get addressed.

This is where LEAN’s concept of waste applies to culture. Fear and defensiveness are waste. They absorb energy that would otherwise go into building, learning, and improving.

Blameless Postmortems

The blameless postmortem is the most direct organizational application of Hanlon’s Razor. When a production incident happens, the goal of the review is to understand the system conditions that allowed the incident to occur, not to identify the individual who made the error.

This isn’t about protecting people from accountability. It’s about recognizing that in complex systems, the conditions that enable mistakes matter more than the mistakes themselves. If a developer deployed a change that caused an outage, asking “why did they do that?” is less useful than asking “what made it possible for that to happen without being caught?”

The systemic question leads to systemic improvements: better deployment gates, improved test coverage, clearer runbooks, automated safeguards. The blame question leads to a developer who is more careful next time, and unchanged conditions that will produce the same result with a different developer.

Teams that do blameless postmortems consistently see fewer repeated incidents. The improvement compounds over time.

Code Review Culture

Code review is where Hanlon’s Razor applies most directly on a daily basis.

A review comment that assumes incompetence (“why would anyone do this”) shuts down learning. It makes developers defensive about their work and less likely to ask questions or try unfamiliar approaches. Over time it degrades the psychological safety that high-performing teams depend on.

A review comment that assumes good intent and asks for reasoning (“can you help me understand the tradeoff here?”) opens a conversation. It might reveal that the reviewer missed something. It might give the author a chance to recognize a better approach without feeling attacked. Either outcome improves the codebase and the people working on it.

The best code reviews are collaborative. Two developers examining a problem together, neither treating the review as a judgment. Agile’s emphasis on cross-functional, collaborative teams makes this culture more achievable, but it requires deliberate practice.

Retrospectives and the Assumption of Positive Intent

The sprint retrospective is one of Agile’s most powerful tools for applying Hanlon’s Razor at the team level. The retrospective assumes that everyone is doing their best given the constraints they’re operating under. The goal isn’t to assign blame for what went wrong. It’s to identify what the team can change to improve outcomes.

This requires psychological safety. If retrospectives are used to surface individual failures or to confirm that certain team members are problems, people stop participating honestly. The meeting becomes theater.

When psychological safety is present, retrospectives produce real insight. Teams surface process problems, unclear expectations, and interpersonal friction early, before they compound. The team improves continuously rather than waiting for a crisis.

Building Psychological Safety as a Practice

Psychological safety doesn’t happen automatically. It’s built through consistent behavior over time.

Leaders demonstrate it by sharing their own uncertainty and mistakes. Senior engineers demonstrate it by asking questions in code review instead of making statements. Teams demonstrate it by treating retrospective feedback as data rather than judgment.

The Agile ceremonies provide the structure. The team provides the trust. Both are required.

Hanlon’s Razor isn’t naive. It doesn’t mean ignoring repeated problems or avoiding hard conversations. It means starting from a position of good faith, and building the kind of environment where people bring their problems to the surface instead of hiding them.

Ready to build a more collaborative software team? Let’s talk.