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