Hanlon's Razor

The idea

The saying appeared as "Hanlon's Razor" in Arthur Bloch's 1980 collection Murphy's Law Book Two, and is usually credited to Robert J. Hanlon, who submitted it. Similar thoughts go back centuries. The original wording blames stupidity; the version that helps architects is more generous: most puzzling decisions are explained by missing information, real constraints or honest mistakes, not by bad faith.

Architects regularly inherit decisions that look baffling: a hand-rolled queue, a duplicated database, an integration that ignores the standard. Assuming incompetence or malice damages relationships and, worse, blinds you to the constraint that produced the decision. That constraint may still be there.

Why it works

People act on the information they have. Google's SRE practice builds blameless postmortems on the assumption that everyone involved had good intentions and did the right thing with the information they had. Starting from that assumption leads to better questions.

Charity uncovers constraints. Asking "what made this sensible at the time?" surfaces deadlines, missing tools, broken standards and conflicting incentives. Those are things you can fix; a person's character is not.

Blame makes people hide things. If teams expect to be judged, they stop reporting problems and near misses. A charitable default keeps information flowing to the people who need it.

Where it applies

• Post-incident reviews, to look for systemic causes rather than a culprit.
• Inheriting legacy systems, where past decisions look strange without their history.
• Cross-team friction, such as a team ignoring a standard or missing a commitment.
• Stakeholder conflict, when another group's position seems unreasonable.

How to apply

1. Pause the judgement. Notice when you are forming a story about someone's motives, and treat it as a hypothesis.
2. Reconstruct their situation. Find out what they knew, what deadline they faced and what options they had.
3. Ask, don't accuse. "Help me understand why it was done this way" opens doors that "why did you ignore the standard?" closes.
4. Fix the system. If the cause was missing information or a broken constraint, change that, so the next person does not repeat it.

Example scenario

An architect assumed a product team had ignored the integration standard out of laziness, and was preparing to escalate. A conversation first revealed that the standard's middleware did not support the protocol their main partner required, and the team had no other way to meet its deadline.

Instead of escalating, the architect updated the standard to cover the partner's protocol and helped the team move onto it. The team that had looked like a critic of the standard became one of its strongest supporters.

Questions to ask

When not to use it

• Security incidents and fraud, where malicious intent is a real possibility and must be investigated, not assumed away.
• Repeated patterns after the constraints are fixed. If the information and tools are in place and the behaviour continues, look at it directly.

How it misleads you