WABI – SABI is a Japanese aesthetics and at its core is the acceptance of imperfection. To be at peace with the product. The underlying idea I like about this concept is that it is preferable to do something in a reasonable amount of time than to spend an inordinate amount of time seeking perfection.
In military doctrine, where they literally put their lives on the line on the battlefield, we find an equivalent phrase from one of the key generals in the defeat of Hitler in World War II: A good plan violently executed now is better than a perfect plan executed next week. — George S. Patton
I learned this lesson 4 years ago while working for a mobility solutions company at a leading German car manufacturer. The idea wasn’t that revolutionary. A market analysis showed clearly that there is not saturated market in Spain for van and truck rental. The company was set up and a team was hired (including me as its second employee). When we finally launched our rental service, it did not work out as calculated, even though we delayed the launch to have a perfect product. Turns out we could have launched perfectly well and started billing months earlier in the same fashion we did with months’ delay. I estimate that the delayed launch cost us at least one hundred thousand euros.
Perfectionism is not only the enemy of the good. It can also be terribly expensive.
Ask Vilfredo Pareto, the creator of WABI – SABI for business. His Pareto principle says that 80% of the results are achieved with 20% of the total effort. The remaining 20% of the results require the most work with 80% of the total effort. Read that again: If you done 20% of the total effort, you are already at 80%. Near perfection, but to achieve the perfection you need to invest 4 times the same effort. In a world where everything can change with one single viral tweet, choosing where to invest your time to maximize your learning opportunities can mean the difference between succeeding and disappearing.
Iteration speed is a competitive advantage! Ask Elon Musk. When Tesla first tested their cars with the other car companies in Finland in snowy conditions. The competitors were surprised to find the whole engineering crew with equipment in the cold. The Tesla did some rounds and afterwards the engineers gathered to check the results and iterate directly on the track. Traditional car companies, drive lots of rounds and then go back with the car to their factory or lab in their home countries to iterate. The first approach allows several iterations within a week. The second approach is a question of several months. Tesla was belittled by the traditional car companies; however, they closed the gap thanks to iterating more often.
While the other companies worked to minimize risk, Tesla, knowing that the real learning happens on the track, built his cars decoupled. This allowed them to change settings in a very short time after each attempt, reducing learning cycles from months to days.
Tesla’s rivals sought perfection. Tesla, however, maximized it’s learning opportunities by WABI – SABI (prototyping, testing, failing and iterating). This is one of the keys to the best teams and product companies out there: they optimize to learn.
The false dilemma of rework
One word that sets me off in my teams every time I hear it is “rework,” referring to avoiding doing the same job twice because you didn’t do it perfectly the first time. I started my consulting career in processes. By nature, I tend to optimize everything I do. Doing the same thing twice because you didn’t get it right the first time seems like a crime. It goes against everything we are taught.
But if you go back to the Tesla story, those who lost the competition, are those who wanted to avoid rework by getting it perfect on the first try. Reworking is the basis of experimentation. How many times did Edison try to create a functional light bulb until he succeeded?
The real problem of rework is not the rework itself, but the speed with which you are able to iterate. The cost of throwing away a one-day or one-week effort has nothing to do with the cost of a feature that took you three months to release. If your development cycles are long, your problem is not rework, your problem is the maturity of the company.
Avoiding rework, premature optimization, leads to comical situations. I’ve seen initiatives delay years by trying to avoid doing the same work twice. Years in which you could offer a solution to your users, and you didn’t do it to avoid incurring a supposed double cost in the future.
Donald Knuth, one of the fathers of computer engineering, makes it clear: “Premature optimization is the root of all evil.” At the same time, it takes a lot of experience to tell an engineering team or your management layer that rework can be good. Furthermore, sometimes it is necessary to take shortcuts to iterate, because that speed you gain by learning is what keeps you in the game and with options to win.
I encourage you to pass this post to your teams and companies and start that discussion: Are we optimizing our time to maximize our learning, or are we optimizing to supposedly save rework by investing extra time to make it perfect the first time?
The answer to that question can give you clues to the maturity of the company and even its own future. And yours as well. Those that are not optimized for learning have their days numbered.