Velocity Guardrails: Ship Freely Until the Metrics Go Red
Standardize a few quality metrics per team; below the line they ship anything, above it they fix before they ship.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
High velocity doesn't tank quality if you install control mechanisms that catch the downside. Ramp standardizes a small set of quality metrics across teams—operational burden, CSAT, NPS, and a 'customer confusion' rate—and gives teams total freedom as long as they stay green. The moment a metric goes red, the team is barred from shipping new features until it's fixed.
Origin
Geoff Charles at Ramp, echoing Nicole Forsgren's research that quality rises with velocity because fast teams can fix and re-ship quickly rather than waiting on heavy review cycles.
Core principles
- 01Velocity is a magnitude, not a direction—guardrails supply the direction
- 02Fast teams produce higher quality because they can fix and re-ship immediately, without long review-and-release chunks
- 03Feedback must reach the specific engineer, PM, and designer who own the surface, or the loop doesn't close
- 04No bug backlog—bugs are fixed as they surface, assigned to the on-call engineer so they feel the pain
How to run it
- 1
Define a standard metric set per team
Give every team the same scorecard: operational burden (percent of tickets from their area, normalized by users), CSAT, NPS, and the number of customers confused (support tickets caused by confusion).
- 2
Route every negative signal to the owners
Every negative review goes back to the tech lead, PM, and designer monthly. Bugs are assigned directly to the on-call engineer so the person who can fix it feels the pain.
Pro tip Run a voice-of-customer process so no negative review disappears into an aggregate dashboard.
- 3
Grant total freedom while green
As long as a team holds its metrics, it does whatever it wants—no permission required for how it builds or ships.
- 4
Freeze features when a metric goes red
If confusion tickets or operational burden go over the line, the team cannot ship new features and must revert to fixing the quality issue first.
Pro tip Watch the confusion-ticket count as the leading indicator of UX debt—slightly elevated is your trigger to freeze.
Watch out Without an enforced freeze rule, 'ship fast' quietly compounds into 'ship broken.'
In the wild
Ramp doesn't maintain a bug backlog; bugs are fixed almost as soon as they surface, treated as part of the production engineer's core job.
→ Velocity is leveraged to solve quality problems fast, keeping the business protected while teams move quickly.
Common mistakes
Treating velocity as inherently lower quality
Assuming faster means worse leads to heavy gatekeeping that actually lowers quality; in practice fast teams fix and re-ship so quickly that quality rises—if guardrail metrics are in place.
Letting quality metrics live only as aggregates
If NPS or bug data only appears in a dashboard and never reaches the specific engineer/PM/designer who owns the surface, no one feels accountable and the feedback loop never closes.
Is it for you?
Best for
Fast-shipping product and engineering orgs that want speed without silently degrading customer experience.
Not ideal for
Safety-critical or regulated products where a single shipped defect is catastrophic and can't be fixed forward.
From the transcript
“as long as you maintain those metrics you do whatever you want but the moment that these things are under the red you can't”
“we don't have a bug backlog we've we fix every bug once they're surfaced almost”
“velocity is just is just a magnitude it's not necessarily a specific Direction”
“we report back operational overhead meaning the percentage of tickets that come from your product area normalized by the number of users”
From the episode
Velocity over everything: How Ramp became the fastest-growing SaaS startup of all time
Geoff Charles (VP of Product)