This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Raising Large Issues
Of course, large is not a well-defined magnitude, and neither is the largeness of a team. Will a team be considered large if it contains 2, 10, 100, 1,000, or even more people? And what impact does every additional order of magnitude in staff number have on the process? For example, let’s look at its influence on communication:
- 2 people and more: If a project is developed by only one person, that person should have the big picture of the project in mind. He or she knows the whole system in terms of code and design. As soon as another person is added to the project, these two people will have to communicate with each other. Communication is the only thing that will enable both developers to understand what is going on and to further coordinate their efforts. For example, it would be annoying if they both worked on the same programming task unknowingly, only to find out once they began to integrate the code.
- 10 people or more: With teams of this size, you have to start coordinating members’ efforts and their communication. You have to explicitly establish communication channels in order to discuss topics with the whole group.
- 100 people or more: Even if you have an open-plan office available, teams of this size will not fit in a single room. Therefore, across the entire team, you have to strategically foster the kind of “natural” communication that would take place inside a single room.
- 1,000 people or more: Chances are high that this team will not only be distributed over several rooms, but also over several buildings, perhaps over several locations. Consequently, the people on the team are unlikely to know all their teammates.
This example shows not only that large is relative, but also that scaling can lead to different consequences.