Stop Measuring Developer Productivity. Start Measuring Decision Velocity.

The most dangerous metric in software engineering right now is not a bad one. It is a distracting one.

We are still measuring developer productivity the same way we did in 2015: commits, pull requests, story points, cycle time. None of these tell you whether your engineering organization is making good decisions. And in the AI era, decision quality is the only metric that matters.

Why Traditional Metrics Fail

AI has compressed the cost of writing code to near zero. A team that makes the wrong architectural decision can now ship the wrong system twice as fast. They can generate more tests for the wrong abstraction. They can build more features on the wrong foundation.

The traditional view of productivity assumed that more output meant more value. That assumption is broken. When code is cheap, bad decisions are expensive — and the metrics that measure output will never catch them.

What Decision Velocity Actually Means

Decision velocity is not about making decisions faster. It is about converging on the right decision faster, with fewer expensive reversals.

I measure it through four signals:

1. Decision speed: How long does it take to make a reversible decision? (Should be hours, not days.)

1. Decision quality: How many decisions are reversed within 90 days, and what was the cost of the reversal?

1. Decision distribution: How many people in the organization are empowered to make technical decisions without escalation?

1. Decision compound: Are today's decisions making tomorrow's decisions easier or harder?

What Changes When You Measure This

When you start measuring decision velocity, several things shift:

• Architecture reviews become faster because the baseline information is established before humans debate

• Escalation patterns become visible — you see exactly where decisions are bottlenecked and why

• Reversal costs become explicit — teams start measuring the cost of wrong decisions, which changes how they evaluate risk

• Authority boundaries become clear — you can see which decisions are being made at which level and whether that distribution is healthy

The Dashboard That Replaces Sprint Metrics

I do not care how many story points my teams completed last sprint. I care about:

• How long did it take to decide on the architecture for the new service?

• Was that decision reversed, and if so, what did the reversal cost?

• How many technical decisions were made without engineering leadership involvement?

• What is the average time from "we have a problem" to "we have a plan to solve it"?

These are the metrics that predict engineering outcomes. Commits predict nothing.

The Hardest Part

Measuring decision velocity requires trust. It requires admitting that some decisions were wrong and learning from them publicly. Most engineering cultures punish wrong decisions. Decision velocity measurement requires the opposite: surfacing reversals as data, not failures.

The teams that do this well create a culture where "I was wrong" is a signal that the decision-making system is working. The teams that do not will keep optimizing for speed of output while their competitors optimize for speed of learning.

Start Here

Pick one recent technical decision that did not work out. Ask yourself: how long did it take us to realize it was wrong? What would have surfaced the issue earlier? What signal were we not measuring?

That gap is where your decision velocity lives.

Would you rather be on a team that ships fast and reverses often, or a team that ships deliberately and learns forward?

Think this argument fits your event? Tell me about the room — the calendar is selective.