The Scaling Function of Teams
6 min read
When I arrived in Silicon Valley, resource planning (at the large tech companies) was/is based on ratios. The formula is pretty simple, for every X Engineers there will be Y Designers.
The ratio, I heard most often and saw employed most widely was 1:10. For every 10 engineers there would be 1 designer. Where did this number come from? Why was 1:10 the perfect team? No one knew or seemed to question it. It was cannon.
It reminded me of why lawyers bill in 6 minute increments. It is easily divisible by 60. The idea that 6 minutes is a reasonable amount of time to do work isn't based in any fact, it's just easier math. I assume 1:10 is similar. It isn't accurate, It's just easy math.
While 1:10 is an arbitrary and convenient number, it isn't that far off (see Coda below). Continuous delivery software teams scale pretty linearly and there is a relationship between engineers and designers. If you tell me how many engineers are on a team, I can tell you, with reasonable accuracy, how many Designers you need. This is a neat party trick but doesn't get me invited to as many parties as you might think.
Ratios only work for teams where there is a well established relationship between the denominator (Engineers) and the function you are trying to determine resources for. It only works for self contained product or feature teams with embedded designers (not studio based models). It fails everywhere else.
Most teams scale in steps. Their scaling function is different to linearly scaling teams. If you are making a video game, the number of Designers you need has a low relationship to the number of Engineers. The scaling function is tied to the complexity and size of the game. How many levels does it have? How many unique assets (art) needs to be created? Is it a new game or part of an existing franchise?
Hardware scales based on how many concurrent programs are running. The Industrial Design team could care less about how many ML Engineers are hired as it has no relationship to their work or the resources required to do their work.
Step scaling teams need to hire for their expected output. Since people (resources) aren't very elastic (in an economic sense), these teams start off with excess capacity. Over time, they become efficient as they are given new programs, then become over worked until the next team is hired.
A marketing team can handle only so many product launches in a year. If the company adds one more product launch, a whole new team needs to be hired to handle that one additional program. A sales team can only handle so many markets. If the company wants to sell in a new country, a whole sales team needs to be spun up.
Step function teams are expensive because the resources are hired up front, not gradually. This scaling will look inefficient to finance (because it is). It looks more like a capital investment where it pays off over time vs linear scaling which scales in concert with company revenue/profits.
When scaling teams, you need to determine if its scaling function is linear or step. Finance needs to have models for both and an understanding that some teams require larger upfront investments to bootstrap them. I see a lot of managers trying to staff step function teams with linearly scaled headcount and it always ends in tears.
Ratios, are macro economic tools. They are a crude and blunt instrument. In the right context they are a quick way to estimate at scale but can not be confused as a precise tool. Too many companies use ratios as if they are a law of physics or some truth. They are not.
Coda
I have done countless estimations on ratios for design teams. After looking at too many bottom's up and top's down spreadsheets the ratio that consistently comes up is 1:7 (not 1:10). I don't know why this is the number but it is. It is a pattern that i trust and I have adopted it into my resource estimation algorithm.
In my experience, 1:10 will leave the designers chasing the backlog but can be workable depending on the product and the Designers. 1:5 can lead to out designing what can be built by the Engineers.
The more specialized the work (work that requires distinct design disciplines vs generalist designer) the more designers are required and ratios become less meaningful.
I have not found a strong ratio for UX Research or Content Design. I have struggled to find the right denominator for these disciplines. I have tried denominating against PM, Design, Eng and all end up not lacking in some way. I have had more success trying to understand what work is needed in each team and then determining resources (i.e. bottom's up planning).