About Teams and Projects

In The Wisdom of Teams, Jon R. Katzenbach and Douglas K. Smith explained that, for a working group to coalesce as a team, it needs a common goal, complementary skills, and mutual accountability among members. It sounds simple, but it is in fact a tall order, and there is no evidence that it is sufficient.  The authors don’t claim it is, but they found these characteristics among successful teams in sports and business, and found them lacking in unsuccessful ones.

What Makes a Great Team

Let us explore the meaning of these three characteristics in more detail:

1. A common goal. It can be organizing a successful conference, or JFK’s “before this decade is out, landing a man on the moon and returning him safely to the earth,” or building a motorcycle that wins a race. Whatever it is, the goal must be clearly stated in few words, with obvious success criteria, for team members to sign up.

2. Complementary skills. The participants must have complementary skills, as in the original Mission Impossible TV series, with the master of disguise, the mechanical and electronics genius, and the muscle. With complementary skills, team members reinforce each other; with identical skills, they compete with each other instead. It should be noted that this applies to project teams but not to production teams on the shop floor, where members are expected to have multiple, overlapping skills, and stand in for each other as needed. It also applies only to small teams with, say, 5 to 10 members. For example, a new car design team grows to involve ~1,500 people prior to new product introduction, and overlapping skills are inevitable.

3. Mutual accountability. Observing the British people in World War II, Charles de Gaulle said “all behaved as if the outcome of the war depended on their individual behavior.” This is the essence of mutual accountability. All members do whatever it takes to make sure they don’t let the others down. A Quality manager told me how, after he noticed that final test had failed to detect missing gaskets in a product — as a result of mating surfaces matching so well that no leakage occurred — he drove 70 miles at night to the final assembly plant to prevent shipping products with the defective units. He didn’t just call or email; he physically made sure all the defective units were pulled off. His company had an excellent reputation for quality, and, if he hadn’t done as he did, he felt he would have let down his co-workers.

Teams in Real Life

In real life, most work groups fail to coalesce into teams. The few that do produce outstanding results and are unforgettable experiences for participants. I have personally experienced this, perhaps once a decade. Katzenberg and Smith’s conditions are not sufficient but they are necessary, and they are often not met. Let us review why for each. 

Goal Setting

Of the three criteria, only goal setting is entirely under the control of the organization, but organizations often have hidden agendas, particularly in public service. From 1983 to 1998, the European Union’s ESPRIT program, for example, funded research projects in information technology by consortia involving companies and universities in multiple countries. Officially, each project had the goal of developing technology and prove its values through pilot projects in industry; unofficially, the whole program aimed to stimulate R&D in Europe, particularly among the poorer members of the European Union.

To best serve the official goal, it would have made sense to bring individual researchers from all participating organizations to a single, central location to work together. The unofficial goal, on the other hand, drove the opposite: have a separate team in each participating country, with a weak coordination structure. This made the participants a so-called “virtual team,” which was not a team.

Prompted by the availability of videoconferencing and software supporting on-line collaboration, many organizations today are tempted to rely on virtual teams as an alternative to collocation. But participants in multiple locations are loyal first to the people who are physically around them, and inevitably pulled in different directions. I experienced this personally as coordinator of an ESPRIT project in the 1990s. Officially, the project was successful, but the technology was essentially developed by one of the member organizations, in a single location. 

When discussing the clarity of goals, it is easy to forget that stating a goal does not make it achievable. As Frederic Brooks pointed out, the tower of Babel project had the clear goal of building a tower whose top is in the heavens. Part of the project game, however, is setting stretch goals, that can only be achieved by innovation, and the line between an stretch goal and an impossible one is not easy to identify.

What is possible or impossible also depends on the skills of the people in the project team. For example, the goal of reducing raw material losses in a plastic extrusion process is realistic for a team that includes chemical engineers knowledgeable about extrusion; it is not with a team of production operators led by a supervisor, who cannot anticipate the effects of changing temperatures or flow rates.

Complementary Skills

Team members with the requisite complementary skills are not always available. When composing a team, not all the skills are needed in the same quantity nor at the same time. In fact, you need to make a distinction between a core of members who need to be dedicated to the project for its duration, and others who participate occasionally.

In a new production line project, design and development engineers may be in the core team, while the expert who validates compliance with the fire code is occasionally consulted. The promoters of the scrum approach to software development call these two categories “pigs” and “chickens,” metaphorically based on eggs-and-bacon, in which the chicken is involved while the pig is committed.

Some recommend breaking down the levels of involvement further, into the “RACI” categories, which stand for:

• Responsible — Team members who do the work of the project.
• Accountable — Team members who responsible to management for the outcomes.
• Consulted —  Experts called upon to make occasional contributions based on their specialized expertise.
• Informed — Non-members of the team, whose work is affected by project activities, and who must therefore be kept informed on its activities.

If, in practice, these finer distinctions make a difference, I have not seen it. What I have seen, on the other hand, is project teams spending time on the classification of contributors to each tasks among four different categories, when it would have been more useful to charge ahead on project tasks.

Of course, complementary skills matter most in the core team, where overlaps are most difficult to avoid, and perhaps not always as detrimental as Katzenberg asserts. In business cultures that value specialized expertise over anything else, most individuals will stay in the same functional areas and move between companies; in organizations that value membership in, and loyalty to an organization, they will move between functional areas within the same company. In the first case, the IT manager in company X started out as a systems engineer in company Y, and has never had a job that was not centered in IT; in the second, the purchasing manager is a former design engineer.

Professionals rotated in this manner develop greater expertise in how the company works than in their original specialty. As a consequence, when you form a team, you are likely to have members who have been in each other’s shoes and, as a result, have overlapping skills. When working with each other, however, the perfectly complementary specialists may be hobbled by their inability to communicate. Their perspectives on the company’s activities may be so different that they don’t even use the same vocabulary to describe them. The generalists with overlapping skills, on the other hand, have a common language, and the former engineer now in purchasing may think he or she stills knows technology better than the current engineer formerly in production control, and it may cause counterproductive rivalries in the work of the team. It is up to the team leader to specify upfront the roles of the different team members and their expected contributions.

Mutual Accountability

More than a common interest is needed for a group of people to feel mutually accountable. As discussed above, it is much more difficult to develop a sense of mutual accountability among people who never meet face-to-face than if they share the same work space. And, even if they do share the same work space, its layout matters. An obeya, “big room” is an effective structure for this purpose. 

While management cannot provide the spark that ignites the formation of a genuine team, it can act in many ways that keep it from happening, for example by using rank-and-yank. When membership in the organization is a game of musical chairs, with the bottom 10% in performance being fired at every review cycle, everyone has an interest in making others fail; no one, an incentive to help others. More generally, if the human resource system is focused exclusively on individual performance, management is sending the message that the organization does not appreciate teamwork. Some will still work in teams, because it is in their character and they don’t know any other way, but many won’t.

Multitasking is another commitment killer, with each project an employee is involved in providing an excuse not to make any progress in the others. Many managers fail to understand that dedication to one project at a time is the most effective way to get many projects completed. An engineer you ask to divide work time among 15 projects will not only be mentally exhausted by changeovers between projects but will also fail to bond with teammates on any of these projects. It is different from a sales rep who maintains a pipeline with many prospects that he or she is simultaneously coaxing into becoming customers.

Team-building games that are unrelated to the project don’t usually help. What can really build a team is intense, collective effort on its project, and it doesn’t always work. You cannot make team members feel mutually accountable. All you can do is create an environment that gives group dynamics a shot at making it happen.

Personal Peak Experiences

My first professional experience after leaving school almost 40 years ago was an internship with a team of academic geophysicists who were mapping the boundary between the earth’s crust and mantle — the “Moho” — by seismic soundings. The way they finished each other’s sentences, the initiatives each individual took to help the group, and the respect they had for its leader made this rookie believe this was the normal way for adults to work together. I had no idea how exceptional this was, particularly among academics. I was particularly in awe of the clever devices lab technicians had designed to carry 70 lbs of seismometers and 1970s electronics using backpack H-frames and camping iceboxes. They had in real life the spirit and the ingenuity of the fictional storm chasers of Twister.

They were blasting charges of 1,000 lbs of dynamite on the surface and listening to the echo from the Moho. I was a temporary addition to a team of six who had been doing this together for several years, on a campaign in the Azores where we worked 12 hours/day, 7 days/week installing, operating and dismantling recording stations in the fields and mountains of the islands of Sao Miguel and Terceira. The eventual conclusion was that there is no Moho under the Azores: they are, in fact, pieces of mantle sticking out of the ocean.

A few years later, in Silicon Valley, I joined a team developing what was not yet called a Manufacturing Execution System (MES) for semiconductor manufacturing. As was typical of the time and place, it was a group comprised mostly of recent immigrants, from China, India, Iran, the UK, Italy,… built around a core of engineers who had previously developed a data acquisition and analysis system for semiconductor testing. Until that point, the hundreds of measurements and attributes collected as part of the testing done on integrated circuits at the end of their process had been essentially dumped instead of being used to refine the manufacturing process. As their system had been widely adopted in the industry, their plan was to expand on it,  by automating data collection in the manufacturing process itself and using the in-process data in troubleshooting, production control, and yield enhancement.

For three years, this was a team that was pursuing a clear goal, with members having complementary skills, and with a sense of mutual accountability that made the members push themselves. The manager had not recruited them to fill slots in a predetermined organization chart but for talent, drive, and loyalty, with specific roles to be determined. Some came from the manufacturing plants while others were computer scientists with advanced degrees. In the initial stages, at least, all had to invent their roles, with guidance that was rarely much more specific than “Go structure chaos.”

There was much work to do and few to do it, but it gradually did become more structured, as the system grew and was adopted by the various plants in the company. In a number of ways, it was ahead of its time. It had, in particular, tools to generate, approve and implement engineering changes that had enthusiastic end-users but that the market would only appreciate 10 years later. Efforts to commercialize the system outside the company were unsuccessful, and neither it nor the company itself survived the semiconductor recession of 1985. Most team members went their separate ways, but a core group survived as a startup supplying production simulation, planning and scheduling software to the same industry, and was acquired by a large software company 20 years later. What I personally learned from this experience was the basis of my first book.

Consulting, teaching, and writing about Lean — my main economic activities for the past 28 years — do not afford the same opportunities for teamwork as a large engineering project. You get to coach client teams, but not to be part of them. At least in the work I have been doing, you team up with one or two colleagues for a week at at time, not with ten for a year or two.

Still, one recent experience stands out, where a consultant, as project manager, had summoned the help of five others, including myself, to address a client’s competitiveness issues, which ranged from overdesigned products to production lines in need of improvement. Complementary skills and clear roles were essential in this case, because the last thing he wanted was a rivalry with two consultants arguing in front of the client.

We all had personal, one-on-one relationships with him but had never worked together before. While younger than all of us, the project manager combined a confidence-inspiring understanding of the client’s needs with respect for each team member’s expertise and a manner that made us willing to work with him late into every night. We wanted to make him successful in his engagement with the client. The leader’s quality that made this group of individualistic strangers click as a team and support him, we call “charisma,” but it is only putting a label on our inability to describe what it is.