“Move fast and break things” is a failed VC math

As someone who wasted a lot of time and money in my startup, I advocate for a more measured approach with a special attention to the infrastructure necessary for moving fast.

I often like to point out why I take the time to write a piece. So, here it is for this one: I hear from some founders-to-be who book me for advice that they want to “move fast and break things”. They say it in different ways like “oh, i just need to get this demo together, and then I’ll raise money and scale quickly” or “XYZ raised money with a rough idea and no business model” etc.

As someone who bought into that ethos without thinking about it and wasted a lot of time and money, I advocate for a more measured approach with a special attention to the infrastructure necessary for moving fast. 

A History Lesson

A quick look at history teaches us a lot about this. “Move fast and break things" was a direct response to the traditional waterfall approach, which originated in manufacturing and later became a dominant method in software development. Waterfall emphasizes a sequential, phase-by-phase approach to projects, where each stage (like design, development, and testing) is completed before moving to the next. This method is known for its slow, rigid processes, which can hinder innovation and adaptability. Waterfall methodologies were popular because they were designed to minimize risk and prevent mistakes by following a linear, highly controlled process.

In this climate, Mark Zuckerberg's mantra of "move fast and break things" emerged at Facebook in its early stages to foster rapid experimentation, especially in a tech landscape where companies needed to iterate quickly to stay competitive. The idea was to prioritize speed and agility, even if it meant making mistakes along the way. The goal was to learn and adapt faster than competitors, recognizing that perfection often leads to paralysis. This approach stands in stark contrast to the conservative and cautious ethos that was common: one might even say an over-correction for the existing trends. 

It is not surprising that this took over silicon valley and later the broader startup conversation in the Western countries given what was going on in the VC land. The tech world was recovering from the dot com crash and new tech trends like social media, search engine, e-commerce, and cloud infra were seeing promising examples, and ideologies like lean startup were starting to shape up. All this was changing the venture capital more and more towards a “disruption” focused narrative and the “go big, or go home” type of mentality. The way this manifested itself was that VCs started coming up with all sorts of theses around how they picked their so-called outliers, and of course, they would occasionally make mistake and the way their math work is that it’s best for those mistakes to run out of business as quickly as possible in favor of the ones that prove to be more promising. See the connection?

Tiger Global, one of the early investors in WeWork, was the firm that took this philosophy to another extreme by following a “what can go right” mentality and therefore investing 10x more than what the firm needed to be great in favor of massive velocity. While this approach had remarkable success, it also produced spectacular failures like WeWork’s remarkable IPO failure, and other examples that a quick Google search would surface. 

Role of Infrastructure

The world we live in today is very different from the one in which “move fast and break things” was a relevant anti-trend. Since then Facebook has changed its mantra to “move fast with the right infrastructure” and the VC world has corrected its philosophy to focus on startup infrastructure and ecosystems well past “throw money at it and hope for the best”. 

In this journey, the tech world has come up with so many interesting technical, organizational, and operational practices to enable moving fast and safely. DevOps is one of the most remarkable examples that has significantly reduced the cost of failure in software development by introducing tools and processes that automatically integrate, test, monitor, and scale code changes. You no longer need significant investment in racks of hardware in your basement because you can provision, use, and wind down virtual machines on the cloud with a few clicks. And especially in the post-pandemic world, you can find cross-functional collaborators or gig experts within your org or from across the globe with a few online calls.   

So, the right question for a founder in 2024 should be more like: what infrastructure / environment / ecosystem do I need so that I can get the necessary failures out of the way quickly, cheaply, and safely? Capital is definitely one of the important parameters, but certainly not the only one by any means. Velocity is definitely an important factor but not at the cost of safety or learning quality. 

Verdict

If you are an early stage founder and you’re thinking about “moving fast, and breaking things”, then take a moment to re-evaluate your context. Are you driving a Fiat 500 on an unmaintained back alley, or a Ferrari LaFerrari on a German Autobahn? If you try to move fast in the former you’re going to injure yourself, anyone around you, and the vehicle you’re in. You need to think carefully, deeply, and importantly: honestly, about what you need to fail at first, and how you can do that cheaply, and then how you can streamline and refine your experimental process.