Moving Fast and Breaking Things: Pros and Cons
"Moving fast and breaking things" is at the heart of the startup philosophy of being scrappy. Facebook was the notable proponent of this philosophy until recently, but many startups also believe in it. This way of working usually emphasizes testing out new ideas, iterating quickly based on data, and aiming for more frequent points of learning.
The startup I joined a year and a half ago used to believe very much in moving fast and breaking things. As the company has matured, we've consciously moved to a slightly more deliberate pace of work (let's call it "moving at a nice clip and breaking fewer things", pithier version forthcoming). This transition, however, has really allowed us as employees to see the pros and cons of our older philosophy.
Pros (aka the Times of Exhilaration)
You can test many ideas very quickly. This is the obvious benefit of moving quickly - you can brainstorm multiple ideas that you think are promising, and within a surprisingly short amount of time get those ideas out on production to see how they perform with users. For an early-stage startup, this is vital for both figuring out where the product should go in the long-term and figuring out solutions to satisfy shorter-term goals (e.g. user acquisition or monetization).
You learn a lot more things a lot faster. As a consequence of testing ideas quickly, you can get a lot more learnings about your product, your users, your tech stack, or things you would never have imagined. On Monday, you might have a strong belief that doing X will make a huge difference to the users' experience. By Wednesday you release a test implementing X, and by Friday you take a look at the data, which suggests that X is in fact causing users to engage less! Imagine this happening in parallel across a handful of small teams running different tests; the amount of aggregate learning is astounding. Even when these quick experiments don't reveal the whole picture of what's going, each experiment hopefully illuminates a new small piece of the puzzle.
It gives everyone a sense of urgency. Having the company's blessing to move quickly even at the cost of occasionally breaking things influences how employees think about their work. For example, it definitely increases everyone's sense of urgency, even without hard deadlines. When our company was consciously moving fast, I remember nearly every project on the product side being completed ahead of estimates. There was definitely a sense of focus, perhaps even of frenzy, among the developers as we tried to push our projects out as quickly as possible. We were definitely breaking things, but there was a pressure to hustle and to quickly get ideas out as live tests.
It provides cultural and morale benefits. When a startup moves quickly, new parts of the product are getting rolled out frequently. This creates a certain feeling of vibrancy around the company: it is growing, it is figuring out who it is, and it contantly has new updates. This feeds into the sense of urgency among employees, but this leads to a greater sense of cohesion among the team: everyone is facing the challenge of growing the company together, and the company is actively tackling that challenge. It's not just a David vs. Goliath (a larger incumbent, an industry being upended, the nameless "market" that will decide your fate) story, but a war where your close-knit company is fighting for something you believe.
Cons (aka The Potential Regrets)
You will accumulate tech debt. This is almost a certainty. As you build incremental parts of the codebase as quickly as possible, there is less capacity to think about how any given part will hold up over time. Shortcuts will be taken in the code, and code tests will not fully cover all the edge cases. Nobody is maliciously pushing bad code, but coders can very easily fall into the thinking that since everything is "just a test", there is not much sense in doubling the development time to write code and tests super thoughtfully. At some point in the future, all the accumulated tech debt will make the entire codebase difficult to work with, and there's no telling what other consequences will result from layers and layers of bandages put on over time. Woe be to the employee who has to refactor a vital but incredibly messy system that results from this tech debt.
It can also hurt culture and morale in the long-term. Being a part of a scrappy, cohesive team can create a great short-term morale boost, but in the long-term it can lead to frustration and burnout if there aren't enough victories along the way. This philosophy can also create tension between those who create the tech debt (probably the more product-focused developers) and those who have to deal with the consequences (probably more back-end or systems developers), if people fall consistently into one of the two camps. These penalties to culture and morale take effect over a longer period of time, and can have many culture-related manifestations, such as some developers feeling disrespected at work.
The company needs to be better at coordinating between different teams. If different teams are working on different parts of the product, coordination is less of a problem. But, coordination becomes much more urgent and more difficult when teams work on the same product or the same part of the codebase. In order to prevent people from stepping on each others' toes, some person or people will have to spend more time figuring out what everyone is doing and working out solutions to conflicts. There isn't always a great solution either: sometimes one team will have to delay their project because of another team's work.
There is the peril of never building out anything well. Aside from tech debt, the frantic pace can also lead to rolling out sub-par products. When a test goes well, the instinct is to immediately roll it out, and then start on the next exciting thing. This next thing, however, might not be an iteration on the previous feature. That means that a product which might still have a lot of kinks and sub-optimal parts will get rolled out to users, and might stay in that state for a significant period of time. To put it in rough mathematical terms, if every new feature is rolled out at a 95% quality level, and a second feature gets rolled out on top of a first feature ("on top of" because it depends on the first, or is a supplement to the first), you hope that the overall experience is still at a 95% quality level. In reality it might end up at a 95% * 95% = 90% quality level. Over time, without a strict standard at every product rollout, the overall quality of the product will be eroded.
There might be hidden costs of being 'wrong'. This is related to the above point. As you run tests, you will be releasing features that are slightly buggy, or which might not work in the way users expect. And as in the above example, features might get rolled out at less-than-perfect quality. Any noticeable minor flaw in the product might decrease the product's standing in the user's eye. A design error might make the whole website feel sloppy, a poor UX flow might make the experience frustrating, and content errors (e.g. in the results of your website's search engine) might make your product just plain unreliable or 'wrong'. One way around this is to hope that your user growth is strong enough such that proportionally few in your userbase will see or remember a mistake. But if this is not true, over time the cumulative hit to users' goodwill might become significant. At a time when there are so many different products to capture users' attention, how many tiny mistakes can you afford to make?
I've had the chance to experience both the "move fast and break things" philosophy and a slower, more deliberate philosophy within the same company. It's definitely possible to "move fast and break things" in a clearly wrong way: if your tests aren't designed to give you valuable learnings, if you're breaking too many things in your attempt to move faster, etc. And even if your company executes it well, you will probably want to adopt a new philosophy as you mature, as our company did. If you have any good stories or analyses of how this philosophy contributed to or detracted from the success of a company in the long-term, please leave a note about it!
comments powered by Disqus