Once a software delivery system grows beyond about 20 people, program-level structure emerges and requires management for system-level optimisation for collaboration and trust.

Scissors cut Paper; Paper covers Rock; Rock crushes Lizard; Lizard poisons Spock; Spock smashes Scissors; Scissors decapitate Lizard; Lizard eats Paper; Paper disproves Spock; Spock vaporizes Rock; And as it always has: Rock crushes scissors.

Rock Paper Scissors Lizard Spock
Image by DMacks [GFDL or CC BY-SA 3.0], via Wikimedia Commons 

As a team grows, the number of communication channels within the team grows exponentially, according to the formula:
Channels of Communication = (n*(n-1))/2

This is why Rock Paper Scissors is a pretty dull game that becomes vastly more interesting when you add just two more possibilities. You go from 3 relationships (each member of the set beats one and only one other and is beaten by one) to 10, in which each member beats and is beaten by two other members.

Let my good friend, Dr Sheldon Cooper, explain:

Definitive Rules
  • Scissors cut Paper
  • Paper covers Rock
  • Rock crushes Lizard
  • Lizard poisons Spock
  • Spock smashes Scissors
  • Scissors decapitate Lizard
  • Lizard eats Paper
  • Paper disproves Spock
  • Spock vaporizes Rock
  • And as it always has: Rock crushes Scissors

Given that software teams working on anything but the simplest of systems nearly always have to stay in pretty close co-ordination to be effective, it’s unavoidable that as a team grows, teammembers spend a greater proportion of their time communicating, and a lesser proportion thinking creatively about how to solve business problems with code. While it’s true that the definition of organisations is that humans working together achieve more than the sum of the individuals, and that achievement is a product of communication, the effort involved to maintain a channel imposes its own tax.

As the number of channels increases (exponentially as shown above), the cost/benefit curve most definitely has a peak, the location of which is different, depending on the kind of communication you need. The closely integrated communication needed for a software team is similar to that of a family, peaking around 5 indviduals. Further peaks occur at around 15, 50, 150 and 1500, which is why those are very much linked to common sizes of military units, human settlements and other organisations.

The Mythical Man-Month Cover

The Mythical Man-Month

Once you start adding more people to that optimum size, the inefficiency tax of communication starts winning out over the benefit of collaboration. As has long been observed (and formalised in The Mythical Man Month as Brooks’ Law):

Adding more people to a late running delivery makes it run even later.Fred Brooks

So when you need to produce something that takes more than 5 people in a sane amount of time, what do you do?

The only sane thing is to split the group along domain lines, keeping close communication within small teams, and constraining the communication needs between the teams to defined areas of cross team dependency. Assuming a well defined and communicated aim, this probably works without much further structure up to the second Dunbar number (or roughly 3-5 teams), with factors of stronger specialisation enabling the higher end of this.

This is the sweet spot of feature teams: fewer interdependencies and cross-cutting requirements will make this much easier.

Above this number though, you start running into problems because you really do need to understand the whole as a system, and it needs to work as a system. And as the group grows, the understanding and empathy for more remote members to one’s own team decreases in direct correlation with the communication intensity and frequency, and the quality minded team starts organising for local excellence, rather than systemically. You start observing antagonistic customer and supplier behaviours, pushing responsibility away while grabbing control mechanisms to avoid being the loser in a blame game, rather than acting as trusted collaborators on a shared initiative.

As Deming observed:

A system must be managed. It will not manage itself. Left to themselves in the Western world, components become selfish, competitive, independent profit centers, and thus destroy the system.W. Edwards Deming: The New Economics
If the various components of an organization are all optimized (each for individual profit, each a prima donna), the organization will not be. If the whole is optimized, the components will not be.W. Edwards Deming: The New Economics

At this scale, you need to manage your system as a team of teams, planning and executing in a co-ordinated way to achieve a common goal. The common goal and activity will mitigate the alienation between teams that don’t otherwise interact much, and avoid the tendency towards Not me, Guv-ism, and management actively works towards developing an environment that supports trust and collaboration across a much larger number than would otherwise happen.

Program level management increases the optimum membership size for each Dunbar-scale organisation, growing the level at which collaboration collapses to the next scale up.

Follow me
Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 The Rock Paper Scissors Lizard Spock of Teams by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: