Admittedly, the second half sentence “why we should communicate less” is provocative in the modern world of work, but true. But more about that later …
By the very hear-worth Podcast “Führungs auf den Punkt gebracht” by leadership coach Bernd Geropp a topic came to me, over which I wanted to blog for a long time: The ideal team size and the dangerously rising communication effort with too large teams.
The magic number 7
In the Episode 165 of the podcast Bernd Geropp describes the ideal leadership span, i.e. the number of people that can be meaningfully led by a manager. The findings can be applied thereby not only to high-level personnel, but also and particularly with self-leading agile teams.
He mentions an article of Professor Dr. Wolfgang Grunwald, work and industrial psychologist. It is shown that groups in the cultural history always consist of approx. 7 humans and larger groups inevitably fall into smaller groups. (For further background information I recommend the podcast or a Google search for the article “Psychologische Gesetzmäßigkeiten der Gruppenarbeit” [Psychological laws of group work].)
I found the article and podcast so interesting because it’s more than 20 years old, but picks up on things I first learned in agile teams and UX:
Hick’s law and the magic 7
In UX we often speak of Hick’s Law. It describes the relationship between response time and number of choices. In short: With the number of options our reaction time increases. With about 7 options the reaction time is more than one second. This time can only be reduced by training.
With UX and web designers the rule of thumb has established itself, never to offer more than 7 options e.g. in the main menu or to display at the same time.
Brooks’s Law and the communication paths
Brook’s Law by the American computer pioneer Fred Brooks states that adding more people to a delayed software project will increase the implementation time, not decrease it.
[pullquote align=”right” cite=”Fred Brooks” tweet=”true”]adding human resources to a late software project makes it later[/pullquote]
In addition to the difficult induction and the complex special tasks involved in software development, this is also due to the higher communication effort within the team.
The non-linear growth of communication paths according to team size
In addition to the formula behind Hick’s Law, another formula is interesting. It describes the possible lines of communication of people, if everyone would have to coordinate with everyone:
n × (n-1) / 2
Communication does not increase linearly with the number of people:
- For 2 persons it is 1 connection
- For 3 persons there are 3 connections
- For 4 persons there are 6 connections
- For 10 persons there are already 45 connections!
(Very impressive in this context also this graphic from Stackoverflow.)
If we now take our rule of thumb discovered in Hick’s Law, we have a manageable amount of communication lines somewhere with 5-7 people, depending on how many active/extroverted participants there are.
Small anecdote: I recently participated in a workshop with about 35 participants. What do you think: how many possible communication channels would that have been? I’ll tell you: 595.
Agile teams and methods of communication avoidance
Communication avoidance sounds absurd at first. We are an agile team, we do dailies, we have product owners who manage stakeholders, we have extensive retrospectives. We should avoid communication?
Yes! We’re already doing it!
In the Wikipedia article on Brook’s Law there are a few limitations: His law dates back to 1975. Today, there are many things that actively avoid communication because they are convention:
- Scrum Meetings with fixed Timebox
- Design Patterns and Coding Guidelines, which define certain formalities at work
- Modern practices such as Continuous Integration or Iterative development make a large part of the coordination between developers superfluous or reduce it strongly.
5 Rules for effective avoidance Communication
On this basis you can summarize 5 simple rules, as well as you can reduce your communication outside of agile teams and achieve more:
- Creates standards and rules
Standard meetings like in Scrum, email rules like: “Don’t answer when you’re in CC” or “Only answer in case of emergency”.
- Shared Meetings
Pick up participants individually or in small groups. Resists the temptation to coordinate everything in a big, clarifying conversation. In the sum and in the result meetings with under 7 persons are clearly more successful.
- Save yourself e-mail recipient
Considers who really has to get the info from the mail and who only on principle has to be informed in the Save-My-Ass-if-you-are-informed-CC-column.
- Don’t give too many options
To find a decision, offer 2 or 3 options only. The more options, the more overstrained the participants are
- Reduce the communication channels
This might be a topic for a single blog entry: Avoid constant availability and a large number of communication possibilities
How big should a team be?
After all that text I haven’t answered the initial question exactly yet. Science or not, the easiest way to behave is like Jeff Bezos with his two-pizza rule:
[pullquote align=”full” bordertop=”false” cite=”Jeff Bezos” link=””” class=””tweet=”true”]Never have a meeting where two pizzas couldn’t feed the whole group.[/pullquote]