Developer velocity without metric theater

Engineering leaders want better visibility into delivery speed. That is reasonable.

What is not reasonable is pretending a handful of shallow metrics can explain how software work actually moves.

Velocity becomes metric theater when teams measure whatever is easiest to count and then act surprised when those numbers distort behavior. Commit counts rise. Pull requests get smaller in meaningless ways. People optimize for visible movement instead of valuable movement.

AI has given this problem a new costume. If the dashboard celebrates tool usage and the delivery system is unchanged, you have bought novelty.

Why metric theater happens

Metric theater usually begins with a legitimate need. Leaders want visibility. Product wants predictability. Teams want to know whether improvements are working.

The problem starts when measurement outruns understanding.

Instead of clarifying what kind of delay they are solving for, organizations collect numbers because the numbers are accessible. Once those numbers are visible, they become socially powerful even if they are weak indicators.

That is how teams treat activity as progress.

Useful velocity measurement begins with a more honest question: what kind of delay are we trying to understand?

Common answers include:

• work waiting too long for clarification
• reviews sitting with the wrong person
• environments and missing developer context slowing testing
• one-off integrations that should have been a primitive
• priorities changing because planning was never inspectable
• incidents creating rework because follow-through is not a system

Those are systems questions. They do not show up cleanly in a commit graph.

Developer experience is usually the missing metric

Developer productivity often breaks down because engineers repeatedly pay the same coordination or tooling cost.

I try to identify those patterns and turn them into better defaults. I am particularly interested in the point where productivity stops being an individual habit and becomes an engineering system.

When we worked on public APIs, API documentation, the Public API UI, and the Developer Portal, the goal was not a vanity self-serve surface. It was reducing the amount of developer context that had to travel through Support, TPMs, or individual engineers.

If partners and internal teams still need a human to explain the API, you do not have velocity. You have a queue with extra steps.

The same is true for integration deployment automation, observability defaults, and reusable workflows. Each one removes a class of delay that no sprint metric will name correctly.

Good metrics are diagnostic, not moral

Once the delay is named, metrics can help — as diagnostics.

• lead time can reveal process friction
• review turnaround can reveal collaboration bottlenecks or a manager who became the review path
• change failure rate can reveal quality debt
• planning accuracy can reveal missing specs or hidden dependencies

The cultural shift matters more than the dashboard. Metrics should help teams reason. Once a number becomes moralized, behavior bends around impression management.

If review speed is tracked, the goal is to find overloaded reviewers or a missing review layer — not to approve weaker work faster. I have been trying to split implementation review toward peers and technical leads, and keep more of my own time on architecture, contracts, and high-context risk. That change is a velocity intervention. It will not look like “more comments from the EM.”

AI will make theater cheaper unless you measure outcomes

I am helping lead how AI enters the software development lifecycle at SpotDraft: specifications, implementation, testing, reviews, project workflows, agent infrastructure, adoption.

The temptation will be to measure usage. Usage is easy. Outcomes are not.

I care about whether these systems create measurable engineering outcomes rather than simply increasing AI-tool usage. If specs get worse while drafts get faster, you have not improved velocity. You have moved the delay into review and production.

The same diagnostic question applies: where is work waiting now? If it waited on implementation and now waits on evaluation, the operating system has to change — review design, evaluation gates, and when a deterministic workflow is better than an agent.

Velocity is an operating-system question

No single metric explains throughput. The point is not certainty. The point is a better shared model of where time is lost.

I still stay technically close to the systems I lead. I increasingly measure impact by what continues to work when I am not directly involved. That includes whether engineers can ship without a private briefing, whether a reverse-sync primitive exists instead of another customer-specific job, and whether planning artifacts exist before a high-context effort like Legal Intake turns into status theater.

Teams move faster when measurement improves decisions. They move worse when measurement becomes theater.

Ask:

• Where is work waiting?
• Which repeated pain should have become a platform?
• Which handoffs are noisier than they should be?
• What quality issues are creating rework?
• Are we counting activity because the real system is hard to see?

Those questions lead to better operational improvements than generic pressure to move faster.