Folks, I need some help. Do you know any studies (ideally with numbers) about measuring developer productivity? One Company I am providing consultancy has this crazy idea to measure developer productivity with…number of commits. Seriously. What resonates well in this company is hard numbers & evidence. What I am looking for is articles or methodologies which are battle-proven & have case studies (ideally from financial institutions, but let’s treat that as a nice to have). I’ll be thankful if you share your notes :)

Metrics were part of last month's CNCF platform engineering content-club. Thos might help you: • Metrics That Matter - by Bryan Ross - Chief Therapy Officer • #6 - The Art of Measuring What Actually Matters in Platform Engineering | LinkedIn • DX Core 4: finally! Opinionated developer productivity metrics that speak business - Blog • Metrics At Altitude | Steve Fenton •

Looking good, thank you!

this is all great, but not based on science, afaik there is only one science based research stream working on the topic: Stanford

The team at DX have worked on this. This provides an overview. https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4/ "Productivity" isn't the best angle on successful teams. The DORA research shows that user-centric teams outperform other teams while having lower throughput, basically it's less records, more hits. https://dora.dev/research/2024/

I wonder how they measure executive productivity?

Problably the number of meetings ;) (joking. I have no idea)

Infinite numbers are hard to measure 😜

I was perhaps a bit flippant with my comment? I have little patience for command-and-control style of leadership compared to servant leadership. The way the question was framed smelled more like the former than the latter to me. I'd probably ask a bunch of questions that might annoy them, like what changes this might drive and why they thought it important.

I am going to ask, just…politely :) in my role it’s better not to annoy the customer too much, as I sincerily want to help them, not judge. The way they may see developers work today can also be a result of developers attitude during the good times, or promises from IT which were never met. I try to be a man in the middle, understanding both ways of seeing things

Developer productivity could be correlated with the delivery of features that meet quality, cost, and time expectations. However, measuring this is not straightforward—it requires integrating data from multiple systems and placing it in the right context. To better capture value, we should go further and link feature delivery to business or operational outcomes, such as improvements in user engagement, reduced support costs, or faster go-to-market timelines. A balanced approach should also consider team collaboration, code health, and developer experience to fully assess productivity.

I am after the retrospection. The results are obvious - when we had a flat structure, with teams making independent business decisions - quallity (incidents per changes), productivity (changes per developer) and time to market was the best