The Velocity-Stability Tension
Every engineering organization faces a fundamental tension: the business wants features shipped quickly (velocity), and users want the system to work reliably (stability). These two goals are not always in conflict, but they frequently are.
Consider deploying a new feature:
- Optimize for speed: Ship it now, monitor for issues, fix them as they arise. You get the feature to users faster, but you accept a higher risk of incidents.
- Optimize for reliability: Extensive testing, staged rollouts, canary deployments (releasing to a small percentage of users first), load testing, chaos engineering. You reduce the risk of incidents, but the feature takes longer to reach users.
Neither extreme is correct. A startup with zero users and a burning runway cannot afford six weeks of reliability engineering for every feature. A hospital's electronic health record system cannot afford "move fast and break things."
The context determines the right balance:
| Context | Lean Toward | Why |
|---|---|---|
| Pre-product-market-fit startup | Speed | No users to break things for; speed of learning is everything |
| Consumer app with millions of users | Balance | Users expect reliability but also expect new features |
| Financial trading system | Reliability | A bug can lose millions of dollars in seconds |
| Internal developer tooling | Speed (with guardrails) | Users are engineers who can tolerate and report issues |
| Healthcare / aviation / safety-critical | Reliability | Failures can harm or kill people |
The modern DevOps approach tries to achieve both by investing in infrastructure that makes safe, fast deployment possible: automated testing, feature flags (which let you deploy code without activating it for all users), canary deployments, and instant rollback capabilities. This is the insight behind the DORA metrics — four measurements that research has shown correlate with high-performing engineering organizations:
- Deployment Frequency: How often you deploy to production
- Lead Time for Changes: How long from code commit to production
- Change Failure Rate: What percentage of deployments cause incidents
- Time to Restore Service: How quickly you recover from incidents
High-performing teams achieve both high deployment frequency and low change failure rates — but only by investing heavily in their deployment pipeline, test automation, and observability. The investment is the prerequisite, not the shortcut.
Key Point: "Move fast and break things" is not a universal strategy — it's a context-dependent trade-off that made sense for a social network in 2008 and makes no sense for a payment processor in 2024. The mature version is "move fast with confidence," which requires significant investment in testing, observability, and deployment automation. When an interviewer asks about this trade-off, demonstrate that you understand the spectrum and can calibrate your approach to the specific context rather than applying a blanket philosophy.