Everything Wrong With Developer Productivity Metrics

Posted by aviator_co@reddit | programming | View on Reddit | 19 comments

The DORA Four were meant as feedback mechanisms for teams to improve, not as a way to compare performance across an entire org. Somewhere along the way, we lost that thread and started chasing “productivity metrics” instead.

Martin Fowler said it best: you can’t measure individual developer productivity. That’s a fool’s errand. And even the official DORA site emphasizes these aren’t productivity metrics, they’re software delivery performance metrics.

There’s definitely an industry now. Tools that plug into your repos and issue trackers and spit out dashboards of 40+ metrics. Some of these are useful. Others are actively harmful by design.

The problem is, code is a lossy representation of the real work. Writing code is often less than half of what engineers actually do. Problem solving, exploring tradeoffs, and system design aren’t captured in a commit log.

Folks like Kent Beck and Rich Hickey have even argued that the most valuable part of development is the thinking, not the typing. And you can’t really capture that in a metric.

[-]

elmuerte@reddit

If it is a number, it will be used to represent productivity.

If it is a number, it will be used in calculations.

If it is a number, it will be gamed. If the number is used in performance reviews, it will absolutely be gamed.

[-]

Big_Combination9890@reddit

Also known as Goodhart's law.

"When a measure becomes a target, it ceases to be a good measure".

[-]

koreth@reddit

“Our velocity is about 50 story points per 2-week sprint and we have postmortem meeting if we start falling below that number, but story points are definitely not a measure of time.”

[-]

findanewcollar@reddit

This is word by word what happened in a company I worked for minus postmortems. Dogshit micromanagers need to be hanged.

[-]

throwaway490215@reddit

We set up an 6 AI-agents that simulate: 1 PM, 3 devs, 1 QA, and 1 senior dev.

They're blasting through 650 story points per 2 weeks!

We're thinking of hiring an AI engineer that can write a reward-function so we can increase those numbers, but before we do we're going to check out if we can just set up an AI-engineer agent to do it for us.

[-]

grauenwolf@reddit

You should be held accountable for that. Imagine, only 50 story points for a long-running project. Six months in, a 50 point story is changing the text on the home page. It should take you all of five minutes, four of which is getting permission to correct the spelling.

[-]

dodeca_negative@reddit

Goodhart's Law etc obtains

I've seen it happen in real life and it's something to behold

mprbst@reddit

What's particularly annoying is the use of deployment frequency as a goal metric. Deployment frequency has a hard cut off, where beyond some limit more frequent deployments aren't useful, or even harmful.

It's just not beneficial to anyone to deploy every five minutes. It doesn't accelerate delivery meaningfully (no customer ever wanted that button all of five minutes earlier!). And it's really harmful for production stability, as it becomes increasingly difficult to attribute breakages to particular releases.

I'd argue similarly for lead time to production. For a significant product, you want a careful and measured rollout across dev, QA, and then individual canary stages and production clusters. You cannot do meaningful canarying in five minutes - so shorter lead time to production will be strictly worse (assuming you don't waste time on manual QA).

aviator_co@reddit (OP)

That's a great point about deployment frequency!
And it is discussed in the conversation - starts around 19:00.

And Adam gives a great piece of advice - to use metrics in pairs.

simonask_@reddit

The problem is way deeper than that.

Measuring productivity serves no other purpose than control. It’s something managers reach for when they lose the sense of connection with the thing their team is actually making.

My question is, what are you doing managing a team without a connection to each member of that team? Is your team not talking? Or are they not talking to you?

What exactly is the purpose of a manager or lead, if not to be deeply involved in the actual work? What other industry would ever even consider such a structure?

Successful teams are led by people skilled at the work, not people skilled at corporate pseudo-work. If your company is making software, this better go all the way to the top. Usually it doesn’t, and the industry sucks as a result.

bart007345@reddit

The team is in India.

Just had somebody tell me they measure individual productivity by frequency of commits. It's 2025 and I can't believe this still happens.

Coherent_Paradox@reddit

Luckily this can easily be scripted. Delivering 100k commits a week I'd expect a sizeable raise. Look how much business value we got from my 100k commits!

Ark_Tane@reddit

Oh god, I had a manger ask me to pull out data for the number of commits a sprint. (Fortunately not individuals, I'd have outright refused that) I didn't stay there much longer. It was precisely bullshit like that which was killing productivity, not the time wasted, but the lack of trust it communicated, and the constant focus on metrics, even at the expense of the outcomes they were a proxy for.

superwormy@reddit

Genuine question here -

If productivity metrics aren't the answer/aren't a good thing... how do you find and weed out the developers who aren't pulling their weight?

What is the metric or how do you find those people who are just slacking, while everyone else is pushing hard to move the company forward?

chorizodecaviar@reddit

Heuristics. Got to hire people who have education and know what they do based on their track record. You then use them to sniff out the non workers. Easy as that.

The problem? You need to pay them well and it requires a culture where their word has weight. If mgmt gives a crap about it, then they'll have no other option to switch to metrics and then we go back to square 1.

So - hire/fire based on gut feelings.

Exactly. Like it has been across history and across all other industries. Or do you think architects get told to sit down, pull up autocad and start being given designing challenges to do on the spot?

Now, if you think the gut feeling of a MSc in Comp Sci that has worked across multiple types of industries and companies and has actually pulled off projects is the same as that of a random HR recruiter or some PM: That's a whole different conversation.

Somewhere along the way, we lost that thread and started chasing “productivity metrics” instead