FEATURE – This powerful article explains why we should place learning at the heart of our lean strategy to build better products – something Toyota has always done – and how management fits in the picture.

Words: Daniel T Jones, Chairman, Lean Enterprise Academy

For several years I have been convinced that traditional consulting and lean are incompatible. Many organizations have learned this the hard way – my warning has not always gone down well in the lean community – after the “programs” consultants initiated for them (often at a very high cost) failed to bear fruit that lasts and the limits of an approach that sees lean as nothing more than a cost reduction or a process improvement methodology became evident.

At its core, lean is a customer-focused strategy to develop better products, which are created and delivered by much better product development and production processes.

We now know that these processes are grown out of the cumulative capabilities of front-line teams, in engineering and production, supported and nurtured by hands-on management. They are not designed by experts for compliance by those who work them, but they evolve out of the learning of the teams and those leading them. The biggest lesson for us as a movement is that what makes these processes exist and deliver more with less is learning, which lies (or so it should) at the heart of a lean strategy.

For too long, most of the lean movement has focused on the production and delivery systems – which are of course important – spending less time on the significant contribution learning in production processes can make to developing next-generation products. In doing so I believe we are missing a big opportunity. Improving existing production processes can only go so far, but the deeper learning about current constraints is key to making bigger leaps in designing products our customers want and, in doing so, ensuring the success of our enterprise.

If we look at Toyota’s original strategy, the importance of product development could not be clearer. From the very beginning, Toyota was determined to develop their own technology, rather than license it from other car manufacturers, and to do so without relying on bank financing. The challenge Toyota faced was to come up with a better system for developing new cars that used fewer resources and took less time than the competition. To them, the end result was to continuously improve their products and technology at a faster rate than the competition, first to catch up and then to pull ahead of the competitors (and pull ahead they did!). Essentially, Toyota wanted to develop its own knowledge faster than anyone else.

The second challenge Toyota faced was of course to develop a production and delivery system that did not rely on expensive assets or economies of scale, but could make a growing mix of models on the same line at lower volumes, with less human effort and without any batching and buffers between steps. We are probably all familiar with this concept, but are perhaps a bit rusty on the TPS insights that frame the learning to build a lean production process. (For this I suggest you go back and reread Kaizen Express).

Learning is the key concept here. In recent years, we have started to define lean thinking as a “system for learning” and – no surprise here – Toyota was already way ahead of us: from the outset, learning was built into the purpose of Toyota’s strategy, which has been incredibly successful in driving the organization forward over the decades.

HOW TOYOTA DOES IT

It is worth spending some time looking into the capabilities behind the success of Toyota's superior and learning-based product development system, so here is my, possibly incomplete, list:

1. Deep experience in clearly defining the work to be done to make the next product generation a success, from understanding customer needs to deciding what needs to change and what stays the same, plus the ability to articulate the necessary resources and to mobilize the right team to accomplish them. These skills are learnt by assuming more and more responsibility over successive projects, ending up with the Chief Engineer carrying full responsibility for the success of the product with only a small staff reporting directly to him or her.
2. A clear understanding of the fact that spending more time up front exploring alternative technical solutions to development issues, using set-based concurrent engineering, not only clarifies and speeds up the task of turning these into production-ready designs but also eliminates much of the rework and the ramp-up issues after launch. In other words, not jumping to quick solutions and then trying to make them fit the facts.
3. Cumulative experience that making the work visible and reviewing progress on a daily and weekly basis allows the team to respond to and learn from deviations to the plan (as in production work). This allows the team to focus their discussions on finding solutions to these deviations and prevents the cumulative slippage so common in traditional waterfall development programs.
4. A deep commitment to creating reusable knowledge that can become the standard for subsequent projects and can be captured in many ways, such as trade-off curves, check sheets and A3 reports. Far from constraining creativity, this creates a common problem solving language, avoids reinventing the wheel and frees up time for creating new knowledge.
5. An effort to challenge and deepen the skills of every team member along three dimensions – knowledge of customer needs and the product (maybe from tracking the root-cause of a customer complaint), deeper knowledge of their technical specialty (by finding a new solution to a technical problem) and knowledge of the end-to-end process of working together as a team. This includes working with and learning from production engineering, operations and suppliers as well as sales and marketing.

[For more details on this, you can read Al Ward and Durward Sobek’s Lean Product and Process Development and James Morgan and Jeff Liker’s The Toyota Product Development System: Integrating People, Process, and Technology]

The model I have just described could be summarized in one idea: solving the right technical problems in the right way at the right time, every time. This, in turn, points to three observations:

1. What are we doing to capture and feed the learning from continuous improvement in production or service delivery into designing products and services for the future?
2. The cumulative creation of reusable knowledge in a regular cadence of new products builds the basis for making big leaps work, Toyota's hybrid technology being a case in point.
3. The software development movement still has a lot to learn from the very rich experience of Toyota's development system. Agile, Scrum, XP, DevOps, and so on, all address different pieces of the problem, without building a true learning system.

WHAT ABOUT MANAGEMENT?

This article has stressed the importance of building learning into our strategy to develop better products for our customers. But there is another important aspect of learning: if embraced, it fundamentally changes the way management manages. By building learning into the functions of management we are adding a powerful layer to the idea that problem solving is the key to developing a learning organization.

I actually think that problem solving is only part of the story. As Michael Ballé has pointed out many times, if you are solving the wrong problems you are wasting your time. The key challenge for management is finding the right problems to solve, which can only be done by going to the front line to understand how they struggle with today’s challenges. It’s all about problem finding and helping managers to learn how to unearth the underlying issues they are currently not seeing.

I have recently experienced this as I was walking with senior managers on the shop floor of a car factory. Their initial problem statement – before going to the gemba – was that their costs were too high and they had to reduce them to stay competitive. After going to the gemba, hearing the Toyota story and talking to people at the front line, however, they had an epiphany. When I asked the senior execs again what their biggest problem was, they told me, “Quite clearly, it is us.” People at the front line had been asked to work with broken systems commissioned by management. Does this sound familiar?

This sort of realization can be very profound for senior managers. It has the power to start a different journey into finding and framing the next steps to tackle the real challenges the company is facing. Critically, it creates a link between problem solving on the shop floor, designing better products and making learning the core of the organization's strategy.

_{THE AUTHOR}