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.