🇫🇷 Cliquez ici pour la version française de cet article.
Many tech leaders still see speed and quality as opposites, as if one always comes at the expense of the other. This belief runs deep in the culture of most tech organisations: on one side, those obsessed with delivering the roadmap as fast as possible; on the other, those advocating for more rigour, testing, and stability. And yet, this opposition is an illusion.
In reality, every velocity problem is a quality problem. When a team slows down, it’s rarely because people aren’t going fast enough — it’s because they’re dragging the hidden weight of past technical, organisational, or process decisions that degraded the system’s quality. A messy codebase, unclear specs, rushed architecture decisions, or fuzzy communication, every compromise on quality adds friction to the system. And the sum of all these frictions inevitably slows the machine down. Velocity loss isn’t a cause; it’s a symptom. The real issue never lies in the pace of execution, but in the quality of the process that enables it.Le mythe de la vélocité
The Myth of Velocity
In most tech organisations, speed and velocity are still used interchangeably. But in physics, the distinction is crystal clear:
- Speed measures how fast something moves.
- Velocity measures how fast and in which direction it moves.
In other words, you can go very fast... in the wrong direction. That’s exactly what happens in many product and engineering teams. They ship features at full speed, close tickets, and complete sprints — but without ensuring that their work actually creates user value or improves system stability. They confuse movement with progress. Speed is raw execution: more code, more features, more releases. Velocity is the ability to consistently deliver value in the right direction, without losing quality or accumulating debt.
An engineering team can move fast for a few weeks, but once complexity and instability build up, the system inevitably slows down. So why do companies keep chasing speed? Because speed is visible and reassuring. It looks like progress (graphs going up, more releases, more demos...), but it’s an illusion. The more you optimise for speed, the more you sacrifice quality, and it’s precisely that quality that determines true velocity. Velocity doesn’t come from pressure; it comes from flow. And flow depends on one thing only: the overall quality of the system, from the initial idea to the final product.
The Many Quality Problems That Kill Velocity
When we talk about quality, most teams think about code quality (tests, refactoring, technical debt...). But in reality, quality affects every step of the Software Development LifeCycle, from idea pitch to user feedback. It’s the accumulation of small quality issues at each stage that eventually paralyses velocity.
- Low-quality ideas → poorly framed problems lead to wasted effort and misaligned priorities.
- Low-quality specs → vague or changing requirements create endless product-engineering back-and-forths.
- Low-quality technical design → rushed architecture decisions generate long-term friction.
- Low-quality development → messy code and lack of testing slow integration and debugging.
- Low-quality testing & release → weak QA cycles lead to regressions and deployment anxiety.
- Low-quality feedback loops → poor data and missing user insight prevent teams from learning fast.
When teams “slow down,” it’s rarely because they code too slowly — it’s because they spend their time compensating for upstream quality problems. Velocity is built from the very first idea.
Restoring Velocity Through Quality
Restoring velocity isn’t about going faster, it’s about reducing friction. Velocity isn’t a matter of energy; it’s a matter of system fluidity. When a team feels slow, it’s rarely due to a lack of effort. It’s because the system is clogged: vague ideas, unclear specs, unstable code, or feedback loops that take weeks. Each quality flaw adds micro-resistance to the flow, until every release becomes an obstacle course.
Rebuilding velocity means fixing quality at the source — and that’s everyone’s job. Quality shouldn’t just concern developers. It’s a shared responsibility between product managers, designers, engineers, QA, and managers. Instead of arguing for abstract principles (“give us more time to code,” “we need more tests”), each team member should focus on reducing waste and optimising their own workstation, their zone of influence in the system. Three simple levers help achieve this:
- Clarify: ensure every idea, spec, and ticket is clear, testable, and tied to user value.
- Simplify: remove unnecessary complexity in code, process, and communication.
- Tighten feedback loops: gather feedback early, from tech peers, product, or users, to fix issues before they snowball.
Quality isn’t declared; it’s practiced daily. And when everyone optimises the micro-actions within their control, the team as a whole regains sustainable velocity.
Velocity as a Reflection of Collective Quality
Velocity is never the result of individual effort, it’s the reflection of collective quality. Every unclear ticket, fuzzy decision, or unanticipated bug adds a grain of sand to the system. And those grains, over time, jam the flow. Conversely, when everyone focuses on improving their own area of work, flow naturally returns. Less waste, less waiting, less rework, and suddenly, the system breathes again.
The fastest teams aren’t the ones working in constant urgency; they’re the ones that have learned to work cleanly. They’ve understood that quality isn’t a luxury, it’s the very foundation of sustainable speed. Because in the end, all velocity problems are quality problems. And by raising the quality, of code, specs, decisions, and interactions, organisations finally recover what they’ve been chasing all along: the ability to move fast, in the right direction, without friction.