This post was first published on CoderHood as The Stages of Teamwork Complexity. CoderHood is a blog dedicated to the human dimension of software engineering.
Coding alone and coding in a team are two very different activities. Often people do not realize how quickly the complexity of teamwork explodes as the number of people increases. If you struggle to see the benefits of a development process, or if you have never thought about the productivity of teams of different sizes, this article is for you.
Thinkers such as Jeff Sutherland, Taiichi Ohno, and Kent Beck designed different forms of production processes to organize and tame team interaction complexities. Those processes form a body of well-defined frameworks that can be used to manage the flow of communication, providing a method to synchronize interactions between team members and attempting to create some predictability of the team's output.
Even with a framework, things can become overwhelmingly complicated with more than seven people working on a single project and operating as a single team. Over that limit, most teams start experiencing a noticeable decrease in productivity due to overhead, miscommunication and general confusion. There are exceptions, of course, but seven is a reasonable and safe upper limit.
I have given names for the various stages of the scaling of an engineering team, and I have identified characteristics at each one. The terminology in this post is mostly my own. I encourage you to use it freely as it will help clarify the stage and the challenges in a scaling engineering team and organization.
Definitions
Total Lines of Communication (TLC)
The number of all possible separate one-on-one interactions between team members. In a team of N people, that number is:
TLC = N*(N-1)/2.
Individual Lines of Communication (ILC)
The number of all possible one-on-one interactions that each person can have with other team members. In a team of N people, that number is:
ILC = N-1
Individual Communication Loss (ICL)
Individual Communication Loss is the number of one-on-one conversations that each team member misses. It is calculated wit:
ICL = TLC -- ILC
The higher the Individual Communication Loss is, the more each team member experiences loss of information and detachment from the overall state of things.
You can write the same equation this way:
ICL = (N-1)*(N-2)/2
Team Size Stages
The stages described below explain what happens at different team sizes. In this context, I am assuming the following:
- The team members are working on the same codebase. The work of each person is either dependent or a dependency for the work of the other people.
- To be effective, each person needs to be aware of what others are doing, at least at periodic intervals.
- The team has shared goals and milestones.
Team of One, The Learning Stage.
- Total lines of communication: Zero.
- Individual lines of communication: Zero.
- Individual Communication Loss: Zero.
When you learn to code, or when you start a personal project, you are often alone. The vision is in your head, the schedule self-imposed and you make progress at whatever speed you want. Coding alone is like exploring an uncharted territory and making decisions in whatever way seems to work best for you.
Even if you are working for somebody as a team of one, you make most of the technical decisions. You may have deadlines to meet, but the way you work and how you organize your tasks is entirely up to you.
Not having to communicate with other developers and synchronize your development process, saves you a considerable amount of time. However, all the problems are on your shoulders, and you cannot delegate anything. If you decide not to do something, it won't get done until you do it.
In a team of one, the quality of the work you produce is not subject to review, and any mistake you make and don't see will not be caught until much later. You might or might not have somebody to brainstorm ideas, but in most cases, you are the only one understanding the profound implications of every decision you make.
In this stage, you get exposed to all aspects of development, but you cannot scale. The amount of code you can write and test is limited by your ability to deliver it and bound by your experience and skills.
Team of Two, The Partnering Stage.
- Lines of communication: One.
- Individual lines of communication: One.
- Individual Communication Loss: Zero.
When you work in a team of two, you have a partner that collaborates with you. In this stage, you can divide the work and responsibilities, and you must discuss how your work gets integrated with your partner's. You start realizing how APIs need to be well defined and stubbed, tests become fundamental to avoid your partner to break stuff you did, and integration becomes a word in your daily activities.
Collaborating requires for you to communicate, and communication is time-consuming. In this stage, you have only one line of communication between you with your partner, so it is not too complicated given that you are directly involved with every conversation. If you get along with your partner, things move smoothly, and overhead can be minimal. However, if your partner is on a different wavelength, communication can become a significant part of your day.
In this stage, you learn the power of brainstorming, and you are no longer alone making all decisions and mistakes. You catch some of your partner's errors, and your partner finds some of yours. Code reviews start happening naturally, and you find yourself periodically giving and asking for status.
With two people the development process can be natural and organic. As long as you communicate frequently, things move forward.
Team of Three, The Growing Stage.
- Lines of communication: Three.
- Individual lines of communication: Two.
- Individual Communication Loss: One.
When the team grows to three engineers, you are officially in a growing stage. Communication between three people is much more complicated than between two people. The team now has three lines of communication to manage, and each person is only part of two of them. That means that each team member is missing in average 1/3 of the one-on-one discussions. For this reason, you need to start formalizing a development process to make sure information doesn't get lost.
In this stage, accidental or loose alignment no longer works. Decisions need to be well documented and shared in a more formalized and organized ways compared to a team of two.
Growing is exciting, but it can also be distracting. In this stage, the team starts forming a micro-culture, and that culture begins to have effects on the outcomes and overall productivity.
Leadership is not strictly necessary in the growing stage, but it helps immensely. If nobody takes a leadership role, things can still work smoothly as long as everyone goes along and is aligned. It is rare, but it is possible.
Team of four, The Leadership Stage.
- Lines of communication: Six.
- Individual lines of communication: Three.
- Individual Communication Loss: Three.
With four people you have a total of six lines of communication; each person is only part of three of them, so the potential of loss of information is real. With four people it is vital to have a well-designed way of working, collecting data, splitting the work, deciding who does what and keep each other informed.
This stage is called the leadership stage because one individual should start functioning as a leader, naturally or by agreed arrangement. Without a leader, a team of four stumbles and often stalls; the vision of what is being built can easily get lost, and miscommunication can take a high toll on productivity and quality of results.
In the leadership stage, the culture of the team becomes more palpable, and the leader should be taking an active role in shaping it. Without that active role, the group will form a natural and accidental culture. That can work, but it has a potential of devolving into friction and misunderstanding.
An engineering team of four without a defined development process can start feeling aimless and inefficient. Misunderstandings begin crippling the work, and the team risks to lose much of its productivity dealing with logistic issues.
Team of five, The Communication Stage.
- Lines of communication: Ten.
- Individual lines of communication: Four.
- Individual Communication Loss: Six.
When five team members are working on the same project, each person misses more than half of the one-on-one conversations. Unless a suitable development process is in place to centralized essential discussions and decisions, this stage is going to be crippled by miscommunication and misunderstandings.
I call this the "communication stage" because things tend to implode unless there is focus on communication management, even if the team has a go leader. Communication management, in this context, is an efficient method to share, discuss and retain critical information. Such method cannot be accidental; it has to be deliberately designed and defined. Development processes such as Scrum and Kanban provide, among other things, well-defined frameworks for communication. Different custom methodologies can be described as needed if standard methods don't work in the context of the organization.
Team of six, The Entropy Stage
- Lines of communication: Fifteen
- Individual lines of communication: Five
- Communication Loss: Ten
Entropy is a lack of order or predictability and a gradual decline into disorder. Even with well a designed communication framework, with six people on a team, the group will tend to naturally descend into a state of disorder and lack of predictability; this tendency can be controlled with a well-designed development process such as Scrum or Kanban, and attention to keeping activities orderly and synchronized.
At this stage, the team should start looking for ways to split into two or more separate groups by discussing how to organize the work in different, independent, or partially independent projects.
Team of seven, The Scaling Stage
- Lines of communication: Twenty-one.
- Individual lines of communication: Six.
- Individual Communication Loss: Fifteen.
With every individual in the team potentially missing 3 out of 4 one-on-one conversations, a group of seven is as big as you want it to be without collapsing under its weight. That is why I call this the "scaling stage." Any team larger than seven would benefit from a split into multiple groups, making seven a practical upper limit.
Just to be clear, I have seen teams larger than seven people (up to ten) work somewhat efficiently; still, I would not recommend it. The overhead is too significant, and I do not believe that it is a sustainable arrangement.
Multiple Teams and TOLLx (Team of Leads Level x)
When more than seven engineers work on the same project, it is wise to split the team into multiple smaller ones of up to seven people each.
In such a configuration, each team should have a tech lead who is familiar with the details of the team's area of ownership. The lead is usually the person discussed in the "Leadership Stage" section above. Each team lead has the responsibility to meet regularly with the other team leads to make sure that proper coordination and communication occurs between groups. I call this meeting a cross-team meeting, and it can be held daily, weekly or at any appropriate interval.
In organizations using Scrum as a development process, this group of project leads can operate as a Scrum Team with a separate backlog. In Scrum, this process is called a Scrum of Scrums and the leads are called Ambassadors or Champions. Such an arrangement works for up to seven teams of seven people each, that is up to 49 engineers in total. I call "TOLL1" (Team of Leads Level 1) the group formed by the seven projects leads.
If you need more than seven teams, you can scale to the next level. In such a configuration you'd have a lead selected from each TOLL1 that meets and coordinates with the leads from other TOLL1s. The team of TOLL1 leads is called a TOLL2, or Team of Leads Level 2. This configuration, in theory, can organize up to 343 engineers.
I don't know why you'd want to put more than 343 engineers on the same project, but if you had to you could theoretically scale this to a TOLL3 which could organize up to 2401 engineers. In practice, you'd want to manage things differently using independent engineering divisions. I'll tackle this topic in the future.
Top comments (1)
Thank you for writing and illustrating this.
It was a bit to verbose for my taste, but the images kept me going :)
It made me think about what things we in a (kanban) team of currently 13 people (4 remotely) are doing to keep working efficiently.
We are working in (changing) pairs 90% of times, well defined processes for various levels/kinds of development tasks, code reviews across the whole team have some impact on knowledge transfer, regular 15-30 min team gatherings with show'n'tell or proposals in case of changes that will affect the whole team, ...
It is not always going working out nicely, of course.
And communication isn't the only challenge :)