Chapter 6. People

Lean is a management system that creates engaged, thinking people at every level of the organization and most particularly at the front line. If you implement all of the lean principles save one—respect for people—you will reap only a shadow of the potential advantages that lean can bring. If you implement only one principle—respect for people—you will position the people in your organization to discover and implement the remaining lean principles.

This was a “bet the company” deal, an incredibly aggressive deadline with fierce penalties for not meeting it, coupled with a once-in-a-decade opportunity to define the next generation aircraft. Alan Mulally was charged with making it happen, and he responded by creating an entirely new management system for the Boeing 777 program. There were those who argued that this was not the time for a new management system—the old one had worked well for years. But root cause analysis of every problem that delayed the schedule of previous programs led to only one conclusion: Delays were caused because people were not working together, not looking for problems early enough, not paying attention when a problem arose, not communicating with each other promptly or effectively. So Mulally focused his energies on Working Together—an enormously successful example of organizational teamwork that has been largely credited with the extraordinary success of the Boeing 777 program. He created more than 200 design/build teams with members from design, manufacturing, suppliers, and customer airlines—everyone from pilots to baggage handlers. These teams captured the insight of those who would use the plane while it was being designed. For example, one team discovered that the fuel port on the wing was so high that no United fuel truck could reach it, something that would probably not have been caught until delivery under the former approach to development.²

Mulally urged everyone to “share early and share often,” and he insisted on no secrets. Every problem was to be raised with and discussed by the team until a solution emerged. Suppliers worked on the basis of trust, and customers were given an unprecedented insight into the development process and status, as well as a large voice in trade-off decisions.

Mulally preached a “test early and fail fast” philosophy. Testing was moved as early in the development process as possible at all levels. For the first time the entire plane was designed using a 3-D modeling system. 3-D modeling provided a sort of unit test for each part, to be sure it fit and did not interfere with other parts. This resolved a problem that had plagued the early manufacturing stage of all previous models.

Testing was aggressive at every stage of integration. The new Pratt & Whitney engine was considered so well-tested that flight tests could be bypassed. But the collective wisdom of the engineers was biased toward testing it anyway, so at considerable expense, one of the new engines was mounted to a 747 and tested in real flight. The engine backfired badly, and a critical part had to be redesigned. Mulally’s reaction was: “Isn’t that great! We found the problem early.”

We know his reaction because Boeing allowed the Public Broadcasting System (PBS) to film the entire five-year development effort without exercising editorial control. The resulting five hour, publicly available documentary³ brings home how Working Together solicited and quickly acted on the ideas of everyone—a wing sealer on the production line could get a suggestion implemented in an hour instead of weeks. It showed how a small company in Australia manufacturing the rudder was handed one impossible change after another by Boeing, but working on the basis of trust, they figured out how to deliver the rudder on time.

Boeing had to work creatively with the Federal Aviation Administration (FAA) to obtain long-range flight certification before delivery of the plane to United, because twin engine planes were supposed to be tried in actual use for a couple of years before being allowed to fly more than an hour from an airport. Boeing proposed a set of tests so rigorous that pilots and regulators alike were intrigued: Could a brand new plane really pass such a rigorous test regime? The “test early and fail fast” strategy worked. The new plane passed the extensive testing with ease, and was the first twin engine plane to receive “out-of-the-box” long-range certification.

The 777 was Boeing’s first fly-by-wire aircraft—controlled by software and electrical actuators rather than hydraulics and cables. As part of the Working Together program Boeing insisted that everyone use the same software language: Ada. Although suppliers were initially resistant, they came to like the discipline that a strongly typed, object-based language imposed at compile time. The largest part of the software was the Airplane Information Management System developed by Honeywell’s Air Transport Systems division. Honeywell used a loosely coupled architecture that allowed the seven main functions to be developed independently by teams of 60–100 engineers. In the end, all of the 777 software was delivered and working on time except the passenger phone system.

On June 7, 1995, three Boeing 777s took off on their first commercial flights, meeting the deadline established five years earlier. For more than a decade, Boeing has delivered 777 aircraft at the rapid pace of about 50 per year, and as of this writing it holds orders for another five years of deliveries.

Boeing has moved on to the defining program of this decade, the 787 Dreamliner. This program brings another management innovation: an unprecedented degree of collaboration between Boeing and its global partners in the design and development of the aircraft. Boeing has created a worldwide innovation network and directs design challenges to the center of expertise around the world that is best equipped to handle the challenge. The 787 development is supported by far superior electronic collaboration tools than were available to the 777 teams, but it is Boeing’s Working Together culture that makes the collaboration work.

Deming traveled to Japan several times over the next 15 years, but back home in the United States, he was relatively unknown. Then in 1980 the NBC report “If Japan Can...Why Can’t We?” featured Deming chiding US companies for the poor quality of their products. At 80 years old, Deming had finally been discovered by his own country. The TV show aired only once, but it shocked the country and put quality on corporate agendas. Deming was at the forefront of the quality movement in the United States until his death in 1993.

Deming espoused a System of Profound Knowledge that has four main points:

1. Appreciation for a System. Deming taught that the synergy between parts of any system is the key to the overall success of the system. Since he saw production as a system, he emphasized that it is important to manage the relationship between its parts—the relationship between departments in a company—the relationship between suppliers, producers, and customers. Above all, Deming believed that a systems view was fundamental; suboptimizing any part of the system was not in the best interest of the whole.

2. Knowledge about Variation. Deming was appalled at the way in which workers were blamed for problems that were inherent in the system in which they worked. His lectures focused on making sure managers understood that most system variation was what he called common cause variation, that is variation inherent in the system. He did exercises to show that trying to eliminate this variation from the system is not only futile, it just makes things worse. Deming emphasized that the bulk of the causes of low quality and low productivity were inherent in the system and thus, lie beyond the power of the individual worker. Deadlines and slogans do nothing to address systemic problems. What was needed instead, Deming insisted, was leadership in changing the way the system works.

3. Theory of Knowledge. A physicist himself, Deming espoused the scientific method for developing a data-based understanding of the system and making decisions. The steps of the scientific method—hypothesize, experiment, learn, incorporate learning—give us the well-known Deming Cycle⁴—plan, do, check, act (PDCA). A version of this cycle is found in virtually every quality and process improvement program. For more on this, see Chapter 7.

4. Psychology. Deming admonished managers that numbers don’t tell the whole story, and when it comes to people, the things that make a difference are skill, pride, expertise, confidence, and cooperation.

Deming summed up his multidimensional perspective on quality in 14 points for management (see sidebar).

Alan Mulally created a management system for the 777 straight out of Deming’s playbook at a time when many companies throughout the US were discovering the power of Deming’s ideas. The design/build teams, the weekly team meetings to expose, discuss, diagnose, and dispose of problems went to the heart of creating pride of workmanship in everyone working on the plane. Although the deadline loomed, it was never allowed to get in the way of doing the right thing.

Deming said that the real purpose of a company was not to make money, it was to create customers who were so pleased that they would continue to buy products. Mulally made sure that the 777 development team was not focusing on hitting deadlines at the lowest possible cost; instead it was to develop a plane that would be efficient to manufacture, cost-effective for airlines to operate, easy for pilots to fly, simple to maintain, and comfortable for the people who flew in it.

Deming emphasized that suppliers should be chosen based on their ability to work closely with the producer to minimize total system costs. Boeing not only followed that principle, it went one step further and maximized system value over a long timeframe. For example, Boeing felt that the parts for the airplane needed to come from around the world, if it expected to sell the plane around the world. Thus, for example, 20 percent of the 777 would be manufactured in Japan, one of the biggest buyers of Boeing’s wide body jets.

The innovation in management thinking that Deming brought to the world is this: When things go wrong, the cause is almost always inherent in the system, and therefore it is a management problem. Managers who push harder on people to meet deadlines or reduce defects are ignoring the system problem and will usually make things worse. Instead, leaders must envision and institute fundamental changes that address the systemic causes of current problems.

Gary Hamel suggests that the largest improvements in companies come from a management innovation—a marked departure from traditional management principles, processes, practices, or organizational forms—that confers a competitive advantage on the innovative company.⁶ When a management innovation creates a competitive advantage, it is a big one, and it is very difficult to copy, because management innovations are such a marked departure from accepted norms.

But that doesn’t keep companies from trying to copy the best practices of a competitor and attempting to mimic their perception of the management innovation. Almost without exception, the fundamental principle of the innovation is overlooked by the mimicking company, because as Gary Hamel says, “Management orthodoxies are often so ingrained in executive thinking that they are nearly invisible and are so devoutly held that they are practically unassailable. The more unconventional the principle underlying a management innovation, the longer it will take competitors to respond. In some cases, the head scratching can go on for decades.”

In other words, the central point of a management innovation is invisible to most management teams trying to copy the innovation. For example, many companies have tried to copy lean practices, but they often missed the central point. As Hamel noted, Toyota’s real innovation is its ability to harness the intellect of “ordinary” employees. Successful lean initiatives must be based first and foremost on a deep respect for every person in the company, especially those “ordinary” people who make the product or pound out the code.

Consider the kind of messages that your policies and practices telegraph to the “ordinary” people in your company and to your suppliers. Do you trust your employees, or do you have locked stock rooms? Do you say that quality is important but only look at deadlines? Do you ask people to work in teams but then rank them against each other or base bonuses on individual performance? Do you talk about trust with suppliers, but insist on fixed price contracts? If you do these things, you are missing the central point of lean thinking: respect for people.

The difference between individual sports and team sports is fairly clear. In individual sports, contestants win or lose based on their individual abilities. In team sports, the entire team wins or loses together based on the team members’ ability to work together. When our son was in college he was the coxswain of a crew team. He sat in the back of a long narrow boat synchronizing the efforts of eight hefty rowers as they sped down the water. Rowing is clearly a team sport.

We might call diving and gymnastics team sports because individual scores are totaled to a team score. But that’s not the same as basketball or soccer, where team members have to synchronize their efforts in order to perform. We should keep the same distinction in mind with work teams. People who work side by side are not necessarily a team, even when they sum up their individual efforts into a collective result. A work group becomes a team when the members hold themselves mutually accountable to produce a “collective work product.”⁸

There is nothing wrong with individual sports, they’re simply different than team sports. And there is nothing wrong with work groups, but they are different than teams. Putting a group of people together and calling them a team doesn’t make them a team. The thing that turns a group into a team is the mutual commitment of the members to pool their various skills and work together for a common purpose.

Creating good software is a lot more like rowing than swimming. Software development involves constant problem solving; people make complex decisions many times a day, often with implications far beyond their own work. Pooling skill and knowledge from many different perspectives is critical to excellent results.

Teams need a challenge, a common goal, and a mutual commitment to work together to meet the goal. Team members depend upon each other, and help each other out. A wise organization will focus its attention, training, and resources on creating an environment where teams are challenged by their work and engaged with their teammates in doing the best job they can.

Toyota believes that consistent excellence in product development starts with “towering technical competence in all engineers.”⁹ And the company does not think that such competence is learned in college; it is developed over time—several years—with experience and mentoring. Toyota starts by sending new engineers to automobile plants to make cars. Then they work in dealerships for a few months, selling cars and talking to customers. After about a half a year, new engineers are assigned to a department to work under the guidance of a senior engineer. The first thing they do is a “freshman project”—an improvement project which provides a challenge and teaches the engineer Toyota’s approach constant improvement. At the end of a year or so, new engineers start a rigorous, two year, on-the-job-training program in which they acquire a standard set of skills. Only then do they move up to entry level engineer and begin to be a serious team contributor. After this initial period, an engineer can expect to spend five or six years within the same specialty before being considered a first-rate engineer.

Excellent software products start with highly competent technical experts in many areas—architecture, object-oriented technologies, coding strategies, data structures, test automation. This is not a function of the methodology used for development; behind every excellent product, no matter how it was developed, you will find excellent technical people. In lean development, we acknowledge this fact and focus organizational policies on hiring and developing such experts.

A development team should have among its members the expertise necessary to meet its goals. Team members should mutually commit to specific team goals, and reliably achieve those goals by working together, pooling their expertise, and helping each other out whenever necessary. It is easier to help each other out when there are multiskilled people on the team. As development progresses, there may be more need for testing and less for development, or more need for user interface coding rather than database work. Developers can help testers, user interaction designers can test user interactions, junior members can pair up with more experienced team members to help out and learn new skills. Every person on the team is first of all a member of the team, and second a specialist in some particular discipline. No one on the team gets credit for being done until all the work the team committed to is done, so everyone pitches in however they are able.

A large team without leadership is like a crew team without a coxswain. The team can perhaps go fast in the right direction, but it is unlikely to apply synchronized power and make the subtle course corrections that create a winning product. Toyota operates from the basic principle that teamwork is essential, but someone always needs to be responsible.¹² We concur. All too often we find that “Everybody’s job is nobody’s job.” In Chapter 3 we discussed the importance of a champion who brings to a development team a deep understanding of the market need and the technology that can meet that need in a unique way. The question we address now is this: Does a development team also need a process leader? How many leaders does a team really need, and what are the appropriate roles?

Don’t make the mistake of thinking that process leadership is a substitute for product and technical leadership. It is not. The role of champion remains essential; there should be one or two people who deeply understand the customer and deeply understand the technology. If there are two people, they should speak with one voice and have joint responsibility for the success of the product. When an organization puts a new process in place, a process leader may be a good idea. However, the process leadership role must synchronize well with the role of champion, either through close cooperation or by adding process leadership to the champion’s role. If there are two people in the champion role already, three may be too many. If there is one champion, she or he may welcome the assistance of a process leader.

The way this works at Toyota is remarkable. The product development process has specific synchronizing events such as vehicle sketches, clay models, design structure plans, prototype, and so on. The dates for each event are scheduled by the chief engineer. Every engineer and supplier knows that these dates will not—ever—be moved. They know exactly what is expected of them at each synchronizing event, and they will—always—be ready with their contribution by the date. There are no excuses. Engineers are expected to obtain for themselves everything necessary to be ready on time. Thus, information is “pulled” by engineers as they need it instead of broadcast to long distribution lists. At Toyota, the engineering tasks required for each synchronization event are well known and standardized. But they are not tracked. The schedule is managed through the fundamental imperative that schedules are never missed. The rest is the responsibility of the engineers.

This may seem like an impossible development approach, except that you can find examples of the same approach being successfully applied in every major city in the world. Any city with a daily newspaper has a group of skilled people who develop a new product every day. They never miss a deadline, even when the news is changing right up to the cutoff, even when computers go down, and with surprisingly few exceptions, even while coping with local disasters. So if you would like to see a development process that never misses a deadline, go benchmark your local newspaper.

An important consideration to bear in mind when schedules become a commitment is that people must always have the time to do the job that they have committed to complete, and at the same time, the details of the job will always change. As we discussed in Chapter 5, if you expect teams to meet aggressive deadlines, you must limit work to capacity.

There is more than one way to accomplish this. Toyota has a good feel for how much effort will be required in any development cycle and staggers model development cycles so that the demands on each function are more or less leveled. Further, Toyota makes no attempt to schedule at the detailed level but expects that each function or supplier will back up their team members with additional help whenever it is needed.

PatientKeeper estimates features and tasks at a fine-grain level and dynamically adjusts that estimate daily. The new estimates give PatientKeeper an immediate alert when work exceeds capacity, and the amount of work is quickly adjusted make sure that there is no more work scheduled into an iteration than can be completed by the deadline.

Maintenance organizations maintain slack by working on routine requests that can be set aside, which provides the capacity to jump on emergencies when they arise. However you do it, remember that it is impossible to implement responsibility-based planning and control unless you understand the capacity of each team and limit the work expected of a team to its capacity.

First you look at your ticket to see what flight you are supposed to take. Your ticket tells you the details: the airline, the flight number, and the originally scheduled departure time of your next flight. (In manufacturing, we would call such a ticket a kanban, a card with the instructions for your next job.) Your job is to get on that flight before it leaves. Now your question becomes, where is that flight leaving from, and how do I get there on time? To answer this question you find a big display to help you out. You look at the display to find out what concourse and gate the flight will leave from and when it is currently scheduled to leave. In larger airports there will often be another display to tell you how many minutes it will take you to walk to that concourse or gate to help you decide if you need to run or flag down an electric cart. Next, you follow easily visible signs to your concourse and go down the concourse where gates are numbered in order until you find the gate your plane is supposed to be leaving from. Finally, you check the display at the gate to be sure that the plane leaving from this gate is really the one your ticket says you should be on.

Airports use tickets, displays, and visible signs quite effectively. But one thing that’s missing in most airports is a dashboard, something that gives everyone a general idea of how the airport is operating. That’s OK when things are going well, but it is missed when something goes wrong.

Dispatching involves planning every step of someone else’s job. Making work self-directing involves setting up an environment so people can figure out how to do their job without being told what to do. When a lot of things have to happen quickly, self-directing work is the only approach that works, and it works very well. In busy downtown areas, flagging down a taxi often works better than having one dispatched to your hotel. If managers really want things to happen quickly, they will focus their attention on organizing the work space so that work becomes self-directing.

When work is self-directing, everyone showing up for work in the morning can figure out exactly what to do without being told, and what they choose to do will be the most important thing for them to be working on. As people complete one job, it is immediately obvious what to do next. Throughout the day when people have questions, the workspace is organized so that people can look around and find the answers. Think of self-directing work as a package that you ship overnight. You attach instructions to the package, and from then on, every person and machine that handles your package can simply look at the instructions and know exactly what to do with the package.

If you are a manager who’s been wondering what you are supposed to do once responsibility-based planning and control relieve you of a lot of your current dispatching work—here’s part of your new job: Organize the work space so that work becomes self-directing. There are three key levels of information to focus on when organizing a self-directing workspace: kanban, andon, and dashboard.

The challenge with Kanban is not really figuring out how people might go about choosing what to do next. That’s the easy part. The challenge is figuring out how to be sure that the content of the card and its location are correct, so that when the card is selected, it contains a sufficient description of a job that is the right size and is the right thing to do next. The card is not the specification of the job; it is a signal that the next job is to bring together the right people to create the detailed designs, verifications, and implementation of the story on the card.

Whatever mechanism is used to make work self-directing requires some thought and experimentation. Each job must be succinctly described, the set of jobs must be both complete and correctly sequenced, and the rules for posting and choosing jobs must assure that they will be done by people with the expertise to do them well.

Over time, andon has also come to be used for any kind of visual message board or other display device that can be easily changed. The message boards at train stations that display departure tracks are sometimes called andon boards. An andon board calls attention to any abnormality that requires attention, dynamically displays changing status, and shows locations of things that are frequently reconfigured (for example, which sever is currently the test server).

It is important for teams to see the overall progress of their work in its context and in the context of the broader goals of the company. For this we use various kinds of dashboards. Every team room should have big, visible charts on the wall that show off to everyone how well the team is doing—or not—and make status visible to anyone who walks in the room. Things like burn-down charts, graphs of acceptance tests written and passed, and so on are very useful. Charts of the overall status of a multiteam effort should be available in the main “war room,” as Boeing called it, for everyone to see. Dispersed teams should have visibility into status also, and here an electronic dashboard might be the perfect tool. Electronic dashboards are also useful for key metrics that are easier to generate electronically than manually.

We often ask our classes, “In your organization, how do people know their progress toward meeting the overall goal of their work?” (See exercise 4 at the end of this chapter.) We have been surprised by the number of times the answer is, “Actually, that information isn’t readily available.” Organizations that do not engage people in the ultimate goal of their work are squandering a great opportunity to inspire people and teams to enthusiastically contribute their best efforts to the cause.

There are two kinds of companies, according to de Geus, the economic company and the river company. The purpose of the economic company is to produce maximum results for minimum resources and produce wealth for a group of managers and investors. The purpose of a river company, on the other hand, is to keep on flowing, that is, to stay in business and provide jobs over the long term. For example, Sakichi Toyoda and Kiichiro Toyoda had as their primary purpose to provide jobs for Japanese workers by figuring out how to manufacture complex products that would otherwise have to be imported.

In the economic company, de Geus says, there is an implicit contract between the company and the individual: The individual will deliver a skill in exchange for remuneration. In a river company, the implicit contract is different: “The individual will deliver care and commitment in exchange for the fact that the company will try to develop each individual’s potential to the maximum.”¹⁶ Commitment is a two way street: People are committed to a company if they feel that the company is committed to them.

On the other hand, when a company is committed to developing each individual’s potential to the maximum, a performance evaluation can be a time set aside to reflect on where that potential lies and what steps that the company and the individual can take to further develop the individual’s potential. Thus, we do not have a rating system as much as we ponder honestly and openly whether the individual would be best aiming toward a technical ladder or a management ladder, what training and job assignments would be best for the coming year, what specific areas (public speaking, for example) need improvement to support further career growth.

Annual performance evaluations should never surprise employees with unexpected feedback. Performance feedback loops should be far shorter than an annual, or even a quarterly, evaluation cycle. If the annual performance evaluation is the only time employees finds out how they are doing, something is truly wrong with the evaluation system. Performance review criteria should put strong emphasis on teamwork, making contribution to team success as important—if not more important—than individual contributions. You get what you reward, so if you find effective ways to reward collaboration, you will get more of it.

One-directional evaluations give the appearance that only the evaluated person needs to improve, but Deming insists that most performance issues are a management problem. When an employee isn’t performing, the first question a manager should ask is, “What am I doing wrong?” Managers should take personal responsibility for the performance of their organization and collaborate with their people to improve the performance of the system.

Now consider the same team, only the members know that once a year their supervisors have to go into a secret session and rank the entire department so that raises and promotions can be handed out in order of value and contribution to the company. The team members must give their supervisors ammunition to show why they are better than their teammates, so as to get a higher rank and a better raise and better shot at a promotion. The incentive to allocate blame and take individual credit for finding a solution is high; collaboration is strongly discouraged by such a ranking system. If you have a ranking system in your company, a lean initiative will be hollow at best. The behaviors that ranking systems encourage are competition, hiding information so as to look good, and hiding problems so as not to look bad.

Nothing is more likely to create contention and interfere with collaboration that the system used to determine compensation, no matter what system is in place. Although no compensation system will ever be perfect, some are better than others. We offer the following guidelines.

The foundation of any promotion system is a series of job grades, each with a salary range in line with industry standards and regional averages. People must be placed correctly in a grade so that their skills and responsibilities match the job requirements of their level. Initial placements and promotion decisions should be carefully made and reviewed by a management team.

Usually job grades are embedded in titles, and promotions make the new job grade public through a new title. A person’s job grade is generally considered public information. If employees are fairly placed in their job grades and promoted only when they are clearly performing at a new job grade, then salary differences based on job grade are generally perceived to be fair. Thus, a team can have both senior and junior people, generalists and highly skilled specialists, all making different amounts of money. As long as the system of determining job grades and promotions is transparent and perceived to be fair, this kind of differential pay is rarely a problem.

Even when annual raises are loosely coupled to merit, evaluations will always be a big deal for employees, so attention should be paid to making them fair and balanced. Over the last decade, balanced scorecards have become popular for management evaluations—at least in theory. Balanced scorecards ensure that the multiple aspects of a manager’s job all receive attention. A simple version of a balanced scorecard might also be used for evaluations that impact annual raises, to emphasize the fact that people must perform well on many dimensions to be effective. Input to the scorecard should come from all areas: teammates, customers, senior management, those receiving guidance from a leader. It is important that employees perceive that the input to a scorecard is valid and fairly covers the multiple aspects of their job. It is also important to keep things simple, because too much complexity will unduly inflate the attention paid to a pay system which works better when it is understated. Finally, scorecards should not be used to feed a ranking system.

Conventional wisdom says that people should be rewarded based on results that are under their control. However, when information sharing and cooperation are essential, rewards should be based on a person’s span of influence rather than his or her span of control. For example, testers should not be rewarded based on the number of defects they find, but rather, developers and testers alike should be rewarded based on the team’s ability to create defect-free code. Development teams should not be rewarded based on the technical success of their efforts; instead, the whole team should be rewarded based on the business success of its efforts.

In the book Hidden Value,¹⁸ Charles O’Reilly and Jeffrey Pfeffer present several case studies of companies that obtain superb performance from ordinary people. These companies have people-centered values that are aligned with actions at all levels. They invest in people, share information broadly, rely on teams, and emphasize leadership rather than management. Finally, they do not use money as a primary motivator; they emphasize the intrinsic rewards of fun, growth, teamwork, challenge, and accomplishment.

Treat monetary rewards like explosives, because they will have a powerful impact whether you intend it or not. So use them lightly and with caution. They can get you into trouble much faster than they can solve your problems. Once you go down the path of monetary rewards, you may never be able to go back, even when they cease to be effective, as they inevitably will. Make sure that people are fairly and adequately compensated, and then move on to more effective ways to improve performance.

a. It’s the whole product, the whole team, the whole system that matters.

b. When something goes wrong, in all probability it was caused by the system, which makes it a management problem.

c. Use the scientific method to change and improve.

d. With people, the things that matter are skill, pride, expertise, confidence, and cooperation.

Imagine that Deming was scheduled to tour your organization next week. Prepare a presentation for him on how each of these points is addressed in your organization. What do you think his advice would be? Would you be prepared to act on it?

2. Review Deming’s 14 points with your team. For each one, discuss: Is this point relevant today in our organization? Is it important? If we regard it as relevant and important, what does it suggest we should do differently? What would it take to make the change?

3. How are teams formed, chartered, and led in your organization? Are they actually work groups or true teams? How many teams are individuals typically on?

4. Fill out the Visual Workspace Assessment on the next page:

a. In column 2, answer the question posed in column 1 as it relates to your organization.

b. In column 3, rate how self-directing your organization is. Give your organization a score of 0–5, with 0 = people are told what to do and 5 = people figure out among themselves what to work on next.

5. The next time your company does an employee survey, add these questions:

a. Do you feel that the compensation system is fair?

b. Do you feel that the promotion system is fair?

c. Rate how the compensation affects your dedication to your job (Scale of 1–5):

1. It angers me and gets in the way of doing a good job.

2. It sometimes annoys me and occasionally affects my performance.

3. It doesn’t make much difference.

4. It occasionally motivates me to work harder.

5. It motivates me to work hard every day.

2. Deadline! How Premier Organizations Win the Race Against Time, by Dan Carrison, AMACOM (American Management Association), 2003, Chapter 5.

3. 21st Century Jet: The Building of the 777, Produced by Skyscraper Productions for KCTS/Seattle and Chanel 4 London, 1995.

4. Deming called this the Shewhart Cycle, since it was originally taught by Walter Shewhart, who developed statistical process control in the Bell Laboratories in the United States during the 1930s.

5. True to his philosophy of continuous improvement, Deming continually modified the wording of his 14 points. This list is our summary of the 14 points and their discussion, found in Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.

6. “Management Innovation,” by Gary Hamel, Harvard Business Review, February, 2006, p. 74.

7. Special to The Washington Post, by Clare Crawford-Mason Tuesday, April 23, 2002, p. HE01, used with permission.

8. See The Wisdom of Teams, by Jon R. Katzenbach and Douglas K. Smith, Harvard Business School Press, 1992.

9. James Morgan and Jeffrey Liker, The Toyota Product Development System: Integrating People, Process, and Technology, Productivity Press, 2006. See Chapter 9.

10. James Morgan and Jeffrey Liker, The Toyota Product Development System: Integrating People, Process, and Technology, Productivity Press, 2006, p. 169.

11. The OASIS standards organization approved DITA in June of 2005. DITA is an XML-based standard and a set of design principles for creating “information-typed” modules at a topic level. DITA aims to deliver content from a single repository directly to the point-of-use.

12. Jeffrey Liker and James Morgan, Ibid., p. 103.

13. The Living Company, by Arie de Geus, Harvard Business School Press, 1997.

14. Ibid., p. 3.

15. Ibid., p. 10.

16. Ibid., p. 118. Italics in original.

17. Parts of this section are from an article originally published by Mary Poppendieck in Better Software Magazine, August 2004, under the title “Unjust Deserts.”

18. O’Reilly, Charles A., III, and Jeffrey Pfeffer, Hidden Value: How Great Companies Achieve Extraordinary Results with Ordinary People, Harvard Business School Press, 2000.