Can we learn anything from Toyota suppliers in Japan?
June 14, 2023
Roberto Priolo is editor at the Lean Global Network and Planet Lean
Share this article:
In a world of digital apps and generative AI, is there anything to be learned from Toyota's supplier network in Japan? This is the question we (the authors) explored when we were fortunate enough to visit parts factories in the Nagoya region with senseis and Toyota veterans Mr. Amezawa and Mr. Yoshino. Mr. Amezawa has 50 years of Toyota experience and is a former vice president of both the Kyushu Lexus plant and Toyota's Kentucky plant. Yoshino has worked closely on the Toyota Hoshin Kanri program from its inception, on structuring training at the NUMMI California plant and is co-author of Learning to Lead, Leading to Learn with Katie Anderson. As we toured the plants and marveled at the precision of the jidoka and just-in-time systems we saw, they tried to explain to us the underlying human system that made it all possible.
Does any of this apply to the ecosystem of a startup, where the flat organizational structure is adored and digital native developers seek flexible work? Visit after visit, the sensei's message was both simple and complex: "Make the work of the gemba people easier." How do you constantly make the lives of the people who actually create value easier? And what kind of management do you need to do that, to focus on quality and delivery to customers, to improve processes and, even deeper, to create the right conditions so that existing processes work flawlessly? When someone asked Mr. Amezawa what the best Toyota factory was, he immediately joked that it was "Lexus Kyushu, of course" - his former factory - and then hesitated. He thought about it a little longer and told us it was the factory where the gemba people had the best attitude, both in terms of taking responsibility for the work and their team and in terms of self-development in terms of technical skills.
This got us thinking. If you take the perspective of the "gemba people," of an operator or even a code developer, what would you expect your management to feel they are responsible for your own delivery and development? There is, of course, no definitive answer to such a broad question, but by piecing together the sensei's conversations and what we saw in the factory, we tried to formulate hypotheses that we will now share:
Clear teams and chain of command.
Clear work and reasonable requirements.
Hierarchy that shares intentions rather than instructions.
Change preparation and regular learning opportunities.
Assistance with personal problems and conflict resolution.
Fair recognition of efforts and support for career development.
In the factories we visited, it was very clear that each "gemba person" was part of a defined team of five to 10 people, with a defined team leader (often wearing a different colored cap) who reported to a group leader, then assistant manager and area manager. Within the jidoka perspective, the chain of command is as much an auxiliary chain as it is a conduit of instructions, and the human structure of production in these factories helps to make clear who comes to the rescue when an operator identifies a problem, how it is solved (often with immediate support and then training), and how follow-up to the problem-solving is organized to check that the problem does not recur. Notable is the clarity of the team/team leader structure and the gemba support role of the team leader (intervening within a minute).
The "what" of the work is also very clear. Tasks are visualized and both quality criteria and delivery goals are visually specified and regularly monitored by group leaders. Various boards show how many parts are to be produced within the shift (and how effective the shift is in terms of real-time % realized versus plan) and what the quality status is at any given time. This visualization ensures that the demands of the hierarchy remain reasonable: if the team falls behind, it is management's responsibility to create the right conditions to get it back within target (or adjust the target). This happens especially with a new product or a change in branch time. Engineering implements the necessary change and then the gemba hierarchy supports kaizen work to make this change workable for gemba people through relentless kaizen until the new work is easy again. Difficulties in work are not given to team members to solve in the typical "I expect results, I don't care how" way of Western management. In this system, individual difficulties are the responsibility of management.
Both Mr. Amezawa and Mr. Yoshino were adamant that if you give someone an instruction, you take away both their responsibility and their ability to learn. In explaining Toyota's past failures, they said the company had learned the hard way that if you force people to do things your way, they will either resist or mindlessly obey - and to no avail. The idea is to make it easy for people to engage and learn by explaining to them the purpose - the why, not the how. Then you clarify with them the current situation and visualize the gap to reach the goal. Finally, you help them find their own route, figure out their own way to get there and support them in doing so. The explicit goal of management is to encourage gembas to think for themselves and voluntarily participate in improvement activities to learn more about their processes. For Yoshino, the two most important roles of managers are first to create an environment where people can follow the business strategy and second, to help people grow continuously.
One of us had visited several of these factories 10 years ago and then again. It was striking to see how the general structure of the factories had changed little and yet everything had changed in terms of parts, processes and even technologies. In the hypercompetitive context of the auto industry, change is permanent, but to make things easier for the gemba people, management strives for stability. When we examined this contradiction with the sensei, we saw kaizen in a different light. Engineering changes incessantly, driven largely by customer demand for new products, new processes or new technologies - that's a given. However, the manager's main job is to work with the people at the gemba to adopt, stabilize and improve these changes through a process of kaizen. Each change creates difficulties for everyone. The role of the workplace hierarchy is to bring conditions back to the point where work is easy by encouraging and implementing the ideas of the gemba people - kaizen. In practice, many of the workplace techniques we saw were based on "henkaten": preparing for change, training and improving.
Another less visible part of the system is the constant focus on group cohesion. From the team leader, management is expected to help people with their personal problems and deal with conflicts within the team and between individuals to maintain group spirit and cohesion. This requires a difficult balance between allowing special cases for people with specific problems and keeping the way everyone is treated fair. Managers learn to listen to and act on employee concerns. In this sense, they are not supposed to be someone whom employees look up to, but facilitators who make them feel that their voices are being heard and that their concerns are being addressed by focusing on thinking more carefully about the problem and reaching a compromise between what the company can do and what the person themselves can do to resolve it.
The explicit goal is a culture of frank and heart-to-heart communication. As one can imagine, this is easier said than done. A surprising part of creating such a culture is encouraging employees to express their preferences for their next career move. In one company, for example, we were shown a personal hoshin kanri format that required everyone to write on one sheet of paper:
Their understanding of the company's vision.
How they chose to personally contribute to that vision.
What they were already doing in their work to do that.
What they wanted to do in the future to keep doing that.
What changes this would entail.
What training and development they needed to bring these changes to fruition.
The company then tried to accommodate these requests as best it could. It is obviously impossible to assess the degree to which management is flexible and open to such requests, but the intention was clearly to achieve a compromise between available positions and employee requests, in many cases creating ad hoc positions when appropriate. This is very different from the usual Western management approach where people are "offered" a position based on an assessment of their capabilities by management and regardless of their own preferences or development potential.
As we reflected on these complex messages, we realized we were looking at a typical Toyota model "but": a series of contradictions that one tries to balance as best one can to create the right conditions for "gemba people.
Clear hierarchy but lenient requirements
Strong leadership on purpose and development but little authority
Frequent changes but stabilization with kaizen
Individual responsibility but cooperation and teamwork
Personal issues facilitate but group cohesion
The question remained: what would all this mean for a software company with millennial managers? More precisely, what kind of person would we need to learn to recognize and foster to create a culture obsessed with balancing the needs of quality and delivery for customers and a drive to make developers' lives easier? Our own self-assessment compared to what we saw in Japan meant that our management system often led to unreasonable demands and arbitrary instructions on the one hand and just-for-show management rituals where nothing was resolved on the other. Managers are unable to strike the right balance between being micromanagers and letting people struggle on their own. This often leads to situations where they either tend to microplan and micro-instruct, often without explaining why and without allowing the team to contribute, or lose their footing and are unable to jump into the gemba problem to analyze it from a systems thinking perspective. In either case, success is difficult and costs both managers and gemba people a lot of energy.
As we delved more into typical startup projects, we often saw cases where:
The requirements for the project were simply unreasonable: there was no known way to make the request successful in the short term, and to do so required in-depth problem solving. Yet the manager, lacking technical understanding of the problem, often gave the team instructions that rarely helped and sometimes made things worse.
The management ritual set up to deal with these situations proved unconvincing at best, with lengthy discussions about diversionary tactics and other defensive routines that bypassed the real problem and avoided authentic conversations about how to find a path to success and make life easier for the development team.
What we normally expect our managers to do is to master it:
Technical skills - mastery of basic technical skills and mental models specific to their team's work.
Clarity and demandingness - the ability to assess progress and recall priorities, while raising the bar when someone is close to achieving a goal.
Caring - adapt to the individual's level and motivational factors, improve working conditions (tools, standards, training and staffing) to enable the team to make autonomous decisions, as well as provide encouragement and recognition.
We now think we need to look more specifically for two dimensions in the people we consider for a management position: the person's own commitment to both technical and leadership competence and their sense of responsibility for both results and team cohesion.
Commitment to competence is key to being proactive about one's own learning curves and continuing to visualize the gap between where they should be and where they are - what do you want to achieve? What are you already doing? What could you do more of? What would be the first thing you would have to learn to do to do that? On the second dimension, commitment to accountability leads to ownership and a focus on stabilizing both people and results. It is a balancing act where we "don't compromise" between team satisfaction and results. Too much focus on results and too little focus on team cohesion creates a toxic environment when sensemaking (collective goals) dominates meaning-making (what's in it for me) just as, conversely, too much focus on team feelings and too little on results leads to equally bad work environments where too much meaning-making overshadows sensemaking.
Looking back on the study tour, we generally find it striking that to pursue a clear goal, such as making work easier for gemba people, leaders look for a balance between opposing forces rather than, as we tend to do, choosing a process and sticking to it in all cases. They keep the goal in mind and then look at the balancing parts along the way - which also explains the focus on deeper thinking. Because they are looking for a difficult balance, they will ask themselves the same questions over and over again instead of, as we tend to do, reacting to a situation and moving on. Indeed, ask "why?" five times.
Any generative AI can give you the consensus on the most important dimensions to look at in a given situation. What it cannot teach you or do for you is weigh conflicting dimensions against each other to seek better outcomes. You can only learn this by trial and error in the physical world of people and machines, of customers and processes, of situations and systems. Constantly seeking this balance through change management and kaizen is what the Toyota supply network is remarkably good at, and every visit to Japan reminds us of the impact of this balancing skill on overall performance. ChatGPT offers not real hands-on knowledge, but the feeling of knowledge - the false satisfaction of our worries bump without the real discipline of learning. As the sensei would say over and over again, "Gemba is your best teacher."