There is a specific kind of meeting that happens in software companies.
Usually quarterly. Sometimes more. Leadership reviews the engineering metrics – story points completed, sprint velocity, deployment frequency, tickets closed – and the numbers look good. The team is shipping. The dashboards are green.
And the product is still not growing.
Revenue is flat. Sales is still making apologies. The features that were supposed to unlock the next tier of customers are technically "done" but somehow haven't done anything.
Everyone is confused. The numbers say the team is performing. The business says otherwise.
Here is what's happening: velocity is not progress. It is often waste at scale.
What We Measure Is Not What We Care About
We measure what's easy to measure.
Story points are easy to measure. Deployment frequency is easy to measure. Sprint completion rate is easy to measure. Lines of code, PRs merged, tickets closed – all of it is easy to count.
None of it tells you whether the work mattered.
That's not a measurement problem. It's a decision problem. We made a choice, somewhere upstream, to treat these metrics as proxies for the thing we actually care about – which is: did we create value? Did this work connect to revenue, to retention, to something a customer recognized as meaningful?
And then we forgot we made that choice.
We stopped asking whether story points were a good proxy for value and started treating them as if they were value. We started optimizing for the metric instead of the thing the metric was supposed to represent.
This is not new. It has a name – Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." We know this. We cite it. And then we measure story points.
High Velocity Makes the Problem Worse
Here is the part that's counterintuitive.
A fast team that's pointed at the wrong problems isn't just unproductive. It's a liability.
Every sprint, they are building something. Accruing technical decisions. Creating dependencies. Writing code that will need to be maintained, understood, and extended by the next engineer who touches it.
If the direction is wrong – if the features being shipped aren't moving the metrics that matter – then velocity is the enemy. You are compounding your problem at high speed.
A slow team in the wrong direction can course-correct. A fast team in the wrong direction has already built the walls.
I've seen this play out. A product team spent six months executing flawlessly – shipping on time, low defect rate, high velocity, excellent eng/PM relationship. By the time they finished, they had built a beautifully engineered version of something customers didn't want. The fix took longer than the original build because now there was something to undo.
They hadn't failed to execute. They had executed perfectly on the wrong problem.
Where the Velocity Trap Comes From
Most velocity problems start at the roadmap level.
A roadmap is a prioritization system. It decides what work gets into the sprint queue. If the roadmap is disconnected from revenue signals – from what's actually causing deals to stall, customers to churn, renewals to slip – then the sprint queue fills up with work that feels important but doesn't connect to business outcomes.
Engineering then executes that work faithfully. Sometimes brilliantly.
And the business doesn't move.
The trap is that this can go on for a long time before anyone catches it, because all the intermediate signals look fine. Sprints are completing. Engineers are shipping. PMs are happy. The team culture is good.
The only signal that something's wrong is the business signal – and that's often attributed to sales, or market timing, or competition, before it's attributed to the execution system.
By the time leadership connects the dots, there are six months of misaligned work sitting in the codebase.
The Difference Between Speed and Direction
Speed is a measure of how fast you're moving.
Direction is a measure of where you're going.
They are not the same thing. And of the two, direction matters more.
An engineering team that ships slowly but only ships things that connect to revenue will outperform a fast team that ships constantly but builds things nobody uses. Not because slow is good – it's not. But because a slow team in the right direction eventually gets there. A fast team in the wrong direction doesn't arrive anywhere useful faster.
The goal is to optimize direction first, then make it fast.
This sounds obvious. It is almost never what organizations actually do.
What organizations actually do is hire faster engineers, add more PMs, adopt more agile tooling, and optimize the sprint process. All of which makes the team faster. None of which changes the direction.
What Fixing Direction Actually Requires
Fixing direction is a leadership problem, not an engineering problem.
It requires connecting three things that most organizations treat as separate:
What customers need most – not what they asked for, but what's actually blocking expansion, causing churn, or preventing the next purchase. This comes from sales conversations, customer success calls, churn interviews. Most engineering teams never see this data.
What the roadmap is actually building – not the description in the planning doc, but the real-world outcome it's designed to produce. If the team can't articulate what customer problem a feature solves and how you'll know it worked, the direction hasn't been set – it's been assumed.
What engineering is actually able to ship – given current capacity, technical debt, and existing dependencies. Roadmaps built without real engineering input are targets, not commitments. The gap between what product planned and what engineering can deliver is where most velocity evaporates.
When those three things connect – when the roadmap is built from revenue signals, framed in terms of measurable outcomes, and scoped against real engineering capacity – velocity becomes useful. Fast teams in the right direction are genuinely powerful.
But you have to fix the direction first.
The Metric That Actually Matters
I want to suggest a metric you probably don't track.
What percentage of features shipped in the last six months measurably moved a business outcome?
Not "were used." Not "got positive feedback." Not "were delivered on time." Measurably moved – adoption, revenue, retention, something that connects to the business logic of why you built this company.
Most organizations can't answer that question. Not because they don't care, but because they never established the measurement infrastructure to answer it. They captured story points and velocity. They didn't capture outcome data.
Start tracking that number. Even a rough version of it. It will tell you more about the health of your execution system than any sprint metric.
If that number is high – great. You have a fast team pointed in the right direction. Keep going.
If that number is low – you have a velocity problem. Not a speed problem. A direction problem. And adding resources or improving the sprint process will not fix it.
Moving Fast Is an Amplifier
Speed is not inherently good or bad.
It is an amplifier. It makes whatever direction you're pointed in arrive faster and with more force.
If you are pointed in the right direction, speed is your biggest advantage. You outlearn competitors. You iterate faster. You compound value.
If you are pointed in the wrong direction, speed is your biggest risk. You build faster, compound mistakes faster, and create more technical and organizational debt before the course correction happens.
The question isn't whether your team is fast. The question is whether fast is what you need right now.
For most organizations I work with, the answer is: not yet. Get the direction right. Build the measurement system. Connect the roadmap to revenue. Then make it fast.
A team that ships less but ships the right things will always outperform a team that ships constantly but hasn't found the target yet.
Find the target first.