The Metric Trap: When Doing Less Means Achieving More
The most valuable platform engineering work often makes tickets disappear, not appear. What happens when we measure activity instead of outcomes?
Every engineering organisation wants to know the same thing:
“How do we know if we’re being productive?”
We create dashboards, track velocity, measure cycle times, and count tickets completed because numbers feel objective.
For many engineering teams, these metrics are useful.
But what if we’re measuring the wrong things?
A product team can often point to something tangible.
A new feature.
A customer improvement.
A bug fix.
Platform engineering is a little different.
Some of the most valuable work is the work that means something never happens.
We often measure what is visible, but some of the best engineering work is making things invisible. And invisible work is much harder to measure.
You can’t measure the incident that didn’t happen
Imagine a platform team spends a month improving their deployment process.
They build automation. They improve observability. They create a self-service workflow.
At the end of the month, someone looks at the Jira dashboard.
“The team closed fewer tickets this month.”
Did they become less productive?
Or did they remove the need for those tickets to exist?
That is the metric trap.
We are measuring activity because activity is easy to count.
But the outcome we actually care about is often the reduction of unnecessary activity.
The work didn’t disappear. It moved.
Imagine a developer needs a new environment.
Before, they create a Jira ticket. An engineer manually provisions the infrastructure, configures everything, and closes the request.
The Jira board shows activity.
After investing in a platform, the same developer follows the golden path. They commit some YAML, a pipeline runs, the infrastructure is provisioned, certificates are issued, DNS is updated, and the application is deployed.
No ticket is required.
The Jira board shows less activity.
But the organisation is objectively better.
The work didn’t disappear.
It moved.
The complexity was absorbed into the platform so that future developers no longer have to solve the same problem.
The danger of measuring the wrong thing
This isn’t an argument against Agile, Scrum, Kanban, or Jira.
They are all valuable tools for organising work.
The challenge is assuming every engineering team creates value in the same way.
A product team often creates value by building something new.
A platform team often creates value by removing friction.
If we only measure visible activity, we risk rewarding the wrong behaviours.
More manual work.
More tickets.
More repeated effort.
Ironically, the best automation often results in fewer tickets appearing on the board.
Not because the team is doing less.
Because they solved the problem.
The invisible work
A mature platform team might have fewer tickets flying across a Jira board, but that doesn’t mean they’re less busy.
Often the opposite is true.
Instead of manually responding to the same requests every day, they’re building automation, improving reliability, strengthening security, reducing operational risk, and creating better experiences for the engineering teams around them.
The work hasn’t become smaller.
It’s become more strategic.
Measuring what matters
Maybe the question shouldn’t only be:
“How many tickets did we close?”
Maybe we should also ask:
“How much unnecessary work did we remove?”
The outage that never happened.
The manual process that became automation.
The ticket that was never created.
These things rarely appear on a dashboard.
But they are often some of the most valuable engineering work we do.
The goal of engineering isn’t to create more work.
It’s to build systems that make valuable work easier.
Comments