Slow is Smooth, Smooth is Fast.
Lessons
“Slow” is the fastest you can do something without making mistakes
The more time-constrained, the more important it is
It only applies when there are no second chances - failure is important for learning
“Slow is smooth, smooth is fast” is a catchy adage that I learned in another life, and is a principle whose value has proven itself repeatedly and frequently over the years. The same concept is found in “The Tortoise and the Hare”, where the lesson is known by just about everyone: slow and steady wins the race. But what does that really mean? It means that the faster you go, the more prone you are to mistakes, and mistakes cost at least time - depending on the circumstances, they often cost much more than just time. Although it looks good on paper, some might not accept it as practical in reality, suggesting that slow cannot equal fast, that they’re antonyms and not synonyms for a reason. That’s simply because you’re thinking of slow and fast as binary, and they’re not. Like most principles, this one, and it’s definitions of slow and fast, are relative.
Slow is relative
It’s different for each person. What this principle really means is that you should move at the fastest pace of mastery and never faster, and that level of mastery is different for every person or group. Think of mastery as the fastest speed at which you can do something without making any mistakes and while under intense pressure. Take this example:
My level of mastery driving a car is far less than (as of writing this) seven-time F1 champion, Lewis Hamilton. Now, say you set up a line of cones that each of us had to weave a car through without knocking a single one down, and every cone we knocked down cost us $1mm. I would need to go embarrassingly slow compared to him, but I’d still do it faster than my 90+ year old grandfather (no offense, Nonno). However, one thing holds true for all three of us, in order to consistently avoid knocking a cone down, we’d have to go slow relative to our individual total driving ability.
Next time you play the game “Spoons” watch who wins, it’s almost always the calmest and most methodical player. The loser of the game is the one who is trying to push their speed of grabbing and exchanging cards beyond their ability to also monitor the number of spoons remaining. They overload their brain, which causes them hyper focus on one thing (the cards) in an attempt to compensate, which causes them to make mistakes (not seeing spoons being grabbed), and then they lose the game.
If you’ve ever taken a supply-chain or operations class, or work in those fields, you too know this rule well; in those fields if you don’t follow this rule, you end up with overages and bottlenecks respectively. Look at the mad dash for toilet-paper during the pandemic, or any number of other supply-chain issues that occured. To compensate, stores put a limit on the number of certain items you could buy. Why? To forcibly slow the system down to a manageable pace.
The point is, regardless of the application, going slow relative to the system’s (Nonno in a car, the supply chain, your brain, etc.) maximum ability prevents it from overloading, allows it to efficiently process tasks without error, and ultimately allows it to maximize throughput.
Not all the time though…right?
“Surely in times of crisis, when time is the biggest factor, this principle doesn’t apply…” you might say. In fact, when time is constrained is precisely when this principle matters the most and can provide the most benefit. When you’re under time constraints is when mistakes - which cost time to correct - are the most detrimental. Say it’s the NBA finals and Lebron James has 5 seconds to get the ball down the court and score; if he trips, loses his grip, lets an opponent steal the ball, etc. it will cost him the game. If it’s the first period, he could intentionally throw the ball out of bounds and it probably wouldn’t make a huge difference to the outcome of the game.
That may seem obvious, but this is truly difficult to follow in the moment, when your brain is going 1k miles-per-hour, and the pressure is on. Think about the last time you were up against a deadline at work. How did you react?
As a Product Manager, I produce very little myself. I’m beholden to my development teams to produce functionality for me. However, I’m the one held accountable for the experience users have, and the timeline in which new features are delivered. It’s a pretty precarious position to be in - all the responsibility without any of the control. So, I often find myself wanting my teams to go faster, to build more in less time, and I’ve occasionally forgotten this rule and pushed them past their level of mastery in order to deliver something faster than they’ve told me they can. And you know what? They’ve always delivered. Every single time, they’ve delivered the functionality I need in the timeframe I push them to. Wait…what?
It’s true. However, every single time it’s been lower quality, has bugs, is fragile and needs to be reworked down the road, etc. Ultimately it’s never been worth it. Now again, speed is relative, and nothing is binary (except binary :P). I’d venture to say most teams don’t operate at their highest level of mastery at all times, so you can push a team to go faster; the point is not to push them beyond their highest level of mastery (which again, is lower than their total possible output).
How fast do I push then?
It’s a great question, but it doesn’t have a great answer. Individually, it takes an incredible amount of self-awareness to know what your highest level of mastery is. On a team, it takes incredible “inter-awareness” to know what your collective highest level of mastery is - note: it’s only as high as your weakest team member’s. What you can do however, is constantly recalibrate. Are you making mistakes? Slow down. Are you executing consistently, push yourself to go a little faster. Repeat.
One closing thought is that this principle applies only to execution, when the chips are down, results really matter, and most importantly there are no second chances. It does not apply to practice or training. In practice, training, or really whenever you can afford to make mistakes and learn from them, you must push yourself to that point in order to improve. Muscles only grow when you push their limits. Diamonds are created under pressure. Etc. Etc. Etc. Again, this applies both individually and when on a team, and really be honest about it. The vast majority of the time it’s incomparably valuable to fail or let your team fail, inspect what happened, and adapt for the future.