McKinsey is *Still* Talking about Engineering Productivity, and That’s a Good Thing

Updated: August 14, 2024

Original post: August 24, 2023

McKinsey is *Still* Talking about Engineering Productivity, and That's a Good Thing

Just under a year ago, I responded to the McKinsey engineering productivity article titled “Yes, you can measure software developer productivity.” The article ruffled a lot of feathers in the engineering community, but while a couple of points have been softened, in principle McKinsey doesn’t appear to be backing down.

Author Chandra Gnanasambandam released an updated take on the topic this past May, where he double-downs on McKinsey’s positions on measuring software engineering productivity. And I have to say, I’m happy to see it. I also felt it fitting to update my original piece with additional insights I’ve gained over the past year.

As I noted in my original response, Shubha Nabar, Matthew Tovbin, and I co-founded Faros AI to transform engineering into a data-driven discipline. McKinsey’s strongest critics were those who view software development as an art, exempt from the scrutiny of CFOs and corporate strategists. We have always taken a different approach.

As senior managers at LinkedIn, Microsoft, and Salesforce, we were forced to become experts at building business cases for additional budget, headcount, infrastructure, or training. We had to demonstrate engineering’s accomplishments and impact on corporate outcomes through data-driven narratives. We had to become adept at justifying engineering spend, headcount, and efficiency to the C-Suite and the Board.

But it was never easy to pull together the data or insights we needed, hence Faros AI was born. And I have to say, our timing was perfect.

Engineering has become one of the most expensive and most complex corporate functions. The business of engineering requires a pragmatic approach to maximizing ROI from that investment. Both DORA and McKinsey’s research finds a strong connection between software excellence and business success, including revenue, profitability, market share, and customer satisfaction. Thus, an organization without a top-down approach a-la McKinsey’s engineering productivity framework cannot rise to the challenges of the day, including the most recent challenge of successfully incorporating AI in our products and engineering workflows.

So what’s changed in the last 12 months? Only good things.

We launched several new engineering intelligence modules for Investment Strategy, Developer Experience, Initiative Tracking, and AI Copilot Evaluation. We built  a customized machine-learning workflow that analyzes key engineering metrics against 250 factors that can impact them, so we can identify issues and provide team-tailored recommendations to address them. We also use GenAI tools (LLMs) to summarize and explain the insights to help your team understand them and take action quickly.

These new capabilities we’ve introduced to the platform over the past year make it possible for any organization to get the visibility McKinsey recommends, delivered within days.

McKinsey’s Engineering Productivity Approach: What They Got Right

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.

McKinsey’s approach is based on several key points I fully agree with:

1. Optimizing the engineering workforce’s productivity is indeed a critical (and continuous) task, exacerbated by current market conditions and the emergence of AI. It’s pretty remarkable to see how far AI has come in the last two years, and developers are some of its main beneficiaries. Across every industry,  engineering leaders are evaluating AI coding assistants like GitHub Copilot, Amazon Q, and Gemini Code Assist under the watchful eyes of executives who anticipate significant productivity gains. Adoption and impact are being closely monitored to prove the ROI and help forecast the future of an AI-augmented engineering workforce. Not surprisingly, one of the most popular use cases for Faros AI is our AI Copilot Evaluation intelligence module, because it provides a holistic view into AI’s impact (or lack thereof) on every aspect of developer productivity.
2. The high amount of dissatisfaction, rework, and inefficiency reported by developers is a cause for change. Engineers do not 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 — continues to be my definition of “soul-sucking”. And while it is currently an employer’s market, the world’s leading tech companies are not resting on their laurels. They are extremely focused on improving the developer experience, as are we. Our Developer Experience intelligence module implements the winning methodology of blending qualitative data from employee surveys and interviews with machine-curated data from engineering tools and workflows. This mash-up helps engineering leaders and their HR partners take corrective measures faster, eliminating the biases from a purely qualitative approach and neutralizing the “coldness” of a purely quantitative approach. By bridging developer concerns and leadership action, this approach elevates both job satisfaction and feelings of psychological safety.
   
3. The C-Suite needs to understand the SDLC, how it’s evolving, and what it needs. Every day, I speak to organizations standing up new teams or centers of excellence focused on improving engineering productivity with unique metrics frameworks. We have found that two essential components determine whether these teams can accomplish their objectives: grasping the full picture and conveying it clearly. With Faros AI’s Investment Strategy intelligence module, engineering leaders and CFOs gain key insights to inform annual budgets and global sourcing strategies based on historical performance, productivity, and outcomes. They can jointly monitor initiative progress, identify high-cost investments with low return, and benchmark org composition and productivity to maximize resource utilization. This helps transform the partnership between engineering, finance, and other members of the C-Suite to ensure mutual understanding and alignment for better resource allocation and value realization for the entire organization.

What I’d Tweak in McKinsey’s Engineering Productivity Approach

There are three points in the original 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 tools and processes. One example which I’m incredibly proud of comes from our customer, SmartBear, who grappled with fragmented views across their 25 product lines — each with very different ways of working and technology stacks. In need of a single, centralized visibility solution, SmartBear selected Faros AI for our ability to integrate with its diverse stacks and be customized to its taxonomy, without needing to overhaul their existing systems and processes. That’s the data science we’ve developed at Faros AI. According to Vineeta Puranik, SVP of Engineering and Operations at SmartBear, the data in Faros is so good that she’s comfortable with it being seen by her CEO and every single team member.
   
2. Noncoding activities such as design sessions or dependency mitigation are not wastes of time. McKinsey’s latest take on outer-loop activities adjusted their original statement to now distinguish between high-value design and architecture activities and developer toil. This is more in line with my views on the matter, as certain outer-loop activities can be vital to ensuring high-quality, secure, and compliant code. And, those high-value activities should not be automatically lumped together with cross-functional delays and manual inefficiencies bogging developers down (occurrences which I agree are wastes of time). In fact, some outer loop activities 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 AI to be extensible to many data sources beyond traditional engineering telemetry — including employee data like seniority and tenure — precisely to bridge this gap. We’ve also launched an Initiatives Tracking intelligence module to provide visibility into what engineers are working on and how initiatives are progressing, so engineering leaders can keep critical work — whether it’s coding or non-coding — on track.
   
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. Relying exclusively on human-curated data (like status updates) paints a very partial view of engineering productivity. A more complete picture emerges when you construct it from the full developer experience, which includes source control, CI/CD pipelines, quality, and incident management systems.
   

McKinsey’s Engineering Productivity Findings Signal a Growing Business Imperative

While some folks may have had a few reservations about some of the details in the original McKinsey engineering productivity article, I remain excited that McKinsey is continuing to help 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.

And as the number of companies implementing McKinsey’s engineering productivity framework has grown from 20 to over 50, things appear to be shifting in the right direction. With an increasing number of companies focusing on this crucial business imperative, I’m confident that happier, more productive developers will propel business success to new heights.

If you're striving for engineering excellence in pursuit of improved revenue, profitability, market share, and customer satisfaction, reach out to our team. We don’t just provide the technology and technical expertise — we can coach you  on how to communicate the work you do to management, how to tactfully roll out the metrics internally, and how to plan for the incremental adoption of productivity metrics.