Developer productivity metrics have long been a point of contention in tech. Measuring productivity is difficult and improving it even more so. But no company can succeed without a thoughtful approach to productivity. Getting it wrong has myriad knock-on effects, not least of which is that it’s bad for employee well-being.
One argument is that when we focus on developer experience (DevEx), developer productivity (DevProd) will follow, but what measurable changes does that involve?
Metrics are only useful if they help us work toward bigger goals. The right metrics can help you identify what’s holding your developers back. When you remove those roadblocks, metrics improve, but more importantly, your developers are happier and more effective.
The answer to the debate isn’t to choose one side or the other; it’s to recognize that both are means toward the same end. Choose the right metrics, make the right DevEx investments and better DevProd — and, crucially, better products — will follow.
How Are Teams Measuring Developer Productivity?
Most productivity metrics focus on lines of code (LoC) and completed tasks, but a developer’s work is much more than this. It involves enjoyable work, like building environments and learning the latest technology, but it also involves frustrations, the most significant among them being technical debt and tech stack complexity.
Beyond that, developers’ work styles and responsibilities can vary immensely, even for developers of comparable rank who work at the same company. The way they choose to tackle problems can also be very different.
The long-term value a developer provides comes from their ability to work through challenges, build on organizational knowledge and use their individual expertise to solve problems creatively. Your senior developers may spend far more time thinking and researching than writing code, especially where application performance is a priority.
How do you measure developer productivity given those challenges?
If you pose this question to a dozen tech leaders, you’ll likely get as many different answers. Factors that influence the choice include how big your team is, how diverse their assignments are, and how much time and tooling you have available. Other than LoC, companies have traditionally focused on:
- Coding speed
- Number of commits and pull requests
- Cycle time (how many hours to go from pull request to production)
- Deployment frequency per service
- Mean time to recovery (MTTR)
Two popular frameworks build on these metrics to measure fundamental aspects of developer productivity: DORA and SPACE. Both focus on code, with DORA prioritizing outcomes and SPACE looking at optimizing development teams.
McKinsey recently set off a new round of arguments on DevPod when it outlined its own set of metrics to complement DORA and SPACE, claiming an “end-to-end view of software developer productivity.”
These “opportunity-focused metrics” include a Developer Velocity Index and a talent capability score. The idea is to optimize in-demand talent by tracking developers’ time in both the inner and outer loop.
Other teams have opted to quantify “soft” factors, focusing on project hygiene and motivators to measure employee well-being and team morale.
Consider the diversity of responsibilities under the “developer” job title and how many obstacles can get in the way. It’s difficult to see which metrics could accurately measure the contributions of any significant number of devs.
So, are we even asking the right question?
Make Changes Where You Know They’ll Matter
Metrics might be a part of team member evaluation, but that shouldn’t be their primary purpose. They’re a tool to help you reach the real goal: to improve processes so you can deliver better products.
The question isn’t which metrics to use to measure your developers’ productivity; it’s how metrics can reveal what’s getting in the way of your developers doing their work. To do that, you must tie your metrics to the work environment where your developers spend their time: the inner dev loop.
The Inner Dev Loop Is Evolving
McKinsey’s approach hits on a crucial fact: The inner dev loop is where developer productivity lives. Unfortunately, we’ve lost sight of its value. Thanks to containerization, the inner dev loop has lengthened, and the tasks of the outer dev loop require developers to spend even less time in this focused zone.
Developers’ work has changed, and it will change more with the rise of AI tools like GitHub Copilot and other AI-driven code-gen tools. As the pressure on technical organizations increases, we must make developers’ work environments as efficient as possible. Metrics can help us do that.
First, we must shorten the inner dev loop and reduce the container tax. If you look closely at what sucks up the most time in your developers’ days, you’ll find factors like incompatible local and deployment environments, slow container build times and CI/CD process failures. The data you uncover can direct you toward the right tools and process changes.
Second, we must take a broader view of what makes an effective developer. As AI takes on more of the rote tasks of the old inner dev loop, the developers who contribute the most value won’t be the ones who write the most lines of code. They’ll be the ones taking advantage of the smoother inner dev loop to test out bigger, bolder ideas.
It’s about time we started thinking of developer productivity in terms of business goals and design innovations, not lines of code or commit histories.
Can Productivity Be a Feel-Good Goal?
Productivity shouldn’t be a dirty word in tech — it feels good to be productive. Measuring productivity is pointless if you do it in isolation and worse if it limits creative problem-solving. But there are many ways it can make a positive difference:
- It helps ensure alignment: Setting metrics allows development efforts to align with business expectations. Metrics give developers a better understanding of what’s expected of them. Highlighting specific goals and standards ensures you spend time and resources wisely.
- It accelerates development: You can use metrics to evaluate the entire development workflow, identifying inefficiencies and bottlenecks. Highlighting delays in the pipeline facilitates streamlining processes and speeds up development, which is crucial for improving the inner dev loop experience.
- It motivates developers: People like to know that their contributions make a difference. Setting metrics lets them track their progress toward specific goals, get recognition and substantiate their ideas for process improvements.
The greatest value of metrics is that they can help you identify processes and environments that aren’t working. It’s not about measuring people: No one wants to be valued only for their output, and managers should take it in good faith that most developers want to be efficient and make meaningful contributions. Don’t just look at the metrics; look at the whole picture. But, the metrics can help you diagnose where bigger issues might be hiding.
The fact remains that being productive at work is necessary. Getting things done and seeing the proof before you is also gratifying. Metrics can and should serve that purpose: finding the obstacles that keep people from doing creative, innovative work.
Improving Internal DevEx Feeds Productivity
Companies don’t make money by writing the most code. Developers don’t build good applications that way either. You make money by building great products efficiently. To do that, you must retain your best developers and empower them to do their best work.
This is an argument for building better DevEx, but it’s not an argument for giving up metrics. You need one to get the other.
Internal DevEx Focuses on the Inner Dev Loop
Often, we think about DevEx in terms of product design — what’s it like for developers to use our product? It’s critical to think about the experience of your developers, too — what’s it like for the developers who build our product?
If you think your developers could be more productive, ask yourself: What’s preventing them from being as productive as possible?
No matter how much developers want to improve their productive capacity, they face many obstacles outside of their control. Metrics can help you spot issues, but making life better for your developers means acting on the knowledge you gain. Considering the friction that typically occurs throughout the inner dev loop, it’s a good place to start if you see problems in your metrics.
What Metrics Matter for Internal DevEx?
Too many companies neglect internal DevEx, but it can pay big dividends in productivity gains. In the short term, developers get more done and code quality is higher. In the long term, developers stay engaged at work and avoid burnout. However, many leaders struggle with how to measure DevEx or how to improve it.
You can start with a few key DevProd metrics:
- Environment build time and crash/error rates: Do developers lose valuable time waiting for cloud environments to build? Do they depend on other teams to set up development and test environments, or can they do it on their own? How much time do they spend debugging environment setups? Problems here also affect DevOps and QA teams, so look for tools that decouple production and development environments.
- CI/CD pipeline delays: Do legacy tools or incompatible processes create duplicate work or add manual steps? Modernize and streamline your tool stack to eliminate tedious and repetitive tasks, such as creating standardized specs, API mocks and boilerplate code. Automating repetitive tasks frees developers to focus on more creative and challenging work.
- Time in and length of the inner dev loop: Developers need tools and environments that reduce the container tax and shorten the build stage of the inner dev loop. They need more time on focused work and fewer delays to see their ideas in action.
- Time spent waiting for code reviews or other collaboration requests: Provide tools that allow teams to communicate and collaborate more effectively. Encourage teams to share knowledge and engage in problem-solving, which fosters teamwork.
Productivity obstacles are also morale killers. To get the most out of your metrics and your DevEx investments, focus on the end goal: empowering your developers to build better products with fewer frustrations.
Build a More Resilient Team for Whatever Comes Next
We need a paradigm shift in how the tech industry defines and approaches productivity for developers. You’ve recruited talented developers for your projects, so let them see the big picture and think beyond code execution to find better ways to solve problems.
The work of development is changing, but the most productive developers will always be the ones who see their work as part of a larger ecosystem. Your best people can help you weather the changes ahead. They have crucial organizational knowledge and a deeper understanding of the real-world problems your company solves. Treating them like machines and bogging them down with outdated metrics won’t serve anyone’s needs.
Instead, invest in solutions that make work more enjoyable for your developers and motivate them to keep improving. Key in on the metrics that relate most closely to what’s happening in the inner dev loop, and work to make the time developers spend there as valuable as possible.
The post Let Productivity Metrics and DevEx Drive Each Other appeared first on The New Stack.