Moving Fast and Breaking Things
There’s a phrase that’s floated around tech circles for years: "Move fast and break things." It’s bold, almost reckless, and it captures something essential about how progress happens. Mark Zuckerberg famously championed it in Facebook’s early days, and it’s since become a kind of shorthand for the startup ethos. But like most slogans, it’s been parroted so much that people rarely stop to ask what it really means, or whether it’s even a good idea.
Let’s unpack it. Moving fast sounds obvious. Speed is an advantage, right? If you’re building something new, a product, a company, an idea, the faster you get it into the world, the sooner you learn what works. Iteration beats perfectionism every time. But the "breaking things" part, that’s where it gets interesting. Why break anything? What’s the point of speed if it just leaves a trail of wreckage?
The real insight here isn’t about speed or destruction for their own sake. It’s about trade-offs. Moving fast and breaking things is a bet: you’re betting that the cost of fixing whatever you break is lower than the cost of moving slowly and breaking nothing. It’s a bet that action teaches you more than planning, that reality is a better editor than your imagination. And like most bets, it’s not always right.
Think about how software gets built. The best engineers I’ve known don’t sit around debating architecture for months. They write code, messy, imperfect code, and ship it. They see what crashes, what users hate, what actually gets used. Then they rewrite it. The first version of anything is almost always a hack. Gmail was a hack. Twitter was a hack. Even Google’s search engine started as a scrappy experiment, not some pristine masterpiece. The hacks that survive get polished later. The ones that don’t, well, they’re just broken things.
But here’s the catch: breaking things only works if you can fix them, or if the things you break don’t matter much. Imagine applying "move fast and break things" to, say, a bridge. You don’t ship a half-built bridge and patch it up after cars start plunging into the river. Speed without competence is a disaster. The tech world gets away with it because software is malleable, bits are cheap to rearrange. Most of what gets broken is temporary: a feature flops, a server crashes, a few users grumble. The stakes feel high in the moment, but they’re rarely existential.
That’s why this mindset fits startups so well. When you’re small, you’ve got nothing to lose. Breaking things is just feedback. You’re not a bank or a hospital or a government, systems where mistakes compound into catastrophes. You’re a scrappy little outfit trying to find a foothold. Speed is your edge because no one’s waiting for you to fail, they’re not even paying attention.
Contrast that with big companies. Once you’ve got customers, revenue, a reputation, moving fast gets trickier. Breaking things starts to mean breaking trust. If Facebook’s newsfeed goes down for an hour, millions of people notice. If a startup’s app crashes, maybe ten people care. Scale changes the equation. That’s why you see older companies slow down, they’re not dumb, they’re just carrying more weight.
So is "move fast and break things" a universal rule? No. It’s a strategy, and like any strategy, it depends on context. If you’re in a domain where mistakes are cheap and reversible, it’s a superpower. If you’re in one where they’re costly or permanent, it’s a liability. The trick is knowing which game you’re playing.
There’s a deeper layer here, though, one people don’t talk about as much. Moving fast and breaking things isn’t just about efficiency. It’s about psychology. It’s about forcing yourself to confront the gap between what you think will work and what actually does. Most of us are paralyzed by the fear of being wrong. We polish our plans, tweak our designs, wait for the perfect moment. But perfection is an illusion, it’s just fear dressed up as diligence. Shipping something flawed and watching it break is a kind of therapy. It teaches you that failure isn’t fatal, that the world doesn’t end when you screw up.
The flip side is that breaking things can become a fetish. Some founders take it too far, smashing through problems without ever stopping to think. They confuse motion for progress. Speed without direction is just noise. And breaking things without learning from the pieces, that’s not iteration, that’s vandalism.
Here’s the real lesson: moving fast and breaking things isn’t about chaos. It’s about discipline. It’s about knowing what you can afford to break, what you can’t, and how to turn the wreckage into something better. It’s a bias toward action, tempered by the humility to clean up your own mess. Get that balance right, and you don’t just build faster, you build smarter. Get it wrong, and you’re just a kid with a hammer.
So should you move fast and break things? Depends. What are you breaking? Can you fix it? And what are you trying to build in the first place? Answer those, and you’ve got something more useful than a slogan, you’ve got a principle.