Metrics such as story points completed, deployment frequency, cycle time, lead time and tickets closed were introduced to help organisations understand how software teams work. Used correctly, they can reveal bottlenecks and highlight areas where delivery processes need improvement.

The problem starts when these measurements become targets.

Once a number becomes a performance objective, teams naturally begin optimising for the number.

Engineering starts asking how to increase velocity rather than whether the work being accelerated actually matters.

A company can therefore become extremely efficient at producing software while becoming increasingly inefficient at creating business value.

What Engineering Velocity Metrics Actually Measure

Engineering velocity metrics are useful because software development is difficult to observe from the outside.

A business leader cannot always see why a feature took three weeks, why a deployment was delayed or why an engineer spent two days resolving a seemingly small issue.

Metrics provide visibility.

Cycle time can indicate how long work takes to move through the development process. Deployment frequency can show how regularly teams release changes. Lead time can help identify delays between an idea and production. Defect and change-failure measures can provide signals about software quality and operational stability.

The mistake is assuming that these measurements represent the entire performance of an engineering organisation.

They do not.

They measure specific aspects of delivery.

They do not automatically tell you whether the team selected the right problems, whether customers benefited from the release, whether the architecture became healthier or whether the work contributed to revenue, efficiency or strategic differentiation.

That gap is where misleading interpretations begin.

When Velocity Becomes the Goal, Behaviour Changes

Imagine an engineering team is told that its velocity needs to increase by 20%.

The intention may be to improve productivity.

The team, however, has several ways to make the metric move.

It can break work into smaller tickets. It can prioritise easier tasks. It can avoid complex technical improvements that are difficult to measure. It can reduce collaboration time because meetings appear to slow delivery. It can focus on work that can be completed quickly rather than work that creates the greatest value.

The metric improves.

Engineering velocity looks better.

The underlying organisation may not be better.

This is a classic measurement problem: once people know what is being measured, they adapt their behaviour around the measurement.

That does not mean engineers are manipulating the system. It means the system is rewarding a particular definition of productivity.

If leadership defines productivity as throughput, teams will naturally optimise throughput.

Story Points Were Never Designed to Measure Individual Productivity

Story points are one of the clearest examples.

They are intended to help teams estimate the relative effort, complexity or uncertainty associated with work. They are useful within a team when used consistently as part of planning.

They become problematic when management compares story points across teams or uses them to assess individual engineers.

A team that reports 80 story points in a sprint is not necessarily more productive than a team reporting 40.

The numbers depend on estimation practices, team composition, work type and the team’s own reference points.

Trying to turn story points into a universal productivity currency creates incentives to inflate estimates or divide work differently.

The organisation ends up measuring the mechanics of estimation rather than the value of engineering.

Faster Delivery Can Produce More Waste

Speed is valuable when it reduces the time required to deliver something useful.

But speed without prioritisation can increase waste.

Consider a product team that can now release twice as quickly because its development process has been streamlined.

That sounds positive.

But if half of the releases address low-value requests, the organisation has simply become more efficient at delivering low-value work.

This distinction is particularly important in large enterprises where engineering teams receive requests from many stakeholders.

Sales wants custom functionality. Operations wants workflow changes. Marketing wants another integration. Compliance wants a new reporting capability. Leadership wants an executive dashboard.

The engineering organisation can become extremely busy satisfying requests.

Velocity rises.

Strategic progress does not necessarily follow.

The real question is therefore not “How much can engineering deliver?”

It is “Which outcomes deserve engineering capacity?”

DORA Metrics Are Useful, but They Are Not a Business Scorecard

Modern engineering organisations often use DORA-style delivery performance measures to understand software delivery.

These metrics can provide valuable signals around software delivery performance, particularly when organisations want to identify bottlenecks and improve the reliability and speed of their delivery systems.

But even strong engineering metrics have boundaries.

Deployment frequency does not tell you whether the deployed functionality matters.

Lead time does not tell you whether the underlying requirement was strategically important.

Change failure rate does not tell you whether the product solved the customer’s problem.

Recovery time does not tell you whether the application is creating enough business value to justify its operating cost.

The mistake is not using these metrics.

The mistake is asking them questions they were never designed to answer.

The Missing Metric Is Often Business Impact

Engineering performance becomes much easier to understand when delivery metrics are connected to outcomes.

Suppose a retail company launches a new checkout capability.

Engineering might report that the feature was delivered in 18 days, deployed successfully and had no major production incidents.

Those are useful facts.

But the business needs to know more.

Did checkout completion improve? Did cart abandonment fall? Did support requests decrease? Did transaction volume increase? Did the change improve mobile conversion?

Without those measures, leadership knows that engineering delivered the feature.

It does not know whether the feature was worth delivering.

This is why engineering metrics need to sit inside a larger chain:

Engineering activity → Product behaviour → Business outcome

The first layer is relatively easy to measure.

The third is where strategic value becomes visible.

Technical Work Often Looks Slow Because It Is Valuable

Another problem with velocity metrics is that some of the most important engineering work produces very little visible output.

Refactoring a critical service may not create a new feature.

Improving observability may not increase ticket throughput.

Replacing a fragile integration may not change the user interface.

Reducing technical debt may actually make the team’s short-term velocity look worse.

But these activities can dramatically improve the organisation’s ability to change the system later.

If leadership evaluates engineering primarily through feature throughput, teams can become reluctant to invest in this work.

The organisation then accumulates technical debt while celebrating delivery efficiency.

Eventually, the contradiction becomes visible.

Features take longer. Incidents become more expensive. Changes require more coordination. Developers spend increasing amounts of time understanding old systems.

Velocity falls.

Leadership then asks engineering to move faster.

The underlying problem was created by the measurement system itself.

Innovation Is Especially Difficult to Measure Through Velocity

Innovation creates another measurement problem.

Exploration is uncertain.

A team might spend three weeks testing an idea and conclude that customers do not need it.

From a delivery perspective, almost nothing was shipped.

From a product perspective, the team may have saved months of unnecessary development.

That is valuable learning.

But conventional velocity metrics rarely capture it.

This creates a bias toward predictable work.

Teams prefer requirements that are already understood because predictable work is easier to estimate and measure. Experimental work introduces uncertainty and can make delivery performance appear worse.

Over time, an organisation can become very efficient at incremental development while becoming less willing to explore genuinely new opportunities.

The business thinks it is improving engineering productivity.

It may actually be reducing its capacity for innovation.

AI Makes This Measurement Problem More Important

AI-assisted development is making the question even harder.

Engineering teams can increasingly use AI tools to generate code, write tests, investigate documentation, refactor components and accelerate parts of the development process.

This can increase the amount of software an organisation is capable of producing.

But more code is not automatically more value.

If AI increases development capacity while product prioritisation remains weak, businesses may simply create more functionality, more dependencies and more maintenance obligations.

Traditional velocity metrics may even improve dramatically.

That does not mean the organisation has become more innovative.

The bottleneck may have moved.

When software production becomes faster, decision quality becomes more important.

The ability to determine what should not be built can become more valuable than the ability to build another feature quickly.

What Businesses Should Measure Instead

The answer is not to eliminate engineering metrics.

It is to stop expecting one category of metrics to explain everything.

A more balanced engineering measurement system should connect delivery performance with product, operational and business signals.

For example, organisations can look at:

• Delivery health: cycle time, deployment frequency, lead time and change failure rate.
• Product impact: adoption, retention, task completion, conversion and customer satisfaction.
• Operational health: reliability, incident volume, recovery performance and infrastructure efficiency.
• Engineering health: technical debt, maintainability, architecture quality and developer friction.
• Business impact: revenue contribution, cost reduction, process efficiency and strategic capability.

The important part is not collecting dozens of metrics.

It is understanding the relationship between them.

If deployment frequency increases while customer adoption remains flat, leadership should investigate.

If cycle time improves while technical debt rises rapidly, there may be a hidden cost.

If feature throughput falls but reliability and customer outcomes improve, the organisation may actually be making better engineering decisions.

Context matters more than the number.

Metrics Should Help Teams Ask Better Questions

Good engineering metrics are diagnostic tools.

They help teams investigate what is happening.

Bad metrics become judgement mechanisms.

They are used to rank teams, compare individuals or create arbitrary performance targets without understanding the work behind the numbers.

A healthy engineering organisation might look at rising cycle time and ask whether dependencies, architecture or decision-making are causing delays.

An unhealthy organisation might simply demand that cycle time fall by 15%.

The first approach searches for the cause.

The second pressures the system to produce a better number.

That distinction is crucial.

Metrics should create better conversations between engineering and business leadership, not replace those conversations.

The Best Engineering Teams Are Not Always the Fastest

There is a temptation to believe that the strongest engineering organisation is the one that ships the most software with the least effort.

That definition is incomplete.

A high-performing engineering organisation should be able to make good decisions, deliver reliably, maintain a healthy architecture, respond to changing business requirements and create measurable customer or operational value.

Sometimes that means moving extremely fast.

Sometimes it means slowing down to redesign a fragile system.

Sometimes it means refusing a feature request.

Sometimes it means spending an entire quarter reducing technical debt.

Sometimes it means running an experiment that never reaches production.

Velocity is therefore only one dimension of engineering performance.

The real advantage comes from knowing when speed creates value and when speed simply creates more work.

Engineering Metrics Need Business Context

For CTOs and technology leaders, the goal should not be to find a perfect engineering productivity metric.

There isn’t one.

Instead, leadership needs a measurement system that reflects how engineering contributes to the business.

Delivery metrics should explain how work moves.

Product metrics should explain what users do with what is delivered.

Operational metrics should explain how reliably the technology performs.

Business metrics should explain whether all of that activity actually matters.

When these layers are connected, engineering velocity becomes useful again.

A sudden increase in cycle time can signal a genuine problem. A reduction in deployment frequency can prompt investigation. A rise in change failures can expose architectural or process weaknesses.

The metric becomes evidence rather than a target.

That is the difference between measuring engineering and managing engineering by numbers.

How Verbat Technologies Helps Businesses

Improving engineering performance often requires more than changing development metrics. Organisations may need to modernise applications, simplify architectures, improve integration, strengthen engineering practices and create better connections between technology delivery and business objectives.

Verbat Technologies works across custom software development, product engineering, application modernization, enterprise application integration, API development, cloud solutions, DevOps, AI/ML and digital transformation to help businesses improve the technology foundations behind their digital operations.

The objective is not to make engineering teams look faster on a dashboard.

It is to help them become more effective at creating reliable, adaptable technology that produces measurable business value.

The fastest engineering team is not necessarily the most productive one.

The more important question is whether the organisation is becoming better at turning engineering capacity into outcomes.

A metric can tell you how fast the machine is running.

It cannot, by itself, tell you whether the machine is going in the right direction.