If velocity is killing us, what should we measure instead? Looking for frameworks that balance speed with sustainability

alex_infrastructure · March 15, 2026, 9:19am

I need to confess something: as VP Product, I spent the last three years optimizing for the wrong metrics. And I’m watching those chickens come home to roost.

The Velocity Obsession

When I joined this company in 2022, our board had one message: move faster. Our competitors were shipping features weekly. We were shipping monthly. We were losing deals because our product roadmap looked slow compared to competitors.

So I did what any ambitious product leader would do: I optimized for velocity. Every board meeting, I reported on story points delivered. Every sprint, I pushed for more throughput. Every planning session, I asked ‘how can we ship this faster?’

And it worked! Our velocity increased 47% over two years. Our feature release cadence went from monthly to bi-weekly. Our roadmap execution rate went from 60% to 85%. By every metric I was tracking, we were crushing it.

Except we weren’t.

The Metrics That Told the Real Story

While I was celebrating velocity wins, other metrics were quietly degrading:

Customer Satisfaction (CSAT): Declined from 4.2 to 3.7 out of 5
Net Promoter Score (NPS): Dropped from +42 to +28
Support Tickets: Increased 34% year-over-year
Bug Reports: Up 41% despite ‘better testing’
Feature Adoption: Down—customers weren’t using half the features we shipped
Churn Risk: Increased 18% among enterprise customers

I was hitting my velocity targets and missing the point entirely. We were shipping faster, but we were shipping the wrong things, with lower quality, creating more problems than we solved.

The Wake-Up Call

Last quarter, I lost a major renewal—a 00K ARR customer who’d been with us since 2020. The exit interview was brutal:

‘You’re shipping so many features we can’t keep up. Half of them don’t work properly. The other half we don’t need. We asked for better performance on the core features we use every day, and instead you gave us fifteen new features we’ll never touch. Your product used to be focused and reliable. Now it’s bloated and buggy.’

That hurt. But it was true.

I’d optimized for velocity and feature count while ignoring whether we were actually delivering customer value. I’d treated software development like a factory—measure output, maximize throughput—when it’s actually a creative and quality-driven process.

The Frameworks I’m Researching

I’ve been digging into alternative frameworks that balance speed with sustainability and quality:

1. DORA Metrics (DevOps Research and Assessment)
Four key metrics:

Deployment Frequency: How often we ship to production
Lead Time for Changes: Time from commit to production
Change Failure Rate: Percentage of deployments causing issues
Time to Restore Service: How quickly we recover from incidents

The insight: velocity is only valuable if it doesn’t increase failure rate or reduce reliability.

2. SPACE Framework (Satisfaction, Performance, Activity, Communication, Efficiency)
Looks at developer productivity from five dimensions, not just activity/velocity. Includes developer satisfaction and wellbeing as first-class metrics.

The insight: sustainable productivity requires happy, healthy engineers, not just more output.

3. DevEx Metrics (Developer Experience)
Focuses on friction in the development process:

How long does it take to get feedback on code?
How often are engineers blocked?
How much time is spent on toil vs. creative work?

The insight: reducing friction increases sustainable velocity more than pushing for more output.

4. Outcome Metrics Over Output Metrics
Instead of measuring features shipped, measure:

Customer value delivered (adoption, satisfaction, retention)
Business impact achieved (revenue, conversion, efficiency)
System health maintained (reliability, performance, security)

The insight: shipping features is meaningless if they don’t move business or customer metrics.

What I’m Proposing

I’m working with our CTO Michelle and VP Engineering Keisha to redefine what ‘success’ means for our product organization. Here’s the framework I’m proposing:

Tier 1: Outcome Metrics (What We’re Trying to Achieve)

Customer satisfaction (CSAT/NPS)
Feature adoption rates
Business impact (revenue, conversion, retention)
Customer-reported quality (bug reports, support tickets)

Tier 2: Health Metrics (Can We Sustain This?)

System reliability (uptime, MTTR)
Code quality (technical debt, security vulnerabilities)
Team health (developer satisfaction, retention, burnout indicators)
Deployment safety (change failure rate)

Tier 3: Velocity Metrics (Are We Moving Fast Enough?)

Feature delivery rate
Sprint velocity
Lead time for changes
Deployment frequency

The key difference: velocity is the lowest priority tier. We measure it, but we don’t optimize for it unless Tier 1 and Tier 2 are healthy.

The Pushback I’m Expecting

I know what the board is going to say: ‘This is too complicated. Velocity is simple. We can track it easily. Why make this harder?’

My answer: because velocity is a lagging indicator of productivity, and it’s easily gamed. Teams can ship faster by cutting corners, skipping tests, ignoring technical debt, and building features customers don’t want. Velocity goes up, but value and sustainability go down.

We need leading indicators that tell us we’re building the right things, the right way, for the long term.

What I Need from This Community

I know I can’t be the first product leader to realize that velocity metrics are misleading. What frameworks are you using? What metrics actually correlate with sustainable product success?

Specifically:

What metrics prove you’re delivering customer value, not just features?
What metrics indicate you’re building sustainably, not just fast?
How do you communicate these metrics to non-technical stakeholders who love simple numbers?
What’s the right balance between output metrics and outcome metrics?

Because right now, I’m convinced that optimizing for velocity is killing us slowly. But I need a better framework to replace it with—one that the board will actually accept.

Help me figure out what we should be measuring instead.

— David

eng_director_luis · March 15, 2026, 9:19am

David, I appreciate this confession because it’s forcing me to look at my own metrics and realize I’ve been complicit in the same problem.

The DORA 4 + Debt Ratio Framework

We’ve adopted a hybrid framework based on DORA metrics plus a technical debt ratio. Here’s what we track:

The DORA 4:

Deployment Frequency: We’re at 12 deployments/week, up from 3/week two years ago
Lead Time: Average 4.2 hours from commit to production, down from 28 hours
Change Failure Rate: Currently 8%, target is <5%
MTTR: Average 47 minutes, target is <30 minutes

The Debt Ratio:
Percentage of sprint capacity going to technical debt vs. new features. We target 15-20%.

Why This Framework Works

The DORA metrics tell you if you’re shipping sustainably. High deployment frequency and low lead time are great, but only if change failure rate is low and MTTR is fast.

If you’re shipping fast but breaking things frequently, or if your MTTR is slow, that’s unsustainable velocity. The metrics self-regulate.

The debt ratio tells you if you’re maintaining system health. If debt ratio drops below 15%, we know we’re accumulating technical debt faster than we’re paying it down. That’s a leading indicator that velocity will degrade.

The Business Translation

When I present these metrics to the board, I translate them to business outcomes:

Deployment Frequency = speed of innovation, time to market
Lead Time = responsiveness to customer needs and market changes
Change Failure Rate = customer experience, reliability, brand trust
MTTR = blast radius of incidents, customer impact minimization
Debt Ratio = sustainability, future velocity preservation

The board doesn’t care about story points. They care about whether we can ship fast without breaking things. DORA metrics answer that question.

The Quality Gate Model

Here’s the governance model we use: we have acceptable thresholds for each metric. If any metric degrades below threshold, we pause feature work and focus on fixing the underlying issue.

For example:

If change failure rate exceeds 10%, no new features until we improve testing
If MTTR exceeds 60 minutes, we invest in observability and incident response
If debt ratio falls below 15%, we increase debt allocation

This prevents the velocity trap you fell into: we can’t sacrifice quality or sustainability for speed.

The Leading vs. Lagging Indicator Balance

Your question about leading vs. lagging indicators is critical. Here’s how I think about it:

Leading Indicators (Predict Future Problems):

Technical debt accumulation rate
Test coverage trends
Security vulnerability trends
Developer satisfaction scores
Code review cycle time

Lagging Indicators (Measure Current State):

Deployment frequency
Change failure rate
Customer satisfaction
System reliability

We monitor both. Leading indicators tell us where to invest. Lagging indicators tell us if our investments are working.

My Recommendation

Start with DORA 4 + a health metric of your choice (debt ratio, test coverage, security posture, whatever matters most for your system). Get those stable and improving.

Then add customer value metrics (adoption, satisfaction, retention). Make sure velocity is actually translating to customer outcomes.

If DORA metrics are healthy and customer metrics are improving, velocity will follow. You can’t game the system by cutting corners because the quality metrics will catch you.

— Michelle

brian_opensource · March 15, 2026, 9:19am

David, this resonates deeply. I’ve been managing engineering teams for 15 years, and the shift from outcome-focused to velocity-focused metrics has been one of the most damaging trends I’ve witnessed.

Developer Satisfaction as a North Star

One metric I’ve become obsessed with: Developer Satisfaction. Not because I’m trying to coddle engineers, but because there’s a direct correlation between developer satisfaction and sustainable velocity.

We survey our engineering team quarterly on:

Do you have the tools and resources to do your job effectively?
Do you feel productive?
Are you learning and growing?
Do you feel proud of the code you’re shipping?
Is your workload sustainable?

When developer satisfaction is high (>4.0/5), our velocity is stable and quality is good. When it drops below 3.5/5, velocity starts to degrade within 2-3 months, and quality issues spike.

The Burnout-Velocity Correlation

Here’s the pattern I’ve observed:

Phase 1: Velocity Push
Leadership pushes for more output. Velocity increases 20-30% as engineers work harder, cut corners, skip debt work.

Phase 2: Satisfaction Drop
Developer satisfaction drops as engineers feel pressured, quality standards slip, technical debt accumulates. Usually happens 3-6 months into the velocity push.

Phase 3: Velocity Collapse
6-12 months in, velocity crashes as technical debt makes every change harder, quality issues require rework, and burned-out engineers leave.

We end up with lower velocity than when we started, plus we’ve lost institutional knowledge and damaged team morale.

Sustainable Velocity Metrics

Instead of raw velocity (story points per sprint), I track Sustainable Velocity:

Sustainable Velocity = Velocity × (1 - Rework Rate) × (1 - Debt Accumulation Rate)

This accounts for:

Rework Rate: Percentage of work that’s bug fixes or rework of previous features
Debt Accumulation Rate: Rate at which technical debt is increasing

If we’re shipping 60 story points per sprint but 20% is rework and debt is accumulating at 15% per sprint:

Sustainable Velocity = 60 × 0.8 × 0.85 = 40.8

Our actual forward progress is 41 points, not 60. The other 19 points are running in place.

This metric has been eye-opening for our board. It shows that the ‘productivity gains’ they thought they were getting from pushing harder were largely illusory.

The People Metrics That Matter

Beyond developer satisfaction, we track:

Retention Rate: Are we keeping our best engineers?
Time to Productivity: How long until new hires are effective? (Rising time indicates increasing system complexity)
Knowledge Concentration: How many critical systems have only one expert? (Bus factor)
Meeting Load: Percentage of engineer time in meetings vs. coding (Productivity drain)

These metrics tell you if you’re building a sustainable engineering organization or burning one down.

The Framework I Use

I think about metrics in three layers:

Layer 1: People Health
Developer satisfaction, retention, burnout indicators. If this layer is red, nothing else matters.

Layer 2: System Health
Technical debt, reliability, security posture. If this layer is red, velocity will degrade.

Layer 3: Delivery Metrics
Velocity, deployment frequency, lead time. Only meaningful if Layer 1 and 2 are green.

Most organizations measure Layer 3 obsessively and ignore Layer 1 and 2. Then they wonder why velocity degrades and quality suffers.

What I Tell Leadership

Velocity is like your car’s speedometer. It tells you how fast you’re going right now, but it doesn’t tell you if your engine is overheating, your tires are bald, or you’re heading for a cliff.

You need engine temperature (system health) and road visibility (people health) metrics too. Otherwise you’re driving blind.

— Keisha

data_rachel · March 15, 2026, 9:19am

David, your customer exit interview is haunting because I’ve heard almost identical feedback from our customers. We’re shipping features they don’t want, with quality they don’t trust.

The Technical Leverage Concept

I’ve been thinking about metrics through the lens of Technical Leverage—the idea that good engineering decisions create compounding returns, while bad decisions create compounding costs.

High Leverage Activities:

Build a component library: saves time on every future UI feature
Improve test infrastructure: catches bugs earlier, reduces rework
Document architecture: reduces onboarding time, enables better decisions
Refactor a core service: makes all dependent features easier to build

Low/Negative Leverage Activities:

Ship a feature quickly but poorly: creates future maintenance burden
Skip tests: creates future debugging and rework burden
Take architectural shortcuts: makes future changes harder
Build one-off solutions: doesn’t benefit future work

The Leverage Ratio Metric

I’ve been experimenting with tracking a Leverage Ratio: percentage of engineering time spent on high-leverage activities vs. low-leverage activities.

Right now we’re at about 40% high-leverage, 60% low-leverage. My goal is to flip that to 60/40.

The hypothesis: if we increase high-leverage work, our effective velocity will increase even if raw velocity stays flat, because each unit of work will create more value and less future burden.

Measuring Real Velocity vs. Apparent Velocity

I think the metric we actually need is Real Velocity vs. Apparent Velocity.

Apparent Velocity = Story points shipped (what we currently measure)

Real Velocity = Apparent Velocity - Rework - Maintenance Burden Created

Most teams measure Apparent Velocity and wonder why they feel like they’re running faster but not getting ahead. It’s because Real Velocity is much lower due to rework and debt accumulation.

The Metrics I’m Proposing

For my engineering org, I’m tracking:

1. Code Longevity
What percentage of code we write is still in production and unchanged after 12 months? High longevity means we’re building things right the first time.

2. Feature Dependency Cost
How many files/services does a typical feature touch? Increasing dependency cost indicates growing system complexity.

3. Debug Time Ratio
Percentage of engineering time spent debugging vs. building. Rising debug time indicates quality issues.

4. Test-to-Code Ratio
We’re targeting 1:1 test code to production code. Lower ratio indicates we’re under-testing.

5. Architectural Drift
How many deviations from our architectural standards exist in the codebase? Rising drift indicates we’re making short-term shortcuts.

These aren’t perfect metrics, but they tell a story about whether we’re building sustainably or accumulating problems.

The Board Communication Challenge

Your question about communicating to non-technical stakeholders is the hard part. I’ve found that storytelling works better than metrics.

I show the board:

The Cost of Poor Quality: Dollar cost of the bug that took down production for 3 hours
The Cost of Tech Debt: Feature that should have taken 1 sprint but took 3 because of architectural limitations
The Cost of Attrition: What it cost to replace the senior engineer who left due to burnout

Then I show the metrics that predict these costs:

Change failure rate predicts outages
Technical debt ratio predicts feature slowdown
Developer satisfaction predicts attrition

Boards understand risk and cost. Frame your metrics as leading indicators of business risk, and you’ll get their attention.

— Luis

alice_security · March 15, 2026, 9:19am

David, as someone who bridges design and product, I’ve struggled with the exact same velocity trap from the design side. We were measuring design output (mockups shipped) while ignoring design outcomes (did it solve the user problem?).

The Design Parallel

For years, our design team was measured on:

Number of mockups delivered
Percentage of roadmap features designed
Time from design request to design delivery

We optimized for these metrics. Design velocity increased. We were shipping designs faster than ever.

But user satisfaction was declining. Features looked good but didn’t solve user problems. The design team was stressed and burned out.

The Shift to Outcome Metrics

We completely changed our metrics to focus on outcomes:

1. User Problem Resolution
Does this design solve the user problem we identified? Measured through user research and usability testing.

2. Design System Adoption
What percentage of new features use our design system vs. one-off designs? High adoption means we’re building sustainably.

3. Design-to-Development Handoff Quality
How many rounds of revision are needed after handoff? Low revision count means we’re designing clearly.

4. Feature Adoption Post-Launch
Are users actually using the features we designed? This is the ultimate outcome metric.

The Technical Leverage Concept Luis Mentioned

This resonates with how we think about design systems. Every hour we invest in the design system creates leverage for future design work.

We track Design System ROI: how much time do we save per feature by having pre-built components vs. designing from scratch?

Currently, features using the design system ship 40% faster and have 60% fewer design revisions. That’s the leverage Luis is talking about.

Could engineering track something similar? Engineering Infrastructure ROI—how much time do your platform investments save on feature development?

The Sustainability Question

The key question I’ve learned to ask: Are we building in a way that makes future work easier or harder?

If we’re cutting corners to ship faster, we’re making future work harder. If we’re investing in systems and infrastructure, we’re making future work easier.

That’s the metric that matters: Trajectory of Difficulty. Is it getting easier to ship features over time, or harder?

If velocity is increasing but difficulty is also increasing, you’re in a death spiral. If velocity is stable but difficulty is decreasing, you’re building sustainably.

My Recommendation

Start measuring:

Customer outcomes, not just outputs (adoption, satisfaction, retention)
System health, not just feature velocity (reliability, maintainability, security)
Team sustainability, not just throughput (satisfaction, retention, burnout)

If those three categories are healthy, velocity will take care of itself.

— Maya