“Be humble.” “Be truthful.” “Be courageous.”

These dicta are easy to stomach because their efficacy is self-evidence. Obviously, being a bit more courageous will make our lives a bit better.

”Move fast,” though, often does and in any case should elicit some resistance.

Often, it’s a bad idea. If you have a fixed number of tasks, and do tasks in order of importance, moving fast more or less equates to completing the most important tasks less well in exchange for a few more marginal tasks getting done. That’s often a horrible trade! This is probably the rule at teams in bigger companies. If it’s only feasible to coordinate once a week, you’re more or less guaranteed a fixed number of tasks, and then voila.

Yet, startups should move fast. That is, there is good reason for specific people working at startups to move fast much of the time.

Since I’ve made the argument for why moving fast is sometimes stupid, it’s probably worth articulating why it’s essential for us.

Employee’s Perspective (non-exhaustive list)

You get to solve new problems.

One of my history teachers denominated days in sleeps. E.g. “ten sleeps until the chapter 8 exam.” Sleeping is like magic - head to bed with a problem on your mind, and upon rising it’ll be solved. Sleep is an incredible problem-solving resource; if one is occupied with yesterday’s work, and the day has yields no new problems, the brain sits idle overnight - a waste. If a week brings no new problems, it’s a tragedy - you’re using an incredible resource at 1/7th capacity. In startups, there are too many problems - you simply cannot afford to run that low.

You solve problems when they’re fresh.

When you decide to test a hypothesis, re-design a component, or whatever, you have an image in your mind of what it is you’d like to build. You have all the context in working memory and are excited about the outcome. All of that changes the next day, and the one after, and soon enough it’s all an emotional drag. Startups churn code fast, and have emergencies that require attention at a moment’s notice - if you delay, you will lose context and forget your intention.

You’re subject to less stupidity

You can’t know everything when you’re building something new. No matter how smart, you’ll make stupid choices. Those stupid choices tax you until you detect them, and after that it’s up to you. If you move fast you can solve them that afternoon. If you move slow, it might wait 2 months. You have enough of yesterday’s stupidity to deal with - don’t tolerate last quarter’s, too.

You might actually learn something

A lot of startups is testing hypotheses. Humans are bad at credit assignment. Forming an ML hypothesis and testing it that same afternoon will yield much more learning than would testing it in a week. Testing a feature hypothesis in two days is qualitatively better than testing in 2 weeks. Testing a product in a week is worlds apart from testing one over a quarter.

Quality of Life

When I find a way to do something quickly that I previously did slowly, I immediately think “how did I live like that?” Moving quickly is engaging, flow-inducing.

Startup’s Perspective (non-exhaustive list)

Moving Fast Keeps Inventory Low

Think of a line of code as a bet. It costs your engineers’ working memory, requires maintenance, and eventually turns into tech debt. But it can bring value by answering questions about product and system design, and by serving customers. You start paying the price the second it’s written, but only start reaping rewards once it’s shipped. Ceteris paribus, code costs more at a startup - it decays fast because less was known when it was written. Hence, its days are numbered and getting value from it the next day after it’s written can be a huge improvement over the base case where it sits in inventory for days or weeks before shipping. Moreover, discovering code quality by testing the feature/system in prod allows a team to quickly cut out the most costly logic.

Cheap Experiments Means More Hits

Experiments that matter fail most of the time, because experiments worth taking for a startup promise trajectory-altering outcomes. If experiments are denominated in man days, a startup can take 100 a year and the 10 that work will render it unrecognizable (good). If they’re denominated in weeks, it will take 10 and have one major win a year, enough to keep things interesting. If they’re denominated in months, it might take two and nothing will come of it. Unlocking a massive surplus-generating win every month produces a qualitatively different startup than producing one a year, which itself is a world away from never winning.

Many Counterparties Have a Minimum Delta

Your product may not quite be ready for a huge prospect, but they might be willing to bet on you if they see you move fast. Why not get started today if everything will be ready in two weeks anyways? You can start to look at customers as having a response function. If they see face-melting velocity, they’ll sign today. Good velocity, maybe in two weeks. Mid velocity? Circle back next quarter. Bad velocity (below the minimum delta)? Bye! Unlocking a big customer a month early can be huge. Unlocking every customer months earlier is always transformative. As it happens, many other counterparties (prospective employees, investors, so on) operate the same way.

Think of velocity as an SLA, as a promise. If Rippling advertises its support team’s time-to-first-response, we advertise our changelog.

Market Speed

Many startups sell to an evolving market. Changes in customer preferences and use cases translate to accomodation on the product and engineering front. If it takes you 3 months to ship a product, it might be half obsolete upon arrival. Being nimble isn’t a vibe - it often means -1000/+1000 daily LoC churn just to tread water in an changing environment. Is that -1000/+1000 churn an entire day of work, or just your morning? If you’re not well above the waterline for your opportunity, your default is to lose ground.

Inadequate Equilibria

The human default dynamic for hours worked is dominated by marginal returns. For the reasons above, additional hours of work at a startup often yield increasing returns, sometimes with substantial local convexity. Per Thiel, you should throw everything you have behind convexity. Per reality, local convexity eventually gets throttled as the wheels start coming off the bus in other domains. While hypothetically working 48 hours straight maximizes context window utilization, man needs to sleep. Naturally, this results in equilibrium levels of velocity at the team level. I’ve seen S-tier series A startups that move disgustingly, blindingly fast. A-tier startups that hit a quick stride, B-tier startups that are respectable and a big tail. A B-tier startup with a great market can still win, don’t get me wrong.

But if you find yourself straddling between tiers - an inherently unstable position - I believe that “bumping up” can have outsize impact on odds of success. Early on, you get to decide.