Focus on improvement metrics that actually matter 

Estimated reading time: 7 minutes

You’ve generated a ton of developer productivity data. Now what?

“Developer productivity metrics are having their moment in the spotlight,” says Laura Tacho, CTO of DX.

Amid the tough macroeconomic climate of 2025, leaders are craving more insight into engineering output. This has led to an increased focus on monitoring developer productivity metrics.

Developer productivity frameworks like DORA, SPACE, or DX Core 4 track key metrics such as deployment frequency, lead time, recovery time, and even revenue per engineer.

The idea is that managers and directors can use these metrics to gauge overall output and discover bottlenecks to optimize the engineering workflow, leading to a higher return on investment.

However, productivity data is useless if it just sits in dashboards. According to Tacho, developer productivity metrics can drive meaningful improvements – you just need the strategies and resources in place to apply them.

You also need to know what metrics to focus on. Not all metrics are created equal. Where some can inspire action in the moment, others are better suited for strategic reflection.

Budgeting time to act

When building out a developer productivity initiative, many organizations invest in tools to monitor and collect important developer productivity signals. 

According to Tacho, the right developer productivity metrics can surface issues like: 

• Slow time to first review on pull requests: PRs are sitting without review, slowing progress.
• High cycle time: Moving a project from the idea stage to delivery has bottlenecks.
• Flaky or slow-running test suites: Builds are unreliable, or tests fail and must be re-run, wasting time.
• Inefficient build pipelines: Slow rendering times or excessively slow CI/CD pipelines.
• Infrastructure limitations: There’s not enough capacity to test deployments, hindering progress.
• Poor onboarding experience: A lengthy ‘time to 10th PR’ could signal bottlenecks in the hiring and onboarding process.

These kinds of signals often call for deeper investigations – and may require changes to engineering practices, tooling, culture, or infrastructure. But too often, organizations don’t plan for the next step: setting aside the time and resources to respond to the issues they uncover.

“We need to spend time investing in it – otherwise, what’s the point of measuring?” says Tacho.

Part of the problem stems from a lack of top-down direction. Without really strong executive sponsorship, it’s difficult to use developer experience metrics as guidelines for continual improvement, says Tacho.

There are a number of tactics to get said executive buy-in. Tacho recommends educating executives on the fundamentals of developer experience, using financial outcomes with direct numbers, and framing the existential urgency of improvement. Stressing the fact that “developers are losing, on average, 20% of their time each week due to inefficient processes and tools” could really win them over.

“Like it or not, it’s the responsibility of engineering directors to educate their counterparts and executive team on what developer experience even is,” she says.

Therefore, when planning developer productivity engineering initiatives, leaders should carve out ample time and resources from the outset.

Focus on improvement metrics

It’s easier to drive action when you focus on targeted, granular benchmarks that you can measure often – what Tacho calls “improvement metrics.” This may be something like the time it takes to review a pull request, time to first PR approval, project CI build times, or the number of project handoffs. Good improvement metrics are narrowly scoped and support decision-making “in the moment.” 

These are opposed to “diagnostic metrics” that are more coarse-grained, lagging, and represent an aggregation of cues. For example, common diagnostic metrics include cycle time, change failure rate, and deployment frequency, says Tacho. They are helpful high-level indicators, but don’t explicitly say where to act.

Diagnostic metrics can be hard to diagnose since they’re complex and represent aggregated workflows. They’re also highly variable across development teams, making specific engineering modifications unclear.

Flip on failure modes

“Leaders often forget about the floor or failure case,” says Tacho. In other words, they often don’t plan for what to do when things go south. She added that leaders are quick to outline what success looks like, but don’t give clear guidance on failure scenarios, which can leave teams stalled or unsure how to respond.

One way to address this gap is by setting clear thresholds that act as early warnings. Triggering notifications when metrics hit certain thresholds is an easy way to influence real-world action.  For instance, if the time to first review for a pull request reaches a certain threshold, it could ping team members that they haven’t been reviewed.

By setting thresholds and directing real-world changes, says Tacho, you can make developer productivity metrics more actionable. Instead of just having a report on systems, metrics can be a feedback mechanism for continual improvement. For example, a pending PR doesn’t just highlight a delay; it sparks an action and helps keep work moving.

Encourage triage ownership

Too often, teams are left without the necessary tools or authority to address problems they are already aware of. Just presenting data to them and saying “go do something with it” is not enough, says Tacho. What they need is a structure to triage problems.

That structure starts with leadership. Team leaders need to feel empowered to articulate their priorities and when they need organizational support. This encourages an active participation “that gets the teams into ownership mode of the data,” says Tacho. For instance, if a team knew rendering time was slow, and building metrics showed flaky tests were causing failures and re-runs, they might advocate for better concurrency or request additional infrastructure to run faster tests to address the issue. 

With the right structure, data doesn’t sit idly, but informs improvement metrics that guide adjustments to the engineering workflow. “The more targeted you can be with the activity, the better,” says Tacho.

Frame improvements in business terms

Historically, engineering leaders have not been expected to articulate business impacts in the same way as other business counterparts have had to. “It’s an underdeveloped skill,” says Tacho.

For example, vague goals like “improving developer experience” don’t always land with higher-ups. “I think developer experience,” says Tacho, “really has a ping pong and beer problem when it comes to perception.” In other words, developer experience is equated to office perks rather than meaningful improvements.

Developer productivity is actually about “removing friction and expediting innovation for the area of your business that has the highest ceiling on revenue potential,” she adds.

She encourages engineering leaders to justify their actions with clear business outcomes. When pitching developer productivity initiatives and suggesting responses, technical leaders should frame it from a business perspective: either it enhances the go-to-market strategy, drives revenue, reduces churn, or improves quality.

“Every executive cares about continuous improvement, even if they don’t have that exact language to describe it,” says Tacho. “Everything can be traced back to money – that’s the thread to pull on!”

Take Goodhart’s Law with a grain of salt

In developer productivity engineering circles, Goodhart’s Law is often cited as a caution against relying too heavily on metrics. It states: “When a measure becomes a target, it ceases to be a good measure.” Ultimately, it describes how a subject’s behavior changes the more it’s monitored.

For example, if a developer knows they’re being measured on lines of code, they might write more verbose or less efficient code to increase their line count. That’s worrisome for developer metrics, as it could lead to gaming. If the system becomes gamed, metrics become misleading and complicate any efforts.

Tacho responds with her own law: “If you’re worried about developers gaming a system, it’s a problem with the system, not the developer.”

Goodhart’s Law rears its ugly head when a lot is riding on an individual signal, like pull requests per engineer. “It’s felt most sharply when you only have one metric,” says Tacho.

The antidote, Tacho suggests, is to track a balanced system of metrics that hold each other accountable, such as throughput, cycle time, deployment frequency, and change failure rate. When these metrics are moving in tandem, it’s a sign of overall improvement. However, if one metric surges while the others stagnate, it’s a telltale sign that it’s being inflated.

Overall, juiced stats could stigmatize fruitful responses to productivity metrics. To insulate, Tacho recommends having a robust system of metrics and analyzing a wide breadth of contributors simultaneously, if possible. Then, you can trust the metrics enough to confidently act on them.

If you build it…

“This is not an ‘if you build it, they will come’ moment,” says Tacho. Taking developer productivity metrics into action requires more than a dashboard on a screen.

Although unearthed semi-recently, developer productivity engineering can trace its roots back to the agile and DevOps movements. 

“The concepts aren’t new, but now we have a better language and evidence about what actually works,” says Tacho. “The sooner an engineering director can realize their job is to articulate the needs and impact of their team in the language of business, the better off that whole team will be,” says Tacho.

The ultimate goal is to secure and retain more funding for engineering, thereby gaining more autonomy to invest in productivity tools. 

And maybe bringing back a bit of ping pong action, too.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.