§ 114
McNamara Fallacy
Decisions drift toward whatever can be counted, until what cannot be counted is treated as if it did not exist.
Keep in mind
Name what you cannot count, and keep it beside the number
What to do
When a decision rests on a dashboard, write down what matters that the dashboard does not show, such as user trust, on-call load or code health, and put at least one direct look or survey beside the numbers. The SPACE authors make the same point about developer productivity: no single metric or dimension can capture it. For a narrow, well-instrumented question such as one endpoint's latency, the number is enough.
Why it happens
Daniel Yankelovich laid it out as four steps in a 1971 speech. "The first step is to measure whatever can be easily measured. This is okay as far as it goes." Then: "The second step is to disregard that which can't be easily measured or give it an arbitrary quantitative value." Then: "The third step is to presume that what can't be measured easily really isn't very important." Last: "The fourth step is to say that what can't be easily measured really doesn't exist." He called the end of that slide suicide, named it after Robert McNamara and pointed to the US experience in Vietnam. Numbers are cheap to collect, easy to compare and easy to defend in a meeting; judgements about trust, morale or the state of the code are not, so they tend to lose by default. It differs from Goodhart's Law: there the number gets gamed; here the number can be honest, and the harm comes from what was left out.
When it stops applying
Measure It Anyway: much of what looks unmeasurable can be measured roughly, and a rough number tells you more than an unexamined hunch; Hubbard argues that the belief something cannot be measured rests on misconceptions (How to Measure Anything, 2007).
Source
Daniel Yankelovich, The New Odds (speech to the Marketing Strategy Conference of the Sales Executives Club of New York, 1971) — the four steps and the name. The common citation Corporate Priorities (1972) is the name of his firm's research programme, which this speech introduces; the four steps are in the speech itself. The link is a transcript published by Ryan Madden (2026), who says he acquired a copy of the original transcript from the UCSD library archives and published it with the copyright holder's permission; the page also links a PDF of that copy; it is the only full text of the speech we found online. Douglas W. Hubbard, How to Measure Anything: Finding the Value of "Intangibles" in Business (Wiley, 2007) — the counter's argument that much of what looks unmeasurable can be measured. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, "The SPACE of Developer Productivity" (ACM Queue 19(1), 2021) — developer productivity cannot be measured by a single metric or dimension.
Read the sourceCite this
Hammurabi, § 114, “McNamara Fallacy.” https://kanywst.github.io/hammurabi/laws/mcnamara-fallacy/
BibTeX
@misc{hammurabi-mcnamara-fallacy,
title = {McNamara Fallacy},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 114},
url = {https://kanywst.github.io/hammurabi/laws/mcnamara-fallacy/}
}Read in a column
- Deciding what to build
- When the numbers run the work Next in the column: Goodhart's Law
Related laws
- 14Goodhart's LawA number stops measuring well once people are rewarded for moving it.
- 21Survivorship BiasConclusions drawn only from successes ignore the failures that used the same strategy.
- 98Genchi Genbutsu (Go and See)Decisions made from reports drift away from what is actually happening, because each layer of summary drops the detail that did not fit its form.
- 115Twyman's LawWhen real effects that large are rare, a metric that moves surprisingly far is more often a bug in the measurement or the analysis than a real effect.