Jeff Bezos often described the ideal size of a (product) team to be somewhere around the amount of people one can feed with 2 pizzas. The moment you go beyond that, things start getting complicated for many reasons.  His reasoning are as follows:

1)  Information is not universal anymore

With over 10 people in the team it is a lot harder to get everyone up-to-speed. Things are happening in parallel with people working on different things at the same time. This creates the sudden need to think about how to update the rest of the team on everything that’s going on. With a team that used to simply “know everything” it is very easy to miss the moment this is no longer the case!

2)  Consensus is harder to come by

Assuming you have done a good job in hiring awesome people, you will quickly find out they don’t agree… a lot! Good people often come with strong opinions and they make themselves heard. When the team is made up of 5-6 people get to a consensus pretty quickly, but when the team passes 8-10 people this is no longer the case. To make matters worse: if you did a good job, all of these people know their stuff better than you do, meaning you will most likely find yourself in a position where you can’t simply decide for them either!

The challenge with the 2-Pizza Rule is teams end up splitting awkwardly.

Once you realize you’ve hit the limit to work efficiently in a single team there aren’t many magical solutions: you have to split up and start organizing in different groups. This is not an easy task and brings with it a fair share of issues. Beyond the simple team-dynamics (which you don’t want to mess with too much as I am sure they have been working nicely up to now) there is the awkward decision on where to draw the line of separation between the groups. Do you split front-end & back-end development? In this case you end up with people that specialize fairly early on and work on the same sort of problems every day. The other choice is to split on product or similar feature-sets, effectively creating two smaller product teams focussing on parts of the greater product. The problem here is that people stop understanding all facets of the greater product and how they each relate to each other.

None of these choices seem perfect. On top of the issues raised above, what happens when you suddenly need to rush for a big push on one specific feature that involves only front-end development? Suddenly half your team doesn’t have a full understanding of that part of the product anymore and will need considerable time scaling up before being productive (in which case it is probably too late, due to small timeframe of the rush itself).

The Solution: Switch the Teams Every X Months!

Although it seems fairly obvious, somehow neither my research nor any of the people I talked to about my problems mentioned this solution. Whichever method you choose to split up your team, making the group switch every X months (we choose every 3 months) solves many of the issues mentioned above.  

Problems surface by themselves

Both teams will have a slightly different way of organizing and working together. Every time they switch, each is confronted with how the other team has decided to approach various issues and they either like their proposed solutions or they don’t. In case they do, they will be able to learn from it and adopt the new method in their own team. In case they don’t, debate generally follows (“why did you not do it this way?”) and both approaches get put on the table. In both cases, you win: the teams learn and gets better from each other.

Documentation actually gets written

Everyone knows documenting your code is a good thing, but no one likes to write it.  There always something else better and more productive to do. Switching teams blows this problem up in the best way possible. As both teams switch, they are confronted with what the other team has written in the past 3 months and it doesn’t always make sense. The result is that everyone asks a bunch of questions and realizes just how much time could have been saved, had documentation been written properly. The next time the teams switch, you will be surprised at how much additional documentation is actually being maintained.

Motivation & Productivity skyrockets

Most people don’t like working on the same thing for too long. By providing a regular context switch such as this, people get to change their daily routine and ideas to focus on something different. The result is that everyone keeps their motivation, stays sharp and is generally more productive.

Everyone understands all facets of the business / product

Last but not least, having people work on every aspect of your company’s products makes them understand the company in a more complete way, instead of creating specialization too early. This means the team maintains flexibility to focus on one particular aspect of the product, should it need a little push (which has definitely happened to us more than once).