Over the past two decades, companies have become increasingly focused on measuring developer productivity. As someone who has led technology teams across different industries, I understand this drive. At my current company, I work on building tools that support hundreds of engineers, enabling them to work more effectively and happily. I also meet regularly with leaders who want to understand what makes high-performing developer teams, and it’s clear that they aren’t measuring productivity just for the numbers. Leaders genuinely want to support their teams and maximize the value of their investment in people and technology.
But the reality is, measuring developer productivity is incredibly challenging. In many organizations, it becomes an obsession—allocating significant time, energy, and resources in search of the perfect metric. Ironically, this effort to measure productivity can actually detract from initiatives that would make developers more productive in the first place. Imagine if all that focus on measurement was channeled instead into enhancing the environment where developers work.
It’s simple: happy developers are productive developers. We’ve all seen this in action. Think of any outstanding developer you’ve worked with. They probably exceeded expectations, not because they were being measured, but because they were engaged, had what they needed to do their best work, and generally enjoyed what they were doing.
Research backs up what we see in practice: satisfied employees are productive employees. In the case of developers, their productivity is often a natural byproduct of feeling engaged and supported at work. If we’re serious about improving developer productivity, our focus should really be on cultivating what I’ll call "developer joy."
Two major factors contribute to developer joy: developer experience and engineering culture.
Developer Experience (DX): is essentially about how developers feel about the tools, frameworks, and processes they use. The quality of these tools, as well as the efficiency of workflows, can make a big difference in how developers view their work.
Engineering Culture: refers to the overall environment within which developers operate, encompassing values, practices, norms, leadership style, and more. It’s how work gets done and how it feels to work there.
Leaders can directly impact DX through better tools and processes, but shaping engineering culture requires patience and intentionality. By actively working on both, companies can significantly enhance developer joy—and, as a result, productivity.
While every organization is unique, a few steps can help improve developer experience and drive productivity as a natural outcome.
The people who know best about the developer experience at a company are the developers themselves. A great starting point is to ask developers a simple question: “How can we make your work experience better?”
When I did this, I ended up with a long list of ideas that could improve both developer experience and productivity over the next couple of years. Developers are often full of insights and eager to share if they know their feedback will lead to real change. Surveys can be a useful tool here as well, especially in larger organizations, to get a pulse on the developer experience and identify areas for improvement.
Platform teams are dedicated to enhancing the developer experience across the organization. By managing internal services, such as infrastructure, CI/CD pipelines, monitoring tools, and compliance support, platform teams make it easier for development teams to self-serve and work independently.
The goal of a platform team is to make sure developers have everything they need to deliver software effectively. When developers are supported by reliable tools and streamlined processes, they’re empowered to focus on building great products.
Platform teams can also use a developer experience platform to make life easier for developers at scale. A good DX platform will help by:
Many people misquote Peter Drucker’s famous line, “You can’t improve what you don’t measure,” using it to justify unhelpful metrics around developer productivity. The truth is that DX and engineering culture, which both drive developer joy, are unique to each company. Measuring productivity should align with these unique aspects; metrics copied from other companies are unlikely to fit well and could even have negative effects.
Instead of following what others measure, look at how successful companies find their own metrics and learn from their approach. This will likely be a more rewarding and valuable journey for any organization.
In the end, companies that prioritize developer experience and foster a positive engineering culture will see more productive developers and perform better overall. The companies that obsess over productivity measurement will still be searching for the perfect metrics, while those who focus on experience will be pulling ahead.
I know which type of company I’d want to work for.
Written by Muhammad, is a young DevOps Evangelist with extensive experience in software delivery and service management in various organizations. He provides a practical perspective on how teams and organizations can maximize the benefits of DevOps and Project management based on real-life experience.
2 Comments
Kevin martin
The article makes a compelling case for prioritizing developer experience over rigid productivity metrics. As a developer, I can attest that a supportive and engaging environment significantly boosts my productivity. Investing in better tools and fostering a positive engineering culture should indeed be the focus.
Sarah albert
I completely agree with the points raised in this blog. Measuring productivity can sometimes be counterproductive if it doesn't take into account the developer's well-being and satisfaction. Creating a platform team and improving the developer experience seems like a practical and effective approach to enhance productivity.