One of those areas is organizational design and team size. Scrum originally recommended a team size of seven, plus or minus two, so five to nine individuals. From what I can gather, that number was really based on a psychology paper by George A. Miller called "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information." If you want, you can download the paper here for personal use from the University of Toronto. Miller's basic premise is that humans have a natural upper bound for being able to keep concepts in working memory, and that upper bound is, in many cases, nine. Alongside that, seven items are truly in a sweet spot of sorts. If you don't want to read the paper, but are interested in Miller's Law, you can read the Wikipedia synopsis here.
From Scrum's perspective, team members must effectively communicate and coordinate with one another, and the same limit of five to nine individuals results in highly functional teams. As Scrum has grown, and effective teams have been found with as few as three individuals, the recommendation in some circles is now six, plus or minus three, retaining the same maximum of nine.
Another popular team sizing guideline comes from Amazon's Jeff Bezos, commonly cited as the originator of the "two pizza rule," which recommends that no team (or meeting) consist of more people than can be fed by two pizzas. Again, that puts a pretty strong upper limit at around nine to twelve individuals.
So when your organization is larger than nine people, how do you manage it? I recommend you stick to the guidelines across levels of the organization where you can. Try to follow some of these guidelines:
Keep team size under eight direct reports.
In order to keep under the magic upper limit of nine, keep teams under eight direct reports plus a manager. The nine individuals will communicate and coordinate more effectively than teams of twelve or fifteen. In addition to overall team size and communication, it is difficult to manage more than eight direct reports. I always recommend managers talk one on one with their employees, and even with eight employees, that's three days per week requiring doubling up on those conversations just to make the rounds once per week. Once you get above nine or ten, it becomes immensely difficult to keep track of what the team is working on.
Respect lower bounds as well.
Whether you choose three or five as your lower bound, teams should have a minimum number of individuals to be able to contribute successfully. If there are not enough employees in the organization or overall team, consider flattening it out, having the two or three individuals as peers rather than a management-employee relationship. Teams with one employee reporting to a manager may not have enough bandwidth to effectively accomplish what they need to and create unnecessary managerial tasks for the lead. Flatter teams in that regard would bump the managerial responsibilities up to someone who already has that as a large function of their job, and would give the team access to more peers to collaborate and work with.
Tighten it up as you move up the chain.
As the size of the organization being managed increases, the need to get closer to a sweet spot becomes more important due to one factor: span. The leader of an organization with five hundred employees has no ability to know what each of those employees are doing on a daily basis, so it is ever important that the model be optimized for upwards, downwards and peer-to-peer communication. Once the organization gets more than two levels deep, the span of topics covered makes it that much more difficult to manage large numbers of direct reports. Some individuals get lost in the shuffle entirely, along with their entire teams. As the span increases, a range of five to seven direct reports becomes much more manageable. I have witnessed even great executives struggle when presented with eight or nine direct reports.
Do you have anything to add to this article? Drop me a line and let me know, or share the article with your friends on social media or email.
This article is the first in a series evaluating how Scrum methodology might be utilized in non-IT business operations and decisions to improve productivity and performance.
Image modified from silhouettes extracted from an image from geralt on Pixabay.
