Engineering Velocity: What It Is, What It Isn't, and Why Platform Quality Is the Lever

Ask ten VPs Engineering what engineering velocity means and you will get ten different answers. Some mean story points per sprint. Some mean pull requests merged. Some mean number of features shipped per quarter. A few mean something closer to the right thing: how fast does value reach users?

The confusion matters because the metric you choose determines the behavior you get. Teams optimize for what they are measured on. If you measure story points, you get story points. If you measure features shipped, you get features shipped. Neither of these is the same as users getting value faster.

What engineering velocity actually measures

Engineering velocity is a system property. It describes the rate at which an engineering organization delivers value to users. Not the rate at which engineers write code. Not the rate at which tickets move across a board. The rate at which real changes reach real users and do something useful.

That definition has an important implication: velocity is an organizational output, not an individual one. A team of ten engineers working on a poorly designed deployment process can have lower velocity than a team of five engineers with a well-designed one. The bottleneck is not the engineers. It is the system around them.

This is why individual productivity metrics are the wrong tool. They answer the wrong question. The question is not "are the engineers working hard?" The question is "how fast does value move through the system from idea to user?"

Why the common proxies fail

Lines of code, story points, PRs merged — these metrics share a structural problem. All of them can increase without increasing real velocity.

An engineer who breaks one large PR into twenty small ones has not moved faster. An engineer who merges twenty trivial changes in a day has not delivered more value. A team that estimates generously and finishes every sprint at 100% has not shipped more. These metrics are gameable in ways that look good on a dashboard and mean nothing in practice.

The deeper problem: most of these metrics measure input, not output. They count what engineers do, not what users receive. The distance between engineering effort and user value is exactly where most delivery problems live — in slow deployment pipelines, in manual review processes, in coordination overhead that nobody counts as waste.

DORA as the best available proxy

The DORA research, conducted annually by the DevOps Research and Assessment program at Google Cloud and tracking thousands of organizations over more than a decade, identified four metrics that correlate most strongly with organizational performance: deployment frequency, lead time for changes, change failure rate, and mean time to restore. Source: dora.dev.

Of these, deployment frequency and lead time for changes are the most useful leading indicators of engineering velocity. Deployment frequency measures how often the organization is shipping. Lead time measures how long it takes a change to move from code commit to production. Together, they tell you how fast the system is actually moving value through.

High-performing organizations deploy on demand — multiple times per day. Lead time is under an hour. These are not aspirational targets for large, well-resourced companies. The DORA data shows high performers across all organization sizes and sectors. The gap between high and low performers reflects practice differences, not resource differences.

The platform engineering connection

DORA research consistently finds that software delivery performance is correlated with technical practices: continuous delivery, loosely coupled architecture, automated testing. These are not team-level concerns. They are platform-level concerns.

A product team does not own the deployment pipeline — the platform team does. A product team does not own the test infrastructure — the platform team does. A product team does not own the observability stack that tells you whether a deployment succeeded — the platform team does. When any of these are slow, unreliable, or hard to use, every team building on them is slower.

This is why engineering velocity is a platform engineering problem as much as it is an engineering leadership problem.

Why platform quality is the leverage point

A team deploying once a week is not slow because the engineers are slow. They are slow because deploying is slow. The process requires manual steps. The test suite takes 45 minutes to run. A deployment window needs to be scheduled three days in advance. Senior engineers need to be involved. None of these are problems with the engineers. All of them are platform problems.

Fix the platform, fix the velocity. This is the leverage point that individual productivity metrics completely miss, because no individual productivity metric can see the deployment pipeline. It is infrastructure. It is invisible in the data until you measure the right things.

The organizations that have made the largest velocity improvements did not change their hiring bar or their sprint process. They invested in faster pipelines, automated testing with useful coverage, self-service deployment, and observability that tells teams immediately whether a change worked. The engineers were already working. The system around them was what needed to change.

What VP Engineering should track

Two leading indicators: deployment frequency and lead time for changes. These tell you how the system is performing in aggregate, without requiring you to measure individual engineers.

One lagging indicator: change failure rate. This tells you whether faster deployment is trading off against stability. If deployment frequency goes up but change failure rate follows, the quality foundations are not keeping pace.

One qualitative signal: developer experience survey data. DX surveys that ask engineers where they spend time they wish they weren't spending are the best early warning system for platform friction. Engineers know exactly what is slowing them down. Asking them is faster and cheaper than instrumenting everything.

What not to track: individual productivity, story point velocity, code volume. These metrics answer questions you should not be asking, and they create incentives that push in the wrong direction. The engineer who ships one carefully considered change that removes a deployment bottleneck has created more velocity than the engineer who merges twenty PRs that nobody needed.

For a structured read on how DORA metrics connect to platform investment decisions, DORA metrics for engineering leaders covers the measurement setup in detail. If you want a baseline of where your platform currently sits, the Foundations Assessment produces specific data across deployment, testing, and observability dimensions. The broader framing of what developer experience means as a platform concern is in the developer experience glossary entry.