How to measure the impact of engineering in 2025

Estimated reading time: 15 minutes

Across decades, developer salaries went up as technology departments scaled to sometimes half a company’s size.

Add to this a hefty sprawl of developer tool and platform subscriptions and growing cloud bills, and engineering became the most expensive division at many organizations.

Yet engineers have often lacked the business language to justify their expense and the whole department can often remain a mysterious cost center. That can be OK during times of seemingly endless growth. But the tech industry is in a downturn, increasing the pressure to justify budgets.

As we look to 2025, here’s four trends to look out for when it comes to measuring developer productivity in a way that highlights the impact of engineering on business goals.

Investment in DevEx

Whether it’s called the DevEx or platform engineering team, 2024 saw an acceleration of the trend of abstracting out distractions and frustrations to improve the developer experience. 

Despite the discipline of platform engineering falling this year from Gartner’s peak of inflated expectations down into the trough of disillusionment, that same analyst firm predicts that 80% of organizations will adopt a platform engineering strategy by 2026.

“Instead of cost-cutting for survival’s sake, organizations will now shift their attention to prioritizing and resolving the areas that create friction in engineering organizations so they can deliver more value to customers,” predicts Lizzie Matusov, CEO of Quotient. “This renewed focus on engineering org efficiency will drive increased adoption of DevEx, enabling teams to deliver greater impact to the company and their customers.”

This also means shifting our approach to measuring team performance in a way that accounts for the holistic developer experience.

“2025 is going to be the year of efficiency … for better or for worse,” said Laura Tacho, CTO at DX. “I’m most afraid for those developers doing a lot of intangible work that might not show up in activity metrics from commits and tickets alone.”

This is the glue work that is often outside of job descriptions and pull requests, but that holds teams and codebases together. This includes documentation, post-mortem notes, and onboarding, mentoring, and training colleagues. 

In 2025, how do we find ways to effectively measure the value of all that valuable – even thankless – work?

Don’t assume you know what your devs want

One of the main struggles with goal-setting and measuring the internal developer experience is that technical leadership assumes it already knows what developers want and need. 

“The biggest issue in DevEx is the misalignment between leaders and engineers on the friction that’s impacting developers on a daily basis,” said Andrew Boyagi, head of DevOps evangelism at Atlassian. In 2024, this led to management slapping a lot of AI on devtools, but “that didn’t improve things much for developers, as these solutions weren’t pointed at friction points for developers,” he adds.

In the 2024 Atlassian-DX State of DevEx survey, leaders responded that they thought AI is the most effective way to improve developer productivity and satisfaction. While two-thirds of developers responded they hadn’t experienced any significant AI productivity gains yet. This misalignment was echoed in this year’s DORA report which found that a 25% increase in use of generative AI actually reduced throughput by 8%.

“When you are thinking about a limited investment budget to improve developer experience you want to make sure that you’re moving that investment towards the thing that’s going to have the most impact,” Boyagi said. 

Developers responded in the State of DevEx that the following are their biggest productivity blockers:

1. Technical debt.
2. Insufficient documentation.
3. Build processes. Lack of time for deep work.
4. Lack of clear direction. 

AI-generated code means more code, which creates more debt and demands more docs. Interestingly, the only place AI drove significant productivity gains was in documentation.

Managers are blatantly ignoring developer complaints that they don’t get enough time to focus on coding, by looking to automate the best part of their jobs.

In 2025, Boyagi predicts we will start to see a stark contrast between companies who have done their homework to deeply understand their developers’ pain points and those who haven’t – not only in tech talent retention but profits too. 

“DevEx is only worth investing in if companies see how it will help them achieve other goals. Right now all the money and power is focused on AI, and all the ways it will improve things,” said Winston Hearn, senior technical product manager at Honeycomb. “This also means that the entire industry is focused on automation, which usually you apply to solved problems.”

How do we quantify the impact of engineering? 

Platform teams’ inability to measure and prove their impact on developer productivity and the company’s bottom line has them labeled cost centers and their budgets on the chopping block. 

In 2025, platform teams will need to show how they are driving business impact.

As Marko Bevc, principal consultant at the Scale Factory put it, engineering organizations need to focus on how they are delivering outcomes and then translating those outputs to business value.

But figuring out how to measure developer impact isn’t so easy.

Developer productivity certainly doesn’t lack metrics frameworks to choose from. The 2024 DORA report asked over 100 questions. The SPACE framework offered dozens of suggestions. And DevEx Metrics has us considering the interlinkage among feedback loops, flow states and cognitive load with a more theoretical than practical approach. We’ve already covered what McKinsey got wrong about developer productivity. Just released, the DX Core 4 aims to be a more prescriptive metrics launchpad, grounded in the four base measurements of speed, effectiveness, quality, and impact. 

“It’s important to understand that developer productivity shouldn’t be measured on a single metric,” emphasized Trisha Gee, lead developer advocate at Gradle. “The SPACE framework encourages us to pick perhaps three from five different dimensions. The tension between these different dimensions can prevent over-optimizing in one area at the expense of another, such as creating more code at the expense of quality.”

The DX Core 4 metric to measure the impact of engineering activities on overall business goals is the percentage of time spent on new capabilities. If a platform or DevEx team is in charge of removing and automating developer toil, then that should free up markedly more time for app developers to build new features that drive business value. 

“With better developer productivity, we should be seeing the ability to spend more time on user-facing thinking,” said Abby Bangser, principal engineer at Syntasso.

What should you ask developers in 2025?

The million-dollar question is: What do you ask? As budgets, time, and statistics degrees are scarce, you need to hone in on the right metrics. 

“To measure the latency of your app, you need to instrument each request end-to-end,” said Tilde Thurium, senior developer educator at LaunchDarkly. It therefore stands to reason that, to measure developer productivity, they continued, “you need to similarly collect data on every step towards getting features into production – requirements gathering, design, implementation, writing tests, code review, release, monitoring, and more – in order to identify bottlenecks.”

This calls for a mix of quantitative metrics – like DORA’s deployment frequency, change lead time, change fail rate, and failed deployment recovery time – and qualitative ones. 

Measuring build times – which directly affects the DevEx metrics of feedback, flow, and cognitive load – was suggested most frequently. 

“Developers often complain about slow builds, but unless you measure them, you cannot improve it,” remarked Brian Demers, developer advocate at Gradle. “If long builds are not the pain point, then figure out what is, [and] measure it. Was it really the problem you thought it was? If so, work on fixing [it] incrementally.”

Camille Fournier, author of the Platform Engineering Guide for Leaders, echoes this, arguing that: “The answer is always: How fast/frequently are people able to ship?”

You also need a mix of self-reported and system-based metrics.

“In 2025 and beyond, measuring the productivity of knowledge workers means asking questions that go beyond simple output metrics while remaining practical and tied to meaningful outcomes,” said Helen Greul, VP engineering at Multiverse. She offered these questions to consider:

• Are we delivering updates that genuinely benefit users?
• Do developers have the tools and environments needed to stay focused, or are they hindered by blockers and unnecessary complexity?
• How effectively are teams collaborating across functions, and are they striking a balance between innovation and managing technical debt? 
• What processes can be automated or streamlined to reduce friction and improve efficiency?

Questions around developer perception are particularly powerful. Ask developers how they rate their own productivity, suggested developer experience specialist Lorna Mitchell, and then track trends around how their productivity rate changes over time.

“Impact on retention – which I think is already being done, but can always be more effective – and impact on end user/business metrics,” Bangser said, is a balance every organization should aim for in its metrics.

“What decisions are we trying to make with these metrics? Metrics should be used to start conversations that lead to changing something about how a team works,” said Nathen Harvey, DORA lead for Google Cloud. 

“What will we do differently if this number doubles? What if it drops by 50%? What conditions, capabilities, or tools do we need to put in place to drive or prevent those changes?”

Don’t take your positive numbers for granted either. There’s always room for continuous improvement. Then, for those rare, elite organizations that feel they have proven not only their impact and budget, but have truly optimized their developer workflow, it could be time to think about next steps. 

Hearn broached perhaps the most interesting consideration: “What would the world look like if we hit maximum developer productivity based on the things we currently measure? Is that world actually desirable?”