As tech layoffs continue, including Return to Office (RTO) mandates which cause attrition by design, there has been a very real pressure to focus on “efficiency” in 2023 that I am starting to see carry into 2024 plans. Meta went so far as to dub 2023 “the year of efficiency.” This focus makes sense given the macro economic state and a pace of rising interest rates not seen in 40 years.1 But how?
Coupled with the focus on efficiency, the general industry sentiment is that engineering teams are getting slower. And to that I would say: they are right. We seem to have forgotten what we know from Mythical Man Month, which I will summarize as “the fastest way to slow down a project is to add more people to it.” Despite this, the software industry has grown immensely. For example, Meta’s employee count has an exponential growth shape. While rounds of layoffs will cut this number for 2023, the shape is still exponential and the size of organizations have increased tremendously; it is due to this size increase that the sentiment of slower engineering teams arises. So, what are we going to do about it?
In addition to layoffs, another hot topic right now is measuring developer productivity through DORA, SPACE, or some other new framework. This was all amplified by McKinsey in August with this report which sparked internet backlash, such as this Pragmatic Engineer response. Of course, productivity measurement is important for performance and is common in other industries and roles (although you can see how this can be taken to an extreme with automated firing decisions based on performance). However, DORA and SPACE measurements are simply proxy metrics to help shine a light on issues; they do not solve efficiency issues on their own. In fact, they can add confusion rather than clarity.
For example, is deploying less frequently fundamentally bad? What if the service being deployed has additional compliance constraints, such as serving a regulated industry and being SOX compliant? What if we flipped the question around and asked what is good? To answer this, perhaps we look at the top 25% of teams at the company across these metrics, but this is problematic when variance is expected as per the example above or if all teams are underperforming at a company. So what do we do? I argue that jumping to such measurements to improve developer productivity is skipping ahead of a more immediate problem: inspecting your company’s organizational structure.
The Rise in Engineering Overhead Roles
Yes, I am talking about something much more uncomfortable than measuring developer productivity. I am talking about the fact that the exponential growth patterns of company size doesn’t come exclusively from engineers, but the rise in “engineering overhead” roles.
What are “engineering overhead” roles? Well, any role that isn’t a software engineer!
But wait – you’re a TPM, Straker. Are you calling yourself overhead? Yes; overhead doesn’t mean bad! In fact, some is very necessary; I am not calling these roles bullshit jobs (although this is a great read). But the keyword is some. Yet anecdotally, friends across companies, including multiple FAANG/MANGA companies, are all saying the same thing: companies have grown, but there are significantly more non-engineers in rooms now making decisions, which in turn slows things down. So why are we focusing on measuring developer productivity? My hypothesis is that on average, the teams with the worst developer efficiency have bad ratios across functions within engineering, design, product, and marketing.
Why has this happened? The answer is simple: the gamification of planning processes to enable promotion processes.
That doesn’t sound simple… Allow me to explain. For many, in order to be promoted, they need to manage a certain scope. To manage a certain scope, a minimum organizational size is expected. For example, if other VPs at the company manage 80 people, but you only manage 30 as a Senior Director, you need to increase your organizational scope in order to get promoted.
So how do you increase your organizational scope? Through planning processes! Typically, these processes happen 1-4 times/year to state what the plans are until the next cycle. In producing such a plan, leaders state how important they are and what they could do with more headcount. In turn, this process all becomes a game to “win” said headcount. Now take into account that many companies operate with 
functional or hybrid organizational structures, where there are managers for every function and the exponential shape of employee growth starts to make sense.2 This growth was never about operating a business strategically, but individuals operating to serve their own best interests.3
So what should we do instead? I will talk about how to replace this process in the future, but first you should see if your company even has this problem.
And how do we do that? You have another suite of metrics to start inspecting: ratios of managers to ICs and ratios across roles.4
The Most Important Thing: Monitor and Observe Your Ratios Over Time
You probably were expecting me to start with some “silver bullet” ratio numbers to have “the perfect organizational structure” 👌. However, I don’t believe in such rigidity here; context matters. For example, compare the team working on Tesla autopilot to a team working on an internal developer tool to make engineers more productive. You wouldn’t expect these teams to look the same, given the consequences of production failures for the autopilot team can result in human injury or death. You would expect a much slower change process and rigorous testing far above the average case. You might expect dedicated Testing/Quality resources. However, production failures for the internal tool team are perhaps acceptable compared to the cost of added testing, especially if such failures do not block internal teams’ Software Development Life Cycle (SDLC).
Taking this context into account is much easier in an integrated organizational structure, where an owner can decide what ratios make sense for their organization. Regardless of your organizational structure, the most important thing is to monitor and observe your ratios over time. Just like how DORA or SPACE metrics are indicators and don’t have globally applicable “good” or “bad” numbers, such ratios are the same. Perhaps most importantly, you need both of these metrics to draw correlations across them, allowing you to confirm or deny the hypothesis outlined in this post that slower engineering teams have more engineering overhead than others.
Will you give any ratios to serve as a baseline? Fine…
Rules of Thumb
While this is a taboo topic, it doesn’t have to be. Will Larson has written about this topic with his Sizing Engineering Teams, Hiring Ratio, and Organizational Design posts. While they are great posts, they focus on the engineering organization only; I want to focus on ratios across functions. Here are my own rules of thumb:
- I agree with Will Larson that small teams (< 4) aren’t teams. This applies to any function, not just engineering. Such small teams do not need dedicated managers.
- On the flip side, if you have more than 12 direct reports, you are not going to be able to give them individualized support; 6-8 direct reports seems to be the sweet spot.
- All ratios need to be looked at both globally and per team on a recurring basis that aligns with your planning process schedule. In a functional or hybrid organizational design, you must account for who is on what team as the org chart will not give this information.
- You do not need a PM nor a TPM for every engineering team. Rather, you should approach these functions at the organizational level which usually spans 3+ teams.
- You do not need a bunch of PM variants; be intentional with which you have at your company level. In my post, I explain that it is likely you only need a technical PM, where the P can stand for either Product or Program.
- While observing the specific ratios across roles is important, it is also important to look at the aggregate engineering overhead per team in comparison to the engineering size.
- Excluding engineering managers, there should never be more than one engineering overhead role per three engineers. This is the floor and should be the exception, not the average. For example, imagine a team of 6 engineers with a designer and a technical PM; there are situations where this makes perfect sense.
- With just a single Technical PM at the organizational level, you could have but a single engineering overhead role for 32 engineers (four teams of 8). I have personally been in this situation for a backend platform organization that had no designers, product managers, or marketers and it was an acceptable ratio for the circumstance.
Conclusion
In conclusion, it is more important to monitor organizational ratios than it is to implement a developer productivity framework. However, if you do both, you can see if correlations between the two exist that lead to decreases in developer productivity while maintaining context of specific situations.
Appendix: Good External Resources
All of these external resources are not linked earlier in this post and were discovered after I wrote it. However, they are good and worth adding here retroactively:
- Why We Don’t Ship Software as Fast as We Used To – this article would say I am “blaming it all on bloat,” but it acknowledges bloat is a big part of the problem. It is a well-written alternative but does not give any solutions to the problem. I like the article, but argue they are comparing development from 30 years ago to today, whereas I am comparing development from ~5 years ago to today. These different timescales mean both of these articles can be true simultaneously.
Footnotes
- I do not mean to say that layoffs are good, but rather that focusing on efficiency to minimize the need for layoffs is an understandable goal. ↩︎
- Meta follows a functional organizational structure, at least for many roles. TPM did not report to the same manager as SDE until the CTO while I was there, for example. ↩︎
- This violated Will Larson’s rule of putting company needs over individual wants. ↩︎
- Given I have mentioned ratios in the past, it should come as no surprise I am talking about this. ↩︎
1 Comment
Leave your reply.