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 by numerical targets leads you down a road of incorrect assumptions and information, and is ultimately a losing battle.

Depending on the job, it can be impossible to accurately measure impact and productivity by looking at metrics.

This problem is industry agnostic. You can find apocryphal stories from the olden days, like the Soviet Shoe Factory Principle. There are articles from all sorts of industries.

It's a topic that has extensive literature written about it, there are so many famous quotes, and even "laws" written about it, like Goodhart's Law

So why is it still so common to to come across people trying to measure the unmeasurable?

Is it laziness, foolhardiness, inexperience, or not learning from the past?

Gaming the system

Take tracking hours worked for example. If someone is paid per hour, they have a very strong incentive to take as long as possible to complete the job.

They're not getting paid for the job, they're getting paid for the hours. So of course stretching it out to work more hours is beneficial.

The same problem is common in IT support roles. When performance is judged by the number of tickets closed, you can spot it instantly. Agents will ask if they can close your ticket, or worse, they will close it without confirmation and add a note telling you to open a new ticket if the issue is not resolved.

The goal stops being “fix the problem” and becomes “close the ticket,” regardless of whether the customer is actually helped.

Unintended Consequences

This is when an incentive causes results that are undesirable and contrary to the original intention of the incentive. Some historical examples:

"The Cobra Effect" - The British government was concerned by the number of venomous cobras in Delhi, so they put a bounty on dead cobras. This led to people breeding cobras so they could turn them in for the reward. Once the breeding was found out, the government stopped the program. Since the breeders couldn't turn the cobras in for money anymore, they just released all of them, making the cobra problem much worse than it started.

"The Great Hanoi Rat Massacre" - similar story, the French colonial government paid a bounty for dead rats, accepting a severed rat tail. So people would catch rats, cut off their tails, and release them as to produce more rats. Besides the fact that this had no effect on reducing the rat population, it also occured during a global plague pandemic, and a ton of people handling rats certainly did not help.

There are countless examples of Perverse Incentive

Counterproductivity

Tracking hours worked, lines of code written, etc, does not incorporate the number of hours that was spent thinking about a problem, testing it out. Nor does it take into account the actual impact of work.

Jobs that involve creative or knowledge work, such as programming, are affected by this the most because there is often no direct one-to-one relationship between the effort put in and the value produced.

I have spent all day thinking about a specific implementation and then writing a few lines of code, resulting in a highly used, revenue-generating feature. I have spent hours working with other developers, helping them through issues, affecting multiple codebases positively.

Conversely, I have made dozens of commits with thousands of lines of code all 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.

And this is the core issue. The people designing the metrics will try to work around these challenges. Believing they are being clever, they create elaborate plans to “track the right metrics,” convincing themselves that one number can somehow be more meaningful than another.

Track lines of code and you will get bloated, unnecessary code. Track commits and you will see dozens of tiny, meaningless commits. Use Scrum and track sprint velocity, and suddenly the backlog is full of oversized stories. Track burndown charts, and every task gets split into a flood of tiny two-point items.

Tracking The Right Thing

"I work for the company, not the customer" a developer said to me during a conversation about metrics and "delivering value to the customer".

I think this line of thinking is a huge problem in the industry. Not specifically for dev work, but in general. Your clients/customers are why your job exists. Everything you do is in service of the product.

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.

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

The Solution

The best way to track performance and productivity is the one nobody likes to hear. It requires significant effort and cannot be reduced to a simple set of metrics. It will change day to day, and person to person.

It's often best to start with a holistic view of the organization. Go as high up as you reasonable can. What are you all doing there? Why are you all working together? What is the product? Who is the product for? What work needs to be done? Where is value derived? How is value created?

Once you can answer all of those questions, then you can start getting more specific. What needs to be accomplished this quarter/month/week/day? What needs to be done to reach those goals?

What's Important

The intermediate steps are irrelevant to anyone outside the team. Within the team, they can be useful for identifying areas to improve, ensuring processes are followed, and coordinating work. But if you are not part of that team, you should not care.

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 that assigns these metrics needs to be someone who is intimately aware of how this all works. They need to be close to the work.

Someone who isn't probably won't understand all of the inner working and minutia of the day to day work of meaningful work of someone writing code. Honestly, someone without direct experience in a role should not be managing that role at all.

Shortcut

If you want to skip the hard work of introspection and long-term planning, you can take a shortcut. Decide what needs to be done in two weeks, check in at the end of week one for progress, check again at the end of week two for completion, and 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. How you measure it is entirely up to you and your team, and it will vary for every team and product.

The important part is to focus on outcomes that matter, not vanity numbers that are easy to count but meaningless in practice.

By centering measurement on real value delivered, you keep attention where it belongs, on solving problems, creating impact, and making meaningful progress.