Goodhart's Law on Engineering Teams

A lot of organizations want engineers to act as product owners, but they still measure them like typists. We expect developers to figure out what not to build. Then performance reviews roll around, and the conversation reverts entirely to PR volume and velocity.

AI makes code generation cheap, which pushes the baseline expectation for volume up. But the actual bottleneck hasn’t moved. Figuring out what to build still takes deep context and time. The real work is deciding whether a feature should exist at all. If we measure output by PR count while demanding product ownership, the system breaks.

A peer at another company recently shared a maddening example. They work in a heavily regulated industry, and they asked management to wait for legal approval before writing code, precisely to prevent wasted effort. Management said no, keep coding. The result: ten times in one month, completed PRs got blocked by compliance and were never merged.

The proposed solution was pure chaos. Management told the team to relabel the blocked PRs as “prototypes”, which cleanly bypassed the metrics dashboard.

Writing code before getting legal clearance isn’t agile. It is just burning money. And relabeling a blocked PR to sneak it past compliance fundamentally misunderstands why those guardrails exist.

This is Goodhart’s Law playing out in real time. When a measure becomes a target, it ceases to be a good measure. The gamers get rewarded, while the people actually holding the product together get questioned on their velocity.

Pumping out low-context PRs leaves a wake of technical debt that eventually explodes. Think of that quick PR that hardcoded a single currency just to hit a deadline. Six months later, the team spends weeks rewriting the entire billing service to support a new market.

For engineering leaders, the fix is structural. Stop confusing motion with progress. Evaluate the impact of decisions, not the volume of keystrokes.

For engineers on the ground, the pragmatic survival move is making your invisible work visible. If you spend three days figuring out what not to build, document that as a massive win. Put it in writing. Show the blast radius of the bad ideas you stopped. The value you provide by understanding the why before the how is what actually keeps the lights on.

And if an organization penalizes you for prioritizing product survival over a PR dashboard, the system was fundamentally broken anyway.