The word “team” invokes very positive feelings in people. We associate it with working together towards a shared goal, as in sports. But if we look at the way these groups work in most workplaces, we often find that they really don’t match with what the literature means with a real team.
There are two primary ways to coordinate the collaboration inside a group of people working towards a shared product – workgroup and team. It’s a spectrum, to be precise, but we’ll look at the extremes. I’m also including a “bad workgroup” column, to emphasize that I’m trying to compare two good approaches for organizing groups, rather than “team trumps all others”.
Please keep in mind that in the table I am talking about the same group. In all columns, we have a group with the same external purpose, the same members, and the same externally recognized leader/manager. We will also assume that the group is small, because teamwork does get difficult with group sizes exceeding nine people. The only thing that differs is the way the group organizes and operates internally.
|Bad workgroup||Good workgroup||Team|
|Individual goals (at the expense of shared purpose)||Individual goals
(as a means to contribute to shared purpose)
|Shared goal (that transcends individual contributions)|
|Appointed leadership, negative relationship, intentionally avoiding interaction and support||Appointed leadership, good relationships and helpful to each other, but avoidance to step into other people’s areas of responsibility||Emergent leadership|
|Individual behaviours, little interest to resolve conflicts, everyone stays at their turf||Individual behaviours, separation of concerns/ownership as the preferred way to resolve conflicts||Shared behaviours, alignment of behaviour as the preferred way to resolve conflicts|
The first line talks about what we are emotionally connected to as the focus of our work. In a workgroup, people are seeking to (and want to) build a shared outcome, but they perceive their own goal through their own contribution. We might fail, but if I felt I did my part just fine, I don’t feel that I failed – it was someone else’s fault. In a bad workgroup people obviously don’t care much about the shared outcome, as long as they can’t be blamed for the failure.
But in a team, people are emotionally connected to the collective outcome. They don’t care much how they contribute at a given time, as long as what they do is good for the shared goal. Obviously, most of the time people still work within their expertise (since that’s where they are most useful), but they don’t mind doing other things either. If we fail, we fail together and no single member would claim “it wasn’t me, I did my job.”
On the second line, the “appointed leadership” means that someone outside the group “appointed” someone to be the leader of the group, and that leader then “appointed” others within the team to be leaders of some role or component. Like “design”, “design lead”, “architect”, owner of front-end or back-end, or tester. While they still want to win together, members in a workgroup avoid pointing out problems they see in other team members’ areas – usually out of respect.
In a bad workgroup, people are actively silent about the problems they perceive in other members’ responsibility areas. They are possibly even hoping that the others fail, so that they would look better in comparison. People would also seek to avoid taking any responsibility, even if asked, beyond their immediate responsibilities.
On a team, leadership is emergent.
Since everyone prioritizes the shared goal over individual goals or ownership, members point out possible problems also in other members’ areas of contribution. The leadership also passes fluently from a member to another, as people decide which action is necessary to address the problem. For example, a designer might ask about some possible problem in the way the team is testing some functionality, and a tester then picks up the action to address it. People are also willing to act in other members’ areas of contribution.
The third line talks about how conflicts are resolved. For example, if some code level practices conflict between people, what is the preferred way to resolve that issue. In a workgroup, people prefer to retain their own behaviours and separate concerns instead. For example, the team members might agree to have one person work on one area (like a module or layer, like front-end) and the other person on another area (like another module or layer, like back-end). This is an amicable arrangement, and both will promise to help if the other person needs something in the other’s area.
The downside is, of course, that this adds delays and dependencies. The other person might not be available immediately to help, so the first person would have to pick up some other task for a while. But this is considered less of a problem than aligning the behaviours.
In a team these dependencies and delays are seen as the problem – it slows the team and reduces their ability to reach the goal. The two people would instead discuss how they could work in ways that remove the problem and still allow both to contribute to both areas, as needed. While they still might have their preferred areas, they would still occasionally contribute to the other area. But because they have aligned the ways of working, these contributions do not cause conflicts anymore. This allows the team to be more flexible and effective in reaching their shared goal.
Obviously, not all behaviours are aligned even on the greatest of teams. There are many things where different preferences do not conflict in a way that takes away from the shared goal. So it’s okay to like different kind of coffees, or not like it at all. And so on. Also, being on a team doesn’t mean that people start losing their personality; they just choose to adjust their actions to better suit the overall team. They still retain their preferences outside the team where the preferred practice isn’t harming the team.
In the next post I will explore what impact this choice of coordination has.