The team is at the core of agile practices and frameworks: “team of experts“, “development team“, “product team“, “squad“, etc. Software development requires the work of a team, as individual work can only get you so far.

But is that assumption correct? To answer this question, I looked into organisational psychology and group dynamics research. The next series of posts will present what teams are and conditions for team effectiveness .

This post holds the conclusions presented by Harvard Professor Richard Hackman, a world-leader researcher in group performance, leadership effectiveness and self-managed teams. His signature books are Leading Teams: Setting the Stage for Great Performances (2002) and Collaborative Intelligence: Using Teams to Solve Hard Problems (2011).

What is a team?

Is a group doing an activity together a team? What are the conditions that need to be met for a group to be considered a team? Hackman’s  extensive research (in industries such aerospace or intelligence) presents seven types of groups. And not all of them are teams.

 

Out of the seven types of groups above, only one is an actual team. Let’s see which one.

  1. Community of interest:
    • Are forums for people interested in the same topics or ideas
    • They create connections among people who wouldn’t otherwise meet or interact
    • Example: community of people interested in birds.
  2. Community of practice:
    • Professionals from different domains exchange knowledge and information relevant to their organisational work, even though it’s not part of their job to create or improve the community
    • Example: disrupt HR, which has as objective to improve the people and operations practices in all organisations.
  3. Emergent collaboration:
    • Professionals that coordinate their activities to improve policies and practices in their area of expertise
    • Any change in those practices are done by checking in with the members of the group and getting their input
    • Example: a change in the Scrum guide is done by members in the Scrum professionals community that are highly involved and engaged to improve the practices.
  4. Coacting group:
    • A set of people who operate in parallel but don’t have collective accountability over the work result
    • Example: separate groups work on different part of the product  but none of them has accountability over the final, complete result. Sounds a lot like any waterfall methodology out there.
  5. Distributed team:
    • These are virtual teams: the group has accountability and responsibility for the final product, but members do not interact face-to-face
    • Example: WordPress, Basecamp are some of the most popular fully distributed teams companies.
  6. Project Team or task force:
    • These are temporary teams, put together to complete a specific piece of work by a specific deadline, and they are dismantled when the work is delivered
    • Example: most project-based teams.
  7. Semi-permanent work team:
    • The last category is the only one that can be considered a real team. This category has a defined task that remains the responsibility of the team for an indefinite period of time
    • The membership of the team changes over time, but the team is not dismantled and it continues to stick together
    • Example: feature teams, Scrum team.

Groups can evolve over time from one collaboration form to another, so it’s never all set in stone (e.g. groups that start as temporary project teams that stay together when the project’s scope expands into business as usual).

Why is the last group type the only one that can be considered a team? The main differences between semi-permanent teams and the other groups are that (1) they stay together, (2) they grow and learn together, (3) become more effective over time. I will have a set of separate post on what makes a team and how a team can become most effective.

But… do you need a team?

The answer is: it depends. There are some things that can’t be done by a team – e.g. driving a taxi – and other things that can’t be done without a team, such as football (playing football by yourself is quite ineffective).

But if things are not as straightforward, how can you decide when you need a team and when you don’t? Hackman suggests that, before figuring out the answer to this, we should look into why most organisations assign tasks to teams:

  • They make the assumption that teams always produce higher-quality products than individuals. They don’t (it depends on the nature of the task).
  • Managers do it to distribute their accountability to the team.
  • Managers do it to engage people and increase their commitment to the product or decision the group needs to produce.

Trying to remove these biases regarding teams, you need to have good reasons to create a team, and those reasons should be explicitly named.

When you need a team

Working with a team has multiple benefits: higher variety of skills and knowledge, more resources, higher flexibility (if one individual is not available, someone else can do the job).

More individuals also means putting together different experience, knowledge and skills. A group that works together, grows together and is able to build on these differences to create “magic“, extraordinary quality or innovative products that are hard to be done by an individual alone.

You need a team when:

  • The scope of the tasks is wide, so you need more individuals to get it done.
  • Tasks are more meaningful and more consequential, thus fostering motivation.
  • You need more diverse skills and perspectives to get the work done, and you need the individuals having these skills to work together interdependently.
  • You can easily set direct two-way communication with the client of the work, to get feedback that can improve the team’s performance (feedback being essential for the team to grow and deliver higher quality).
  • Getting the work done requires working and communicating interdependently.
  • You need flexibility to keep pace with a rapidly changing context.
  • You want individuals to hone their personal capabilities through interactions with others.

When you don’t need a team

It’s easy to just toss a team together, out of habit. Do you have good reasons to create a team and can you explicitly name those reasons?

Creating a team requires extra effort and leadership attention so if you don’t check in (at least some of) the reasons why you need a team, maybe you have different options.

There are a few examples when you definitely don’t need a team:

  • Creative composition; the research shows that even creating a collectivistic mindset can compromise creativity. I’m including here copywriting.
  • Writing committee and task force reports; they quality is higher if it’s done by a talented individual.
  •  Executive leadership. Hackman raises the idea that “successful organisations almost always are led by a single talented and courageous human being rather than by a team, no matter how much potential the team has”. It would be interesting to look into this topic in relation with teal | flat organisations (subject for another post). 

How you can apply this learning in practice

First, check at your tasks and team structure. Do you actually need teams or you can use a different group category or better yet, can an individual get the task done?

Every time you have the impulse to “put a team together to work on this” check out the conditions of forming a team, can you explicitly specify why you’re forming the team?

If you do need a team, you can create the right conditions for the team to reach high performance. This will be the subject of following posts on team effectiveness.

 

Sources:

  1. Richard Hackman, Leading Teams: Setting the Stage for Great Performances (2002)
  2. Richard Hackman, Collaborative Intelligence: Using Teams to Solve Hard Problems (2011).