“Yes, you can measure software developer productivity” — the good bits

McKinsey’s recent article promoting their productivity management framework has resulted in a mountain of aggrieved commentary in the tech community.

A useful critical analysis by Kent Beck (and G. Orosz) exists here: https://tidyfirst.substack.com/p/measuring-developer-productivity

But, I also think the article has lots of good things to say. I’m grateful and excited that McKinsey are forcing these issues into the spotlight.

“leaders need to know they are deploying their most valuable talent as successfully as possible”

Most of us agree that techniques for managing of developers desperately need improving. And, even more so, strategic leadership of development organisations. This truth can’t be over-emphasised, and I’m thankful that McKinsey are highlighting it.

“Software development is also highly collaborative, complex, and creative work”

Senior leaders I talk to sometimes fall into one of two polarised camps.

The first group are the “frustrated outsiders”. This group think of software engineers as a management problem. They see an obvious lack of productivity, but see it as due to a weak pool of engineering talent. They struggle to hire people with a mature, disciplined attitude.

The second group are the “uncertain pragmatists”. This group knows that software engineering is a distinctive discipline. They don’t feel qualified to define and support developer productivity. They try to outsource the problem to a technical CTO specialist. They stay very hands-off.

These two extremes don’t help matters. McKinsey is correct to point out the distinctive nature of software development. But, they’re also correct to assert that leadership teams have to engage.

How to think about engineering

They follow on with some suggested questions to consider:

What are the impediments to the engineers working at their best level?

How much does culture and organization affect their ability to produce their best work?

How do we know if we’re using their time on activities that truly drive value?

How can we know if we have all the software engineering talent we need?

This is an excellent initial set of questions for leaders to consider. Too many organisations fail to get to grips with these issues. As a developer, I’ve had my time wasted too many times. As a manager, these considerations are central to my daily thinking.

“while metrics such as story points completed or interruptions can help determine optimization, they require more investigation to identify improvements”

Again, I’m glad to hear McKinsey undermining simplistic frameworks. If McKinsey’s article leads to more organisations thinking for themselves, I’m in favour. But, if they replace one simplistic framework with another, then I’m not.

“Are there specific opportunities to improve how you deliver products and what they are worth?”

I wish more leadership teams would focus on this question. They spend so much time preserving the status quo. Management teams develop echo chambers that lose touch with reality. Focusing on specific opportunities for improvement is ideal. Even better, adopt an experimental approach. Try lots of new things and test what works. Open the doors to new people and new ideas and measure outcomes.

“building products directly generates value and is what most developers are excited to do”

From my experience, McKinsey are being optimistic here. I choose to believe what this statement on a daily basis. But I’m sometimes disappointed by how little developers care about what gets built. I wish all developers cared as much about the outcome of what they do as they do about the art of engineering.

“developers… provisioning infrastructure, running manual unit tests, and managing test data”

This is a real problem I’ve run into — in companies both small and large. For different reasons at different scales, inefficient, legacy approaches to Ops persist. Real, team-integrated DevSecOps, in particular, still seems to be far from the norm. McKinsey are right to highlight this point.

“…standard working practices more thoughtfully for cross-team collaboration”

Another archaic (and anarchic) problem which crops up far too often. Teams often get frustrated with lack of coherence. Often this is a problem of weak leadership. Cross-team collaboration ends up suffering. Good teams go it alone and leave struggling ones behind in the dust. This is something we need to improve.

“we see two main types of missteps occur: misuse of metrics and failing to move past old mindsets”

I love this. Misuse of metrics and failing to move past old mindsets. These two anti-patterns crop up again and again. People want a simple answer. They don’t want to change. They want a metric they can game. Change of mindset is difficult, but it’s what we need.

“Measuring productivity at a system level enables employers to see hidden friction points that impede that work and creativity”

Weak leaders tend to jeopardise system (level) thinking. Teams can compensate at the team level (or lower). But if teams must rely on weak leaders to tie them together, it’s game over. Books such as The Radical Enterprise talk about how to remove those needs. But where that hasn’t happened, the demands on leadership teams are extreme. Friction points at a system level represent a hard limit on what those caught up in the system can achieve.

the need to elevate the conversation about software developer productivity to C-level leaders outweigh the impediments to doing so … Learn the basics. All C-suite leaders who are not engineers or who have been in management for a long time will need a primer on the software development process and how it is evolving.

I agree. Too many C-level leaders see software development as an unfortunate necessity. They still try to push it “down” the organisational hierarchy. They use proxy metrics rather than getting to know the nuts and bolts for themselves. That doesn’t work these days. C-level leaders need to get with the program or get out of the way.

A human approach

even the best approaches, no matter how comprehensive, will not be a silver bullet

It’s nice to see McKinsey aknowledge that approaches such as the ones they discuss are not a silver bullet. DORA, SPACE, and whatever McKinsey come up with are useful. But, they’re not enough on their own. The real challenge is to change leaders’ mindsets.

measuring productivity should ideally create transparency . . . [and] benefit both those individuals and the company as a whole

I hope that McKinsey’s use of their new framework aligns with the most positive and hopeful components of their article.