Anton du Toit

A cohesive team is great to be in. There is energy and focus within a cohesive team that makes the team stand out from others. Not only does it feel good, but cohesion has been shown to be related to a bunch of good things: team performance, team efficiency, team members putting in effort out of hours, lower absenteeism. So what is the magic of cohesion, and how can you get some for your team?

First, what do we mean when we say “cohesion”? As is often the case, the most vivid expressions come from people we’ve worked with:

 “[Cohesion is] .. when you stay up late or back at work to get something done, because you know the people you are working with are doing the same, and YOU ALL need to get the job done.”

– Participant in Science of Teams workshop at AgilePT, Porto, May 2015

We all have a feel for what cohesion looks like in practice, but in order to assess it and work with it, it’s important to note that it comes in two different flavours:

1. Social cohesion is probably what people first think of when you mention cohesion. It’s a shared liking or attraction to the group, emotional bonds of friendship and caring among group members, and enjoyment of each other’s company. This is the team that has lunch together because they want to spend time together, this is where the team members talk about how great the team is, this is where you feel good about working in the team.
2. Task cohesion is a team’s shared commitment to their goal, as well as motivation to coordinate team efforts to achieve common work-related goals. Teams that have people that don’t particularly like each other, but nevertheless work hard together to get the job done, are high on task cohesion. This is the team where everyone wants to achieve the team goal and puts in the effort to get it done.

So which kind of cohesion was our workshop participant from Portugal talking about?[1]

Out of the two types of cohesion, social cohesion is easier to instil in your team. But while social cohesion does contributes to productivity and efficiency, task cohesion contributes more.

Getting some cohesion

• Suppose you have a team with people who don’t know each other that well. How can you build the cohesion they need to form an effective team? Let’s start with some social cohesion. Pair people off; they’re going to talk to each other for 10 minutes, then move on to another pairing. The task of each pair is to discover as many things that they have in common as possible (from both inside and outside their working life).
• Task cohesion is tougher. Clarifying shared goals is an effective way to build task cohesion. Using the “Product box” method, where the product is the team, can do this in an enjoyable way. The team also ends up with a handy artifact they can use to decorate their work area.
• Another way to increase task cohesion is to use group-based rewards, not individual ones.

[1] It was task cohesion, but there’s also a bit of social cohesion implied in the reason giving for working back, i.e. that the others in the team are doing it too.

‘Team’. It’s such a buzzword. Or has it passed beyond that, to be a word that we hardly even notice anymore? Anyway, the fate of most buzzwords is to be used so indiscriminately that they become meaningless, and that’s what we think has happened to the word ‘team’. It’s now used to mean any group of people who work together, on any task, of any nature; or even just people who work in the same organisation.

This is wrong, misleading, and unhelpful. It hides a very important distinction between teams and non-teams ..

Consider these three groups of co-workers:

• A group of sales people who sell the same range of products, in different territories.
• A group of workers in a tech support call centre. If they cannot solve the problem themselves after ten minutes, they ‘escalate’ the call to another worker.
• A group of people working on a software project, including developers, statisticians, business analysts, user interface experts, and end users.

Which of these groups would you call a team?

Our take on the question:

The first and second examples are not teams, because the people in them essentially work independently of one another — even though they may work in the same physical space, doing the same thing. It is possible for a person in either of these groups to help another worker, of course, but they are not dependent on one another to achieve their goal. A sale is made by an individual, and a tech support ticket is closed by an individual.

The software development team is different. They are a team, because the success or failure of the project depends not only on all of the team members doing their own jobs, but also on their co-operation. They literally cannot do the job of building the product by themselves.

So, for a manager or team lead, a fundamental question is whether her people work as individuals, or as a team. This leads to important consequences for how people should be managed. A manager of a group of individual workers needs to manage them as individuals. In contrast, a team leader needs to pay more attention to the processes that happen ‘in-between’ the individuals in the team, and the states that occur ‘across’ the individuals in the team.