How Toyota Turns Workers Into Problem

Solvers
Published: November 26, 2001
Author: Sarah Jane Johnston

Editor's Note: When HBS professor Steven Spear recently released an abstract on
problem solving at Toyota, HBS Working Knowledge staffer Sarah Jane Johnston e-
mailed off some questions. Spear not only answered the questions, but also asked
some of his own—and answered those as well.

Sarah Jane Johnston: Why study Toyota? With all the books and articles on Toyota,
lean manufacturing, just-in-time, kanban systems, quality systems, etc. that came out
in the 1980s and 90s, hasn't the topic been exhausted?

Steven Spear: Well, this has been a much-researched area. When Kent Bowen and I
first did a literature search, we found nearly 3,000 articles and books had been
published on some of the topics you just mentioned.

However, there was an apparent discrepancy. There had been this wide, long-standing
recognition of Toyota as the premier automobile manufacturer in terms of the
unmatched combination of high quality, low cost, short lead-time and flexible
production. And Toyota's operating system—the Toyota Production System—had
been widely credited for Toyota's sustained leadership in manufacturing performance.
Furthermore, Toyota had been remarkably open in letting outsiders study its
operations. The American Big Three and many other auto companies had done major
benchmarking studies, and they and other companies had tried to implement their own
forms of the Toyota Production System. There is the Ford Production System, the
Chrysler Operating System, and General Motors went so far as to establish a joint
venture with Toyota called NUMMI, approximately fifteen years ago.

However, despite Toyota's openness and the genuinely honest efforts by other
companies over many years to emulate Toyota, no one had yet matched Toyota in
terms of having simultaneously high-quality, low-cost, short lead-time, flexible
production over time and broadly based across the system.

It was from observations such as these that Kent and I started to form the impression
that despite all the attention that had already been paid to Toyota, something critical
was being missed. Therefore, we approached people at Toyota to ask what they did
that others might have missed.
Q: What did they say?

A: To paraphrase one of our contacts, he said, "It's not that we don't want to tell you
what TPS is, it's that we can't. We don't have adequate words for it. But, we can show
you what TPS is."

Over about a four-year period, they showed us how work was actually done in
practice in dozens of plants. Kent and I went to Toyota plants and those of suppliers
here in the U.S. and in Japan and directly watched literally hundreds of people in a
wide variety of roles, functional specialties, and hierarchical levels. I personally was
in the field for at least 180 working days during that time and even spent one week at
a non-Toyota plant doing assembly work and spent another five months as part of a
Toyota team that was trying to teach TPS at a first-tier supplier in Kentucky.

Q: What did you discover?

A: We concluded that Toyota has come up with a powerful, broadly applicable

answer to a fundamental managerial problem. The products we consume and the
services we use are typically not the result of a single person's effort. Rather, they
come to us through the collective effort of many people each doing a small part of
the larger whole. To a certain extent, this is because of the advantages of
specialization that Adam Smith identified in pin manufacturing as long ago as 1776 in
The Wealth of Nations. However, it goes beyond the economies of scale that accrue to
the specialist, such as skill and equipment focus, setup minimization, etc.

The products and services characteristic of our modern economy are far too complex
for any one person to understand how they work. It is cognitively overwhelming.
Therefore, organizations must have some mechanism for decomposing the whole
system into sub-system and component parts, each "cognitively" small or simple
enough for individual people to do meaningful work. However, decomposing the
complex whole into simpler parts is only part of the challenge. The decomposition
must occur in concert with complimentary mechanisms that reintegrate the parts into a
meaningful, harmonious whole.

This common yet nevertheless challenging problem is obviously evident when we talk
about the design of complex technical devices. Automobiles have tens of thousands of
mechanical and electronic parts. Software has millions and millions of lines of code.
Each system can require scores if not hundreds of person-work-years to be designed.
No one person can be responsible for the design of a whole system. No one is either
smart enough or long-lived enough to do the design work single handedly.

Furthermore, we observe that technical systems are tested repeatedly in prototype

forms before being released. Why? Because designers know that no matter how good
their initial efforts, they will miss the mark on the first try. There will be something
about the design of the overall system structure or architecture, the interfaces that
connect components, or the individual components themselves that need redesign. In
other words, to some extent the first try will be wrong, and the organization designing
a complex system needs to design, test, and improve the system in a way that allows
iterative congruence to an acceptable outcome.
The same set of conditions that affect groups of people engaged in collaborative
product design affect groups of people engaged in the collaborative production
and delivery of goods and services. As with complex technical systems, there would
be cognitive overload for one person to design, test-in-use, and improve the work
systems of factories, hotels, hospitals, or agencies as reflected in (a) the structure of
who gets what good, service, or information from whom, (b) the coordinative
connections among people so that they can express reliably what they need to do their
work and learn what others need from them, and (c) the individual work activities that
create intermediate products, services, and information. In essence then, the people
who work in an organization that produces something are simultaneously engaged in
collaborative production and delivery and are also engaged in a collaborative
process of self-reflective design, "prototype testing," and improvement of their
own work systems amidst changes in market needs, products, technical
processes, and so forth.

It is our conclusion that Toyota has developed a set of principles, Rules-in-Use we've
called them, that allow organizations to engage in this (self-reflective) a) design, b)
testing, and c) improvement so that (nearly) everyone can contribute at or near his or
her potential, and when the parts come together the whole is much, much greater than
the sum of the parts.

Q: What are these rules?

A:We've seen that consistently—across functional roles, products, processes

(assembly, equipment maintenance and repair, materials logistics, training, system
redesign, administration, etc.), and hierarchical levels (from shop floor to plant
manager and above) that in TPS managed organizations a) the design of nearly all
work activities, b) connections among people, and c) pathways of connected activities
over which products, services, and information take form are specified-in-their-
design, tested-with-their-every-use, and improved close in time, place, and person to
the occurrence of every problem

Q: That sounds pretty rigorous.

A: It is, but consider what the Toyota people are attempting to accomplish. They are
saying before you (or you all) do work, make clear what you expect to happen (by
specifying the design), each time you do work, see that what you expected has
actually occurred (by testing with each use), and when there is a difference between
what had actually happened and what was predicted, solve problems while the
information is still fresh

Q: That reminds me of what my high school lab science teacher required.

A: Exactly! This is a system designed for broad based, frequent, rapid, low-cost
learning. The "Rules" imply a belief that we may not get the right solution (to work
system design) on the first try, but that if we design everything we do as a bona fide
experiment, we can more rapidly converge, iteratively, and at lower cost, on the right
answer, and, in the process, learn a heck of lot more about the system we are
operating.
Q: You say in your article that the Toyota system involves a rigorous and
methodical problem-solving approach that is made part of everyone's work and
is done under the guidance of a teacher. How difficult would it be for companies to
develop their own program based on the Toyota model?

A: Your question cuts right to a critical issue. We discussed earlier the basic problem
that for complex systems, responsibility for design, testing, and improvement must
be distributed broadly. We've observed that Toyota, its best suppliers, and other
companies that have learned well from Toyota can confidently distribute a
tremendous amount of responsibility to the people who actually do the work,
from the most senior, experienced member of the organization to the most junior. This
is accomplished because of the tremendous emphasis on teaching everyone how to
be a skillful problem solver.

Q: How do they do this?

A: They do this by teaching people to solve problems by solving problems. For

instance, in our paper we describe a team at a Toyota supplier, Aisin. The team
members, when they were first hired, were inexperienced with at best an average
high school education. In the first phase of their employment, the hurdle was merely
learning how to do the routine work for which they were responsible . Soon thereafter
though, they learned how to immediately identify problems that occurred as they did
their work . Then they learned how to do sophisticated root-cause analysis to find the
underlying conditions that created the symptoms that they had experienced. Then they
regularly practiced developing counter-measures—changes in work, tool, product, or
process design—that would remove the underlying root causes.

Q: Sounds impressive.

A: Yes, but frustrating. They complained that when they started, they were "blissful
in their ignorance." But after this sustained development, they could now see
problems, root down to their probable cause, design solutions, but the team members
couldn't actually implement these solutions. Therefore, as a final round, the team
members received training in various technical crafts—one became a licensed
electrician, another a machinist, another learned some carpentry skills.

Q: Was this unique?

A: Absolutely not. We saw the similar approach repeated elsewhere. At Taiheiyo,

another supplier, team members made sophisticated improvements in robotic welding
equipment that reduced cost, increased quality, and won recognition with an award
from the Ministry of Environment. At NHK (Nippon Spring) another team conducted
a series of experiments that increased quality, productivity, and efficiency in a seat
production line.

Q: What is the role of the manager in this process?

A: Your question about the role of the manager gets right to the heart of the difficulty
of managing this way. For many people, it requires a profound shift in mind-set in
terms of how the manager envisions his or her role. For the team at Aisin to become
so skilled as problem solvers, they had to be led through their training by a capable
team leader and group leader. The team leader and group leader were capable of
teaching these skills in a directed, learn-by-doing fashion, because they too were
consistently trained in a similar fashion by their immediate senior. We found that in
the best TPS-managed plants, there was a pathway of learning and teaching that
cascaded from the most senior levels to the most junior. In effect, the needs of
people directly touching the work determined the assistance, problem solving,
and training activities of those more senior. This is a sharp contrast, in fact a
near inversion, in terms of who works for whom when compared with the more
traditional, centralized command and control system characterized by a
downward diffusion of work orders and an upward reporting of work status.

Q: And if you are hiring a manager to help run this system, what are the attributes of
the ideal candidate?

A: We observed that the best managers in these TPS managed organizations, and the
managers in organizations that seem to adopt the Rules-in-Use approach most rapidly
are humble but also self-confident enough to be great learners and terrific
teachers. Furthermore, they are willing to subscribe to a consistent set of values.

Q: How do you mean?

A: Again, it is what is implied in the guideline of specifying every design, testing

with every use, and improving close in time, place, and person to the occurrence of
every problem. If we do this consistently, we are saying through our action that when
people come to work, A) they are entitled to expect that they will succeed in doing
something of value for another person. B) If they don't succeed, they are entitled to
know immediately that they have not. And C) when they have not succeeded, they
have the right to expect that they will be involved in creating a solution that makes
success more likely on the next try. People who cannot subscribe to these ideas—
neither in their words nor in their actions—are not likely to manage effectively in this
system.

Q: That sounds somewhat high-minded and esoteric.

A: I agree with you that it strikes the ear as sounding high principled but perhaps not
practical. However, I'm fundamentally an empiricist, so I have to go back to what we
have observed. In organizations in which managers really live by these Rules, either
in the Toyota system or at sites that have successfully transformed themselves, there
is a palpable, positive difference in the attitude of people that is coupled with
exceptional performance along critical business measures such as quality, cost, safety,
and cycle time.