Against Optimization

Let me tell you about a team I once worked on that destroyed itself by trying to be excellent.

We were a small engineering team — eight people — building a product that we cared about. The code was good. Not perfect, but good in the way that matters: it was understandable, it was honest about its limitations, and when something broke, you could find out why in a reasonable amount of time. People helped each other. The senior engineers spent time with the juniors, not because anyone told them to, but because they remembered what it was like to be confused, and because explaining things to someone else is one of the best ways to understand those things yourself.

Then we got a new director, and the new director believed in metrics.

Within three months, we were tracking velocity, cycle time, pull request throughput, code review turnaround, and something called "developer satisfaction" which was measured quarterly with a survey. Every metric went up. Every single one. We were, by any measurable standard, a better team than we had been before.

And the product got worse. The code got worse. The people got worse — not as engineers, but as colleagues. The senior engineers stopped mentoring the juniors, because mentoring doesn't produce story points. The careful code reviews that used to catch subtle design problems became rubber stamps, because thorough reviews slowed down PR throughput. The conversations in front of the whiteboard — the ones where someone would say "wait, I think we're solving the wrong problem" — stopped happening, because those conversations didn't fit into any sprint.

Everything measurable improved. Everything that mattered degraded.

This essay is about why.

The law that governs all metrics

In 1975, the British economist Charles Goodhart articulated a principle that should be carved above the entrance to every office in Silicon Valley: "When a measure becomes a target, it ceases to be a good measure."

This is usually called Goodhart's Law, and its implications are so profound and so consistently ignored that I sometimes wonder if there is a second law — Goodhart's Second Law — which states that knowledge of Goodhart's Law does not prevent you from falling victim to it.

Here is what Goodhart understood. A metric is useful because it correlates with something you care about. Developer velocity correlates with productivity. Test coverage correlates with code quality. Customer satisfaction scores correlate with how customers actually feel. The correlation is what makes the metric valuable.

But the moment you turn the metric into a target — the moment you start rewarding people for increasing it, or punishing them for letting it drop — you break the correlation. Because people are intelligent. They will find ways to increase the metric that don't involve increasing the thing the metric was supposed to measure. They will game the system, not because they are dishonest, but because they are responding rationally to the incentives you have created.

This is not a failure of people. This is a failure of the system that substituted a number for the thing the number was supposed to represent. The map has been confused with the territory, and the territory is being bulldozed to match the map.

What James C. Scott saw from above

The political scientist James C. Scott spent decades studying a phenomenon he called "legibility" — the process by which states, corporations, and institutions simplify the complex reality of the world in order to make it manageable.

In his masterwork Seeing Like a State, Scott traces how this impulse toward simplification has produced some of the greatest disasters in human history. The scientific forestry movement in 18th-century Prussia, which replaced diverse, messy, ecologically rich forests with neat rows of Norway spruce — forests that were easy to measure, easy to manage, and easy to harvest. For one generation, the yields were spectacular. Then the monoculture forests began to die. Without the biodiversity that made the original forests hard to measure, the soil degraded, the pest populations exploded, and the beautiful, legible, optimized forests collapsed.

Scott's insight is that legibility is not neutral. The act of making something measurable changes the thing being measured. The Prussian foresters didn't just measure the forest differently — they remade the forest to match their measurements. And in doing so, they destroyed the illegible qualities — the mycorrhizal networks, the undergrowth, the complex interspecies relationships — that actually kept the forest alive.

This is exactly what happens when you optimize a software organization for metrics. You don't just measure the team differently — you remake the team to match the measurements. And in doing so, you destroy the illegible qualities — the mentorship, the careful thinking, the willingness to say "I don't know" — that actually produce good software.

The counterproductivity of schools

The philosopher Ivan Illich coined the term "counterproductivity" to describe the point at which an institution begins to undermine the very purpose it was created to serve. Schools, designed to produce learning, begin to produce the inability to learn without schools. Hospitals, designed to produce health, begin to produce dependence on medical systems. Transportation systems, designed to save time, begin to consume more time than they save (when you account for the hours of work required to afford the car, the insurance, the fuel, the roads).

Illich's most devastating example was education. What happens, he asked, when you optimize a school for measurable outcomes? You get teaching to the test. Students learn to produce the right answers without understanding the questions. They learn to write essays that satisfy rubrics without learning to think. They learn to perform knowledge without acquiring it.

And the teachers — the good ones, the ones who entered the profession because they believe that education is the most important thing a society does — are caught in an impossible bind. They can do what the metrics demand, which means sacrificing the unmeasurable qualities that make education real: curiosity, confusion, the willingness to sit with a problem long enough for it to reshape your thinking. Or they can do what they know is right, which means watching their numbers drop and their reviews suffer and their careers stall.

This is the cruelty of optimization culture. It doesn't just demand that you do the wrong thing. It demands that you do the wrong thing while believing it's the right thing, because the numbers say so.

The newsroom and the feed

The same pattern is playing out in journalism, and the consequences are visible to anyone who reads the news.

When newspapers were funded by subscriptions and advertising, the metric that mattered was circulation, and circulation was a reasonable (if imperfect) proxy for quality. People bought newspapers that they found informative and trustworthy. The metric and the value were imperfectly but genuinely correlated.

When journalism moved online, the metric shifted to engagement — clicks, shares, time on page. And engagement turned out to be correlated with something very different from quality. Engagement is correlated with outrage, with novelty, with the confirmation of existing beliefs. Optimizing for engagement means writing headlines that provoke rather than inform. It means covering controversy rather than complexity. It means giving people what they want to click on rather than what they need to know.

Every journalist I know understands this. Every editor understands this. And yet the optimization continues, because the metrics demand it, and the metrics are the basis on which decisions are made, and the decisions are the basis on which careers survive. The institution has become counterproductive in precisely Illich's sense: journalism optimized for engagement is producing the inability to be informed.

The software case

Let me return to software, because this is where I live and where I see the damage most clearly.

The modern software organization is drowning in metrics. We measure velocity, throughput, deployment frequency, mean time to recovery, change failure rate, lead time for changes. The DORA metrics. The SPACE framework. OKRs and KPIs and SLAs and SLOs. We have more data about how we work than any generation of craftspeople in history.

And yet. Ask any senior engineer — pull them aside, close the door, speak off the record — and they will tell you that the quality of software has not improved in proportion to our ability to measure it. In many cases, it has declined. Not because engineers are less talented, but because the measurements have displaced the judgment.

Here is a specific example. Code review is one of the most valuable practices in software engineering. A careful review catches bugs, yes, but more importantly, it transmits knowledge. It is the primary mechanism by which a team develops a shared understanding of the codebase. It is mentorship in practice. It is the place where a senior engineer can say, "This works, but let me show you why this approach will cause problems in six months," and the junior engineer can learn something that no documentation could teach them.

But code review is slow. It is unmeasurable in its most important dimension. You cannot quantify the insight that a reviewer transfers to a reviewee. You cannot measure the bug that was never written because a review conversation changed someone's mental model. You can only measure the thing that code review costs: time.

So what happens when you optimize for PR throughput? Reviews get faster. They get shallower. The comments shift from "have you considered this alternative approach?" to "LGTM." The metric improves. The practice dies.

What cannot be measured

Here is where I want to be precise, because I am not arguing against measurement. Measurement is essential. You cannot manage what you cannot see, and metrics help you see. The problem is not measurement. The problem is optimization — the systematic restructuring of a practice around its measurable outputs, at the expense of its unmeasurable substance.

Some of the most important things in any practice are unmeasurable. Not unmeasurable in the sense that we haven't yet found the right metric — unmeasurable in principle, because they are qualities, not quantities, and the attempt to quantify them destroys them.

Trust. You can survey for it, but the survey measures people's willingness to report trust, which is not the same thing. Real trust — the kind where an engineer says "I made a mistake and I need help" — exists only in the absence of measurement. The moment you measure it, you incentivize the performance of trust rather than its practice.

Taste. The ability to feel, before you can articulate why, that a design is wrong. That an abstraction doesn't fit. That a solution, while technically correct, is going to create problems that no one can yet name. This ability is developed over years and transmitted through mentorship, and it cannot survive in an environment where every decision must be justified by data.

Care. The willingness to spend an extra hour on a piece of code not because anyone will notice, but because you know it's right. The refactor that makes the code clearer for the person who will maintain it after you leave. The documentation that you write not because it's in your OKRs, but because you remember what it was like to be lost in a codebase without a map.

These are the qualities that distinguish good software from software that merely passes its tests. And they are precisely the qualities that optimization culture destroys, because they cannot be seen by the instruments that optimization culture uses to see.

A meditation on unmeasurable work

I want to end with something that I have been thinking about for a long time, and that I find difficult to articulate — which is perhaps a sign that it matters.

The most important work I have ever done — the work that I am most proud of, the work that I believe will outlast me — is work that never appeared in any metric. The afternoon I spent with a junior engineer, not writing code, just talking about how to think about distributed systems. The weekend I spent rewriting a module that worked perfectly well, because I knew that the person who would maintain it after me would need it to be clearer than it was. The document I wrote about a system's history — not its architecture, but its history — why certain decisions were made, what alternatives were considered, what we learned from the things that went wrong.

None of this produced story points. None of it moved any dashboard. If you looked at my metrics for those weeks, you would see a dip. A less productive engineer. A less efficient team member.

But I believe — I know — that this work mattered more than the features I shipped and the bugs I fixed and the velocity I maintained. Because this work was about care. And care is the thing that optimization cannot see and cannot produce and cannot survive without.

Ivan Illich wrote that the opposite of a commodity is a gift. A commodity is something produced for exchange, measured by its market value. A gift is something offered freely, measured by nothing, valuable precisely because it refuses measurement. The most important work in any craft is gift work — work done not because it is incentivized, but because it is right.

Goodhart's Law tells us that when a measure becomes a target, it ceases to be a good measure. But there is a deeper truth beneath the law: some things should never be measured at all. Not because they are unimportant, but because they are so important that the act of measurement diminishes them.

The care you take with your code. The patience you show a colleague. The thought you give to the person who will read your work after you are gone. These are not optimizable. They are not scalable. They are not metrics.

They are the work.

And they are enough.