Toyota’s last twelve months could have been better. Reading about it in Stephen Denning’s book The Leader’s Guide to Radical Management led me to thinking about the reason Michelle and I started Corporate Growing Pains.
In Chapter 9 of the book, Steve outlines Radical Management Principle #6 Continuous Self-Improvement and provides an extensive review of Toyota’s history over the last five decades, as well as the problems they experienced over the last 5 years that led to their troubled 2009 – 2010.
He holds Toyota up as an exemplary model for Radical Management, yet Toyota is still dealing with the fall-out from the issues it was recently forced to face. In his analysis, he says:
We can only speculate on why Toyota didn’t get to the root causes of the problem sooner. Everything in its history indicates that it would be the last company in the world to sweep a problem under the rug.
The analysis suggests that there wasn’t one single problem. Instead the organisation lost its way a little. The values got lost, the organisational strategy, environment and capability didn’t quite align. While believing they were still focused on customers, they became dismissive of external views, preferring their own expertise. These changes were incremental, occurred across various parts of the organisation and weren’t recognised for what they were.
Michelle and I call this phenomenon corporate growing pains and we make the point that they are a natural part of corporate life. They are incremental and can be very difficult to identify and assess, which is why external assessment is a benefit. The fact is that all successful organisations go through them, repeatedly.
Toyota’s experience is an example of how the failure to identify corporate growing pains can eventually lead to much bigger problems, even the need for crisis management. It is also an example that the most successful companies are going to experience them, but if they are identified they can be dealt with. It would just be nice if this could happen without going through a crisis.
We established this consultancy to help successful organisations continue their success for the long term by helping them identify and deal with the passion bleeders and success barriers that develop within most organisations over time.
The example of Toyota shows us that we have identified a real experience – corporate growing pains – and that the service we offer can provide tremendous value.
Take part in the Weblaunch of The Leader’s Guide to Radical Management 6am AEDST Monday 25 October 2010.
I really need to read the book, so this comment may not cover the right bases. Geoff – is this about the acceleration problem?
My impression of that saga is coloured by the reporting of the NHTSA’s report, but I don’t know if that was the final word on the technical side.
(The NHTSA report put most of the problems down to driver error.)
Toyota’s problems, as I see it:
1) Lack of understanding of the modern press/consumer/media environment. (Being right is not enough, sometimes it’s not even useful.)
This is partly about not taking external views seriously, but its partly about the reluctance to spend money on the recall – not realising that the brand damage from the firestorm would be worse than the recall cost. It’s also about not taking external emotions seriously. Cars are sold as much on emotion as engineering, it’s a big failing to ignore the emotional response.
It’s also a growing pain, because Toyota mostly got where they are by engineering, not marketing/communications. Maybe now they realise they need real communicators on the inside to look after this, ad agencies are useful for selling, but don’t look after the brand.
2) There’s an internal problem. The “kaizen” approach of continuous self-improvement works very well for manufacturing real objects, but there’s a few big pitfalls in using it for software. Part of the reason Toyota took forever to work out if there were problems in the accelerator control software is that they’d been developing it “kaizen” style and the accumulation of little improvements made for a very complex tangle of code to unwind when looking for an unexpected problem…
Arguably of course, continuous self-improvement may be a dangerous strategy for reputation management too…
Indy, a couple of good points. Yes, this is about the “accelerator problem” though it was all a bit broader than that. The book focuses on the Toyota side of the issue and raises some of the same concerns that you do, though with a different approach.
I would add to both your analysis and that from the book, that Toyota didn’t understand an environment where members of Congress saw the opportunity, having jumped into bed to the tune of Billions of dollars with “US” manufacturers, to inflict some real pain on a major competitor.
Toyota considered that they were employees of tens of thousands of Americans and major contributors to the lifestyle and culture of the US, including changing the way a whole country thinks about cars and the environment. They are, of course, quite right, but that’s not going to get in the way of a few members of Congress and any media environment in which Rupert Murdoch is a major player.
This is another example of how their own internal perception had more importance and sway than the external environment, a sign of growing pains
Cheers, geoff.
Indy,
You suggest there were two big problems.
1) Lack of understanding of the modern press/consumer/media environment. (Being right is not enough, sometimes it’s not even useful.)
2) There’s an internal problem. The “kaizen” approach of continuous self-improvement works very well for manufacturing real objects, but there’s a few big pitfalls in using it for software.
The Toyota story is a complex one, with many threads.
I agree that bad handling of the press between August 2009 and February 2010 helped turn a serious problem into a crisis.
But the reality was that there was a serious real problem that had not been adequately resolved since 2004. So it wasn’t just a PR problem.
What makes this so strange is that Toyota had spent 50 years getting to the root causes of problems. So why not here? It seems that for a five year period they started to become like a traditional organization and focus on growth and cost cutting.
That, I believe, is the primary root cause of their problems in unintended acceleration. They departed from the very principles that had made them great.
Time will tell whether they have now returned to their roots that made them so successful.
As to the idea that kaizen is easier for manufacturing than software, I tend to think the opposite. Creating a car is a very lumpy all-or-nothing thing, whereas software is easily divisible into iterations with updates and improvements. So continuous improvement is in principle easier.
Overall, my take is that kaizen and Agile have been more successful in software than in manufacturing.
Thus In 2003, the foremost foreign expert on Toyota, Jeff Liker, wrote in his book, The Toyota Way, “What percent of companies outside of Toyota and their close knit group of suppliers get an A or even a B+ on lean [manufacturing]? I cannot say precisely but it is far less than 1 percent.” Less than 1 percent is a small number. My hunch is that it’s higher in software development, certainly not 100 percent, but higher than 1 percent. It would be interesting to do some comparative studies.
There is a lot more to this story, which I talk about in the chapter in the book about Toyota and continuous improvement.
Steve
Steve,
I can well believe that a switch of focus to a traditional growth and cost-cutting model would be at the root of Toyota’s problems, I suspect we are fellow travellers philosophically. I certainly defer to you knowledge of the situation inside the company and the wider context.
It would certainly be interesting to see some comparative studies on kaizen and Agile, but I have a couple of reservations:
1) I don’t think Agile and kaizen are actually the same thing – there are similarities, but the difference between what makes for a measurable defect in the physical vs software world has some quite deep implications.
2) For critical control systems, Agile has not gained wide acceptance and that’s not just because control system developers are “stick in the muds” (although many are) it’s because Agile is an approach built for nimble evolution over formal correctness. This is not to say Agile can’t work, but it needs a different mindset over how revisions are judged (which brings us back to defect measurement, perhaps.)