Thoughts On Organizational Design - A Numbers Game

As the Tech industry works its way through layoffs and so-called years of efficiency, I continue to be amazed by the sheer size of these organizations, especially when their CEOs make cavalier comments about "managers managing managers managing managers" as though they had absolutely no hand in creating such an organization ("Don't blame me, bro.  I'm just the CEO.  What do I know?  The buck stops over there.  I take full accountability for that.")

Wikipedia lists Alphabet's total population as 180,895 and Meta's as 69,329.  This is mind-boggling to me.  During the past decade, I've spent my career at companies numbering in the neighborhood of 13,000 to 18,000 employees and have witnessed the sheer tedium their bureaucracies produce on a daily basis.  I can't fathom what working at an even larger company must be like, Tech darling or not.

When I'm left aghast at some particular statistic like this, I often try running thought experiments to determine what would be perfect in my own warped vision.  While I don't strictly adhere to the "you should bring solutions, not problems" school of corporate pseudo-thought (sometimes you just have to be given free rein to bitch), coming up with sketches of solutions can be constructive in ensuing conversations, especially if you're challenged on your premises.

And even the most wacky theoretical concept, if not taken at face value, can translate to real-world improvements.  

For the purposes of this article, I'll keep my scope restricted to a theoretical Software Engineering department, because it's what I'm most familiar with.  However, I imagine the experiment would work in other departments as well - at least in the white-collar world.   

With that in mind, I give you the perfect geometric organizational pyramid.  BEHOLD this wonder in all its mundane glory!


Just so you don't have to strain your eyes looking at all of the arrows, the org chart follows a geometric progression based on a common ratio of 6.  That means each manager has 6 direct reports with a total Tech department size of:

1+6+36+216+1296=1,555

If it's not obvious, I'm choosing 6 for an ideal team size.  My past experience points toward teams of 5-8 being optimal, and this article from Wharton backs that assumption for the type of work typical in Tech, so I know I'm not just sticking a metaphorical finger in the wind.

Humans, per an oft-cited number, have a working social network of between 100-250 people composed of family, friends, and colleagues (though confidence intervals waver between 2 and 500 in follow-up research.  But, still, not 10,000).   Exceed that number and the connections begin to wobble.  The bonds outside of that core number are weaker.  In addition, adding a new person to a group squares the total density of the communication edges in the group as each person now needs to communicate with everyone else in the group.  It's why two-way communication among a large group can quickly grow unruly.

Keeping a core team bounded to a reasonable size -a gain 6 in this case - doesn't put unnecessary pressure on individual communication networks.  Middle management's networking space is the largest due to their sandwich position in the org.  Assuming, at a minimum, you need to know your employees, your 5 peers, and your boss well, that's 12 total connections for day-to-day interaction.  It's also probably why middle management is the most frazzled - by necessity, they need to maintain a greater communication network, which can be exhausting.  Well, that, and everyone keeps questioning their validity in the organization.

A 6-person team is small enough for managers to devote time to each employee while allowing significant time for management duties not directly related to your employees.  Assuming a 1 hour one-on-one conversation every other week and a typical 40-hour workweek, you're able to build strong bonds with your employees and still have 37 hours left in the week for other work.  This provides flexibility to deal with unpredictable situations that invariably arise without neglecting anyone on your team.

From a team standpoint, you have a small core that's able to gain a deep knowledge base in one particular part of the stack. If you have a large project, you have enough people to tackle it in its entirety.  For smaller projects, you have sufficient staffing to handle two or three tasks at the same time in small sub-teams that keep isolation, and the disengagement that accompanies it, at bay.  

As you move up the org chart, the small team size still tends to bear up.  At each level, you have 6 people to help build a cohesive strategy for the corner of the org they're responsible for with enough differing voices to help identify flaws or additional opportunities in proposals.  However, the group isn't so large that building a necessary consensus requires traversing vast swaths of organizational bureaucracy.

The principle continues through to the top level of the organization, where, due to the potential impact across an entire department, decisions are parsed with more care and, therefore take longer.  A smaller core group at this level reduces the overhead of that decision-making as much as possible, and while the power is concentrated within the hands of a few people (6 group leaders plus the CTO), the team should be large enough to surface any concerns (as well as representing the aggregate voices of their sub-orgs) around any key decisions.

Design Variations

What if you don't want an additional layer of 216 managers or have an organization that won't approach 1,555 people, but still need to manage it?  Well, that's the beauty of listing assumptions in theoretical exercises - the assumptions can be easily changed to account for other scenarios.  

Many teams may have fewer than the 6 listed.  A few may have more, but orgs should take care to ensure teams don't grow too large, and that they grow with specific conditions in mind.  Otherwise, the sagging weight of adding more nodes to the communication network will require more people to handle the bureaucracy, not fewer.

That being said, I did mention that the ideal range sits somewhere between 5 and 8.  If we increase the common ratio to 8 then the total Tech department population (removing one layer of management) is 

1 + 8 + 64 + 512 = 585

If you assume that managers can handle a bit more communication overhead due to the nature of the job, but core teams should keep the overhead to a minimum, then you can use a ratio of 8 for managers and 6 for engineers/individual contributors

1 + 8 + 64 + 384 = 457

In this case, you only have one manager managing managers managing managers (i.e. the CTO) and don't have crazy edge cases of 1 person managing 20 others directly.

Theoretically, it is possible for a manager to have a large number of direct reports, but that only works if everyone has sufficient autonomy to make independent decisions.  Paradoxically, large organizations have several management layers because they want smaller parts of the organization to make more informed decisions autonomously, but, due to the size of the org and the power politics that come into play with large populations, tend to slow down the whole process waiting for a centralized decision due to the entrenched hierarchy.

If you have a healthy org, a longer chain of management is fine, because each link in the chain is empowered to make its own decisions with smaller core groups, so everyone is engaged.  But, those long management chains tend to appear as a result of empire-building, ego-branding, or micromanagement rather than to further autonomy, so the effect is easily erased.  

As usual, a healthy org, regardless of its size, will handle the org design well, and make practical adjustments rather than shoving square pegs into round holes.  The catch, however, is that (and here I'll make a bold, unverified claim) anything over 1,000 people will begin to exhibit some level of dysfunction due to the sheer population size and the resulting politics that come into play, even for an otherwise healthy org.

Begin to wander in the tens of thousands or hundreds of thousands and your first order of business is to corral the dysfunction rather than deal with it as a side effect.  This is the primary reason why smaller companies are more capable of making market moves faster.  They can focus on the needs of the customer first.  Large companies need to first ensure that they don't implode under their own weight.  Keep this in mind when deciding how nimble your own organization can be and how best to design it.

Until next time my human and robot friends.

Comments

Popular Posts