Productivity Metrics Are Pointless

Tell me how you will measure me, and I will tell you how I will behave.

-- Eli Goldratt

In almost every job, measuring productivity through numerical targets leads to distorted incentives, flawed assumptions, and ultimately undermines the very thing you were trying to improve.

This is not a new insight. The same pattern repeats across centuries and industries — the Soviet Shoe Factory Principle is a classic apocryphal story, and the problem turns up across all sorts of fields. There is extensive literature on it, famous quotes from nearly every era, and even a formal law named after it: Goodhart's Law

So why does this keep happening? Is it laziness, inexperience, or a stubborn refusal to learn from history?

Gaming the system

Take tracking hours worked. If someone is paid by the hour, they are incentivized to take as long as possible to complete the job. They are not being paid to finish, they are being paid to keep going. Stretching the work out is not laziness, it is a rational response to the incentive structure put in place.

The same thing plays out in IT support. When agents are judged by tickets closed, you can see it immediately. They will ask if they can close your ticket before the problem is actually resolved. Or worse, they will close it without asking and leave a note saying to open a new one if the issue comes back.

The goal shifts from "fix the problem" to "close the ticket", and the customer ends up not being helped.

Unintended Consequences

Sometimes the problem is not just people gaming the system, the incentive itself quietly steers everyone toward exactly the wrong outcome. A few well-known examples:

"The Cobra Effect" - The British colonial government, concerned about the number of venomous cobras in Delhi, offered a bounty for dead cobras. Locals responded by breeding cobras to collect the reward. When the government discovered this and ended the program, the breeders had no reason to keep their stock, so they released them all. The end result was a cobra population that was higher than before the program began.

"The Great Hanoi Rat Massacre" - The French colonial government tried the same approach with rats in Hanoi, paying a bounty per severed rat tail. People quickly figured out they could catch a rat, cut off its tail, and let it go, keeping the rat alive and producing more. This also happened during an active plague pandemic, which made the surge in people handling rats especially unfortunate.

These are not fringe cases. There is an entire catalog of Perverse Incentives that follow the same pattern: well-intentioned interventions that make things measurably worse.

Counterproductivity

The deeper issue with tracking things like hours worked or lines of code is what those numbers leave out. They do not capture the time spent thinking through a hard problem before writing a single line. They ignore the conversation that unblocked a colleague, or the quiet refactor that saved the team months of pain down the road.

Knowledge work does not have a clean one-to-one relationship between effort and output.

I have spent an entire day working through an implementation in my head and then written a handful of lines which became a heavily used, revenue-generating feature. I have also spent weeks churning out commits, thousands of lines of code, for something nobody ended up using.

If you only tracked lines of code in any of those scenarios, you would end up with the opposite impression of the actual value of my work.

When people try to work around this, they get creative about what they measure. But every new metric gets gamed the same way, because the incentive never disappears. Track lines of code and you get bloated, unnecessary code. Track commits and you get a flood of tiny, meaningless commits. Use Scrum velocity and suddenly the backlog is full of artificially inflated stories. Track burndown charts and every task gets split into a pile of two-point items.

Tracking The Right Thing

A developer once said to me, during a conversation about delivering value to customers: "I work for the company, not the customer."

This line of thinking is a huge problem in the industry. Your customers are the reason the company exists. Without them, there is no product, no paycheck, no team. Everything ultimately traces back to the people using what you build.

The people that pay you do not care if your code is clean or clever. They don't care if you completed 25 story points this sprint when you only committed to 20. Your CEO is not reviewing your PR, and the customer is not sitting in on sprint retrospectives. They don't care. They do care about the final product.

The most important thing is delivering value. How you track that is the crux of the issue.

The Solution

The honest answer to "how do you measure productivity correctly" is not what most people want to hear. There is no clean formula. It takes genuine judgment, changes depending on the work, and cannot be reduced to a dashboard.

It's often best to start with a holistic view of the organization. Zooming out as far as you reasonably can. What is the product? Who is it for? What problem does it solve? Where does value actually come from? Once you can answer those questions clearly, you can start getting more specific. What needs to happen this quarter, this month, this week?

What's Important

The intermediate steps of sprints, story points, and burndown charts are coordination tools, not success metrics. They are useful inside the team for staying organized and spotting friction. They mean nothing to anyone outside of it.

But if you're not a part of the team, you don't care. If you need a specific feature, why are you even thinking about sprints, story points, commits, etc. It's like a homeowner caring how many times their plumber turned a wrench. If they fixed the leak and didn't damage your house, they accomplished the job.

Who Cares

The person assigning and interpreting these metrics needs to actually understand the work. Not abstractly, but closely. Someone who has never shipped production code is going to misread almost every signal that comes out of an engineering team. They will optimize for the wrong things, miss what actually matters, and build incentive structures that make the situation worse.

This is not purely a metrics problem. Someone without real experience in a role probably should not be managing that role.

Shortcut

If the full strategic exercise feels like too much, here is a practical alternative. Decide what needs to be done in two weeks. Check in at the end of week one. Check again at the end of week two. Then follow up in week three because you already accounted for the fact that nobody can accurately estimate how long something will take.

Value

Track value. What that looks like will be different for every team and every product, and that is fine. The point is to focus on outcomes that actually matter. Did we solve the problem, did it make a difference? Instead of numbers that are easy to count but tell you nothing useful.

The metrics that are easiest to measure are usually the least meaningful. The ones worth caring about take more work to define.