{"id":3775,"date":"2025-02-28T17:40:03","date_gmt":"2025-02-28T17:40:03","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=3775"},"modified":"2025-09-09T22:23:17","modified_gmt":"2025-09-09T22:23:17","slug":"applying-developer-productivity-metrics-system","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/applying-developer-productivity-metrics-system\/","title":{"rendered":"Measuring Developer Productivity the Right Way"},"content":{"rendered":"\n
\"Developer<\/figure>\n\n\n\n


Whether you think developer productivity can\u2019t be measured (like Martin Fowler<\/a>) or are obsessed with getting precise insights into what slows down developers or makes teams collaborate better, as an engineering leader, you\u2019ll probably have to and want to apply some kind of developer productivity metrics system.<\/strong>

Instead of debating whether you can measure developer productivity or whether you should, let\u2019s figure out how to do it correctly.<\/strong><\/p>\n\n\n\n

Developer Productivity: What to Track, When, Why, and How?<\/strong><\/h2>\n\n\n\n

One thing everyone seems to agree on \u2014 McKinsey, Gergely Orosz<\/strong>, Kent Beck<\/strong>, Martin Fowler,<\/strong> Dave Farley<\/strong>, and hundreds of engineering leaders working at organizations of all shapes and sizes \u2014 is that some standard metrics systems, like the DORA metrics<\/a>, are the best we have so far.<\/p>\n\n\n\n

At least as a starting point. When Orosz asked 17 engineering leaders at 17 companies what metrics they track, he got 17 different answers.<\/a>

And that\u2019s OK. When you go just one level beyond the DORA metrics, every company optimizes for what they care about.

The secret to getting developer productivity metrics righ<\/strong>t is to measure what matters to you, what matters to your engineering teams, and what is applicable to your way of working, your product, and the stage of the company.<\/p>\n\n\n\n

The 4 Rules of Measuring Developer Productivity the Right Way<\/h2>\n\n\n\n


1. Contextualize Developer Productivity Metrics to the Team\u2019s Specific Goals<\/strong><\/h3>\n\n\n\n

Not all teams are alike. The metrics that matter for a team working on a highly experimental, rapidly evolving product will be different from those for a team maintaining a large, stable enterprise application. Engineering leaders should tailor productivity metrics to the specific context of the team and the project.<\/p>\n\n\n\n

\n

\u201cI\u2019m a big proponent of the DORA metrics, but it’s important to understand the context for which you\u2019re going to apply them<\/strong>. We have Atlas, which is a SaaS product, and productivity can easily be measured with time to deploy, time to failure, and time to recovery. That\u2019s the context <\/em>\u2014 cloud-native development <\/em>\u2014 that the DORA metrics were meant for.

But we also have non-SaaS offerings, and our customers wouldn\u2019t want to download a new distro package every day, not even every week or even every month. We have a major version cycle of one year.
You can also measure time to \u2018deploy\u2019 in that context; it\u2019s just going to be slightly different <\/em>\u2014- not measuring packages made available to download, but in our staging environment.\u201d<\/em><\/p>\n\n\n\n

Tara Hernandez, MongoDB<\/strong><\/p>\n<\/blockquote>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Full episode of HangarDX podcast episode on Designing MongoDB developer productivity at Mongo DB<\/a><\/p>\n\n\n\n

2. Developer Experience => Developer Happiness => Developer Productivity <\/strong><\/h3>\n\n\n\n

The goal of developer productivity metrics should be to identify and reduce inefficiencies and friction in developers\u2019 workflows.<\/strong> Although they\u2019re different concepts and shouldn\u2019t be confused, Developer Productivity, Engineering Effectiveness, and Developer Experience are intertwined.

Quantitative metrics like DORA or SPACE<\/strong> should be paired with developer satisfaction surveys<\/strong> to diagnose waste and friction that frustrate developers. Ultimately, good developer experience practices lead to developer satisfaction, which leads to developer productivity.<\/strong><\/p>\n\n\n\n

3. Measure what Matters (and Stop When it Doesn\u2019t)<\/strong><\/h3>\n\n\n\n

When you understand the issues in your organization, you can start tracking whether they are getting better or worse. A good way to avoid metrics overload is to measure only what really matters to your team or organization in addition to the basic DORA or SPACE metrics.<\/p>\n\n\n\n

\n

\u201cWhen you have identified a metric\/signal that is too high or too low, you measure it until it\u2019s where you wanted it to be. Then you STOP. <\/em><\/p>\n\n\n\n

Otherwise, you end up with a dashboard with over 100 metrics that look like the stock market!<\/strong> <\/em>

Half of the metrics are going up, and half of them are going down, and no one knows whether that\u2019s good or bad.\u201d<\/em>
Chris Westerhold, HTEC<\/strong><\/p>\n<\/blockquote>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

4. Tie Metrics with Dollars<\/strong><\/h3>\n\n\n\n

Developer productivity <\/strong>metrics are a means to an end, and <\/strong>different layers of organization need different sets of metrics. Many leaders see developer experience as just a cost center. It\u2019s key to present what bad developer experience is costing the entire company in dollars<\/strong>. Build metrics that can help make that visible to them!

One of the ways is the classic triangle of cost, speed, and quality. By understanding that one of them has to be compromised unless friction is removed within the company, the C-suite will have an understanding of how the engineering organization is affecting the business results. Sixty-nine percent of developers are losing more than 8 hours a week<\/strong> to inefficiencies, according to Atlassian\u2019s Developer Experience Report<\/a>). That\u2019s 20 percent of wasted developer hours!<\/p>\n\n\n\n

3 Ways How Developer Productivity Metrics Can Go Wrong<\/strong><\/h2>\n\n\n\n

1. Measuring the Productivity of Individual Developers<\/strong><\/h3>\n\n\n\n

Measuring the productivity of individuals in any way \u2014 be it the lines of code or the number of closed tickets<\/strong> or something else is pointless. No one likes to be micromanaged, and software development is a team effort anyway. What you measure should say to developers that you\u2019re measuring that with them, not against them.<\/p>\n\n\n\n

2. Metrics for the Sake of Metrics<\/strong><\/h3>\n\n\n\n

Don\u2019t measure things that are easy to measure but don\u2019t have a real impact. As Goodhart’s Law<\/strong> says \u2014 when a measure becomes a target, it ceases to be a good measure. When you set very specific goals for people, especially if those metrics are tied to financial rewards or career progress, they will tend to optimize for those metrics no matter the consequences.<\/strong>

Avoid metric pitfalls by setting your developer productivity metrics in pairs of positive and negative metrics.<\/strong> So, if the goal is to lower code review times<\/a>, you don\u2019t want to achieve that by engineers just approving whatever comes their way and the number of bugs in production going up.<\/p>\n\n\n\n

3. Not Caring About Culture and Satisfaction<\/strong><\/h3>\n\n\n\n

We tend to think of productivity as just an output. But as an engineering manager, you also have to consider people. That\u2019s why the SPACE framework takes into account developer satisfaction and well-being. Because, again, a happy developer equals a productive developer.<\/strong><\/p>\n\n\n\n

\n

\u201cEngineers are not people working in the widget factory. <\/em>

I don\u2019t want to think about productivity as telling a developer <\/em>\u2014 last week, you produced 50 widgets, and this week, you have to produce 51. <\/strong><\/em><\/p>\n\n\n\n

What if he told me that he produced 51 widgets this week, but he was really unhappy because the widget machine was broken, and he did it with brute force? You realize that if you invested in fixing the widget machine, you\u2019d get 100 widgets produced a week!\u201d<\/em>
Max Kanat-Alexander, LinkedIn<\/strong><\/p>\n<\/blockquote>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Listen to the full Hangar DX podcast episode on Developer Productivity and Happiness framework at LinkedIn<\/a>

Interested in measuring productivity and improving developer experience?
Join The Hangar DX, a curated community for developer-experience (DX) enthusiasts!<\/strong><\/p>\n\n\n\n\n

\n
\n

Join The Hangar DX<\/h2>\n

A vetted community of developer-experience (DX) enthusiasts.<\/p>\n

\n \n \n \n