Every slide in the quarterly review was green. Velocity was up, the ticket backlog was down, test coverage had crossed ninety percent, and uptime read four nines. Leadership looked at the deck and concluded the team was healthy, because every number that could fit on a slide said so. What was not on any slide: three of the five senior engineers were quietly interviewing elsewhere, the codebase had reached the point where nobody could estimate a change with a straight face, and the two customers who mattered most had already decided to leave but had not filed a ticket about it. None of that was a number, so none of it was discussed. Two quarters later the attrition, the estimates, and the churn all arrived at once, and everyone called it a surprise.

It was not a surprise. It was a blind spot with a name. The things that actually decided the team's fate were real, but they were hard to count, so they never made it onto the dashboard, and anything not on the dashboard was treated as though it were not happening. That is the McNamara fallacy, and it is a quieter and more dangerous cousin of the measurement traps most people already know. It does not require anyone to game a metric. It only requires that you keep your eyes on what is easy to measure and let the rest slide out of view until you have convinced yourself it does not exist.

What is the McNamara fallacy?

The McNamara fallacy, also called the quantitative fallacy, is the mistake of making decisions based only on easily measurable factors while dismissing everything that cannot be easily quantified. It is named after Robert McNamara, the U.S. Secretary of Defense who ran the Vietnam War by the numbers, most infamously the enemy body count. Those counts rose steadily while the war was being lost, because the things that actually predicted the outcome, morale and local politics and legitimacy, were not countable and so were left out of the analysis entirely. The social scientist Daniel Yankelovich later gave the pattern its formal shape, and the name stuck to the man who gave the clearest demonstration of it.

Yankelovich described the fallacy as four steps, and they escalate in a way that is worth reading slowly, because the damage is mostly in the last two:

Measure whatever can be easily measured.
Disregard what cannot be measured, or assign it an arbitrary number.
Presume that what cannot be measured easily is not important.
Conclude that what cannot be measured does not really exist.

The first step is just good practice. Measuring what you can is how any serious team operates. The slide from reasonable to ruinous happens across steps three and four, where "we do not have a number for this" silently becomes "this is not important," and then "this is not real." By the end you are not merely under-weighting the unmeasured. You have deleted it from the picture, and you make confident decisions inside a map that is missing its most important terrain.

The four steps, and the one that does the damage

What makes the McNamara fallacy distinct from the better-known metric traps is that nobody has to cheat for it to ruin you. With a gamed metric, someone sees the target and takes a shortcut. The McNamara fallacy needs no shortcut and no bad actor. It is a failure of attention, not of integrity: the measurable crowds the unmeasurable out of the conversation, and the conversation is where decisions get made.

The diagram is the whole fallacy in one frame. Decisions flow cleanly from the left column, the measured one, because those numbers are in every report and every meeting. The right column, the one that actually determines whether the team succeeds, has no pipeline into the decision, because nobody put a number on it. The dashed line is cut not by malice but by absence. And here is the cruel part: the outcome is still decided by the right column. Reality does not care which variables you chose to track. It runs on all of them, measured or not, and then presents the bill.

This is why a McNamara-style failure always feels like it came out of nowhere. From inside the measured view, everything looked fine right up until it did not, because the leading indicators of the collapse were never instrumented. The warning signs existed. They just were not numbers, so to a team deep in the fallacy they were invisible, which is step four doing exactly what it does.

The McNamara fallacy in software and knowledge work

Modern teams are unusually exposed to this, because so much of what we build generates clean, tempting, easily charted numbers, while the things that actually matter about the work resist counting. Here are the measurable proxies teams lean on, and the unmeasured reality each one tends to push off the table.

What is easy to measure	What it quietly displaces	How the failure arrives
Story points and velocity	Whether the team can still estimate honestly	Planning stays green until a "simple" change takes a month
Tickets or PRs closed	Whether the underlying problems are actually fixed	Backlog shrinks while the same issues keep returning
Test coverage percentage	Whether the tests catch real regressions	Coverage hits ninety, a basic bug ships anyway
Uptime and latency SLOs	Whether users trust and understand the product	The dashboards are green while customers quietly churn
Lines of code or commits	Whether the codebase stays comprehensible	Output looks high while nobody can safely change anything
Notes captured or tasks logged	Whether you actually understand what you saved	The archive grows while your real recall shrinks
Headcount and hours logged	Whether morale and trust are holding	Capacity looks fine until three people resign in a week

The through-line in every row is the same: the left column is a faithful record of activity and a poor record of value, and the right column is the reverse. None of these metrics is wrong to track. Velocity, coverage, and uptime are genuinely useful observations. They become the McNamara fallacy only when they are the only thing in the room, so the hard-to-measure half of reality drops out of the discussion and then out of the plan. The note-taking row is the one that hits closest to home for most individuals: it is easy to count how many notes you have captured and nearly impossible to count whether you still understand them, so people optimize the number they can see and let comprehension decay unmeasured.

McNamara fallacy vs Goodhart's law vs Campbell's law

These three ideas travel together and get used interchangeably, but they name genuinely different failures, and keeping them straight makes each one sharper. A thread on Hacker News put the family neatly: the McNamara fallacy and Goodhart's law are "the bane of pure data-driven decision making," and they fail from opposite directions. Goodhart and Campbell are about a metric going bad under pressure. McNamara is about the metric you never took in the first place.

	McNamara fallacy	Goodhart's law	Campbell's law
What it names	Measuring only the easy things and ignoring the rest	A measure that stops being good once it becomes a target	A high-stakes metric that corrupts the process it watches
The core failure	The unmeasured is treated as nonexistent	The measured decouples from the goal	The measured corrupts the underlying work
Who is at fault	No one; it is a blind spot, not a shortcut	People optimizing the proxy instead of the goal	Stakes high enough to bend the work out of true
Reach for it when	The thing going wrong was never on a chart	A once-useful number turned into theater	The work itself got worse chasing a number

Put plainly: Goodhart's law describes what happens when a good measure becomes a target and people start optimizing the number instead of the thing. Campbell's law sharpens that for high-stakes settings, where the pressure does not just corrupt the number but corrupts the actual process underneath it. The McNamara fallacy is upstream of both, and in a sense broader: it is the decision, made long before anyone games anything, to only look at what is countable. All three are species of the same genus, the family of ways a reward or a metric produces the opposite of what you intended. When you are diagnosing a decision gone wrong, the question that separates them is simple. If a number got gamed, you are looking at Goodhart or Campbell. If the problem was never a number at all, you are looking at McNamara.

How to avoid the McNamara fallacy

The fix is not to measure less, and it is certainly not to abandon metrics for vibes. It is to stop letting the measured half of reality silently define the whole of it. Most of the discipline comes down to deliberately keeping the unmeasured in view, and running your important decisions through a few questions before you trust the dashboard.

Ask this before you decide	Healthy answer	McNamara-trap answer
What matters here that is not on the dashboard?	We can name it, and we look at it directly	If it mattered, it would be a metric
How did we handle the uncountable factors?	We weigh qualitative evidence alongside the numbers	We dropped them or gave them a fake number
Could this look green while the real thing fails?	Yes, and we watch the real thing on purpose	The numbers are good, so we are good
Where does our judgment come from?	Metrics plus people who see the work up close	Whatever the report says
What would we miss if we only read the chart?	We have asked, and we check for it	We have not asked

The most practical version of this is a habit, not a tool: for every dashboard you rely on, write down what it deliberately leaves out, and keep that list next to the numbers. The point of naming the unmeasured is not to pretend you can count it. It is to keep it from vanishing. A factor you have written down as "important, not measurable" survives step four; a factor nobody wrote down does not. This is the same move that separates teams who reason past the first visible consequence from teams who stop at the number in front of them, and it is cheap insurance against being blindsided by a reality your instruments were never pointed at.

Qualitative evidence is not a lesser form of data. A skip-level conversation, a careful code read, a customer who tells you why they are leaving, an engineer's quiet sense that the estimates have stopped meaning anything: these are signal, often the earliest and most important signal you will get. The McNamara fallacy teaches you to discard them because they do not arrive as a number. The discipline is to treat "we cannot measure this cleanly" as a reason to pay closer attention, not permission to look away.

The judgment that got lost

Here is where a one-time blind spot hardens into a permanent one. The qualitative context behind a decision, the reasons a number was only ever a rough proxy, the caveats everyone understood at the time, lives in people's heads and in scattered notes, and it is exactly the kind of knowledge that decays the moment nobody is actively holding it. The team that chose to track velocity knew, on day one, that it was a crude stand-in for throughput and said nothing about quality. A year later that caveat is gone, the number has been promoted to the truth, and new people read the chart as though it measured everything worth measuring.

The defense is to write the unmeasured down and keep it next to the measured. When you stand up a metric, record what it is a proxy for, what it cannot see, and what qualitative signal you will watch alongside it. That belongs in the same durable record as the decisions it informs, not in a Slack thread that scrolls away by Friday. Try Scribelet free and keep the context behind each number, the part that cannot fit in the cell of a spreadsheet, somewhere it will still be legible to the person who inherits your dashboard. Scribelet's background agents even re-check what you have written against the world over time, so the reasoning behind a metric does not quietly rot while the metric keeps getting reported. A number whose limits are written down stays a tool. A number whose limits have been forgotten becomes the entire map, and that is McNamara's fallacy waiting to happen.

Reading the McNamara fallacy correctly

The overcorrection is to swing to the opposite extreme and distrust measurement altogether, which is its own failure and usually a worse one. Numbers are not the problem. Running an organization on gut feeling and anecdote is how you get the mirror-image disaster, where the loudest voice wins and nothing is ever checked. The lesson of the McNamara fallacy is narrower and more useful than "numbers lie." It is that numbers are a partial view, and a partial view presented as a complete one is where the danger lives.

So the standing question the McNamara fallacy hands you is not "do we have enough metrics?" but "what are we deciding this on, and what did we leave out because it would not fit on the chart?" Measure what you can, name what you cannot, and keep the second list in front of you with the same seriousness as the first. Try Scribelet free and let it hold the qualitative half of your decisions, the context and the caveats and the things that only a person who saw the work would know, so the unmeasured stays visible instead of quietly disappearing until the quarter it comes due.