McKinsey is Talking about Developer Productivity, and That’s a Good Thing

A new article by McKinsey titled “Yes, you can measure software developer productivity” ruffled some feathers this past week. Many have reached out to me for my comments, so here you go:

Shubha, Matthew, and I co-founded Faros AI to transform engineering into a data-driven discipline.

We couldn’t abide by the lack of data to build a compelling business case for additional budget, headcount, infrastructure, or training.

We wanted to show others the value of all the great things our engineering organization had worked so hard for and delivered.

I wanted to be as effective a storyteller in the board room or in All Hands meetings as my peers in Sales and Marketing.

And that, my friends, is done with data.

What McKinsey Got Right

While we can debate a few of the minor statements in the article (see below), the thrust of it is on point.

Here are the key points McKinsey made that I fully agree with:

1. Optimizing our workforce’s productivity is indeed a critical task, exacerbated by current market conditions and the emergence of AI. It is also a continuous one. We better get good at it before machines are writing half our code.
2. The high amount of dissatisfaction, rework, and inefficiency reported by developers is a cause for change. Engineers shouldn’t want to work for companies that don’t take their productivity seriously. Working in an inefficient and sluggish environment with outdated processes and platforms — that are habitually ignored and neglected by senior management — that’s my definition of “soul-sucking”.
3. The C-Suite needs to understand the SDLC and how it’s evolving and what it needs. Many years ago (pre-Agile), a colleague of mine gave a timeline to a project manager who didn’t understand the SDLC... He told him he had three months of development followed by a month of QA. The project manager replied, “I need it sooner. Can you just develop it without bugs?”

Jokes aside, we do need a common language to communicate with our partners across the organization.

Every day I speak to organizations that are creating new teams or centers of excellence focused on engineering productivity, the developer experience, and platform engineering.

Often, we don’t just provide them with the technology and technical expertise to do that. We coach them on how to communicate the work they do to management, how to tactfully roll out the metrics internally, and how to plan for the incremental adoption of productivity metrics.

McKinsey speaks the language of the C-Suite well. If they can get executives to commit time and effort to removing friction from the engineering experience based on what the data is telling us, I am all for it.

What I Would Clarify…

There are a couple of points in the article that I would lend a nuanced opinion on:

1. Measuring productivity doesn’t necessitate an overhaul to how your systems and software are set up. You can get a rich set of metrics to baseline and benchmark an organization quickly and easily, without rearchitecting your tools and processes. That’s the data science we’ve developed at Faros.
2. Noncoding activities such as design sessions or dependency mitigation are not wastes of time. In fact, they are an essential part of the developer’s role at any level, and typically the more senior you get, the more time you spend architecting versus coding. That’s why crossing productivity metrics with HR information about role and tenure is crucial to drawing the right conclusions. We’ve designed Faros to be extensible to many data sources beyond traditional engineering telemetry — including HR, financial systems, and others — precisely to bridge this gap.
3. Relying on task management systems (like Jira) for data isn’t enough. While work management systems might seem the most natural place to get visibility into productivity, they are usually not the systems directly in the developer’s flow and are often inaccurate. A more precise picture emerges when you construct it from the full developer experience, which includes source control, CI/CD pipelines, quality, and incident management systems.

Don’t Throw the Baby Out with the Bathwater

Sure, folks might have a few remarks about some of the details in the article.

But overall, I am excited that McKinsey is helping elevate the importance of developer productivity metrics to their C-Suite audience. We’ve been trying to do the same, like in Shubha’s Forbes article It’s Time For Software Engineering To Grow Up.

If you care about developer productivity, we are better off today than we were a week ago.