I recently came across Mark Graban‘s “Highlights from the Original 1984 NUMMI Team Member Handbook” series. Digging through the archives at Ephlin’s UAW office papers were archived at the Walter P. Reuther Library at Wayne State University in Detroit, Mark found some absolutely extraordinary gems, including this one.
Standing on the shoulders of giants, I reached out to the archivists at the library to see if I could get a copy of the full handbook. They cheerfully obliged, and rather quickly at that!
Grab the PDF and peruse for yourself. The first several pages are the most interesting, but even as you explore the rest of it pay attention to how human and reasonable it is. Mark provides an excellent commentary on several key sections, so I’ll try to avoid highlighting the same thoughts. I hope you’ll share your own findings and commentary in the comments below.
Here are some of the gems I’ve found:
Notice that the first objective is “To help [employees] develop to [their] full potential.” In fact, these objectives start with the individual employee, progress to the company, and then ultimately end with the customer receiving the “highest quality automobiles in the world.” This is a notable inversion from the usual objectives, which usually prioritize stakeholders and customers, then the company, then—if at all—the individual employee.
This is extraordinary in two ways. First, employees are given the expectation that they are going to have a greater autonomy and influence over how other aspects of the organization operate. I’ve heard the statistic that Toyota’s 300,000 global employees make a total of one million suggestions annually, 97% of which are implemented. Secondly, note that the employee handbook is characterized as helping the employee “do [their] job better,” a far cry from the usual purpose of this kind of handbook (protecting the company’s interest).
This sure sounds a lot like a gemba walk to me…
Product Owners: are you making the mistake of telling your team how to do something rather than just what you’d like done? Are you open to product ideas from all sources?
Managers: If an employee comes to you with a suggestion, are you willing to help them turn it into an experiment and examine the results together, or will you argue with them based only on your conjectures?
This is fundamental. Modern software development—particularly at large —corporations—is complex, not complicated. Therefore there is always uncertainty. There will always be things that we do not know. If we cannot create the safety for individuals and teams to acknowledge this, they may not come to learn.
This also reminds me of Mary Poppendieck’s comment in her talk, “The Tyranny of the Plan (transcript):”
Basic project management measurement is variance from plan. So say you vary from plan. What happens? Oh, you’ve got a performance failure, right? Maybe. There is another way to look at performance from schedule. Perhaps it’s not the person who’s trying to manage the schedules fault. Perhaps it’s the schedule’s fault instead. In fact, if the schedule is a hypothesis rolled up from a lot of detail, it’s the schedule’s fault, not the person’s fault and what we really should do is view it as a learning opportunity.
Guess what? We’ve learned something about our capability to schedule and we have to rethink how we’re going to schedule because this particular one wasn’t correct. We came up with a wrong hypothesis. What is it about our scheduling approach that gives us wrong hypotheses?
In this case, it is the manager that accepts the knee-jerk explanation that a human being is to blame, punishes them, and concludes their inquiry. They wholly miss the opportunity to learn.
This reminds me a little bit of the first line of the Agile Manifesto: “Individuals and interactions over processes and tools.” It also reminds me of my fellow coach Monica Yap reminding me to think of how to make things effective (total systemic, long-term efficiency) rather than merely efficient (local and short-term).
I truly believe that Toyota cared a great deal about each individual’s safety and the ramifications for the individual and their family. This is a far cry from GM’s culture at the same plant just a few years before: “You just don’t see the line stop. I saw a guy fall in the pit, and they didn’t stop the line.”
At first it doesn’t seem like software companies could have a problem with safety. After all, there are many physical hazards in a factory that don’t exist in an office environment.
However, we see safety violations all the time if we broaden the term to include any event that could harm the employee, compromise performance, and embarrass the company. Surely the recent allegations of sexual harassment at Uber point to a company that was unable to create safety for all of its employees.
A more prevalent example is muri, the waste of overburden. Yes, stress compromises performance. But it also harms employees and embarrasses the company.
I recall once politely asking a group of managers to exit a conference room our team had reserved for a team meeting and receiving a totally serious reply of “there are more of us than there are of you.” Our team was forced to find another room, utterly demoralized.
No wonder Modern Agile “makes safety a prerequisite.”
Thanks for reading my commentary. I hope you’ll check out the rest of the handbook and share your insights with us.
Thanks for linking to me. I’m glad you were able to get the whole handbook scanned. That’s good to know I can request documents remotely if there’s anything I want to follow up on. That scan is better (and more complete) than my iPhone photos.
Mark, glad you liked it! I believe that they normally they charge for the scans and use fees, so it was a really kind favor of them.
Nice article, Chris, and it was great to see a PDF of the handbook. It brings me back to 1984 – I was working then – a time when companies were not yet so infected with the shareholder value nonsense that took over most US industries shortly thereafter.
Mary, I’m so delighted to hear from you on my blog. I am glad you enjoyed seeing the handbook. I do not have your tenure so I can only imagine such a time. Perhaps the Certified B Corporation movement will do a little bit of good.
Thank you for being such a thought leader in the field. I have learned so much from you.
✦ NUMMI management made themselves accountable by sharing their philosophy and beliefs in a written document.
“We are breaking down the barriers that have traditionally separated employee and management. We are all members of a team. Your suggestions will be solicited and carefully considered. The terms and conditions of employment outlined in this handbook were created to support our Human Resources philosophy. They are designed to help you do your job better.”
✦ NUMMI kept team sizes small
“Each member will be assigned to a team consisting of approximately 5-10 team members with a Team Leader.”
✦ NUMMI promoted T-shaped workers
“…you are expected to be proficient in your own assignment and all other assignments within the group and department and also help other team members. It is important to you and NUMMI that you become as skilled in as many assignments as possible.”
I have more insights but my time box has expired.
Thank you for sharing the handbook, Chris!
Thank you, Steve! I like what you pulled from the details, particularly with respect to team size and T-shaped workers. Nice to hear from you. 🙂
You should try getting your hands on Tesla’s approach next 😉
In all seriousness though, I’d love to see Elon’s strategy.
Replace people in factories with robots and pay a universal basic income, spurring the first World Renaissance? 🙂