“Move fast and break things” is a mantra built for a specific context: small team, early product, learning fast — figuring out whether you’re building the right thing at all — matters more than stability, the cost of a broken thing is recoverable. In that context, it makes real sense. Speed is the only asset a small team has that a large organization doesn’t. Breaking things, learning, and fixing quickly is genuinely the right tradeoff when the alternative is being slow and careful about something that might not matter at all in six months.
The problem is that the mantra tends to persist well past the context that made it sensible.
When I joined AWS in 2020 and took on an org that had grown rapidly, one of the things I spent time on was understanding what our actual relationship to speed and risk was — versus what we said it was, which is a different thing. What I found was an org that had internalized “move fast” as a value, in the abstract, but that was operating in a context where “breaking things” had acquired a cost that the original mantra never accounted for.
What changes at scale is the blast radius — a decision that seemed locally reasonable accidentally breaks something two teams over, and the organizational machinery needed to learn from it takes ten times longer to engage. With a small team of fewer than ten people, everyone knows what everyone else is doing, the context is shared, and if someone makes a call that doesn’t work out, the cost of course-correcting is visible and manageable. With multiple teams spanning dozens of engineers, those properties mostly disappear. The team that caused the breakage often doesn’t know they caused it, and the team experiencing the problem doesn’t know who to talk to — by the time anyone has the full picture, the cost has already multiplied.
This isn’t a people problem. It’s not that the engineers are worse or less careful. It’s that the system they’re operating in doesn’t have the shared context that made fast, informal decision-making work at smaller scale.
When I started working through this with my managers — carefully, because nobody wants to hear “we need to slow down” — the resistance was predictable: “Are you saying we should build a bureaucracy?” That’s a real concern. The answer to “move fast and break things has too high a blast radius” is not “move slow and document everything.” That trades one problem for another and makes engineers miserable in the process.
What actually works is clear decision rights, not a speed mantra.
A speed mantra tells you to go fast — and nothing else. It doesn’t tell you what you can decide without asking, or when you need to loop someone in before acting. Those are the questions that actually slow teams down: not too little urgency, but too little clarity about who owns what. Decision rights answer the specific question: who can decide what, without a conversation? When that’s clear, an engineer doesn’t need to guess whether something is theirs to call or whether it needs coordination first — the answer is already built into how the team is structured. That’s what enables real speed — not a cultural value about moving quickly, but structural clarity about who owns what.
The orgs that resist this framing are usually the ones that confuse decision rights with bureaucracy, which is understandable — a lot of bad governance is done in the name of “process” and “decision frameworks.” But there’s a meaningful difference between a process that exists to create oversight and a structure that exists to make coordination costs visible and predictable. The first adds friction everywhere. The second adds friction only at the places where friction is actually warranted.
What changed in my org after we worked through this wasn’t a slower pace — it was a more confident pace. Engineers stopped second-guessing whether something needed a cross-team design and decision review or could just be done, because the answer was clearer. Teams stopped stepping on each other’s work, not because they were being more careful, but because they had better visibility into where the boundaries were. The incidents we had were smaller and more contained, which meant we could learn from them faster and get back to shipping.
The “move fast and break things” instinct isn’t wrong — the desire behind it, to prioritize learning over perfection, is correct and important. What breaks down is treating speed as a value when what you really want is autonomy combined with clear accountability. Autonomy without clear accountability is how you get teams moving fast in directions that contradict each other. Speed as a mantra is a blunt instrument. Decision rights are a more precise tool.
I’d rather lead an org where every team knows exactly what it owns and moves confidently within that ownership than one that moves fast everywhere and is constantly surprised by what it’s broken.