Why I Track Engineering Metrics Differently

If you ask most PMs what metrics they track, you will hear velocity, sprint burndown, and story points completed. These metrics are popular because they are easy to extract from Jira. They are also nearly useless for making decisions.

The Problem with Velocity

Velocity measures output in an arbitrary unit that varies between teams, changes over time, and incentivizes gaming. When you track velocity as a performance metric, teams inflate points. When you compare velocity between teams, you compare apples to the concept of fruit.

I stopped reporting velocity to stakeholders two years ago. Nobody noticed, because the information they actually needed was always something else.

What I Track Instead

Cycle time. How long does it take from "work started" to "work in production"? This tells me where bottlenecks live. If cycle time is growing, something is broken — blocked reviews, environment issues, deployment delays. Cycle time is a health indicator, not a performance metric.

Flow efficiency. What percentage of cycle time is spent on active work versus waiting? Most teams discover that their work spends more time waiting than being worked on. This metric makes invisible queues visible.

Defect escape rate. How many bugs reach production versus being caught in development? This tells me whether our quality practices are working without measuring something meaningless like "total bugs found."

Forecast accuracy. When I commit to a delivery date, how often do I hit it? This is the meta-metric — it tells me whether my planning process is working. I track this at the program level across all three accounts.

The Dashboard

The Engineering Intelligence Platform aggregates these metrics from Jira and our CI/CD pipeline. My tech leads see the same dashboard I do. There is no "PM version" of reality. Shared metrics create shared accountability.

Measure what matters, not what is easy to measure.