"What engineering metrics should a CTO track?"

"The four DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — are the most reliable predictors of engineering team performance. Complement them with developer experience metrics (how long to go from code commit to production, how often does a deploy require manual intervention) and business outcome metrics (feature adoption rate, time from idea to customer value). Avoid measuring lines of code, story points completed, or hours worked."

Engineering Metrics CTOs Should Track (And the Ones That Don't Matter)

“We track velocity.” This is what most engineering leaders tell me when I ask how they measure their team’s performance. And it tells me almost nothing useful.

Velocity — measured in story points per sprint — is a planning tool, not a performance metric. It measures how much work a team estimates they can do, calibrated against how much work they’ve previously estimated they could do. It’s circular. It’s also trivially gameable: estimate bigger, “deliver” more points.

Here’s what I actually measure when I’m assessing an engineering team’s health.

The DORA Four

The DORA (DevOps Research and Assessment) metrics are the closest thing we have to a scientifically validated set of engineering performance indicators. Google’s research team studied thousands of engineering organizations and found four metrics that consistently predict both team performance and business outcomes.

Deployment frequency. How often does your team ship code to production? Elite teams deploy on demand, multiple times per day. Low-performing teams deploy monthly or less. This metric matters because it directly measures your team’s ability to deliver value to customers. If you can only deploy once a month, your maximum speed of learning is twelve experiments per year.

Lead time for changes. How long from code commit to production? Elite teams measure this in hours. Low performers measure it in months. Long lead times mean your good ideas sit in a queue, aging and accumulating merge conflicts, while competitors ship.

Change failure rate. What percentage of deployments cause a production incident? This measures your quality confidence. If deploying is risky, you deploy less often. If you deploy less often, each deployment is bigger. Bigger deployments are riskier. It’s a death spiral.

Time to restore service. When something breaks, how quickly do you fix it? This measures your operational maturity — monitoring, alerting, runbooks, and the team’s ability to diagnose and fix problems under pressure.

Developer Experience Metrics

DORA tells you about the delivery pipeline. But I also want to understand the developer’s daily experience, because that predicts retention and sustained performance.

Time to first productive commit. When you hire a new engineer, how long until they ship their first meaningful change? If the answer is “three weeks because our dev environment setup is a nightmare,” that’s both a hiring bottleneck and a quality-of-life issue for everyone.

Build and test cycle time. How long does a developer wait after pushing code before they know if it works? If your CI pipeline takes 45 minutes, your developers are context-switching to other work while they wait, which destroys flow state. I’ve seen teams get a 30% productivity increase just by cutting their CI time from 40 minutes to 8 minutes.

Manual steps per deploy. Every manual step in the deployment process is a source of human error and a scaling bottleneck. Count them. Automate them. At Home Depot, we achieved zero-downtime deployments by eliminating every manual step in the critical path.

Business Outcome Metrics

Engineering exists to create business value. These metrics connect the engineering organization to the outcomes the company cares about.

Feature adoption rate. What percentage of shipped features are actually used by customers? If you’re shipping features that nobody uses, your planning process is broken — and no amount of engineering efficiency will fix that.

Time from idea to customer value. Not time from ticket creation to deployment. Time from “we identified a customer need” to “customers are getting value from the solution.” This end-to-end metric reveals bottlenecks across the entire organization, not just engineering.

What Not to Measure

Lines of code. More code is not better code. Often the most valuable engineering work removes code.

Story points completed. As noted above, this is a planning input, not a performance measure.

Hours worked. This measures presence, not output. An engineer who solves a critical architecture problem in four hours of focused work has contributed more than one who spent twelve hours thrashing on a poorly defined task.

Individual developer metrics. The moment you start comparing individual engineers by any quantitative metric, you incentivize local optimization over team outcomes. Good engineering is collaborative. Measure teams, not individuals.