# Metrics Are Easy. Standardization Is Hard. | LinearB Blog

> Learn how to build a data-driven developer productivity initiative with clear metric definitions. Align teams while respecting workflows for meaningful insights

[Blog](https://linearb.io/blog)

/

Metrics Are Easy. Standardization Is Hard.

# Metrics Are Easy. Standardization Is Hard.

![Photo of Dan Lines](https://assets.linearb.io/image/upload/v1721418067/Dan_Lines_3fb5152de2.jpg)

By [Dan Lines](https://linearb.io/blog/metrics-are-easy-standardization-is-hard#dan-lines)

|

January 28, 2025

![Metrics_are_Easy_Standardization_is_Hard_2025_d6ca4e4376](https://assets.linearb.io/image/upload/v1740003944/Metrics_are_Easy_Standardization_is_Hard_2025_d6ca4e4376.png)

If there’s one thing I’ve learned from working with leading engineering teams, it’s that building a data-driven [developer productivity](https://linearb.io/blog/developer-productivity) initiative is never as simple as it sounds. You pick the metrics, set up the dashboards, and then?

_Confusion._

Suddenly, the team is asking: _“Wait, what does ‘in progress’ really mean, anyway? Does it start when we open a Jira ticket or when someone has an idea?”_

Even the biggest champions of the initiative find themselves grappling with the same issue: _“Cool, data… now what?”_ [The real challenge isn’t the metrics themselves, it’s standardization.](https://devinterrupted.substack.com/p/the-hero-culture-trap-sowmya-subramanian)

## The Battle for Standardization

I’ve seen teams trip up on this at every scale. Obtaining the metrics is usually fine. Tools like LinearB or other platforms make it easy to grab essentials like [cycle time](https://linearb.io/blog/cycle-time) or [change failure rate (CFR)](https://linearb.io/blog/how-to-improve-change-failure-rate).

To solve this problem, you need a balance two things:

* teams must have the _flexibility_ to define how metrics are measured within their workflows…
* … but those measurements must also be _consistent_ enough to roll up into a unified view for executives

Take the “in progress” example from before. One team might define it as the moment a Jira ticket is assigned, while another might start the clock when the first commit is made. Both approaches are valid, as long as they align with the company-wide definition of what _“in progress_” means.

This approach creates clarity at the organizational level while allowing teams to work in ways that suit their unique workflows.

![Rock and a Hard Place](https://assets.linearb.io/image/upload/v1737132922/image1_b68d330dd4.gif)

## A Rock and a Hard Place

This balance, _flexibility_ for teams and _consistency_ for leadership, is where the challenge lies. It sounds simple in theory but is incredibly hard to implement at scale.

For example, metrics like MTTR (mean time to resolution) often need to pull data from multiple sources: bugs in Jira, incidents in PagerDuty, continuous delivery failures, and more. Without a system that can unify these inputs into a consistent metric, you end up with confusion at the reporting level.

This is where configurability becomes critical. A robust platform should allow teams to integrate their preferred tools and processes while adhering to company-wide definitions that leadership can trust.

LinearB excels here, offering enterprise-grade configurability that no one else can match. It empowers teams to adapt metrics to their workflows while delivering consistent, actionable data to executives, something other platforms simply can’t do at scale.

This is why standardization is hard:

* To make metrics effective, you need to respect the nuances in how different teams work, while still aligning on a shared company-wide understanding.
* Without this alignment, you risk disengaging your developers and turning metrics into a source of frustration instead of improvement.
* It’s not about _uniformity_, it’s about creating a _shared language_ so you can actually use the data.

## Improve developer productivity with LinearB

Find us on

[](https://www.linkedin.com/company/linearb)
[](https://devinterrupted.substack.com/)

## Your next read

[![Cover image for AI ROI comes from measuring engineering outcomes on day one](https://assets.linearb.io/image/upload/v1783720449/Blog_AI_ROI_comes_from_measuring_engineering_software_security_2400x1256_2c5eae0862.png)](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Eng. Metrics

[AI ROI comes from measuring engineering outcomes on day one](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Kraken Engineering Operations Lead Nik Sudan details how to establish day-one data infrastructure to accurately measure AI ROI. Discover why raw token adoption...

[![Cover image for AI is rebuilding software delivery from SDLC to ADLC](https://assets.linearb.io/image/upload/v1783144233/Blog_AI_rebuilding_software_delivery_2400x1256_3fd5887e75.png)](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation)

Eng. Metrics

[AI is rebuilding software delivery from SDLC to ADLC](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation)

Discover how engineering organizations are transitioning from the traditional SDLC to an Agentic Development Lifecycle (ADLC). Learn why rising token costs...

[![Cover image for 8 million pull requests reveal where engineering productivity breaks down](https://assets.linearb.io/image/upload/v1778099498/Blog_8_million_pull_requests_2400x1256_03724bfbb2.png)](https://linearb.io/blog/8-million-prs-engineering-productivity)

Eng. Metrics

[8 million pull requests reveal where engineering productivity breaks down](https://linearb.io/blog/8-million-prs-engineering-productivity)

8.1M pull requests reveal the gap between AI adoption and engineering impact, and why code review is the bottleneck blocking real productivity gains.