“If you want one year of prosperity grow grain.
If you want ten years of prosperity grow trees.
If you want one hundred years of prosperity grow your people”
— Confucius (~ 500 BC)
I never hired consultants during my journey to learn the basics of JIT/TPS/Lean. I didn’t need to. In the late 1980’s and early 1990’s there was a small, but very active community of JIT/TPS learners scattered around the east coast of the U.S. We found each other through the very active participation within organizations such as the Association of Manufacturing Excellence (AME) and Productivity, Inc. We visited each other’s facilities and we attended conferences where we shared what we had learned. We learned by doing. Besides, there weren’t very many competent consultants around at that time – they were in the process of learning too.
But I did hire a consultant to help me understand the art of dealing with the new concepts of “teams” and “total employee involvement” (TEI) that came along with JIT/TPS. (The term “Respect for People” from “The Toyota Way” did not show up until after the turn of the century). Most of us within that active community of JIT/TPS learners had a manufacturing/technical background and were able, with some difficulty, to grasp the concepts of “flow”, “short lead times”, “manufacturing cells”, “pull”, etc. While there is some degree of art required to master these concepts, the degree of art required to master the people skills involved in “teams” and TEI was beyond the instinctive capabilities of many of us. Us engineering types didn’t do a lot of “art” in college.
Fortunately, with the help of others, I was able to find a consulting firm out of Boston that had been to Japan and had the requisite skills to walk us through this potential quagmire. While I had a vision as to the importance of TEI based on previous experiences in South Korea, I really did not know where to start – and I knew you didn’t get many second chances if you screwed this one up. Thus, the consultant.
What I learned about “teams” and TEI during this initial period stuck with me through the rest of my career. And I kept learning through doing. I have been able to begin and sustain JIT/TPS/Lean transformations at several different companies. And without this ability to “take it to the gemba” and involve everyone, this would never have been possible. Fortunately, I held the position of Plant Manager or Vice President in all of these instances, which made these things much easier to initiate.
The results were fairly consistent over this time period, regardless of the geographical location or local culture (which was quite varied).
- 50 – 300% improvement in net operating margins
- 30 – 50% improvement in shop floor productivity
- 90% reduction in total lead time
- 90% reduction in WIP
- 25 – 50% reduction in finished goods inventories
- 60% reduction in shop floor and administrative paperwork
- 40% reduction in floor space requirements
- 50 – 70% reduction in new product development lead time
But none of this would have been possible without the power of “teams” leading the way each and every time. In fact, one of the “slogans” I learned in my initial training period has proven to be true each and every time:
Power of the Team: None Of Us Knows As Much As All Of Us
But is there just one right way to do “teams”? Should all teams look the same? Are there one set of rules to follow when creating/forming teams? Is there such thing as a “team tool box”? Is there a “perfect team member” type that we can screen for? The answer to all of these questions is a resounding “NO” – sort of.
While there are some general guidelines that we can follow when dealing with teams, we must always remember that we are dealing with human beings here. There are no comparable “laws of physics” that apply to human behavior. While psychiatry, sociology, political science and even economics may sometimes be referred to as science, these fields are not true science. Human behavior is not predictable in an absolute sense; therefore, the study of human behavior cannot be called “science”.
But human behavior can lead us to discover things that we never imagined. Human beings, working together, have created a better life for themselves throughout the timeline of history, although with many “downs” as well as the “ups”. But has anyone ever predicted that history ahead of time? – absolutely not! Expect more of the same when working with “teams”.
But I would like to pause for a moment before jumping into the world of teams en masse. We sometimes get so enthralled with the concept of “teams” that we forget that not everything is best resolved via the use of teams. Problem solving and creative innovation by individuals, acting alone, is still the most valuable product arising from our human resource base. Don’t ever forget this. We must always prize, encourage and reward individual efforts that keep our organizations humming on a day-to-day, week-to-week and month-to-month basis. This is the glue that holds everything together.
So, when should we use teams rather than rely on individuals? Here is a simple rule of thumb.
Rely on individuals if the change entails:
- A single process or process step
- A technical solution
- A situation where the facts are clear or can be ascertained through individual effort
- Clear ownership
Rely on a team if the change entails:
- Complex or cross-functional processes
- More than just a technical solution
- Facts are not clear and opinions abound
- No clear ownership
Now I must admit that the boundaries between these two scenarios can be very fuzzy at times. And an individual effort may evolve into a situation where a team may need to take over. And a team effort can evolve to a point where an individual can sustain the team results. Just recognize that both approaches have their own advantages and disadvantages and there can be a very large overlap between the two.
And always remember that a team is but a group of individuals working together – but often with exponential rather than additive results.
Fortunately, my eyes were opened up to this truism very early in my journey working with teams. One of our key products involved sterilization in a medical environment. Needless to say, this product must perform perfectly each and every time. So, of course, we needed to document this product/process’s efficacy throughout the manufacturing cycle. Over time, the paperwork that followed the product grew to ridiculous lengths. The final documentation package included an amazing 196 pieces of paper. We knew this was ridiculous and decided to whittle the package down to a more reasonable size.
Our first attempt was to assign this project to one of our key managers. He and his group diligently went through all the pieces of paper and came back with a reduced document package of 176 pieces of paper, a total reduction of 20 pieces of paper. He admitted that this was not a very significant reduction but was very cautious since much of the paperwork’s original intent was unclear and the product was too important to take on any unwarranted risk.
Since we were just getting started on our “team” journey, we decided to test the waters with this documentation challenge. We formed a Task Team of four very experienced operators and let them take a shot at trying to further reduce the paperwork/documentation package. (I will cover “Task Teams” a little later). Within a relatively short time period (I don’t remember exactly) they returned with a recommendation to reduce the document package to 12 pieces of paper. We were shocked!
The team explained that they had been watching the paperwork load increase gradually, but dramatically, over the years. Every time we received a customer complaint, paperwork was added. Every time we had an FDA inspection, paperwork was added. Every time we had a quality problem, paperwork was added. Every time we changed a part supplier or a part design, paperwork was added. But old paperwork was never questioned or eliminated. And no one ever asked them what they thought – they just did what they were told. (They did not tell us that we were incompetent, but I’m sure that it crossed their minds). “Waste” anyone?
They then walked us through the gemba (although I wouldn’t know that exact word for for a few more years) and showed us what and why they did what they did. Their recommendation was accepted and implemented immediately. No key information was lost and the document package was actually useful again. The old document package had always been religiously filed away “just-in-case”, but never really used by anyone.
This “team” thing was starting to catch on!! And it became a permanent fixture.
Next: Team Structures