Status:
Branching Factor
If you think of a company as a tree, I believe that most of the value of a company is created at the leaf nodes. It's the Engineers, Designers and PMs who talk to customers and build software and it's the AE's who win deals. I believe that the nodes in the graph above the leaf nodes (the managers) are a kind of necessary overhead. The management is absolutely necessary to keep the company working as one cohesive and well organised unit, and as such it's a valuable and integral part of any company. A good management team acts as a force multiplier for all the Engineers and co. They create a framework in which work can be done efficiently and impactfully. But, if you can achieve the same cohesion and force multiplier benefits with fewer managers, then that's a win. I therefore think it makes sense to organise the company in such a way to make the tree as shallow as possible, in other words with as few management levels as possible.
Short aside: Please keep in mind that I'm using a "tree" here only so that I can illustrate and explore this concept of the Manager to Engineer-and-co ratio, and what impact it has on a company. I want to make the case for why this ratio should be as small as possible. I'm neither saying that a tree is the right way to organise a company nor that it's 9Y's primary organisational structure. You could also structure a company as a Directed Acyclic Graph (DAG), or a million, other, ways. But this concept of "people who do" vs "people who tell people what to do" will always apply to some extent, regardless of the organisational structure. I'm just using a tree to explain the idea because it's the most common company structure and everyone has at least some intuition around it.
Back to the idea about the Manager to Engineer-and-Co ratio. If we want to minimise this (i.e. fewer managers, more Engineers), then that implies that our company management structure should have a high "branching factor". A higher branching factor means that a higher percentage of people in the company are of the useful kind: more engineers, fewer managers. Let me illustrate with a tree diagram.
(I'm being unkind to managers, and that's a little unfair because good managers are incredibly valuable to a company. The point here is not that managers are bad, but rather that if you can manage to get the same value with fewer managers, then that is probably better. It's this effect I'm trying to quantify.)
Here we have a branching factor of 5. For a company of 31 people, the tree is 100% full, i.e. we have hit the scaling limit of the company and can no longer add new team members without adding another layer of managers: bad. This structure has an efficiency of 81%. Efficiency is in this case defined as the proportion of people "who do things" vs "those who tell other what to do" in the company.
Let's increase the branching factor to 8. For the same company size of 31 people, the efficiency has gone up to 84%. We have lost one manager and replaced him with an engineer: win. Even more importantly, the company is now only 43% full. So we can grow to a total company size of 73 people, without adding another layer of managers: win. At 73 people, our efficiency goes up to 88%, that's less money we need to spend on management so more budget for writing code, mentoring, code reviews, etc.: win.
Okay, so a higher branching factor is better. But there's a price to pay here. Branching factor basically means: how many people someone is responsible for. And there is a natural caveman limit to this. As human beings, we have a limit to how big of a social group we are able to effectively keep track of and lead. It's hard to say what this limit is exactly, but I would guess that it's somewhere between 5 and 30 people.
So what can we do to push the branching factor to be on the higher end of the spectrum? See The Handbook for how we tackle this.
I will say though, that while the benefits are really easy to parade, it's really quite hard to increase the branching factor without having everything collapse into chaos.