Every large organization has a moment when one team becomes convinced another team is acting against them. The API broke the day before their launch. The platform team deprecated the endpoint they depended on without warning. The change was approved through a process they were somehow left out of. The pattern reads as intent. It almost never is.
The Law and Where It Came From
Hanlon’s Razor: never attribute to malice that which is adequately explained by stupidity. The phrasing is credited to Robert J. Hanlon of Scranton, Pennsylvania, who submitted it to the 1980 compilation Murphy’s Law Book Two. The idea is older. Goethe gestured at it in 1774, and a near-identical line is often attributed to Robert Heinlein’s 1941 story “Logic of Empire,” which describes ascribing to villainy conditions that result from stupidity.
Two refinements make the razor usable in professional settings. First, replace “stupidity” with something more accurate and less contemptuous: incompetence, oversight, misaligned incentives, or missing information. Second, note the word “adequately.” The razor is not a claim that malice never exists. It is a prior: when both explanations fit the evidence, the boring one is usually correct, because carelessness is abundant and conspiracy is expensive.
Why It Persists in Engineering Organizations
Large systems manufacture coincidences at industrial scale. Thousands of changes per week across hundreds of services guarantee that some failure will land at the worst possible moment for someone, with timing that looks deliberate. Humans are pattern-matching machines with a strong bias toward agency detection: we evolved to assume the rustle in the grass is a predator, and we bring that wiring to the incident channel.
The organizational cost of ignoring the razor is severe and compounding. An engineer who believes a failure was malicious stops investigating, because the explanation is complete: they did it. The actual cause, a gap in the deprecation process, a broken notification pipeline, an ownership boundary nobody wrote down, survives to fire again. Worse, accusations poison the collaboration channels that incident response depends on. This is the mechanism behind the blameless postmortem movement documented in Google’s SRE book: not politeness, but epistemics. Blame terminates inquiry.
The razor applies upward as well. When leadership interprets a missed commitment as sandbagging, or a team’s resistance to a mandate as insubordination, they are usually looking at capacity problems, unclear requirements, or legitimate technical objections that never found a channel. I wrote in “The Silent Saboteur” about transactional leadership reading its own communication failures as defiance. Hanlon’s Razor is the corrective lens.
Case Study: The Deprecation That Looked Like a Hit Job
The following is an anonymized composite drawn from patterns common to platform organizations.
An insurance company’s claims team spent a quarter building a document intake service against the platform team’s file storage API. Three days before the claims team’s launch, the storage API’s v1 endpoints began returning 410 Gone. The claims launch, already promised to a state regulator, slipped. The claims director’s escalation email named the platform team and used the word “deliberate.” Context made it plausible: the two directors had clashed publicly over funding two months earlier, and the platform team had migrated its own consumers to v2 weeks before.
The investigation took one afternoon. The v1 sunset had been announced nine months earlier through a deprecation calendar published on an internal wiki that the claims team had no reason to know existed. Automated consumer notifications had been sent to a distribution list built from an API gateway registry, and the claims team’s service was registered under a contractor’s email address that had been deactivated when his engagement ended. The kill date itself was executed by a scheduled job configured the previous year. No human on the platform team was aware the claims team was on v1 at all. Every element of the “hit job” was a stale config, a dead mailbox, and a wiki nobody reads.
The useful outcome was that the postmortem, once the malice theory collapsed, produced real fixes: deprecation notices moved into the API responses themselves as headers, and consumer registration was tied to team identities rather than individual emails. The malice theory would have produced a feud. The incompetence finding produced engineering.
What To Do About It
- Institutionalize the razor in incident process. Blameless postmortems are Hanlon’s Razor as procedure. The question is never who did this, but what allowed this. Keep the second question alive until you reach a systemic answer.
- Treat apparent malice as a routing failure. Almost every “they did this to us” event is information that failed to travel: a deprecation notice, a dependency, an objection. Fix the channel, not the people.
- Apply it to vendors and AI output too. The model that produced a confidently wrong answer is not lying to you, and the vendor that shipped a breaking change is not targeting you. Both are systems with failure modes. Diagnose accordingly.
- Keep the exception clause. The razor is a prior, not a verdict. Incentive structures can produce genuinely adversarial behavior, and security work in particular must assume malice by design. The razor governs collaboration inside a trust boundary, not defense at its edge.
- Extend the same charity to yourself. Teams under attack for a failure often accept the malice frame in reverse and assume they are hated. Usually they are just unread.
The Architect’s Takeaway
Hanlon’s Razor is an availability heuristic for causes: malice is vivid and rare, entropy is invisible and everywhere. Organizations that internalize it convert accusations into findings and feuds into fixes. The systems you run are not out to get anyone. They are barely holding together, which is both the bad news and the actionable news.
Next in the series: the Pareto Principle, and why 20 percent of your services are generating 80 percent of your pain.
The Laws We Ignore | Part 3 of 11
Previous: Part 2: Hofstadter’s Law | Next: Part 4: The Pareto Principle
