The Lose-Lose

Several weeks ago, I wrote an article about the tradeoff all companies make between productivity and alignment. The more you focus on one, the less you can focus on the other:

As you invest more in ensuring team members are productive, they generally fall out of alignment with one another. And as you focus on aligning your team, individual contributor productivity generally goes down.

Yet in the earliest days of a startup, there is a more pertinent tradeoff. Even when the team is small and communication channels are limited in number (meaning one can be both productive and aligned), every decision seems to fall on the inescapable graph of speed versus stability.

The faster you move, the less stable are the systems/products/services you build. The more you focus on stability, the slower your output will be.

Move Fast

I, for one, favor speed. Or I did in my early startup days, at the expense of pretty much everything else. After all, as I’ve written about before, speed is often a startup’s only advantage over larger, well-funded incumbents. Those competitors are cruise ships; they take a while to turn. Startups, by contrast, are dinghies that can turn on a dime.

Iterating through the early days to product market fit requires this ruthless cycle: try, fail, try something else, fail, try a different thing, fail, and so on. Only on the 89th attempt will you stumble onto something that works. And so, once more, speed is everything.

At Anchor, we sanctified this as one of our four core values by which to orient our team: Move Fast.

And the impact was apparent. We were known as a team that shipped lightning fast. Yet early versions of products we built were riddled with TODOs and edge cases. Problems were fixed with hacky solutions akin to scotch taping a delicate house of cards. But we pressed on, moved fast, knowing full well that many of these decisions (some foundational to our architecture) were ones we would have to revisit.

I wouldn’t have done it any other way, despite the many long nights of rewriting SQL queries and scratching my head at why I’d previously made certain flawed decisions. Because here’s the dark secret about startups: you either focus on stability too early and run out of time and money; or you get scrappy and raise the likelihood that, one day in the future, you’ll be able to finally fix those foundational flaws.

We wrote and rewrote Anchor code many times in the formative years, as the need for a more mature and stable product arose. But I credit only one thing with our even having the opportunity to make those revisions: doing it quickly the first time, so we could race ahead with what mattered in the early days.

The Later Stages

Of course, once a company reaches Product Market Fit, all bets are off. Here, the tradeoff between speed and stability is never-ending. Just as there exists a perpetual tug-of-war between the needs of different customer segments, there is a pendulum-like phenomenon at play here:

On every larger team I’ve ever been on, with every product I’ve ever built, this is a given: The more you focus on doing it quickly, the less stable it will be. The more you focus on making it stable, the less quickly you’ll get it out the door.

And as with serving customers, the counteracting forces get stronger the farther you are. The faster you move, the more you’ll break, and the more your customers and your teammates will complain of the need to rewrite, refactor, rebuild. The more stable you make it, the slower you’ll be, in which case those same customers and teammates will take issue with your inability to ship, ship, ship.

That’s life, I suppose. Business life, at least. Just remember that time moves fast.

After all, “Time flies like an arrow; fruit flies like a banana.”