How to make the case for engineering metrics

Making the case for engineering metrics means convincing the people who fund them, and the people who'll be measured by them, that measurement is an accelerant rather than an audit. Most cases fail on the framing before they reach the numbers: metrics pitched as risk reduction land in the cost column, where they compete with everything else that might be cut.

Winning that argument is an engineering management job before it is a measurement job. It means knowing which objection you're facing, who holds the budget, and what they will accept as proof, and the steps below cover that pitch. Once the program exists, reporting its results to the board is a different conversation with its own rules.

Know which objection you're facing. Finance objects to metrics as cost. Engineers object to metrics as surveillance. Leadership objects to metrics as noise they can't act on. These need different cases, and a pitch written for one lands badly with the others.

Christine Yen, CEO and co-founder of Honeycomb, has spent a decade making the measurement case for observability, and she's candid that the finance objection is often legitimate as stated.

"There are probably many CFOs that would say that their teams have over-invested in observability, right? But that's because they're looking at it from a single lens."

— Christine Yen, CEO and co-founder of Honeycomb, on Dev Interrupted, Observability is your profit center now

The lens is the whole case. Change it before arguing about cost.

The first question to settle is where measurement sits in the company's mental ledger. Yen frames it as the question that decides everything downstream.

"Do you talk about engineering as a cost center or a profit center, right? For a lot of companies in tech, the answer is, like, obviously engineering builds the product that we sell. And yet there are some classes of tools that are viewed as risk mitigation or insurance almost, and so put in the cost category."

— Christine Yen, CEO and co-founder of Honeycomb, on Dev Interrupted, Observability is your profit center now

Engineering metrics get filed as insurance the moment the pitch leads with visibility or risk. The case has to lead with what the measurement lets the organization do faster. Yen's own argument for observability applies directly:

"Tools that enable faster feedback loops, that enable more confident development, that enable more change to be made more frequently, more confidently, those tools should be moved into the profit center. They should be moved into accelerants."

— Christine Yen, CEO and co-founder of Honeycomb, on Dev Interrupted, Observability is your profit center now

Write the ask in those terms. Not "we need visibility into cycle time" but "we need to know which stage to fix so that changes ship faster," which is a claim the people holding the budget can evaluate.

Leadership can't act on a metric they have to translate. Yen's test for which signals matter is whether they describe the customer's experience rather than the system's internals.

"It's probably not CPU hits 70% utilization, CPU hits 75, CPU hits 90. Let's step away from that pattern. It probably is conversations like, if we are an e-commerce platform and our checkout rate drops and sustains that drop for some amount of time."

— Christine Yen, CEO and co-founder of Honeycomb, on Dev Interrupted, Observability is your profit center now

The engineering-metrics equivalent is to open with the business question the program will answer. "How long does a committed feature take to reach customers, and where does it wait" is a question a CEO cares about. "We'd like to track pickup time and review depth" is the implementation detail that follows, and it belongs on the second slide.

The case for metrics fails fastest with the people who'll be measured. The objection is that metrics will be used to rank individuals, and the only durable answer is a commitment in the program's design: teams are compared against their own baseline, never against each other, and nothing is reported at the individual level.

Say that before anyone asks. A metrics program that engineers trust gets used; one they distrust gets gamed, and gamed data is worse than none. The commitment costs nothing and removes the objection that otherwise shadows every later conversation.

The strongest evidence that measurement is working is engineers reaching for the data unprompted, before any number improves. Yen's best customers track exactly that.

"They've moved past the 'have we reduced our downtime,' and they've moved towards things like how many of our pull requests or GitHub issues reference Honeycomb URLs? Because that becomes a signal that our engineers are thinking ahead."

— Christine Yen, CEO and co-founder of Honeycomb, on Dev Interrupted, Observability is your profit center now

Propose the engineering-metrics version as part of the case: within two quarters, delivery data should be cited in planning decisions, retrospectives and pull request discussions. That's the leading indicator that the program moved from reporting to practice, and it's what you'll show the sponsor when they ask whether it's working.

The last part of the case is about what the program will produce. Dashboards are the wrong promise; nobody funds another dashboard. The promise is that questions that currently take a week of spreadsheet archaeology get answered in minutes.

"When the cost of answering a question drops, you can ask more questions, thus building up the reps to ask better questions."

— Christine Yen, CEO and co-founder of Honeycomb, on Dev Interrupted, Observability is your profit center now

The case closes on a concrete example of a question the organization couldn't answer last quarter and could with the program in place.

The sponsor's questions shift from "what does this cost" to "what else can it tell us." Engineers cite the data without being asked. And the metrics show up in decisions, not just reports, which is the difference between a program and a dashboard.

Leading with visibility or risk and landing in the cost column. Opening with engineering vocabulary the audience has to translate. Letting the surveillance objection go unanswered until it's already killed engineer trust. And promising dashboards when the real product is faster answers.

How do I convince a CFO to fund engineering metrics?

Reframe the program as an accelerant rather than insurance: the ask is to know which delivery stage to fix so that changes ship faster, stated in business terms with a proof metric attached.

How do I get engineers to accept metrics?

Commit in the program's design that teams are measured against their own baseline, never ranked against each other, and that nothing is reported at the individual level. Say it before anyone asks.

What's the first metric to propose?

Not a metric. A business question the program will answer, such as how long committed work takes to reach customers and where it waits. The metrics follow from the question.