Why Teams

Teams, in software engineering, form because of success. Without success, the firm wouldn’t be cursed with the problem of having so much talent to have to organize in some way. A founder can easily reduce the complexity in their human organization, and their lives, by simply not hiring any more than seven technologists to work with them on their mission. For some, this is viable. For others, this is not.

Teams emerge in response to scale. They are either formed as by product of centralized hierarchical command structure, or they emerge as a product of network cohesion/polarization. To the extent that either formation is aligned with the vision, goal, mission, or purpose of the organizational chrome is a function of leadership, culture, and talent.

It’s not unusual for the formation of teams to occur when the number of edges that a person can maintain in their working social network exceeds the number of people in the organization. It’s out of response to limitations in communication and trust equity that groups of people form. Sometimes this is dependent on the vision of the founder or leader. Sometimes it’s driven by the median number of connections one can reasonably maintain. There are plenty of anecdotes about the right size of a software team, which vary from 2 to 12. The typical number is 8, though many personally prefer 3 to 6. Generally, one can predict an organization/startup will start organizing into teams at around 11 to 15 technologists.

A team has several attributes. The crudest attribute are the number of fully dedicated people on that team. A team may also have an aggregate skill inventory that is specialized and differentiated from other teams. It’s common for native app developers to be organized into their own team, and for people who work with databases to be in another. Sometimes a team is organized in such a way that it has all the skills necessary to deliver on a feature, mission, or sprint.

Much to the chagrin of people that lead multiple teams, teams also have other attributes. Teams can form their own way of communicating, their own traditions, customs, systems, standards, ideologies, histories, and mythologies. They also form their own social networks inside the team and outside the team. One team may use Slack. Another may not make use of any instant messaging all. One team may use Trello. Another may use Jira. Another may use post-its. One team may have a weekly tradition of reviewing state of the art research. Another team may not. Sometimes teams have different markets, and as a direct result, have different conceptions of what is important and what isn’t. Teams have different ages and are comprised by individuals that have different tenures. The amount of good and bad blood accrued by those in the team also vary. Sometimes a team is in a state of just forming. Sometimes they’re storming. Sometimes they’re norming. Because teams are made out of people, and by people, their consistency varies.

One can have a few responses to this kind of heterogeneity. For some, this is a strength. Teams have different specialization and different functions, and are just different, so they could be, and should be, different. Good ideas can come from anywhere and it’s great to have a tolerance for a lot of different solutions. For others, this is unacceptable because it is inconceivable that there should be any differences among anybody within the organization, we are all 100% aligned with the mission, and any differences are to be minimized. While it may be inefficient to have six different types of instant messaging apps and fourteen different stacks within a firm, it may be enable tremendous speed to market, excellent execution, and very high engagement.

Another response to heterogeneity is mixing. How do you blend paint? By stirring it! One could have a core set of tools and technology, and then enable people to form teams out of the network as need arises. What happens in these situations is that groups of people spend more time forming and storming in the beginning, resulting in lower efficiency, but, there are higher odds of very fantastic and unusual execution. As the tenure of the network increases, clusters form, and there’s much less time storming. One would get a smoother distribution and higher efficiency over time.

The leader has a challenge in converting calories (burned by the human brain) into value. How they organize humans as the organization scales has so much to do with the way value is understood. Some cultures say that 7 is enough. But if scale happens, teams are going to form, either formally or informally. Is there more value in speed, efficiency, or quality? In which ratios?

And in which way that the odds are tilted in your favor?