Vitaly Sharovatov

In the world of physical labour and tools, the world we face on a daily basis, each tool has a name, a term. Each term not only conveys a specific meaning but also carries an implied model of use, encompassing functionality, limitations, behavioral norms and safety considerations.

If I tell you the term “screwdriver”, you recall the tool, the way how to operate it, and the safety precautions. You recall your understanding of the object associated with the term. Chances are, you know how to use the screwdriver to actually drive the screw into the wall.

If I tell you the term “electric screwdriver”, you might also recall the tool — the object associated with the term. You know it’s used for the same purpose as the screwdriver, but you won’t mistake it with the screwdriver, as both come with different models of usage: you don’t rotate the electric screwdriver with your hand, and you never apply the same force and handling to it. If you do, you might overdrill and damage the material, or even cause yourself an injury, as an electric screwdriver requires much less force than a manual screwdriver.

So the terms are different, each associated with a different tool. Even though both objects’ function is the same — to drive the screws in the wall — each has its own characteristics: price, limitations, models of usage, and benefits.

In the world of tools, people usually don’t mistake one term for another, as it’s clearly disadvantageous or even simply dangerous.

In the world of organizational psychology and sociology of work, terms matter no less.

Inspired by Michele Sollecito, I finally composed my drafts on the topic in a series of posts, this one explores the difference between groups and teams.

All managers I know aspire to create teams, as we all intuitively know that teams are very performant and can achieve something individuals can’t: we admire surgical teams, space mission crews, emergency response teams like rescue teams or firefighters, some of us love to see how SWAT teams or orchestras operate. So what differentiates teams in roles like engineering and QA from these dream teams? Often, it’s that “teams” lack trust, which leads to them functioning more like groups than true teams.

One might say that we have an implicit knowledge of the teams’ significance somehow as the team-based approach was fundamental to our survival and success during the evolution of humankind.

So managers want to have all the benefits of teams. However, in most cases that I know of managers treat teams as groups, and when people are managed as if they were mere groups, we inevitably end up with just that — groups, leading to reduced productivity and inferior quality compared to teams.

In our lack of knowledge, managers inadvertently degrade what they intended to enhance.

Our misunderstanding stems from not grasping the distinction between what constitutes a group and what defines a team. Each term suggests a specific management model.

Teams and groups

The group is a set of people working on some set of tasks while sharing a common goal.

The team is a group of people working together on achieving a common goal, and showing a great deal of interdependence, cooperation and trust.

Teams and groups in history of humankind

I love the example of a hunting group Michele Sollecito brought in his post: there might be a group of hunters splitting the hunting area and working individually. They have the common goal: bring food to the tribe.

Members of the group aren’t interdependent, even if one hunter is killed by a lynx, all others will bring their prey to the tribe.

Members of the group don’t need much trust in each other, they don’t need to cooperate, even more, they might even compete, each trying to bring more prey to the tribe. By the mere design of the group hunting process each group member isn’t incentivized to help other hunters, but rather to bring more prey themselves. The more prey one brings, the better the hunter they are.

This lack of interdependence and trust in a hunting group means that this group can’t have an emergent quality of super-result: they won’t be able to hunt a mammoth.

The group might have a common goal, but the group lacks interdependence, cooperation and trust.

Interdependence, cooperation and trust are the key characteristics different between a group and a team.

If the tribe wants to be able to hunt a mammoth or any other dangerous creature which individual hunters formed in a group can’t kill, a team emerges.

Different members of the hunting team might have specific roles, such as driving the animal towards a certain location, using weapons to wound it, or distracting it to enable others to attack more effectively. Each member’s role is vital to the success of the hunt. Interdependence emerges alongside cooperation. The trust comes along: the attacking specialist must rely on the distracting specialist to do their job, otherwise the attacking specialist will be simply trampled.

mammoth hunted by a neolithical tribe

Members of the hunting team are interdependent and the success of the team effort relies on cooperation and trust; if some are killed, the whole team shutters.

Another great example of team work is very successful at the time army formation, the Greek Phalanx. They also showed interdependence, cooperation and trust: the typical Greek hoplite (a heavily-armed foot soldier) in a phalanx would carry a large shield (called “hoplon”) in their left hand, covering mostly the warrior to their left. Since their own right side was exposed, they relied on the warrior to their right to protect it with their shield. This created a system where each soldier’s safety was dependent on the cooperation and competence of their neighbor. Each soldier trusted the neighbor to protect.

ancient greek phalanx formation reconstructed

The Greek Phalanx team formation showed emergent quality: severely outnumbered, they won the Persians at the battle of Marathon. The Persian warriors were mere groups.

If the army wants to be able to defeat an outnumbering force which armed group formations can’t defeat, an armed team formation emerges.

Interdependence, cooperation and trust changes the group to a team and makes it capable of achieving a goal which is not even remotely possible to achieve in a group: a team of hunters can hunt the mammoth, a team of warriors can protect the city from an outnumbering amount of attackers, a surgical team or firefighting team can save more lives.

So how does this apply to software development and why is it important to understand the difference between the team and the group?

Teams and groups in software engineering

The group of engineers can work towards a common goal, but if they aren’t interdependent and if they don’t trust each other and never cooperate, they are not the team. This means that the group efficiency is limited and always less than the efficiency of an engineering team.

So what do interdependence, cooperation and trust mean in engineering?

Interdependence seems simple and obvious to everyone as engineering almost demands specialization: it’s hardly possible to have every single engineer in a group or a team to possess all the required skills to produce a value for the client. Therefore, a frontend engineer depends on the designer and the backend engineer, the backend engineer depends on the DBA and the frontend engineer, etc. Cooperation seems easy too: specialized engineers can sit together and work on resolving a particularly hard problem, they cooperate, i.e. they work together on something.

The value for the client can’t be usually produced and delivered by a single person, akin to a mammoth which is impossible to hunt alone or in a group.

With trust, things are more interesting. Even the definition of trust sounds surprising to some.

Trust is the willingness of one party (the trustor) to become vulnerable to another party (the trustee) on the presumption that the trustee will act in ways that benefit the trustor. In addition, the trustor does not have control over the actions of the trustee.

or

An individual trusts if she voluntarily places resources at the disposal of another party without any legal commitment from the latter. In addition, the act of trust is associated with an expectation that the act will pay off in terms of the investor’s goals.

To summarize, trust is the act of placing belief in another person without control over them, and making yourself vulnerable in them with the expectation that they will reciprocate by acting in common interest. Trust is a proactive behavior, where you take the first step in trusting the person and anticipate that they will behave accordingly.

For example, I, being a front-end developer, should trust my colleague enough to be able to tell them that I forgot something or made a crucial mistake, and that I would expect them to help me fix the problem ASAP; and that this wouldn’t imply any repercussions to me. Alternatively, I trust my manager not to lay me off suddenly because of some suboptimal business decisions made by the top management. I should also believe that if my colleagues need help, and I cooperate, let’s say mentor a new joiner to the team, that this cooperation won’t be taken against me since “I complete less tasks individually”.

Within the team, trust will emerge with time and proper cooperation and collaboration, but only if the manager doesn’t take actions which negatively affect trust.

Similarly to how according to the Conways law, the software architecture is defined by the organization; the cultural traits such as trust, collaboration and cooperation are defined by the organizational structure and the processes of work.

If a hunter who is ready to trust, cooperate and collaborate joins a hunting group where everyone works as an individual, the new hunter will either die expecting others to cooperate and help, or will simply mimic the group’s behavioral pattern and adopt the same work habits.

In IT, if a developer who is ready to trust, cooperate and collaborate joins a group where competitive behavior is praised with individual performance reviews and bonuses or KPIs, chances are this developer will either quit, or adopt the same group behavioral patterns.

So the trust, cooperation and collaboration will only emerge and change the group to the team if the organizational structure and the processes of work allow it to emerge.

Organizational psychology knows a great deal about processes with negative impact on trust, cooperation and collaboration, and in the next article I will delve into the practices and approaches which turn teams into groups.

References: