How the Best Teams Solve Problems

by Anca Metiu , 20.11.12

Imagine a string quartet performing a piece of music. They all share a common goal, and they each know the part they have to play. But in order to perfect their performance, they must be attuned to what their colleagues are doing and respond to it in the right way. They must listen as well as play, so they can engage with the task as a group as well as individually.

We can see a similar dynamic in workplace groups such as product-development teams. To solve problems and reach their goal, they need to engage with each other and develop a mutual focus of attention on the task at hand.

Most previous research has focused on what a team as a whole needs to succeed: clearly defined goals, the right skills, a way to resolve conflicts and proper support. There has been much less focus on how team members actually solve problems and make progress – even though this may be what makes the difference between an effective team and an underperforming one.

To learn more about the way team members solve problems, we studied two software development projects, both in the same Fortune 500 company, called ‘Shield’ and ‘Gateway’. The Shield team were working on a solution for tracking and protecting digital property rights online, while the Gateway developers were building a product to deliver rich content and documents on mobile devices.

We sat in on each team for several weeks, observing how people approached their work, chatting to them about it and occasionally interviewing them in a more structured way. Then we analyzed our notes to identify the main ways in which people developed and sustained group engagement.

The two projects had many things in common. Group engagement was important in both: while people had to be highly engaged with their own tasks, interdependence with coworkers was essential, because of the interactive nature of software development. The number of team members, their ages and their educational backgrounds were also similar.

However, there were important differences too. Both teams used contractors, but while Shield’s were located remotely, in Bangalore, Gateway’s worked in-house. Another contrast was in terms of the number of interactions between developers: at Shield, we often saw small groups of developers working together, but this was much rarer at Gateway. Moreover, Shield developers spent a lot of time interacting informally, while Gateway used more formal meetings. Finally, Shield developers had a strong sense of compelling direction about their project, while Gateway team members felt much less sense of purpose.

One of the main findings of our comparative study was that when one examines the work done in a team, the relevant level unit of analysis is not the team as a whole, but the interaction episodes occurring among smaller, temporary groups of two, three or four people that emerge quickly in response to the task at hand and that solve problems effectively. Thus, our work identified the ‘micro-processes’ that drive group engagement – specifically, the way people develop and sustain a mutual focus of attention. Looking at the way both teams worked, we found three factors that helped to develop a strong mutual focus of attention and enable people to solve problems more effectively.

First, when small groups are focusing on a problem, they go into a ‘task bubble’. Team members who aren’t involved – ‘outsiders’ – understand that they are working intensely on a particular problem, and leave them alone. However, people decide for themselves whether they are ‘insiders’ or ‘outsiders’. If they feel, having watched the interaction for a while, that they have a contribution to make, they step right in and make it. The task bubble is semi-permeable: it keeps irrelevant outsiders out, but lets relevant outsiders in.

At Shield, we saw task bubbles helping to develop and sustain mutual focus of attention and people correctly deciding whether they were insiders or outsiders. At Gateway, the presence of contractors created internal tensions, because the distinctions between insiders and outsiders were far more rigid.

The second factor is the use of task-related artifacts such as whiteboards, computer monitors, documents and so on. Objects like these help people to understand and focus on the task. Some researchers argue that people need to be physically close for artifacts to work, but we found that people could still collaborate effectively by focusing on artifacts such as computer files while working remotely and interacting by phone or instant messenger.

Shield developers used task-related artifacts very intensely – for example, by physically touching computer screens to point out particular lines of code, or drawing together on the same whiteboard. Similar artifacts were used at Gateway, but people engaged with them far less. During formal meetings, artifacts such as PowerPoint presentations were used, but they were not interactive enough to engage people in a mutually focused way.

The final factor we identified is shared emotion, which is both the result of mutual focus of attention and a reinforcer of it. When people overcome a problem together, they share a moment of pride, satisfaction or elation and experience an energy boost that helps them continue with their work. Sharing positive emotion also creates a bond that makes it easier for people to work together in the future.

Why did Shield have more of the factors that help develop mutual focus of attention than Gateway? We found three conditions that make group engagement more likely.

The first was individual engagement. This happens when people feel a genuine love for the work being done, and put an intense effort into it that often spills over into leisure time. We found many highly engaged individuals at both Shield and Gateway – but individual engagement on its own is not enough to create group engagement; other things come into play.

The second condition was interaction level, which has two dimensions: frequency and informality. Frequency means that the more often people interact, the higher the level of mutual focus of attention. This is not surprising – people can’t engage with one another if interactions simply aren’t taking place. We found that interactions were much more frequent at Shield than they were at Gateway.

When interactions are more informal, people feel more comfortable sharing ideas, expressing enthusiasm and doubts, and getting into a task bubble so that unguarded, free, creative exchanges can happen. In contrast, formal meetings are more focused on giving out information rather than dialogue. Interactions at Shield were much more informal than at Gateway. We also found, interestingly, that Shield developers became more interactive and informal under pressure, while Gateway people responded to pressure by focusing on their individual work and using even more formal interactions.

The final condition is a compelling direction that inspires and motivates people to work hard on group tasks. At Shield, a strong sense of direction gave developers real energy and passion for their work, while at Gateway, developers seemed slightly baffled about what they were doing, and why.

The fate of the two projects tells its own story: Shield was successful and became a spin-off company, while Gateway’s product never saw the light of day and its developers were moved on to other projects.

Our research contributes to the understanding of groups by identifying the microprocesses that drive problem solving and high performance. Teams are being used more and more in organizations, and our findings can help managers identify the conditions and approaches that will help their teams solve problems more effectively.