Technology, Media & Telecommunications Practice

Yes, you can measure

software developer
productivity
Measuring, tracking, and benchmarking developer productivity has
long been considered a black box. It doesn’t have to be that way.
This article is a collaborative effort by Chandra Gnanasambandam, Martin Harrysson, Alharith
Hussin, Jason Keovichit, and Shivam Srivastava, representing views from McKinsey’s Digital and
Technology, Media & Telecommunications Practices.

August 2023
 Compared with other critical business functions can require significant, long-term investment.
such as sales or customer operations, software Furthermore, the landscape of software development
development is perennially undermeasured. The is changing quickly as generative AI tools such
long-held belief by many in tech is that it’s not as Copilot X and ChatGPT have the potential
possible to do it correctly—and that, in any case, to enable developers to complete tasks up to two
only trained engineers are knowledgeable enough times faster.
to assess the performance of their peers. Yet
that status quo is no longer sustainable. Now that To help overcome these challenges and make
most companies are becoming (to one degree this critical task more feasible, we developed an
or another) software companies, regardless of approach to measuring software developer
industry, leaders need to know they are deploying productivity that is easier to deploy with surveys
their most valuable talent as successfully or existing data (such as in backlog management
as possible. tools). In so doing, we built on the foundation
of existing productivity metrics that industry
There is no denying that measuring developer leaders have developed over the years, with an
productivity is difficult. Other functions can eye toward revealing opportunities for
be measured reasonably well, some even with just performance improvements.
a single metric; whereas in software development,
the link between inputs and outputs is considerably This new approach has been implemented at nearly
less clear. Software development is also highly 20 tech, finance, and pharmaceutical companies,
collaborative, complex, and creative work and and the initial results are promising. They include
requires different metrics for different levels (such the following improvements:
as systems, teams, and individuals). What’s more,
even if there is genuine commitment to track — 20 to 30 percent reduction in customer-
productivity properly, traditional metrics can require reported product defects
systems and software that are set up to allow
more nuanced and comprehensive measurement. — 20 percent improvement in employee
For some standard metrics, entire tech stacks experience scores
and development pipelines need to be reconfigured
to enable tracking, and putting in place the necessary — 60-percentage-point improvement in customer
instruments and tools to yield meaningful insights satisfaction ratings

Now that most companies are

becoming software companies,
leaders need to know they are
deploying their most valuable talent
as successfully as possible.

2 Yes, you can measure software developer productivity

Leveraging productivity insights different lenses. For instance, while deployment
With access to richer productivity data and insights, frequency is a perfectly good metric to assess
leaders can begin to answer pressing questions systems or teams, it depends on all team members
about the software engineering talent they fought doing their respective tasks and is, therefore, not a
so hard to attract and retain, such as the following: useful way to track individual performance.

— What are the impediments to the engineers Another critical dimension to recognize is what
working at their best level? the various metrics do and do not tell you. For
example, measuring deployment frequency or lead
— How much does culture and organization affect time for changes can give you a clear view of certain
their ability to produce their best work? outcomes, but not of whether an engineering
organization is optimized. And while metrics such
— How do we know if we’re using their time on as story points completed or interruptions can
activities that truly drive value? help determine optimization, they require more
investigation to identify improvements that might
— How can we know if we have all the software be beneficial.
engineering talent we need?
In building our set of metrics, we looked to expand
on the two sets of metrics already developed by
Understanding the foundations the software industry. The first is DORA metrics,
named for Google’s DevOps research and
To use a sufficiently nuanced system of measuring
assessment team. These are the closest the tech
developer productivity, it’s essential to understand
sector has to a standard, and they are great at
the three types of metrics that need to be tracked:
measuring outcomes. When a DORA metric returns
those at the system level, the team level, and the
a subpar outcome, it is a signal to investigate what
individual level. Unlike a function such as sales, where
has gone wrong, which can often involve protracted
a system-level metric of dollars earned or deals
sleuthing. For example, if a metric such as deployment
closed could be used to measure the work of both
frequency increases or decreases, there can be
teams and individuals, software development
multiple causes. Determining what they are and how
is collaborative in a distinctive way that requires
to resolve them is often not straightforward.

Our approach seeks to identify what

can be done to improve how products
are delivered and what those
improvements are worth, without the
need for heavy instrumentation.

Yes, you can measure software developer productivity 3

 The second set of industry-developed measure­ improve how products are delivered and what those
ments is SPACE metrics (satisfaction and well-being, improvements are worth, without the need for
performance, activity, communication and heavy instrumentation. Complementing DORA and
collaboration, and efficiency and flow), which GitHub SPACE metrics with opportunity-focused metrics
and Microsoft Research developed to augment can create an end-to-end view of software
DORA metrics. By adopting an individual lens, developer productivity (Exhibit 1).
particularly around developer well-being, SPACE
metrics are great at clarifying whether an These opportunity-focused productivity metrics use
engineering organization is optimized. For example, a few different lenses to generate a nuanced
an increase in interruptions that developers view of the complex range of activities involved with
experience indicates a need for optimization. software product development.

On top of these already powerful metrics, our Inner/outer loop time spent. To identify specific
approach seeks to identify what can be done to areas for improvement, it’s helpful to think of the

Web 2023
MeasuringDeveloperProductivity
Exhibit 1 of 2
Exhibit 1

Adding a focus on opportunities to software developer productivity metrics

can offer clearer paths to improvement.

Focus areas by level DORA1 metrics SPACE2 metrics Opportunity-focused metrics

Outcomes focus Optimization focus3 Opportunities focus

Are you delivering products Are you delivering products Are there specific opportunities to
satisfactorily? in an optimized way? improve how you deliver products,
and what are they worth?

System Deployment frequency Code-review timing Satisfaction with engineering

level Customer satisfaction Velocity/flow through system
Reliability (uptime) the system Inner/outer loop time spent

Team Lead time for changes Story points completed Quality of documentation
level Change failure rate Handoffs Developer Velocity Index
Time to restore service benchmark4
Code-review velocity Contribution analysis

Individual Developer satisfaction Interruptions Contribution analysis

level Retention Talent capability score

1
Google’s DevOps research and assessment team, which developed these outcome metrics.
2
Satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow; GitHub and Microsoft Research developed these
metrics, which aim to look at developer well-being as a measurement at the individual level.
3
Nonexhaustive.
4
Benchmarks an organization’s technology, working practices, and organizational enablement; see Shivam Srivastava, Kartik Trehan, Dilip Wagle, and Jane
Wang, “Developer Velocity: How software excellence fuels business performance,” McKinsey, Apr 20, 2020.

McKinsey & Company

4 Yes, you can measure software developer productivity

activities involved in software development as being instead of coding, were spending too much time on
arranged in two loops (Exhibit 2). An inner loop low-value-added tasks such as provisioning
comprises activities directly related to creating the infrastructure, running manual unit tests, and
product: coding, building, and unit testing. An outer managing test data. Armed with that insight,
loop comprises other tasks developers must do to it launched a series of new tools and automation
push their code to production: integration, integration projects to help with those tasks across the
testing, releasing, and deployment. From both a software development life cycle.
productivity and personal-experience standpoint,
maximizing the amount of time developers spend in Developer Velocity Index benchmark. The Developer
the inner loop is desirable: building products directly Velocity Index (DVI) is a survey that measures an
generates value and is what most developers are enterprise’s technology, working practices, and
excited to do. Outer-loop activities are seen by most organizational enablement and benchmarks them
developers as necessary but generally unsatisfying against peers. This comparison helps unearth
chores. Putting time into better tooling and specific areas of opportunity, whether in backlog
automation for the outer loop allows developers to management, testing, or security and compliance.1
spend more time on inner-loop activities. For example, one company, well known for its
technological prowess and all-star developers,
Top tech companies aim for developers to spend up sought to define standard working practices more
to 70 percent of their time doing inner-loop thoughtfully for cross-team collaboration after
activities. For example, one company that had discovering a high amount of dissatisfaction, rework,
previously completed a successful agile and inefficiency reported by developers.
transformation learned that its developers,

Web 2023
MeasuringDeveloperProductivity
Exhibit
Exhibit 2 of22

Software development can be broadly divided into two sets, or loops, of tasks;
the less time spent on less fulfilling, outer-loop activities, the better.

Software development activities

Deploy
at scale
Build

Inner Outer Security and

Code
loop loop1 compliance

Test
Meetings Integrate
1
Activities listed are nonexhaustive.

McKinsey & Company

1
To read more about McKinsey’s DVI survey, see Shivam Srivastava, Kartik Trehan, Dilip Wagle, and Jane Wang, “Developer velocity: How
software excellence fuels business performance,” McKinsey, April 20, 2020; and Chandra Gnanasambandam, Neha Jindal, Shivam Srivastava,
and Dilip Wagle, “Developer velocity at work: Key lessons from industry leaders,” McKinsey, February 22, 2021.

Yes, you can measure software developer productivity 5

 Contribution analysis. Assessing contributions by Avoiding metrics missteps
individuals to a team’s backlog (starting with data As valuable as it can be, developer productivity data
from backlog management tools such as Jira, and can be damaging to organizations if used incorrectly,
normalizing data using a proprietary algorithm to so it’s important to avoid certain pitfalls. In our work
account for nuances) can help surface trends that we see two main types of missteps occur: misuse of
inhibit the optimization of that team’s capacity. metrics and failing to move past old mindsets.
This kind of insight can enable team leaders to
manage clear expectations for output and improve Misuse is most common when companies try to
performance as a result. Additionally, it can help employ overly simple measurements, such as lines
identify opportunities for individual upskilling of code produced, or number of code commits
or training and rethinking role distribution within a (when developers submit their code to a version
team (for instance, if a quality assurance tester control system). Not only do such simple metrics fail
has enough work to do). For example, one company to generate truly useful insights, they can have
found that its most talented developers were unintended consequences, such as leaders making
spending excessive time on noncoding activities inappropriate trade-offs. For example, optimizing
such as design sessions or managing interdepen­ for lead time or deployment frequency can allow
dencies across teams. In response, the company quality to suffer. Focusing on a single metric or too
changed its operating model and clarified roles and simple a collection of metrics can also easily
responsibilities to enable those highest-value incentivize poor practices; in the case of measuring
developers to do what they do best: code. Another commits, for instance, developers may submit
company, after discovering relatively low smaller changes more frequently as they seek to
contribution from developers new to the game the system.
organization, reexamined their onboarding and
personal mentorship program. To truly benefit from measuring productivity, leaders
and developers alike need to move past the
Talent capability score. Based on industry standard outdated notion that leaders “cannot” understand
capability maps, this score is a summary of the the intricacies of software engineering, or that
individual knowledge, skills, and abilities of a engineering is too complex to measure. The
specific organization. Ideally, organizations should importance of engineering talent to a company’s
aspire to a “diamond” distribution of proficiency, success, and the fierce competition for developer
with the majority of developers in the middle range talent in recent years, underscores the need to
of competency.2 This can surface coaching and acknowledge that software development, like so
upskilling opportunities, and in extreme cases call many other things, requires measurement to
for a rethinking of talent strategy. For example, one be improved. Further, attracting and retaining top
company found a higher concentration of their software development talent depends in large
developers in the “novice” capability than was ideal. part on providing a workplace and tools that allow
They deployed personalized learning journeys engineers to do their best work and encourages
based on specific gaps and were able to move their creativity. Measuring productivity at a system
30 percent of their developers to the next level of level enables employers to see hidden friction
expertise within six months. points that impede that work and creativity.

2
Klemens Hjartar, Peter Jacobs, Eric Lamarre, and Lars Vinter, “It’s time to reset the IT talent model,” MIT Sloan Management Review,
March 5, 2020.

6 Yes, you can measure software developer productivity

 Getting started overnight. Instead, they can begin the process with
Find more content like this on the
The mechanics of building a developer productivity a number of key steps:
McKinsey Insights App
initiative can seem daunting, but there is no time like
the present to begin to lay the groundwork. The Learn the basics. All C-suite leaders who are not
factors driving the need to elevate the conversation engineers or who have been in management
about software developer productivity to C-level for a long time will need a primer on the software
leaders outweigh the impediments to doing so. development process and how it is evolving.

The increase in remote work and its popularity Assess your systems. Because developer
among developers is one overriding factor. productivity has not typically been measured at
Scan • Download • Personalize
Developers have long worked in agile teams, the level needed to identify improvement
collaborating in the same physical space, and some opportunities, most companies’ tech stacks will
technology leaders believe that kind of in-person require potentially extensive reconfiguration.
teamwork is essential to the job. However, the For example, to measure test coverage (the extent
digital tools that are so central to their work made it to which areas of code have been adequately
easy to switch to remote work during the pandemic tested), a development team needs to equip their
lockdowns, and as in most sectors, this shift is hard codebase with a tool that can track code executed
to undo. As remote and hybrid working increasingly during a test run.
becomes the norm, organizations will need to rely on
broad, objective measurements to maintain Build a plan. As with most analytics initiatives,
confidence in these new working arrangements and getting lost in mountains of data is a risk. It’s
ensure they are steadily improving the function important to start with one area that you know will
that could easily determine their future success or result in a clear path to improvement, such as
failure. The fact that the markets are now putting identifying friction points and bottlenecks. Be
greater emphasis on efficient growth and ROI only explicit about the scope of such a plan, as even the
makes it more important than ever to know how best approaches, no matter how comprehensive,
they can optimize the performance of their highly will not be a silver bullet.
valued engineering talent.
Remember that measuring productivity is
Another key driver of this need for greater visibility is contextual. The point is to look at an entire system
the rapid advances in AI-enabled tooling, especially and understand how it can work better by improving
large-language models such as generative AI. These the development environment at the system, team,
are already rapidly changing the way work is done, or individual level.
which means that measuring software developers’
productivity is only a first step to understanding how No matter the specific approach, measuring
these valuable resources are deployed. productivity should ideally create transparency and
insights into key improvement areas. Only then
But as critical as developer productivity is can organizations build specific initiatives to drive
becoming, companies shouldn’t feel they have to impact for both developer productivity and
embark on a massive, dramatic overhaul almost experience—impact that will benefit both those
individuals and the company as a whole.

Chandra Gnanasambandam and Martin Harrysson are senior partners in McKinsey’s Bay Area office, where Alharith
Hussin and Shivam Srivastava are partners; and Jason Keovichit is an associate partner in the New York office.

The authors wish to thank Pedro Garcia, Diana Rodriguez, and Jeremy Schneider for their contributions to this article.

Designed by McKinsey Global Publishing

Copyright © 2023 McKinsey & Company. All rights reserved.

Yes, you can measure software developer productivity 7