This is the dimension most people seem to mean when they talk about scaling. Every medium-sized company I've visited has fond memories of how things used to be. Problems would just get solved. At some point they realized that the way problems were solved when there were two programmers no longer worked. Their solutions "didn't scale." While it is true that fifty developers can't act like two, the rigid controls and sign-offs frequently instituted aren't the only solution.
When faced with a big problem I work in three steps:
1. | Turn the problem into smaller problems. |
2. | Apply simple solutions. |
3. | Apply complex solutions if any problem is left. |
Following this, when faced with the apparent need for a large team, perhaps the problem really could be solved by a small team. I've seen organizations grow from fifty to three hundred and make plans to grow to two thousand, adding to their problems and losing overall throughput every step of the way. Addicted to scaling in number of employees, these organizations don't seem to want to believe that their problems would be better solved by those fifty original developers.
If just using a smaller team doesn't work, turn the big programming problem into several smaller problems, each solvable by a small team. First solve a small part of the problem with a small team. Then divide the system along its natural fracture lines and begin working on it with a few teams. Partitioning introduces the risk that the pieces won't fit on integration, so integrate frequently to reconcile differing assumptions between teams. This is a conquer-and-divide strategy instead of a divide-and-conquer strategy. Sabre Airline Solutions, profiled in the next chapter, uses this strategy extensively.
The goal of conquer-and-divide is to have teams that can each be managed as if they are the only team to limit coordination costs. Even so, the whole system needs to be integrated frequently. The occasional exceptions to this illusion of independence are managed as exceptions. If the exceptions become the norm and the teams have to spend too much time coordinating, look to the system to see if there are ways of restructuring it to return the teams to independence. Only if this fails is the overhead of large-project management appropriate.
In summary, faced with the apparent need for a large team, first ask if a small team can solve the problem. If that doesn't work, begin the project with a small team, then split the work among autonomous teams.