How To Build A Team

When I went to school, there was a lot of emphasis on the individual: on learning to think well on our own. That’s a critical skill, and we won’t get far without it. But what I didn’t see as much emphasis on was how to build a team (and, along with that, the importance of teamwork).

When we start working in teams, we need to be able to think and solve problems not just on our own but as a member of a group — to think together.

A lot of the work I do is helping groups think together. So I’ve developed my facilitation skills, learned about group process, and established team building practices that help get groups working and thinking together. Even today I’m always on the lookout for methods and exercises to use in retrospectives, planning, problem solving and other group processes.

But methods, exercises, and improved retrospectives aren’t a silver bullet for getting us to work, think, and act collaboratively. Before we can tap into the benefits of teamwork, we need to build a team.

It’s not as easy, or as simple, as it sounds. But teamwork in the workplace is essential. So how can we thrive not only as individual contributors but as teams? I’ll share the 3 key steps to team building below, but first let’s talk about what a team is (and isn’t).


What Is A Team?

Let’s start by taking a look at what a team is.

Some time ago, Abraham Lincoln said the following:

“If you call a tail a leg, how many legs has a dog? Five? No, calling a tail a leg don’t make it a leg.”

Calling a tail a leg does not make it so.

The same can be said of teams.

I hear the term “team” used for any group of people who share almost any common characteristic. In some organizations, functional groups are referred to as “teams” even though the people in those groups don’t work on a common project. People use the word “team” even when their work isn’t interdependent or aimed at creating a whole product.

The emphasis on teams goes to show that people believe in the importance of teamwork in the workplace. But merely using the word “team” isn’t enough to tap into the benefits of teamwork.

If a team is what you need, then you have to build a team. Simply calling any old group of people a team and then expecting teamwork and collaboration is, unfortunately, not how it works. And, if your performance appraisal methods don’t align with teamwork-based work, it will only be that much harder.

A team is a social organization, a group of people who work collaboratively to accomplish some goal. Every team is a group of people, but not every group of people is a team. You don’t need to build a group, but you do need to build a team.

Some work is much better done by a team, some work needs a group, and some needs many same-skilled individuals. It depends on the how interdependent and tightly coupled the work is. Building teams takes energy and commitment–both from team member and managers.  If the work doesn’t require cross-functional collaboration on a day-to-day basis, the work doesn’t need a team. (But beware of inappropriate serialization.)

Teamwork Criteria

In order to be a team, a group needs to fit these criteria:



  • Share a compelling work goal, and that goal is well-understood by all members of the team. Some person(s) in the organization eagerly await the product the team is producing–else there is no reason for the team. Without an external goal, a group may form a social unit, but they are not a team.
  • Have members who are mutually accountable for achieving the external goal. They understand the importance of good team communication as a means to achieving this. Team members do focus on completing their work, but they know that completing individual tasks–by themselves–isn’t enough for success. Members understand the importance of teamwork and that success comes from achieving the overall team, not just the individual, goal.
  • Are doing interdependent work that requires the skills of all to create a finished product. Their skills are complementary and it is the combination of their skills that enables them to reach their goal. It’s not like a ski team where everyone has the same skills, and the team result is the sum of individual scores. On a team, the results aren’t additive; they’re integrative, generative, and collective.
  • Have a shared approach (though not a rigid process). Team members make agreements on how they will work together. They choose methods that fit the work and the goal. They evaluate those methods with retrospectives and other tools such as calculating their meeting return on time invested (ROTI). They need enough constraints on their process so that they can work creatively, avoiding both anarchy and stifling routine.
  • Almost always have fewer than ten members. Some say five is the sweet spot. When there are fewer than five members, there’s not much sense of teaminess. When there are more than ten, the work is so big that it breaks on along natural lines…and so do the people, falling into sub-groups that act more like a team than the bigger unit. The benefits of teamwork are harder to capture in a team that is far too small or far too big.
  • Have shared history/identity. This implies that a group is not a team on it’s first day together. It also implies that shaking up groups every few weeks or months ensures that you’ll never really build a team and achieve one of the main advantages of teamwork: the surpassing results that cohesive teams are capable of.

How Do We Turn Working Groups Into Teams?

Sometime around 429-347 B.C.E., the Greek philosopher and writer Plato said:

“The beginning is the most important part of the work.”

All these years later, that’s still just as true. And especially for team-based work.

I’ve written several articles about the roles and responsibilities of middle level management. A manager’s relationship with a team as they work is essential for cultivating a self-organizing team and maintaining a link with the organization. But a manager’s role in growing effective teams starts long before the work actually begins–it starts from when they decide to build a team.

Over the years, I’ve personally seen how important the initial phases of team creation and team design are for successful teamwork. My experience with the Retrospective Facilitators Gathering (RFG) in particular has shown me that. To tap into the benefits of teamwork, we need to get teams started on the right foot.

How To Build A Team In A Self-Organizing System

In 2002, I started the Retrospective Facilitators Gathering (RFG) with Diana Larsen and Norm Kerth. Each year, a different set of volunteers organize the Gathering. Each year, we must come together and build a team. Continuity comes from linking the immediate past organizer, the current year organizer, and the next year organizer as part of the organizing group. Most years that’s worked reasonably well.

We’ve used lightweight planning and a marketplace for sessions from the start. But over the years, I and other organizers learned more about self-organizing systems. We lightened our planning even more. We planed the parts that need planning– the venue, and supplies, for example. Those aspects that don’t need close planning emerge organically.  But what emerges depends on setting the initial conditions, and attending to containers, differences and exchanges.

Some time back, I reflected on all my years with RFG. Based on a decade of experiments and experience, I identified some key considerations for setting the conditions for effective team building in self-organizing social systems. They are:

  1. Initial conditions shape interactions for the life of the group. Small actions can have a big effect on teamwork, particularly those that amplify the sorts of differences that create division.
  2. When structures and espoused values contradict each other, people sense the incongruity and respond–often in incongruent ways. Consistency from the get-go is a key component in effective team building.
  3. The more people in implied (“organizers”) leadership positions take responsibility for the decisions and welfare of the group, the less responsibility the group will take for their own decisions and welfare. Leaders, formal and informal, need to make space for others to shine.

The initial conditions and beginning phase of the team building process are very important. So, that’s all there is to it then, right? Set the team up right, facilitate a kick off meeting, and then, since teams are self-organizing, they’ll be able to manage on their own with no problems at all.

Not so fast.

Let’s take a look at some misconceptions about self-organizing teams.


Misconceptions About Self-Organizing Teams

At a recent conference, I overheard three managers talking about self-organizing teams.

“You can’t just turn people loose and let a team make all the decisions. They’ll mess things up. And with all these Scrum Masters, Agile Coaches, and self-organizing teams, sounds like I’m out of a job,” said one with resignation.

“This time boxing thing is great,” said another. “Put them in a room, turn up the heat, and they’ll perform,” said a second manager.

“Wow, this means I can move people around based on projects, and they’ll just form and self-organize. I can have rolling, ad hoc Scrum teams!” crowed a third.

Time to rectify some misconceptions.

  • #1. Self-organizing teams are completely autonomous, self-managing, and don’t need managers.
  • #2. All you need to do to build a self-organizing team is provide a goal and apply pressure.
  • #3. Since the team is self-organizing, they can accommodate moving people on and off the team easily.

Misconception #1: Self-organizing teams don’t need managers.

There’s a reason we use the term “self-organizing” rather than “self-organized” or “self-managed.” That’s because it’s a process and a characteristic, not something that is done once and for all. Self-organizing, from a social systems perspective, only means that the team can create new approaches and adapt to meet new challenges in their environment.

Self-organizing Agile teams do have (bounded) authority to make their own commitments, organize and assign their own work. They craft appropriate strategies to accomplish their goals and make decisions with (again, bounded) economic and organizational impact.

But they are not out there on their own, disconnected from the organization. Self-organizing teams leverage the benefits of teamwork to produce a product or service that is valuable to the organization and its customers. They are accountable to make their progress visible and work within financial boundaries. Self-organizing teams may also be self-managed, to one degree or another.

To build a team, managers must create the conditions that enable teams to thrive and continue to self-organize. Managers need to work across the organization to create a work system that enables teams to deliver value to customers and the organization. And managers need to work with the team to set appropriate boundaries and constraints. Managers still act as agents for the corporation. Therefore, they still must be involved where there are legal or fiduciary responsibilities.

Misconception #2: Time boxing forces any group to become a team. Put a group of people together, hand them a challenge, and you’ll immediately see effective teamwork.

I wouldn’t bet on it, and neither should you. Teams do need a clear and compelling work goal. Without that, there’s no reason to form a team. They also need the technical skills required by the work and interpersonal skills to work as a team. They need resources such as tools and access to information and education. They need a connection to the larger organization.

The pressure cooker method of team formation will more likely burn people out than result in the productivity of a real team. Calling a group a team and turning up the heat doesn’t make it so.

Time boxing is one of the structures than can help teams succeed by providing focus. Working in time boxes creates a natural rhythm of feedback and connection to the team’s purpose. It can be a helpful tool when trying to build a team. But a time box and goal, in and of themselves, don’t create a team.

Misconception #3: Self-organizing agile teams should be able to accommodate frequent membership changes. After all, they’re agile aren’t they?

Teams need time to develop the strategies and trust that enable high performance. They need time to establish the key elements of teamwork: understanding each others strengths and weaknesses, developing shared knowledge, and learning how to learn together.

When new people constantly arrive and leave, a group may never be able to tap into the benefits of teamwork. They’ll be less likely to develop the shared approaches and shared knowledge that permit them to outperform a group of individuals.

Some teams—when they’ve had time to form and create a strong team culture—do become adept at adding new members. Even then, it’s best to limit the number of new members added at any given time. Changing more than 30% of team membership causes the team to reboot. Constant turnover prevents a team from truly forming.

As a manager, you can help by keeping teams together long enough to gel and by protecting teams from the revolving door syndrome. Long-lived teams are more able to see the advantages of teamwork (more on that below).


Self-organizing teams are not teams gone mad. Like all teams, they need a compelling goal, skills, information, and enough time to form and perform. And they still need managers to create a supportive context, set appropriate boundaries and constraints, and connect the team to the organization.


The 3 Steps To Effective Team Building

So how exactly do we set teams up for success? It begins in the team formation stage.

The 60-30-10 Principle

J. Richard Hackman, has been studying teams for decades. One of his most significant findings is the 60-30-10 Principle: 60% of the variation in team effectiveness is attributable to the design of the team, 30% to the way the team is launched, and 10% to leader coaching once the team is underway. By team design, he doesn’t just mean picking the best people. When you build a team, you also have to think about the nature of the work, articulate a goal, and plan for enabling supports.

Team Design: Aim for Flexible, Long-lived Teams

You can call a group of people a team the first day they come together, but that doesn’t mean they’ll achieve teamwork right away. Team building takes time. People need time to understand each others strengths, weaknesses and work styles. They need to agree on, try, and adjust the way they work together to find their groove.

In many organizations, managers do understand the importance of teamwork. They form cross-functional teams to meet the needs of a specific project. In some cases, that means the team will be together for a long time. More often it means teams will be disbanded after a few weeks or months. Though managers may understand the benefits of teamwork, short-lived teams don’t have anywhere near enough time for to gel and gain from the benefits of teamwork. Therefore, aim for longer time horizons when setting out to build a team. 

Effective Team Design

Analyze the work that’s in the pipeline (including the work that’s non-value added but necessary). Aim to organize the work so that teams have “whole” work–creating a product or service that has meaning from a business perspective. Look at the trade-offs and tensions inherent in the product. Make sure people who represent those aspects are part of the team. Look for dependencies and to the extent possible, keep them within a team boundary. Form teams that have the breadth of skills to handle a broad range of work.

Then, bring work to the teams, rather than reforming teams for each new project. You won’t find a team that’s perfect for all the work in the pipeline. When teams lack a specific expertise, keep the core team in tact and add expertise.

Team Launch: Articulate a Compelling Goal

An effective goal statement does two jobs. First, it focuses the attention and effort of the team. When the team has a shared understanding of what their task is, they pull in the same direction. When teams don’t have or agree on a goal–or the goal is so vague it’s open to many interpretations–teams experience the opposite of teamwork: members waste time and brain cycles arguing, work at cross purposes, or do the wrong work entirely.

Second, a well-formed goal engages the team in a meaningful challenge. An effective goal provides a sense of purpose to the teams work and accelerates the crucial initial team building phase. The goal might be solving an important problem, enabling business, launching a new product, or meeting a  customer need. State the goal in a way that taps into purpose.

Take the goal handed down to the FinCore team: “Maintain the FinCore Product.” That goal isn’t enough to get someone out of bed in the morning. It talks about a process (maintenance), but leaves out the purpose. It misses the opportunity to tap into pride-in-work.  A more compelling goal might be:

Sustain the FinCore product by adding necessary functionality and ensuring the technical integrity of the code, so we can provide uninterrupted service to 40,000 customers.

Not all work is exciting and sexy, but all work should have a purpose. Making that clear from the start when you build a team will help people focus and engage.

Side note: defining and reinforcing team values will help get your team started on the right foot. For more on that, head to my post on Team Values, Team Norms, Working Agreements, and Rules.

Team Support: Pillars of support

The right people and a compelling goal are a good start to successful team building. But if you neglect the pillars of support when you build a team, they may still wallow. The pillars of support are:

Information related to the situation, domain, problem and technology. These reinforce the goal and provide the context for the team to make good decisions.

Pillars of team support

Material support, such as machines, tools, facilities, adequate budget, and supplies. Adequate material support communicates that the work of the team is important. Starving a team for resources undercuts the goal and creates cynicism. Paradoxically, providing too much isn’t good either. A certain level of constraint can drive creativity (and over constraint kills it). 

Expertise to supplement the knowledge and skills of the team when needed. Even when the team has all the skills required by the task, they may need an expert eye for consulting or reviewing. Sometimes there is some aspect of the work that requires scarce knowledge. It may not make sense to develop that knowledge on the team, or it may only be needed for a short time.

Feedback loops that connect the team to the organization. Regular demos of working software allow the sponsor or product owner to see how the team is doing–and allows for course correction. The heartbeat of progress builds trust.  

If any one of these pillars is missing, you’ve put the team at a disadvantage. That’s why it’s crucial to have these pillars in place when you set out to build a team.

This Sounds Like More Work for the Manager. Why bother?

Team design is a pay me now, pay me later proposition. It’s a myth that team formation means you can simply throw a group of people together and see effective teamwork immediately. Strong teams don’t just happen by some magic chemistry. It takes effort to build a team. But well-designed teams are more resilient. They make better use of the knowledge, talents, and skills of team members. They function and stay on track with relatively little management intervention.

You may not always be able to bring together the perfect team. But with the right initial team building strategies in place, you can set a team up for success. Or failure. It is up to you.