Build Great Teams

At the core of most of the important work done in this world you will find a small, multi-skilled team with effective leadership focused on delivering a product of value to a customer.

Note that teams such as these are found in contexts as different as Jazz bands, Rock groups, filmmaking, Agile Software Development and Lean Manufacturing, to name just a few obvious examples.

It’s now commonplace in business to take the work of teams for granted, but passive acceptance doesn’t always translate into active support.

Let me break my opening assertion down, and explain the significance of each of its components.

“A Small Team”

I mean something in the range of 3 - 15 members. Such a team, if organized well, has the following advantages.

  • Diversity of knowledge, abilities and perspectives.
  • Joint decision-making following joint discussion and consideration of alternatives.
  • Bonding and cohesion of team members, including reinforcement of shared team norms.
  • Social motivations for completing important work.
  • Direct communication between team members.

What’s magic about the size? Less than three, and you have a duet rather than a group: it’s more about the individuals and their relationship, and less about a team identity. More than fifteen, and it’s hard to maintain direct communication between team members. (And fifteen, by the way is an upper limit: for some sorts of teams, that may be too large a number.)

And note that the ideas of decomposition, cohesion and loose coupling should be employed in order to break down larger groups into these sorts of teams, and to break down larger problems into ones small enough to be assigned to these sorts of teams.


For the sort of team I’m talking about, it’s important for the team to be relatively self-sufficient, which means that all or most of the skills important to the team need to be available within the team. This is different from the oboe section within an orchestra, or a steno pool, or any sort of pool of resources sharing similar skills. A multi-skilled team is empowered to act as a collective. A group of people with similar skills will not achieve the sorts of benefits I’ve listed above for a small team.

Note that a multi-skilled team is also often referred to as a cross-functional team.

“With Effective Leadership”

A team can be self-organizing, but it cannot generally be self-governing. Some leadership can be internal to the team, and some of it can come from outside the team, but effective leadership is generally required in order for a team to be consistently productive. The product development team needs its Steve Jobs. The jazz band needs its Miles Davis.

Ineffective leadership comes in several common forms. It can be too passive. It can be too self-absorbed, ignoring signals from the team itself, from its customers or from its partners. It can be too diffuse, consisting of too many leaders, from different functions and/or levels, who are not in alignment with each other.

Certainly one of the important functions of leadership is to make difficult decisions concerning the team’s direction. Sometime this involves saying “no” to some options that the team might otherwise pursue, if left to its own devices.

“Focused on Delivering a Product of Value to a Customer”

There are four important but closely related elements that I’m grouping together here:

  • Focus: the entire team must be focused on a common goal.
  • Product: A concrete product forces hard decisions to be made, and forces the team to actually produce a tangible result.
  • Delivery: The team must deliver something in a limited timeframe, again enforcing a degree of discipline.
  • Customer: The product must be something of value to a real customer. Without the ability to visualize such a recipient, it is hard for the team to make the sort of often difficult trade-off decisions involved in any important work.

Note that a cross-functional team focused on delivery of a single product is sometimes referred to as an Integrated Product Team(IPT).

Important Team Characteristics

Let me give further emphasis to a couple of important team characteristics.

First is the cultivation of and adherence to team norms.

Software development is by its nature a particularly solitary activity. Much of the work involves one programmer, one keyboard and one computer. And the quality and quantity of the work being done in this way is often hard to observe directly.

This is one reason why Watts Humphrey commented:

Trying to change the behavior of software engineers is like herding cats. They are very independent people; they all have their own ideas, and they won’t tell you what they think, particularly if they disagree with you. They just do what they want to do.

Winning with Software: An Executive Strategy, 2002

And so it is often difficult for even the best-intentioned managers and coaches to influence the working habits of individual developers.

However, when a small team is working together to achieve a common goal, and when they are committed to delivering working software within a short period of time, and when they are allowed to self-organize, and when the idea of joint ownership of the software code is promoted, and when they agree on a definition of what it means to say they are “done” with a piece of software, then it turns out that the team itself is much more effective at enforcing common norms than is any outside agency.

When considering team implementation, it would also be wise to consider the Core Design Principles for Teams, as defined by Nobel Prize Winner Elinor Ostrom and evolutionary biologist David Sloan Wilson.

Another important team characteristic deserving of further emphasis is that of diversity. Research has demonstrated that teams with diverse perspectives and backgrounds tend to produce better results, even if the discussions within such a team tend to be a bit messier and less straightforward.

In one of our studies, we compared homogeneous and diverse groups trying to solve a murder mystery. The diverse groups reported that they didn’t work together very effectively, and they were less confident about their decisions than the homogeneous groups, yet they consistently outperformed those homogeneous groups.

What Can Be Debated

I’ve tried to summarize above many of the key learnings about effective teams that I’ve gleaned over several decades, based on my experience working as a team member and team leader, and also based on my observations and broad study of the topic in multiple contexts.

But, of course, in this brief overview I’ve just scratched the surface of the subject. Whole books have been written on the topic of teams. There is lots of room for discussion and debate on the various elements of teams and team building.

What Cannot Be Debated

At this late date, it’s probably not useful to waste time debating whether teams like these are important.

Some would say that there is “magic” in such teams, but I think it’s probably fairer to say that there’s not much of lasting value produced without such teams.

Wherever we look today, especially when we dig beneath the surface of any of our modern success stories, we find abundant evidence of the operation of teams that fit the description I’ve provided above.

Heck, I’ve so far avoided any mention of sports, but I think much of our obsession with this endeavor can be traced back to the importance of teams in our society. Every game day we see this fundamental reality played out on the field in front of us – with all of the corporate and societal trappings stripped away – laying bare the workings of two teams, with their members, their diverse skills, their leaders, their activities, their collaboration and, ultimately, their results, all there for us to observe and discuss.

Implications for Your Organization

Much of what I’ve said above is probably fairly non-controversial.

And yet…

What are the implications for the larger organization?

It is probably not too much of a leap to say that successful organizations will be those who do the most to foster, sustain and nurture such teams.

Yet how many organizations embrace this truth as one of their core operating principles?

Instead leaders of large organizations often seem to lose grasp of what’s going on within their teams, and as a result lose track of the effects their decisions may have on the operation of these teams. After all, if leaders observe the business norms of interacting only with those immediately above, below or adjacent to them in the organization, with only occasional ceremonial contact with any working teams, it is all to easy for them to insulate themselves from first-hand knowledge of what’s happening at this level of their organizations.

I think this is one reason why the the videos on Spotify Engineering Culture have been so popular. There are a lot of great ideas here, but many team members simply seem to like the fact that a major company thinks their teams are so important that they will release content entirely focused on the way their teams function.

Let me return to my original assertion:

At the core of most of the important work done in this world you will find a small, multi-skilled team with effective leadership focused on delivering a product of value to a customer.

If this is true, then you need to ask yourself: what is your organization doing today to create, nurture and sustain these sorts of teams?

For more on this topic, see the Pagan Tuna post, “The Power of Diverse Teams.”

For more on the topic of teams, see the following Pagan Tuna posts:

Prior to Steve Jobs’ return to Apple, there was a decent centralized usability team equipped with those fancy rooms with one-way mirrors and video cameras. I’m certain these folks did significant work, but when Jobs returned, he shut it down and he cast the design teams to the wind. Each product team inherited part of the former usability team.

Now, I arrived after this reorganization occurred, so I don’t know the actual reasoning, but I do know I never saw those usability labs used once and I would argue that in the past decade Apple has created some of the most usable products out there. My opinion is that the choice to spread the usability design function across the engineering team was intended to send a clear message: engineer and designer need to party more… together.

I can’t imagine building a team responsible for consumer products where engineers and designers weren’t constantly meddling in each other’s business. Yes, they often argue from completely opposite sides of the brain. Yes, it is often a battle of art and science, but engineering and design want exactly the same thing. They want the intense satisfaction of knowing they successfully built something that matters.

No man is more important than The Team. No coach is more important than The Team. The Team, The Team, The Team, and if we think that way, all of us, everything that you do, you take into consideration what effect does it have on my Team? We’re gonna believe in each other, we’re not gonna criticize each other, we’re not gonna talk about each other, we’re gonna encourage each other.

Bo Schembechler, Legendary University of Michigan Football Coach, addressing his team in 1983

Next: Govern Wisely