THE GOAL IS TO BE LESS EFFICIENT

I've seen scaling engineering groups succeed and fail in many different types of organizations with many different teams. One thing most people don't seem to grok is how much to scale which is precisely what I'll give you a formula for in this essay.

To make it easy to explain, let's consider the work done by one engineer to equal 1 Work Unit (WU). More specifically, 1 WU = Current Work Output / n Engineers as this respects the current output of a team and normalizes 1 nth of that to a Work Unit. This WU is comprised not only of the code they write but also of the real engineering work which is the creativity and thinking that they bring to the team. Let's also ignore any resource drain they'll inflict upon the existing team when they're ramping up. Engineer = () => 1 WU

For small teams of say < 10 people the math is dirt simple. If a 5 person team currently produces 5 WU but they need to produce 10 WU, you just add 5 engineers. n WU == n Engineers

The model doesn't break for larger teams, it simply reveals itself. The equation above isn't quite right but it's close enough for back-of-the-napkin. If you want to get all fiddly about it the real equation is n WU < n Engineers > n WU - 1 Every time the team added an engineer there was something nefarious going on in the background. A bit of that engineer's time that would have gone towards a work unit was lost in communication. It's almost imperceptible in small teams but there's some time lost because the knowledge is more widely distributed across the team. Something simple like asking Arthur how he built something might result in Arthur referring the asker to Sophie who is now the SME on that topic. Not much is lost but a few crumbs fall off the table.

So what happens to slightly larger teams, say 40-75 people? More efficiency is lost. The most obvious distinction is that it's no longer a "team" at 40-75 people, it's something like an organization or department, which implies that there are multiple layers of reporting hierarchy. As a matter of necessity, more efficiency is lost. I wonder if the answer to calculating scaling needs is 1.6180339887

1.6180339887 or ϕ, is the "Golden Ratio" and is found many places in the world from the distribution of leaves on certain trees to Béla Bartók's Music for Strings, Percussion, and Celeste to the foundation of the Parthenon. I believe that this is the answer to the scaling problem for two reasons:

• The Fibbonacci Sequence increases approximately by this ratio which for some reason makes this feel "right" for scaling
• It is backed up by my own observations

The math works something like this.

A 50 person department produces 50 WUs

It needs to scale to production of 100 WUs

Headcount Needed = ( Needed WUs - Current WUs) * 1.6180339887

You need to hire 81 (rounded up).

This figure seems about right in my experience. Even if it's a bit off the principle at play is still valid. The goal is to scale. Scaling makes each employee a bit less efficient. It can be said then that the goal is to be less efficient.

I'd love to hear your thoughts or alternative ratios you've used over in the comments on LinkedIn.