Velocity stopped meaning anything

Velocity was a useful metric because shipping was hard. If a team pushed features out quickly and reliably, that told you something real: they'd solved the coordination and execution problems that slow most teams down. Speed was a proxy for competence because speed was scarce.

Agents made speed cheap. A small team, or one capable person, now ships at a rate that would have looked heroic two years ago. When everyone can move fast, moving fast stops distinguishing anyone. The proxy broke.

Velocity was a useful metric because shipping was hard.

Velocity metrics are sticky, though. Teams still count story points and cycle time and features shipped, and leaders still read those numbers as health. So a team that shipped twelve things nobody uses looks stronger on the page than a team that shipped three that moved the business. A high number now can mean a team is producing the wrong things quickly. That's worse than producing slowly, because it burns the one thing still scarce: judgment about what deserves to exist.

A better velocity metric won't fix this. Ask a different question instead. Shipping is the baseline. Landing is the read. Every launch should carry a status set from measured numbers rather than from the mood of the room: landed, watch, or stalled. Landed means the number you said would move, moved. Watch means it's early and the signal is thin. Stalled means it shipped and nothing happened.

That last one is where teams flinch, and it's the whole value of the exercise. A stalled launch nobody marks stalled stays in the roadmap deck as a win. The team keeps building on top of a thing that isn't carrying weight. Marking it costs one uncomfortable sentence and saves a quarter. Label the confidence while you're there. Some of what a team believes about a launch is measured. The rest is still a bet. Both get quoted in the same tone of voice at the same meeting.

The pace is what makes this urgent. In 2015 you could run a product from a laptop the way you read a car's diagnostics after the session: pull the numbers, review them next week, adjust. Development with agents runs at Formula 1 speed, and a review-it-next-week loop is several laps too slow. What that pace needs is a pit wall: one live surface across strategy, design, the build, and go-to-market, where a person decides mid-race what to change. Strategy and operations stop being two jobs at that surface.

So the real read on a fast team is a question, not a compliment. Fast at what. Building toward what. Landed or stalled, and how do you know. If the answer is a clear view of what's worth building plus measured evidence it's connecting, the speed is leverage. If the answer is a full backlog and a lot of motion, the speed is a liability wearing a strength's clothes, because it lets a team be wrong at scale.

None of this means slow down. It means stop reading speed as the scoreboard. Anyone can be fast now. The teams worth copying are fast and pointed at the right things, and they can show you which of the last ten launches landed. The second half of that sentence is the hard part, and it's the whole job.