Paeans have been written to big, collective projects that were done quickly. Mark Zuckerberg tells you to move fast and break things. Big companies are adopting “agile” management practices to try to speed up (albeit usually ineffectively).
So is going faster always the answer? Maybe not! Venture capitalists are encouraging startups to slow down their spending, and therefore growth, to weather a difficult funding environment. Zuckerberg's company launched Threads impressively quickly, but arguably too quickly, because lots of people have already tried and left the service.
A better goal, in business and in life, is to control the tempo for your benefit, whether faster or slower.
Think of football strategy. For decades, every team moved slowly, huddling between every play to plan out the next one, unless they were forced to run a fast "no-huddle" offense because time was running out. Then some teams realized that going faster could give them an advantage (because the defense would also have no time to plan or substitute players), so they started doing that by choice. Faster = better, right?
But that's not the end of the story. Today, teams have realized that mixing tempos is even better, so now they have a whole set of strategies to intentionally shift faster and slower to be unpredictable and deceive the defense. They run different no-huddle offenses at different speeds, sometimes looking to the sideline to get the playcall, other times just using voice signals. The defense doesn't know how fast they'll go, so it has to be ready for the fastest one, which reveals information when the offense slows down. And some offenses now fake their speed to catch the defense off-guard—pretending to slow down and look to the sideline, then snapping the ball immediately when the defense does the same.
In real life, there is no opponent to keep off-guard, but there are still situations in which going faster or slower might be helpful.
When do you want to go faster?
When you'll learn from doing something. If you release a product quickly, you'll get user feedback quickly, which might tell you if you're on a completely wrong path.
When your task unlocks dependencies. If you go grocery shopping right away, you have more options on what you can cook for lunch, whereas if you put it off until later you'll have to order in.
When new opportunities come up. If you wait two days to respond to an email about a job opportunity, and then the sender does the same, the moment may have passed by. In contrast, if you respond within a few minutes, not only will the opportunity still be there, but you'll have more opportunities to go back and forth on details about the opportunity to make it a better fit. (As Ben Kuhn puts it, these situations have nonlinear returns to speed.)
When you're getting something you'll actually use. The sooner you hire someone to join your team, the sooner they can start contributing—if you wait longer, that time is lost forever. (This is one reason why the famous solution to the “secretary problem" doesn't actually hold in practice.)
When do you want to go slower?
When you're more likely to learn about the circumstances. If you have the opportunity to immigrate to the US, but the value of doing so strongly depends on the political environment, it might be better to wait until after the election rather than to move quickly. (You can also learn just through self-reflection, although this one is more of a trap: "if I just have more time to think about it, I'll eventually get it right" usually doesn't work.)
When you have limited resources. Startups worried about running out of funds might fit in this category, but intangible resources also count: if you ask collaborators on a project for too much input too quickly, they might get sick of you and quit.
When having options is a bad thing. If you're doing a project for someone who is a notorious nitpicker, waiting until the last minute so they don't have time to make changes might be better than doing it quickly.
When it's not actually that important. Then, it's usually better to prioritize other tasks first so you can get the "faster" benefits for those things. (In fact, Structured Procrastination means putting off one task you especially don't want to do might make you faster at everything else.)
Just as football offenses benefit from deciding how fast to move, in life it's a lot more comforting to be in control: working really hard to do something quickly is much easier when it's your decision than when you're doing it because your manager or client told you to. You won't be able to avoid the latter cases, but you can reduce them by predicting what needs will arise in the future and addressing them early, or by working ahead when you have energy so you have more slack for last-minute requests.
And although there is no defense to confuse in real life, you should still mix up your tempos sometimes—think of it as a mini-experiment to learn more about how fast you can go, what are the benefits when you do so, and what are the trade-offs of going slower. To practice what I preach, I set a timer and forced myself to write this week's article in a half-hour (usually these take a couple hours), plus some editing time. Tell me if it's worse than usual!
I'm curious about the claim that companies are adopting agile management practices badly. My experience with "agile management" is bad, and I'm wondering if that's unique or not.