June, 2017: my partner Eve and I are stuck at the visa-on-arrival desk in the domestic transfer wing of Bole International Airport, Addis Ababa. The rest of the transfer passengers, all Ethiopian, are waltzing past us to form a monster queue at passport control. As soon as I get my precious stamp, I sprint off to hold our place before more passengers sneak in front of us.
Ten minutes later, Eve finds me, groggy from our redeye and nonplussed about navigating the Ethiopian visa desk on her own. “Why did you have to run off like that?!” Somehow, “so that we could wait at the departure gate instead of in the passport control line” doesn’t seem like a very good reason.
It was at this moment that I realized I was an unreasonably impatient person.
(In retrospect, I probably should have been tipped off by my compulsion of doing a mental critical path analysis on any everyday activity taking more than 15 seconds, but I just thought that was normal until I started dating people and noticed they often did things in a sub-optimal order.)
Now that I’ve confessed to the sin of impatience, I’m going to spend the rest of this post trying to convince you that it’s actually a good thing.
(The good part is the habit of frequently asking yourself “how could this thing take less calendar time.” I don’t recommend manifesting it in annoying ways like ditching your partner in an Ethiopian airport.)
Being impatient is the best way to get faster at things. And across a surprising number of domains, being really fast correlates strongly with being effective.
Obviously, lots of these are non-causal correlations. Still, the sheer number of different datapoints is a surprising convergence:
It seems trivial, but lots of different people have observed that being slow to respond to emails is a bad sign, or that famous people whom you’d expect to be swamped respond surprisingly quickly.
the most famous, interesting, powerful people all read their own email
they’re almost universally good at responding to it quickly
they’re always very, very curious.
they have very little time. Anything with friction gets done “later”
people tend to be either slow movers or fast movers and that seems harder to change. Being a fast mover is a big thing; a somewhat trivial example is that I have almost never made money investing in founders who do not respond quickly to important emails.
It’s become common wisdom that launching (and iterating) quickly is a major factor behind whether startups succeed.
[Y]ou have to be decisive. Indecisiveness is a startup killer. Mediocre founders spend a lot of time talking about grand plans, but they never make a decision. They’re talking about you know I could do this thing, or I could do that other thing, and they’re going back and forth and they never act. And what you actually need is this bias towards action.
The best founders work on things that seem small but they move really quickly. But they get things done really quickly. Every time you talk to the best founders they’ve gotten new things done. In fact, this is the one thing that we learned best predicts a success of founders in YC. If every time we talk to a team they’ve gotten new things done, that’s the best predictor we have that a company will be successful.
This propagates even down to the level of how quickly you deploy software changes. Nick Schrock on Facebook / Instagram moving fast and breaking things:
Instagram was even faster operationally than Facebook. They had continuous deployment. Any engineer could deploy at any time (they would run a command called “Yolout” lol). Facebook was on weekly deploys at the time on the web and way slower on mobile.
IG story definitely lends credibility to the those-who-ship-faster-win argument
…Worth noting that Facebook learned from this. As the company grew, the release cadence got faster. First daily, then twice daily, and it is now continuous. It’s a remarkable achievement by the release engineering team.
It’s not just Facebook; Accelerate found a strong correlation between deploy frequency and performance:
To summarize, in 2017 we found that, when compared to low performers, the high performers have:
46 times more frequent code deployments
440 times faster lead time from commit to deploy
The “speed matters a lot” principle applies even to things that are already very fast. Google has found that users dramatically prefer faster webpages:
The BBC found they lost an additional 10% of users for every additional second their site took to load.
DoubleClick by Google found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load.
- When AutoAnything reduced page load time by half, they saw a boost of 12-13% in sales.
Google famously prioritized speed as a feature. They realized that if search is fast, you’re more likely to search. The reason is that it encourages you to try stuff, get feedback, and try again. When a thought occurs to you, you know Google is already there. There is no delay between thought and action, no opportunity to lose the impulse to find something out. The projected cost of googling is nil. It comes to feel like an extension of your own mind.
What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task. Users almost always have multiple strategies available to pursue a goal — including deciding to work on something else entirely — and they will choose to use faster tools more and more frequently. Fast tools don’t just allow users to accomplish tasks faster; they allow users to accomplish entirely new types of tasks, in entirely new ways. I’ve seen this phenomenon clearly while working on both Sorbet and Livegrep…
Many individual tests at Stripe would take 10-20s or more…. Because we succeeded at building Sorbet so that it could typecheck the entire codebase in that time window, it became the fastest way many developers could get decent feedback on their code, to check for basic typos, misused APIs, and other low-hanging classes of errors. Since it was their fastest option, we saw users reaching for Sorbet as their first line of checking their code fairly early on in our development and rollout. Getting even mediocre feedback and some confidence fast was much more important than anything that would take minutes.
Watching users use livegrep, I’ve seen a related upside from its performance…. Because livegrep is so fast, users use it interactively in a way I’ve rarely seen people interact with other search engines: they enter an initial query, and then, if they get too many or too few results, they edit it based on the result list, which gets a new set of results, which they continue to refine or expand until they hit on the results they are seeking.
I also made an effort to learn to type really fast and the keyboard shortcuts that help with my workflow.
I was trying to figure out which is the most important computer science course a CS student could ever take, and eventually realized it’s Typing 101.
The really great engineers I know, the ones who build great things, they can type.
This matches my experience at Wave, where the best engineers are disproportionately likely to type quickly, know their keyboard shortcuts, and have invested a lot of time making their common tasks efficient.
Obviously, those aren’t the main things that make them good engineers—but I think they help in more than just the obvious ways.
At Wave, when hiring, we’ve noticed that moving someone through the hiring process faster makes them much more likely to accept our offer. If we take a long time to get back to them or schedule the next steps, it both gives them more time to lose interest, and makes it seem like we’re not excited about them. Not a good look!
This is apparently common trope in sales as well—“time kills all deals”.
Paul Graham on how the founders of Stripe got time on their side:
At YC we use the term “Collison installation” for the technique they invented. More diffident founders ask “Will you try our beta?” and if the answer is yes, they say “Great, we’ll send you a link.” But the Collison brothers weren’t going to wait. When anyone agreed to try Stripe they’d say “Right then, give me your laptop” and set them up on the spot.
Fred Wilson on the same effect in networking:
That night when I got home I told the Gotham Gal “I met Danny Meyer today and he gave me his card and said I could call him whenever I need a table.” To which she replied “go there for lunch tomorrow.” And I told her “I don’t have a lunch tomorrow.” She said “Get one. He will remember who you are tomorrow but won’t next month.”
One of the most influential military strategy writers, John Boyd, is most famous for the idea of the “OODA loop:” that human action is an iterated process of observing the world, orienting within it, deciding how to respond and finally acting on the decision. Boyd’s claim was that going through the OODA loop faster was a decisive advantage:
In order to win, we should operate at a faster tempo or rhythm than our adversaries—or, better yet, get inside [the] adversary’s Observation-Orientation-Decision-Action time cycle or loop … Such activity will make us appear ambiguous (unpredictable) thereby generate confusion and disorder among our adversaries—since our adversaries will be unable to generate mental images or pictures that agree with the menacing, as well as faster transient rhythm or patterns, they are competing against.
As a recent example, for instance, many states and countries waited far too long to lock down when the COVID epidemic hit because the virus got inside their OODA loop:
Right now, the perception of agency at all levels is falling. Individuals, corporations, governments, heads of state, stock traders, the UN, everybody feels they’re losing the plot, but they don’t see anybody else finding it…. As far as we can tell, a virus has gotten inside the OODA loop of Homo sapiens, and seized the initiative, while we’re struggling to figure out what to even call it. It is spreading faster than our fastest truths, lies, and bullshit. A supersonic shock wave in the narrative marketplace.
Life in general
If you’re 10–20: These are prime years!
People who did great things often did so at very surprisingly young ages. (They were grayhaired when they became famous… not when they did the work.) So, hurry up! You can do great things.
(He also maintains a personal list of fast things.)
Once you have figured out what to do, be unstoppable about getting your small handful of priorities accomplished quickly. I have yet to meet a slow-moving person who is very successful.
There’s an obvious way in which moving faster is important: if you’re 10% more productive, you will finish your work in 10% less time, so you can do 10% more work total. But I don’t think that’s the main reason that speed is important.
It’s worth pointing out at this point that all of the quotes above aren’t just about churning out work—they’re about processing information more quickly. The faster you process information, the faster you can incorporate the result into what you do next.
In other words, the main benefit of being fast is that you end up doing different things. Nelson Elhage’s point—“having faster tools changes how users use a tool”—applies across nearly every domain:
If you respond to your emails quickly instead of slowly, you’ll get access to more new opportunities, and end up prioritizing them over whatever you would have done instead.
If you make it 10x faster to test your code, you don’t just save time waiting on tests—you can start doing test-driven development, discover your mistakes earlier, and save yourself from going down bad paths.
If you deploy your new app now instead of next week, you’ll learn how users like the new features one week earlier, and you’ll be able to feed that knowledge back into future product decisions.
That means that moving quickly is an advantage that compounds. Being twice as fast doesn’t just double your output; it doubles the growth rate of your output. Over time, that makes an enormous difference.
My first great mentor taught me to “fail fast” so I can move on to the next proposed solution. My second greatest mentor taught me that if I miss the solution because I’m rushing I’m failing forever. I work somewhere in between.
A rebuttal against your case for impatience:
tldr, your article is a collection of cases in which you’ve defined success as ‘getting more, good results faster.’ Yes, because we’re in a capitalist culture in particular, there are a lot of examples, but is that a good thing? Also, as you summarize at the end of the article, a lot of the value in your approach towards impatience is that you believe in taking the time to find ways to make your effort into a “multiplier” for successful results. That you are so good at that skill of finding multipliers that you think of it as “just what happens when I think about how to do something faster” is also something very, very unusual about you.
But, to get back to impatience… I think most people would categorize “impatience” as the compulsion to move quickly, likely at the cost of moving wisely. They’d say, “move fast and move well, but if you feel like you’re being driven mad by the compulsion to ‘do something/anything, as long as its fast’ force yourself to stop. and. think. because that’s an insanely dangerous mindset for making important decisions.”
Ok, here’s the longer version:
Synchronicity matters. You already mention this one a lot in your post, but you don’t connect the thread between the instances. Tldr: it is frequently valuable to slow your pace down to match the world around you, rather than moving as fast as you can, oblivious to that. I think the airport story is a good example of this.
Being impatient can make bottlenecks worse. It’s frequently the case that a system will have many types of actions that draw from the same, limited resource pool, and, in such cases, it’s critical to keep the pace synchronized in order to get maximum bandwidth through the bottleneck. In a way, this could be thought of either as a generalization of “Synchronicity matters” or as a special case of it. I’m separating it out because I think it’s one of the most likely ways in which one person’s impatience, when they’re part of the group, can lead to the failure of the whole group. tldr, if you aren’t aware of the resources balances within a system, blind impatience can be an incredibly destructive force, even if it’s applied very skillfully within the sub-context that one agent has access to. Which leads us into…
Flaws can propagate just as quickly as successes. There are a lot of nearly-literal examples of this in engineering, but to connect to one story from your post: a lot of startups expand too quickly and find that flaws like internal divisions prioritizing within the company’s complex decision, ethical, and cultural phase spaces grow faster than can be sewn up. The company gets hewn apart.
Rushing towards success implies an “ends”-centric definition of success, rather than a “means”-centric one. This is a bit complex in the context of your article, because I think you’re actually a far above average means-centric thinker. This article is practically dripping with that attitude – with the near-compulsion that you charge yourself with acting intentionally every minute of every day. But, in this particular article, you’re making a very ends-centric definition of success. “Get more success sooner, isn’t that what everyone wants?” … maybe in America :-P, maybe in capitalism. But, no, no this isn’t an absolute ethical framework. Look at any ethical scenario in which you’d say “no, it isn’t alright to do X to accomplish Y, even if Y is amazing. I’m simply not OK with a world where X is something that someone ‘should’ do.” … Means-centric success and ends-centric success aren’t in opposition to each other if “more faster” is achievable without sacrificing the quality of the means. But it’s also important to ask the question: “why is ‘more, faster’ good and important to me in this context?” and if you don’t have a pretty great answer to that question, I’d argue that you should probably slow down and make sure that you’re proud of how you’re doing something.
Conflating doing it now with doing it fast. There are a few interesting examples in your article that have the common thread, “speed is a way to deal with circumstances where it’s hard to maintain focus for a long time.” This is essentially true by definition – if it’s hard to maintain focus for a long time, making the time shorter is an improvement. I think “time kills all deals” is a solid fit for this pattern. Time kills deals because people have never really mastered object-permanence ;-) … if the contract, story, person, etc. isn’t right there, then they’re lost in the noise of “the vast world outside my perception bubble.” So, “get it done while they’re there” can frequently be the only way something gets done. But, I’d argue that this is a conflation of the observation that giving a project disjointed, discontinuous attention can make you much less effective, with the observation that speed and an overwhelming sense of immediacy make a salesperson effective.
I think this last one is particular empowering against the argument Collison makes that “10-20 are prime years!” Yes, some parts of your mind are ‘quickest’ during those years, but many parts of your mind are also actively making you highly distractable. The key, in my opinion, is not letting “distractable” evolve into “lethargic” or “constantly anxious and locked in indecision” as you get older."
Thanks so much, this is a very thoughtful reply with great points!
I agree with large chunks of what what I think you’re pointing out:
I’m tendentiously using “impatience” to refer to trying to go faster without any of the compulsion / foolishness / etc. that it usually entails. Points 1-3, which I agree are correct, are examples of how impatience ends up being counterproductive even by its own standards—or, as I’d sneakily reword it, badly applied impatience. But then again, I could (and probably should!) write whole posts about learning to apply my own impatience productively rather than anti-productively. I strongly agree that it’s not automatic. I do think it’s possible and worthwhile to learn, so maybe that’s a point where we diverge.
I’m assuming readers have goals which they care a lot about achieving. (I don’t think capitalism in particular is like a large part of why impatience is useful—I think the “impatience causes you to learn + course-correct faster” point helps equally with achieving many non-capitalism-related goals.) But I do think it is less productive if you are using a less goal-oriented ethical framework, e.g. I would not expect impatience to be a helpful frame for people trying to attain Buddhist enlightenment, cultivate their Aristotelian virtue, etc.
On point 5 (about some of the examples being dealing with lack of focus), I agree that these examples operate by a different mechanism (I think of it as “momentum”) for why speed can be important, that doesn’t really fit into the “speed -> faster learning -> course corrections” mechanism described at the end of the post. I do think they’re still examples of where well-applied impatience can improve outcomes a lot, but I wasn’t careful about parsing out the two mechanisms.
Thanks again for the thoughtful reply :)
Many, many words. I was impatient reading this comment to you Ben.
As someone who is also constantly mental mathing and optimizing everyday situations I can relate and am interested to learn if you make a distinction between being impatient and having a sense of urgency.
If I understand your post, you’re saying that speed should always be optimized for in business, life, etc. to increase the chances of success.
I agree with this presupposition, but I’m not making the connection on these two things:
How is being impatient actually making things faster? As an Air Force Academy grad, I’ll pick on the OODA Loop reference. My counter argument is that getting a tighter, or faster, OODA Loop has nothing to do with impatience - and being impatient inside an OODA Loop will most often be counterproductive to success.
Thinking of fighter pilots in a dogfight… making decisions with impatience and acting on them can have very negative life and death consequences.
The classic 80s movie Top Gun portrays this exact dynamic as Tom Cruise’s character, Maverick, inadvertently kills Anthony Edwards’ character, Goose, because he is impatient in training and makes a poor decision. To fulfill his character arc Maverick must learn to suppress his impatience in order to become America’s best fighter pilot - and ultimately save his country from the threat of communism. ;)
Kidding aside, the movie portrays that getting better at creating faster OODA Loops in the sky requires time and experience. It can not be rushed simply because someone is impatient. It also portrays that being impatient inside the loops causes catastrophic failure. This is generally known to be true within the military and coincides with the Navy SEAL philosophy that slow is smooth and smooth is fast.
Do you have examples where being impatient makes things sustainably faster? Applied to software development and startups - I think teams should definitely have a sense of urgency when it comes to establishing feedback loops between prospects/customers and product design/dev. And I agree that faster tools are generally better.
But once these processes are in place, they will always be constrained by conflicting priorities and resource limitations.
We know when leaders are continuously impatient here and demand more from the system faster, that it typically does not lead to a sustainable increase in speed. Instead, it typically leads to poor work/life balance, employee burn out, higher turnover, and when it’s bad enough - negative publicity… all of which are counterproductive to success.
Appreciative of your post and genuinely interested in your response as you have the time.
Chris2 – “slow is smooth and smooth is fast” is a beautiful and soothing phrase :) And I really like your use of “urgency” in place of “impatience” - I think it removes a lot of the “compulsive” implications that the word “impatience has.
Ben – regarding “applying impatience productively” I definitely think this is a skill that can be learned. :) I just think it’s difficult to do it well, and very difficult to learn how to systematically and quickly do it in a novel circumstance. Also, I think it’s sometimes extremely difficult, nigh impossible to do well if you don’t understand the full picture of what resources are being drawn into a system to keep it functional.
regarding means vs. ends-centric thinking: The way that you phrase the two examples of means-centric thinking you gave is intentionally(?) ironic. If you have an endgame (like enlightenment or maximizing your heaven-entry-point-score) that’s ends-centric. Here are two examples of means-centric morality:
A) I would never get someone to deeply trust me if I knew that I would grievously betray them. Essentially no matter what is at stake, I’m unwilling to commit to that course of action.
B) When I think back on the narrative of how I chose a college, moved out to CA, and eventually wound up where I am now, I’m proud that at a lot of the “junctions” I pushed back against the fear that would have led me down “more normal” path. It’s not that I think those paths would have led somewhere ‘worse’ than were I’ve ended up. Rather, I’m proud simply that I’ve struggled and pushed back fear’s influence at each juncture.
Very beautifully written.. Thanks Ben!
I agree with the article. However, there are times when we must think about an idea much more deeply. I can cite your own article Think Real Hard here.
Thinking hard takes time. Often after taking an action, we must pause, review what we have done and course correct, and then take action.
Isn’t “moving faster” just another name for efficiency, rather than impatience? I don’t really see how being impatient makes you more succesfull, but it surely makes a lot of people more stressed. And it’s a good thing only for their therapists.
In order to add some balance, go read “Chesterton’s Fence”
My favorite so far. Thank you.
Another example: https://marginalrevolution.com/marginalrevolution/2020/07/frequent-fast-and-cheap-is-better-than-sensitive.html
A well crafted article with some great references and citations. Thank you for sharing.
I do not fully agree with the idea of impatience as a driver for growth. I think the ideas propagated by the software-centric ecosystem of ‘business at the speed of light’ and ‘fail faster’ has created an unrealistic narrative around what it means to grow and succeed. And most of us have become echo chambers of this idea aiding the confirmation bias.
I would base the argument on speed (I would call this impatience-driven) vs velocity (I would call this purpose-driven). Impatience might build momentum and help you fail faster and move on to the next experiment - however, what about the costs involved to keep going at that pace? Purpose-driven velocity on the other hand might give you time to reflect on a failure, regroup and evaluate the next course of action before jumping on to whatever you see next in the spirit of moving impatiently. I have learned this the hard way while working with my teams on different projects.
I also think OODA loop is an excellent example of velocity though you used it to drive an argument in favor of impatience. Observe and Orient are the most critical phases of the OODA loop - if you get them wrong, it does not matter what you decide and act on as the probability of failure increases. I would consider impatience to be a big negative during the first two phases of OODA. This might be a crude example here, but I think of the Cuban Missile Crisis (in military terms) and how OODA would have played out in the mind of President Kennedy in the context of impatience.
My two cents: Context is very important in understanding how to use impatience or urgency effectively. If your decision is easily reversible, by all means move fast and impatiently. If your decision is of irreversible type or carries a heavy opportunity cost, reflection and evaluation of second-order effects might be useful.
This is similar to Dan Luu’s piece on productivity and velocity. Working on the right thing and working fast on it is better than picking just one.