Speed and quality are not a trade-off. Deciding where to be slow is.
Teams talk about balancing speed and quality as if they sat on one dial. They don't. The real trade-off is where you choose to slow down, and most teams make that choice by accident.
Every team I have worked with has, at some point, described its situation as a balance between speed and quality. Turn the dial towards speed and quality suffers. Turn it towards quality and delivery slows.
That dial does not exist. Over any period longer than a sprint, speed and quality move together. Teams with low quality are not fast. They are busy, and the difference matters.
The trade-off that does exist is smaller and more useful. It is not how much quality to give up for speed. It is where to be deliberately slow so that you can be safely fast everywhere else. Most teams make that decision implicitly, through deadlines and habit. This post is about making it on purpose.
Why the dial is a myth
The speed-versus-quality dial assumes quality work is a cost added on top of delivery. Spend less on it and you finish sooner.
That holds for exactly one release. The shortcut you took this week is part of the codebase you have to change next week. Untested paths make the next change riskier, so it needs more manual checking. Unclear code takes longer to modify. Flaky tests slow every merge. Escaped defects interrupt planned work. The time you "saved" comes back as drag, with interest, spread across everything you do afterwards.
The public research on delivery performance has said this for years. Teams that deploy frequently tend to have lower change failure rates, not higher. Throughput and stability correlate. The fast teams are not the ones skipping quality. They are the ones whose quality work made change cheap.
So when someone says "we don't have time to test this properly", the honest translation is usually: "we are choosing to pay for this later, at a rate we haven't calculated." Sometimes that is the right choice. It is rarely a choice anyone made deliberately.
What I already argued, and what this post adds
In The Speed Trap: AI Made Us Faster Than We Can Justify, I argued that AI broke the old relationship between how fast we produce software and how fast we can verify it. Generation accelerated. Verification did not. The gap between what a team ships and what it can defend became the real bottleneck. That post was about rebuilding verification capacity through orchestration: routing, context, evidence and gates.
This post is about the decision that sits before any of that machinery. Even with perfect verification infrastructure, a team still has to decide which work deserves heavy scrutiny and which does not. Verification capacity is finite. Spreading it evenly is the most common way to waste it.
Risk is not evenly distributed, so rigour shouldn't be either
Most quality processes apply the same treatment to every change. Same review depth, same test expectations, same sign-off. It feels fair. It is a poor allocation.
A copy change on a settings screen and a change to how a device writes to persistent storage do not deserve the same scrutiny. Treating them the same does two kinds of damage. The trivial change gets slowed by ceremony it does not need, which teaches the team that the process is bureaucracy. And the critical change gets only the same standard-issue attention, which is not enough.
The alternative is to tier work by the consequence of getting it wrong, and to say out loud what each tier gets. A simple version:
- Low consequence. Easy to detect, easy to undo, small impact: cosmetic changes, internal tooling, flagged experiments. Automated checks and a light review. Move fast here on purpose.
- Moderate consequence. User-facing behaviour with a working rollback. The full automated suite, independent review, and behaviour-level evidence of what changed.
- High consequence. Hard to detect, hard or impossible to undo, or touching safety, money, data integrity or regulatory obligations. Explicit test design before implementation, independent review by someone who did not build it, and a named person who signs off on evidence rather than on a feeling.
The tiers are not the point. The point is that the decision about where to be slow is made in advance, written down, and applied by the team, instead of re-argued under deadline pressure on every ticket.
Speed comes from making the slow parts small
Once rigour is tiered, the next move is to shrink the slow tier.
Every high-consequence change pulls the whole delivery flow towards caution, so the best speed investment is architectural: isolate the dangerous parts. Put the payment logic, the data migration or the safety-relevant control path behind clear boundaries, so most changes never touch it. A team that can say "this change does not touch the high-consequence zone" with evidence gets to move fast on that change without arguing about it.
The same logic applies to tests. A fast, trusted suite around the critical core lets you change that core with confidence. A slow, flaky one makes every change near it expensive. Investment in the quality of the checks around your riskiest code buys speed more directly than almost anything else.
In the BowSmith work this was concrete. Roughly 70,000 automated tests, static analysis with tools like Periphery and PMD CPD, and a separate model reviewing what another one wrote. That scrutiny was not the opposite of speed. It was the precondition for letting the machines go fast.
The question to ask instead of "speed or quality?"
When a team says it is caught between speed and quality, the question I ask is: which of these changes would hurt most if it were wrong, and are we spending our scrutiny there?
It turns an abstract tension into a concrete allocation. It makes the trade-off visible to the product owner, who can take part in the decision instead of inheriting its consequences. And it gives the team permission to be fast where speed is cheap, which is most of the time.
Speed is not the achievement. Justified speed is. The justification starts with knowing where you can afford to be wrong.
If you want to work through risk tiering for your own teams, book a Virtual Quality Coffee. Or tell me in the comments: where is your team spending scrutiny it doesn't need, and where is it missing scrutiny it does?
