Measuring Developers Productivity... McKinsey what's the point?

[@gianpaolocunha]

Making simple. Whoever wants measure a developer, don't know anything about development work. Good amount of work is in their mind until it brings the solution. If it is a simple change... maybe is double in some sense.... but things that brings value comes from developers mind/brain... Your points are good too!!

[@istovall2624]

Goodhart's Law : "When a measure becomes a target, it ceases to be a good measure."

[@denisshaughnessy2651]

Agreed. Measuring lines of code by itself is meaningless, but that’s not a reason to reject metrics altogether- it just means you have to use metrics in an intelligent way.

[@OutOfDevOps]

Do you have examples of metrics that can be used. For me the most important aspects of developers are creativity, problem solving and communication.

[@c_kemper]

Instead of focusing on meaningless metrics companies should focus on healthy team topologies…

[@denisshaughnessy2651]

It seems like a cop out to me. Why should software developers be the only workers in the world not to be subject to some form of productivity metrics? All of the arguments you have made can be dealt with by applying and assessing metrics with a small amount of intelligence. You say that developers would game any targets- if you assume all developers have such a cynical work ethic, then presumably they all game the absence of metrics by doing as little as possible.

[@OutOfDevOps]

Thanks @denisshaughnessy2651 for your comment! I believe there are better tools to measure productivity. OKRs, for example, are a more effective approach in my opinion. Measuring productivity based on lines of code (LOC) goes against best practices. Writing more code doesn’t always equate to better outcomes; in fact, the more code we add, the higher the chance of introducing bugs, and the more tests we need to write and maintain. If I can solve a problem with fewer lines, that’s a win. What really matters is the elegance of the solution, the readability of the code, and collaboration with other engineers.

[@IronCandyNotes]

You can't manage what you can't measure! MUHAHAHA. Wait how did we make it before numbers? Is logic without numbers possible? Arghhh...

[@OutOfDevOps]

Numbers are just a way to represent measurements. Without numbers you can still measure. But without measuring your previous X, how do you know if you’re getting better at it or not? I may have not fully understood your comment.

[@IronCandyNotes]

@@OutOfDevOps It is this stupid mantra about managing only being possible with metrics that turns a lot of otherwise intelligent human beings in management positions into draconian game masters that want to incentivize you the creative on a micro level to do the right thing. They don't know anything real but they know that there is some correlation between output and success so the output needs to be bigger and faster. Add to that the generic management approach that thinks domain knowledge is irrelevant and you could put a cockroach in charge as it has the same objective function of maximizing some gain short term that feels right instead of the human planning, conceptualizing, remembering stuff and winning in the long run over all other animals.

[@OutOfDevOps]

I see what you mean, I have read stories about customers loyalty metrics improving by simply hiding the ‘unsubscribe’ button 🤦‍♂️. I think this is the problem with most definitions/mantras, they don’t capture every possibility.