What tech startups should know about ‘moving fast and breaking things’

One of the most oft-repeated phrases in the startup community is “move fast and break things.” You may associate this mantra with Facebook, a company that certainly embraces the MFABT mindset even though it’s not a startup anymore. Regardless, this has become the guiding principle for many scrappy startups looking to gain an edge and get to market as quickly as possible.

It can be tempting to assume that just because you’re working for or running a startup, you should automatically adopt this creed as your own while building your products, hiring a team and marketing your business. There is much to be gained by moving fast and breaking things, but only if this approach is harnessed for the right reasons and for the right kind of business.

Proceed with caution when attempting to move fast and break things
Before you fully commit to this agile approach to developing products and building your company, you should understand that speed can actually harm your business in some instances. Be cautious and keep the following points in mind:

• It’s not for every startup. Ruchi Sanghvi, former VP of operations at Dropbox and Facebook’s earliest female engineer, told VentureBeat that when she started her job at Facebook, she realized that what worked for her new company would have never worked at Dropbox. Fast-paced iteration may have worked for a social networking site, but with Dropbox, people stored highly sensitive information and documents on the company’s servers. If Dropbox made a mistake during a rapid development cycle, it could be a disaster for the customers and company. Dropbox had to get things right the first time, and that means it had to work slower to ensure no major mistakes were made. For your own startup, make sure that the cost of a mistake isn’t so great that it’ll sink you. If it is, avoid MFABT and be more deliberate.

• Beware of “tech debt.” When you’re building quickly, you’re often making incremental changes to features and code. Forbes explained that this can often lead to developers taking shortcuts – everything is “just a test” after all. But after an extended period, many companies find that all the shortcuts have made it extremely difficult to integrate everything into a cohesive whole. It’s not that employees are purposely doing a bad job, it’s just that they probably won’t have time to go back and double-check what they’re doing during rapid development.

• Cultural issues may arise. In the beginning, moving quickly and knocking out a bunch of small projects can give everyone a boost of energy. But that can quickly wane when people get burned out. In addition, if there aren’t enough small wins during the process, employee morale can take a hit. In addition, the accumulation of tech debt can cause a great deal of frustration for those who have to go back and deal with it later, creating friction between teams.

• Coordination is king. You’ll likely have several small teams of engineers and developers working on separate but related tasks. Because of this arrangement, it’s easy for teams and individuals to end up bumping elbows by accidentally working on the same thing. Unless you have a strong managerial presence that can ensure the proper oversight of the development process, you could see redundancies and waste as some employees’ work overlaps with others due to poor coordination.

The benefits of moving fast and breaking things
After consideration, if you do decide that it’s right for you to MFABT, here are some of the ways it can transform your business:

• You can build quickly. By moving quickly, your team will be able to brainstorm multiple ideas, quickly build them into a workable product and get them in front of beta users as soon as possible. As Forbes noted, this is critical for an early-stage startup that’s looking to move forward while still meeting short-term goals, like figuring out how to monetize the product.

• Fast failure means fast learning. A byproduct of rapid development is that most of your ideas will fail. This isn’t a bad thing, either. As you build and test, you’ll quickly learn what works and what doesn’t. Best of all, you won’t waste valuable time clinging to unverified assumptions about your product or users.

• Trust your engineers and developers.  McCollum pointed out that MFABT can only work if engineers and developers could be trusted to push new code to production as soon as possible. This was necessary because as the website scaled to its current monstrous size, it would be nearly impossible to get anything done if the development team had to post its code to a staging environment before it went live. While the company has a staging environment now, McCollum explained that the lack of one in the early days is what gave Facebook the edge against its competitors. Your startup can enjoy the same benefits, but it will require that you hire the best engineers you can find and give them the latitude to push things to production as they see fit.

• You may see a positive cultural impact. If your team can score some quick victories early on – like a product feature that really resonates with users – it can be a major morale booster as your startup figures out its identity and way forward. The frantic pace, while stressful at times, will keep everyone excited and laser-focused on getting the product to market as soon as they can. When everyone is in the same crucible of a fast-paced, early-stage startup, it can lead to powerful cohesion through the shared challenge of getting the business off the ground.

How can your business start to move fast and break things? If you don’t think that’s the right approach for your business, why not?