Four Ways To Improve Predictability (Tip #3)

This is a continuation of a four-part series.

• Part #1: Narrow your planning horizon
• Part #2: Use empirical data
• You are here --> Part #3: Create smaller teams
• Part #4: Eliminate the fear of failure

Tip #3: Create smaller teams

According to studies, the ideal team size is 4.6 people. If you’re familiar with Agile practices, you know that the typical recommendation is 5-9 heads per team. Assuming there was something to these recommendations, I started experimenting with creating smaller teams about 7 years ago. Since then, countless times I've personally witnessed 1.5x - 2x productivity gains by splitting large teams into smaller teams.

2x productivity gains? How?

Maximized performance: With fewer people on a team, everyone needs to do their part to meet the team goals. Much like a startup environment, a small team environment creates a sense of urgency, ownership, and duty to not let one’s teammates down. On top of that, top talent will help improve productivity of the team members around them. At the other end of the spectrum, a team member with performance issues sticks out like a sore thumb on a small team.

Simplified communication: The below picture is worth 1000 words. As team size increases, the complexity of communication grows rapidly. This complexity can result in slow decision making, team members feeling out of the loop, and lost productivity.

Source: GetLightHouse

Reduced dependencies

Although you may not eliminate all dependencies, assuming that in re-sizing your teams you’ve optimized for team independence, you should find fewer and fewer cross-team dependencies to manage.

How to get started

As with most experiments, I recommend trying a pilot first:

1.      Identify a large team to split

2.      Include the team in the decision making; explain to them the “why” and consider delegating the selection of new team make-up to them. (I’ve done this many times with success and can provide tips)

3.      Split into teams of 7-ish

4.      Optimize the split in such a way that each team is as independent as possible, minimizing dependencies on other teams, and maximizing each team’s ability to deliver value without any outside help

Pitfalls

1.      Creating smaller teams may create shortages of certain roles (such as product owner or scrum master if Scrum is practiced)

2.      If teams are split along functional lines, you may create a dependency nightmare

3.      If you’re developing software, changing your how organization is structured WILL impact how your system is designed. See Conway’s Law.

Source: Google

Let’s discuss

What has your experience been with right-sizing teams?