How to move fast without breaking the product

"Move fast and break things" got repeated so often that people forgot the second half is optional. You can move fast and not break things, and the teams that manage it are not the ones being careful in the usual sense of that word. They are not slower. They have set up their work so that going fast and staying stable happen together instead of competing. Here is how that actually works in practice.

1. Speed and quality are not opposites over time

For a single afternoon, yes, you can go faster by skipping the tests and releasing something rough. The trade-off looks real because on that day it is. It stops being true when you look at a longer period. The team that skipped quality to meet the deadline spends the next month fixing urgent bugs it released, and its speed drops right when it needs to keep going.

Over any real length of time, quality is not the thing you give up for speed. It is the thing that lets you keep speed. A stable product is one you can change quickly and confidently, because you are not afraid of what each change might break. An unstable one gets slower every week, because every change is a risk and people start grouping changes together and delaying. So the teams that are fast for years are almost always the ones that refused to give up quality, even when trading it would have felt faster that afternoon.

The data supports this. The DORA research on software delivery has measured thousands of teams over years, and the pattern it keeps finding is that the highest performers release more often and have lower change-failure rates at the same time. Speed and stability increase together instead of one replacing the other. We saw the same pattern on one product we helped rebuild. The team had been releasing in big monthly batches and treating each release as a risky event, and a real share of those releases had to be patched or rolled back soon after. We broke the work into small daily changes with checks that ran on their own. Within a quarter the releases came more often and the failures went down at the same time, not one at the cost of the other.

Once you see that speed and quality support each other over time, even when they seem to compete on a single day, the rest of this follows.

2. Make the safe way the fast way

The method that makes this work is simple to say and takes discipline to build: set things up so the easiest way to release is also the safe way. When the least-effort action an engineer can take is a small, tested, quickly released change, they will take that action constantly, and quality stays high without anyone having to remind them.

That means a few concrete things. Changes should be small, because small changes are easy to review and easy to undo when they are wrong. Tests should run automatically and catch mistakes before a user ever sees them, so the computer does the checking rather than a tired human. And releasing should be routine, a normal part of a day rather than a stressful event, because when releasing is easy people release often and problems appear while they are still small. Get this right and speed no longer depends on anyone working extreme hours. It becomes the normal way the team works.

There is a practical way to know whether your safe way is actually the fast way: measure it. Google Cloud describes four keys you can track, including how often you deploy, how long a change takes to reach users, and how often a change fails. These numbers are useful for decisions. They tell you which steps slow you down. On one team we worked with, the numbers showed that a single manual approval step was adding a day to every change, so people saved up their work into large batches to avoid paying that cost twice. We automated the check. The batches got smaller without anyone asking, because now the least-effort action was to release the small change right away. Nobody had to be told to do it. The system made the right behavior the easy one.

The opposite is the danger. When the safe way is slow and painful, people avoid it, and quality becomes something you have to ask for instead of something you get automatically.

3. Reversible decisions fast, irreversible ones slow

The last part is knowing where to be careful, because treating every decision as equally important also slows you down. Most decisions are easy to reverse. If you are wrong, you change it tomorrow and lose almost nothing. Those should be made quickly, because the fastest way to learn is to try, and deliberating over a choice you can undo in an hour is wasted time.

A smaller set of decisions are hard to reverse. The structure of your data, the interfaces other teams build on, the choices that become fixed and expensive to change later. Those deserve real thought before you commit, because the cost of being wrong is high and paid for a long time. The skill is telling the two apart and being careful only where it matters. Teams that get this backwards spend days on small choices and rush the ones that will cause problems for years. Teams that get it right move quickly almost everywhere and slow down only where slowing down actually helps.

Jeff Bezos explained this well in his 2015 letter to Amazon shareholders. He split decisions into two types. A one-way door is his name for a decision you cannot undo, so you should study it and go slow. A two-way door is a decision you can undo, so you should make it fast and let people decide without a heavy process. The mistake he warns about is using the slow, careful process on the two-way doors, which stops a whole organization from making progress for no reason. We use the same test when we plan a build. Before a decision goes on a long review, we ask one question: if this turns out wrong, how hard is it to change? If the answer is "we redo it in an afternoon," it does not get the review. We try it. We save the long discussion for the choices we would still depend on a year later.

4. Make it easy to see what broke

There is one more practice that connects the first three, and teams skip it more than any other. Small changes and reversible decisions only help you move fast if you can tell, fast, when something goes wrong. If a change adds a bug to the product and nobody notices for two weeks, you lose the whole advantage of releasing small changes. By the time you find it, ten more changes are added on top, and now you are separating all of them at once instead of one.

So the fourth habit is simple: make problems obvious and quick to find. Watch the product while it runs, not only before it is released. Set up basic alerts on the things that matter, like errors increasing or a page getting slow, so the system tells you instead of a user telling you. Keep enough of a record that when something does break, you can find the change that caused it in minutes rather than hours. This is the same idea the DORA research describes when it measures how quickly teams recover from a failure. The fast teams are not the ones that never break anything. They are the ones that notice and fix within minutes.

We saw this work on a payments feature we helped release. A small change introduced a rounding bug that only showed up on a narrow set of transactions. Because the team had alerts on failed payments, the number went up within the hour and someone caught it the same afternoon. The fix was one line. Had it stayed for a week, it would have meant refunding customers, a long list of support requests, and a harder conversation. Fast feedback turned a possible serious problem into a small one. That is what makes the whole method work: small changes, decisions you can undo, and a system that tells you the moment one of them goes wrong.

What this means for you

Stop treating speed and quality as a choice where more of one means less of the other, and start building the system that gives you both. Make small, tested, routine releases the easiest option, so quality is the default rather than an argument. Move fast on the decisions you can undo and be careful with the ones you cannot. And when a deadline tempts you to give up quality for a day of speed, remember that the day you save usually costs you more days later.

Thanks to the engineers who built the safety checks that let us work fast, and who understood that routine, reliable releases are what a fast team actually looks like day to day. Speed and quality were never opposites. The method is making the right thing also the easy thing, and then doing it every day.

What changes when AI makes writing the code fast

Every practice here was designed against an assumption that no longer holds: that writing the code was the slow step, and the safety work around it was the extra cost you had to justify.

That is now the opposite. AI writes the code quickly, so the build step is small, and the safety practices now take most of the time instead of being a small extra cost. Two consequences follow. Small changes matter more, because only a deliberate rule stops a generated change from being enormous. And your ability to reverse a bad release matters more, because changes now come faster while your ability to understand each one stayed the same.

Moving fast safely always depended more on being able to recover than on being careful. That is more true now.

References

• DORA / Accelerate State of DevOps research: years of data across thousands of teams showing the highest performers release more often and fail less at the same time, and recover from failures fastest.
• Google Cloud, "Using the Four Keys to measure your DevOps performance": the four delivery metrics you can track to find which steps are slowing you down.
• Jeff Bezos, 2015 Letter to Amazon Shareholders: the one-way door versus two-way door framing for making reversible decisions fast and irreversible ones slow.

Related guide: How to build an MVP.