Going Fast

Everyone knows the startup recipe for success:

  1. “Fail Fast, Fail Often”
  2. “Move Fast and Break Things”
  3. “Ship Early, Ship Often”
  4. “Iterate Fast and Release Often”
  5. etc, etc, etc.

Iteration and shipping speed are the hallmarks of your startup. You’re small, you’re nimble, you have a sense of urgency. So you execute at breakneck speed. There is literally no wasted time. The incumbents are resource rich but have built up bureaucratic bloat- they are slow, fat, old dinosaurs, and can’t match your velocity. You’re winning because they’re sitting in planning meetings and strategy sessions while you’re pounding the pavement, pushing out new product features, pitching customers, and rebuilding your entire infrastructure from the ground up. Or so the story goes.

I’m not so sure. It’s a nice narrative, but anyone who has even dabbled in game theory can spot the flaw: moving fast is a dominant strategy. Once you’ve gone through a cycle or two of fast beating slow (and we have), shouldn’t everyone switch to fast? Shouldn’t they throw away their planning meetings and strategy sessions, and move to iteration and shipping? And in fact they do. More organizations than ever are switching to Agile/Scrum/Kanban/Whatever latest non-Waterfall process is in vogue trying to increase their velocity. Then why can’t more organizations actually move quickly?

What the theory really fails to address is the cost, especially on the emotional side. You have to give up on some things that humans (and especially engineers) really like:

  1. That your product will deploy cleanly,
  2. That your code will be perfectly structured and fully maintainable,
  3. That everyone will adhere to best practices and style guides, and most importantly
  4. That everything will work.

When you move quickly, SHIT IS ALWAYS BROKEN. You can write tests, you can QA, you can be diligent, but SHIT IS ALWAYS BROKEN, always in ways you didn’t foresee. Again this is something everyone knows intellectually. It’s the emotional part that they don’t account for. How it feels to have a third of your users tell you their data is wrong. How it feels when your sales team tells you the product crapped out during a demo. How it feels to tell your support team that the pipeline broke again last night and they should be prepared for the onslaught of calls about stale information, handing them the script to try to prevent cancellations. How it feels to tell your CEO the critical report you sent him yesterday had six bugs in the query and the numbers were off by a factor of 2, but to trust you that this new one is correct. That’s where it really gets hard. Most orgs give up the first time it happens. Most people too. Even most startups can’t take it and slow down.

But a magical thing happens when you don’t. Your infrastructure improves day by day. Your feature set develops in ways you couldn’t have imagined. You compress what should be a 5 year data warehousing project into less than six months. You push out a mobile app in two weeks. You spin up an integration in two days. You have tools and capabilities your competitors can only dream of. All because you were able to take the pain. And that’s why you win.

Like what you read? Give Ian Blumenfeld a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.