Building and leading teams

Owen Tremblay's project team at Prairie Ridge Engineering has a problem that will be familiar to anyone who has worked on a large project. The team designing a water treatment plant upgrade grew from six people to fourteen over a year as new specialties were added: process engineers, structural engineers, an electrical lead, two controls specialists, a cost estimator, a scheduler and representatives from the client. Weekly meetings now take two hours, decisions keep being reopened, and the team missed two design milestones. Owen's manager has asked him to fix it. In this session Dr. Sato uses his case to examine what decades of research say about why teams succeed or fail, and why most of the answers lie in how the team is set up rather than in how it is coached day to day.

What a team is, and when you need one

A team is a group of people who are interdependent in their work, share responsibility for collective outcomes and see themselves, and are seen by others, as a social unit. Many groups called teams are really co-acting groups: people who report to the same manager but work independently, like a set of regional sales representatives. That is not a problem in itself. Real teamwork carries costs in coordination and time, and it pays off only when the task genuinely requires people to combine their knowledge and effort. A useful first question for any leader is whether the work needs a team at all, or whether a well-coordinated group of individuals would do better.

When people work together, performance is rarely the simple sum of individual capabilities. Ivan Steiner's classic formulation was that actual productivity equals potential productivity minus losses due to faulty process. Two kinds of process loss are common. Coordination losses arise because people have to combine their efforts, wait for each other and communicate. Motivation losses arise because individual effort becomes less visible. The French agricultural engineer Max Ringelmann observed in the late nineteenth century that people pulling on a rope in groups pulled less hard per person than when pulling alone. Later research named the motivational part of this social loafing; a meta-analysis by Steven Karau and Kipling Williams in 1993 found it to be robust across many tasks, though it is reduced when individual contributions are identifiable, the task is meaningful and people value the group.

Size and communication

Larger teams have more resources but also more coordination problems. One simple reason is the number of possible communication links between members, which rises much faster than the number of people. In a team of n people there are n times n minus one, divided by two, possible pairs. A team of five has 10 pairs; a team of fourteen has 91. Not every pair needs to talk, but the burden of keeping everyone informed, and the risk that information fails to reach the people who need it, grow quickly. J. Richard Hackman, who studied teams for over four decades, argued that teams are often larger than they need to be, and suggested that teams of more than about ten people should usually be split or restructured. Amazon's well-known rule of thumb, that a team should be small enough to be fed by two pizzas, expresses the same idea informally.

# Communication links and a rough coordination budget by team size
def links(n):
    return n * (n - 1) // 2

minutes_per_link_per_week = 15   # assumed time to keep each pair aligned
print(f"{'Size':>4} {'Links':>6} {'Hours/week':>11} {'Hours/person':>13}")
for n in (4, 6, 8, 10, 14, 20):
    hours = links(n) * minutes_per_link_per_week / 60
    print(f"{n:>4} {links(n):>6} {hours:>11.1f} {hours / n:>13.1f}")

# Owen's option: split 14 people into two pods of 7 plus a 3-person leads group
pods = 2 * links(7) + links(3)
print(f"Two pods of 7 plus a leads group of 3: {pods} links vs {links(14)} for one team")

Size  Links  Hours/week  Hours/person
   4      6         1.5           0.4
   6     15         3.8           0.6
   8     28         7.0           0.9
  10     45        11.2           1.1
  14     91        22.8           1.6
  20    190        47.5           2.4
Two pods of 7 plus a leads group of 3: 45 links vs 91 for one team

The assumed fifteen minutes per pair is arbitrary, but the shape of the result is not. Coordination time per person rises steadily with team size, while splitting Owen's team into two pods of seven, one for process and civil design and one for electrical and controls, linked by a small group of three leads, roughly halves the number of pairwise links. The cost is that the leads must manage the interface between pods carefully, which is exactly where design errors on engineering projects tend to occur.

Hackman's conditions for team effectiveness

Hackman's central insight was that leaders cannot make a team great by coaching it during the work. What they can do is create conditions that make effectiveness more likely, and then help the team take advantage of them. In his later work with Ruth Wageman and others, he identified a set of conditions. A real team has clear boundaries, interdependence and reasonable stability of membership. A compelling direction is challenging, clear and consequential. An enabling structure includes a well-designed task, the right size and mix of people and clear norms of conduct. A supportive organizational context provides rewards, information and resources. Competent coaching is available at the right moments. Wageman and colleagues later emphasized having the right people as a condition in its own right.

Hackman and Wageman summarized their findings with what they called the 60-30-10 rule: in their studies of senior leadership teams, roughly 60 percent of the difference in team effectiveness was attributable to how the team was designed, about 30 percent to how it was launched, and only about 10 percent to the coaching it received once the work was under way. The figures are an approximate summary of their research rather than a precise law, but the message is clear and practically important. Owen's team will not be fixed by better facilitation of the weekly meeting. It needs clearer boundaries, a structure suited to its task and a fresh launch.

Timing matters for coaching too. Connie Gersick's studies of project teams found that many did not move through the gradual stages often described in management textbooks, such as Bruce Tuckman's forming, storming, norming and performing, which was based on a review of studies of therapy and training groups and has limited support as a universal sequence. Instead, Gersick's teams established a pattern of work early, kept to it for the first half of their time, and then underwent a burst of change around the midpoint, when members became aware of the deadline. This punctuated equilibrium suggests that leaders should invest heavily in the launch and plan a deliberate midpoint review, when teams are most open to changing their approach.

Psychological safety and Project Aristotle

Amy Edmondson's research on psychological safety began with a puzzle. In a study of hospital nursing units, she expected better-led units to make fewer medication errors, but found that they reported more. The explanation was that people in those units felt safe to report errors, while people in other units hid them. Edmondson defined team psychological safety as a shared belief that the team is safe for interpersonal risk-taking. In a 1999 study of 51 work teams in a manufacturing company, published in Administrative Science Quarterly, she found that psychological safety was associated with team learning behavior, such as asking for help, discussing errors and seeking feedback, and that learning behavior was in turn associated with performance.

In 2015, Google publicized the results of Project Aristotle, an internal study of 180 teams that examined what distinguished effective ones. The company reported that who was on a team mattered less than how members worked together, and identified five dynamics: psychological safety, which mattered most; dependability, meaning that members complete quality work on time; structure and clarity of roles, plans and goals; meaning, in that the work is personally important to members; and impact, the belief that the work matters. The study was an internal analysis rather than peer-reviewed research, and it measured effectiveness partly through executive and team ratings, but its conclusions are consistent with a large body of academic work. A meta-analysis by Alexander Newman and colleagues found that psychological safety is related to learning, voice, creativity and performance across many settings.

Psychological safety is not the same as comfort. Edmondson stresses that the most effective teams combine high psychological safety with high standards and accountability. Low safety with high standards produces anxiety; high safety with low standards produces complacency. Leaders build safety through specific behaviors: framing work as a learning problem, acknowledging their own fallibility, asking genuine questions and responding productively when people raise problems or admit mistakes. The response to bad news is the critical moment. A leader who reacts to an early warning with irritation teaches the whole team to stay silent.

An intriguing line of research has asked whether groups, like individuals, have a general intelligence. Anita Woolley and colleagues reported in Science in 2010 that a single collective intelligence factor predicted group performance across varied tasks, and that it was associated with members' social sensitivity and with more equal participation in conversation rather than with the average or maximum intelligence of members. Later studies have found mixed support for a single general factor, and critics have questioned some of the analyses, so the specific claim should be treated with caution. The finding that groups do better when members read each other well and share airtime, however, fits with the broader evidence on psychological safety.

Launching and running a team

A good launch makes the conditions explicit. Dr. Sato recommends a team charter covering the purpose and the specific outcomes the team is accountable for; who is a member and who is a stakeholder; roles and decision rights, including which decisions require the whole team and which belong to individuals; working agreements on meetings, communication channels and response times; and how the team will review its own process. In multidisciplinary engineering teams such as Owen's, interface agreements matter especially: who owns each boundary between disciplines, and how design changes that affect another discipline are flagged.

After-action reviews, borrowed from military practice, are a simple and well-supported way for teams to learn. After a significant piece of work, the team asks four questions: what did we intend to happen, what actually happened, why was there a difference, and what will we sustain or change next time? A meta-analysis of team debriefs by Scott Tannenbaum and Christopher Cerasoli found that well-conducted debriefs improved team performance by around 20 to 25 percent on average. The key conditions are that the review focuses on learning rather than blame, includes everyone and leads to specific changes.