Foreword: In the following article, I will refer to a huge number of books and audiobooks. For my comfort and simplicity sake, I will refer to all positions mentioned in this article as books. No meter if I have actually read them or listened to the audiobook.
Lately thanks to Audible and Walking my dog (with extreme social distancing) I was on reading (listening?) spree: Phoenix Project, Beyond phoenix projects, Unicorn Project, DevOps Handbook, The Goal, Drive, The Little Book of Ikigai, How to Set Goals with Kaizen & Ikigai, The Starfish and the Spider. In short: books about motivation, DevOps, Communities and work methodologies. While reading, there is one exciting thing.
Toyota success–so what is its real success?
Most of these books bring a case of Toyota. I won’t retell the stories here, but suffice to say it had amazing success, that nobody expected and everybody tried to figure out their secret. Here is where the problem starts. The Goal, and to some degree, DevOps book’s argument that the success of Toyota came from work methodology (Lean Manufacturing). Similarly, a book about Kaizen. Drive claims it is all about motivation. “The Starfish and the Spider” states it is thanks to the way they build their community as starfish model (or more precisely hybrid model). I hope you see the pattern now. For most of the books, Toyota was one of the examples used in favor of the ideas presented. After reading them, I had two issues in my mind:
- So how was it really with Toyota?
- If each book simplifies Toyota case, how much I can trust other examples, they brought to make their point? I don’t have the answer to the second question yet, but I have a good guess about the first.
None of the books had time, will or experience to looks at Toyota case holistically, each of them looked thought their own biases and expertise. So they saw how their cog affected the system. But They weren’t analysing how the cog itself was affected by the system, how other parts were making more or less efficient. “Beyond the Phoenix Project” is the exception here the whole book is dedicated to showing how different practices interact to create DevOps (but still simplify case of Toyota) That’s why system thinking is crucial. We need to see how all of these elements interact.
Long ago, while I was studying Computer Science at the Wroclaw University of Technology, I had Economics Classes. One of the most important terms that Doctor drilled into us was Synergy. If you like playing Deck Builder or Collectible Card Games, you may know this term by heart. Basically, it means that the whole is much just the sum of its parts. I think this video explains it simply. This is also how, in theory, scrum works, each practice by itself doesn’t do much, but together they supposed to give a great boost.
In defence of the books.
I realise that there are other explanations why the books are looking are simplifying case of Toyota. I will mention here two that I think are most probable.
Maybe all those books are writing about the same thing?
There is one more argument here to be made. What if they all are looking at the same aspect but naming it differently or presenting it from a different angle? That is also possible. I would have to reread those books a few more times to answer this question. But I think this is a low probability.
Simplification to make the message more clear.
This is something all writers, speakers etc. has to do. There is always so much information so many variables to cover it all would make long, and maybe hard to read materials. Thing is, this is the case for Articles, but for books, I can’t accept this as an excuse, by definition you have much more space and you should use some of that space to discuss complications and interaction with other systems.
To sum it up how it was with Toyota, really?
I don’t know. But If I would wager a good bet. All those books were right; it was due to community, motivation, and work practice. And I believe that each of these elements was pushing the other to higher performance. No system is saved by one decision, one chance, one man. Yes, maybe there is that point where they were looking back, we can say that was the crucial moment. But still, there were lots of moments before, and after that led to success. That is why we need to look at the whole system. And if someone says that he knows how to fix our project /team/company by changing one thing and we will see results in next week or months. They definitely don’t know what they are talking about. Personally, I think Kaizen is closest to truth; small steps can lead to huge changes. Of course, sometimes big change is needed at once. But remember the lesson from “Civilization” game series, after the huge change there is a time of anarchy until the new system takes roots.
Ps I started reading The Lean Startup – want to bet if toyota will be mentioned in book?