Joshua, thanks a lot! I work with and in organisation of 10 up to a few hundred. That's why some layers, etc. weren't relevant to me until now. I can fully support two things in this article from experience:
* The Ratios are important! Being PM-Heavy creates an overhead, often a pulling in differing strategic direction and is thereby making complex situations worse!
* Keep it flat! there is no need for I-shaped organisations - especially if it only about promoting people so there is an excuse to pay them more than others!
**Being “PM heavy” or worse, “PM-manager-heavy,” means you have folks churning out ideas that you don’t have the people to build. Avoid this if you can.**
So true! (and I'm a PM!)
I've seen a similar dysfunction with program manager ratio -- too many people inventing process you don't need/slicing up initiatives into smaller programs and then failing on cross-coordination. Would love your take on the ratio for key roles like program/project management and design.
Although I started as an engineer, and manage engineers (and product now), much of my career was as a Product Manager - and the most unhappy times where when I was in PM heavy orgs.
To answer your other question, these are my personal opinions, and I've seen a lot of variation in how this is handled, but I think the same comment above applies - don't create make-work positions just because people think the role *should* matter.
For TPMs, my thinking has changed a lot over the years. I'd honestly have as few as possible. Engineering managers should be working with each other, and also designing so their products are communicating through hardened APIs between products & automated release processes - not through individual coordination.
For small orgs & companies I'd have no TPMs. If you have confusion about priorities, this is not a problem TPMs will fix, and if you aren't executing well, check what your engineering managers are doing/not doing.
As you become huge, TPMs help with the mechanics on very large projects (especially those that span orgs, time zones, etc) where status updating, escalations, etc are the norm. 1 TPM for an org of 100 is usually plenty, with two preconditions. First, your product managers and engineering managers and senior staff continue to own the day-to-day mechanics of organizing the team and tracking their execution, off-loading this to TPMs is an unnecessary layer of indirection. Second, you need a mechanism for defining org and company priorities that isn't TPMs communicating to TPMs or Orgs negotiating with each other. I actually wrote a bit about the power of OKRs to drive prioritization and make it obvious what everyone should be working on (including across departments): https://joshuaburgin.substack.com/p/using-okrs-to-manage-your-business
People are under the mistaken impression that if they struggle with getting everyone to align, the answer is more low-level processes or people embedded in orgs whose job it is to discuss status with each other. It never, ever works. This is a company decision-making problem.
You also need to avoid what my old boss used to call the "Bee Watcher Watcher" problem (which is named after a Dr Suess poem where people keep adding layers of "watchers" to make sure something happens) https://seuss.fandom.com/wiki/Hawtch-Hawtcher_Bee_Watcher
In terms of Design - it honestly depends on the kind of product and type of company. If you're building developer or enterprise facing products, you're going to see far less designers. UI/UX still matters, but PMs and Eng leadership should know the customer well enough to design the APIs themselves, and to measure adoption. These folks are doing the "user research". Consoles and UI/UX then is more the polish on top of the product. I'd say you only need 1-2 UI/UX people per org of around 100. If you're building consumer-facing products (or games), you might see a UI/UX person per sub-org (more like 1 designer per PM/per 25 engineers or so) because the UI/UX is such a core part of the customer experience, and honestly engineers and PMs are often pretty bad at this ;)
In either case, if you're large enough you'll have a central Design/User Research team working on things that are "pan-product" (or cross-company), for example making sure the console has a common look-and-feel, or that every designer uses the same framework (which can have a real effect on user experience if you don't) and it's hard to ascribe a ratio to this, but it's a small supporting org, and we're talking when you have 500, 1000 or more developers.
Hi Joshua, thanks for posting, I think there are some good points but also some troubling ideas in what you are sharing. I have spent 30+ years in tech myself and have worked almost every position up to VP for world-class brand name companies and bootstrapping startups. Here are my thoughts; your article is very qualitative, and you are not backing any of your suggestions with good references or data, only personal opinions or experience. You are also mirroring old models and we keep copying broken code. In management, I would suggest much smaller tiger teams, 5-6 max, after that point, it quickly becomes unwieldy to effectively build a high-performing team. The manager-senior manager - director - senior director- vp model is so bloated and dead. Half the time the top-level management is very out of touch with what is going on at the front lines and they are spending all their time operating in the same circles as their peers, they need to be in high contact with their teams on the plant floor. Organizations should be much flatter to have effective communication and quick decision-making - many small teams with managers > 1-3 high-performing directors (if you go past 4 something is very wrong) > 1-2 killer VPs. Cut the cruft and eliminate the excess directors, the senior managers and senior directors, you are just creating a very bloated organization. There are at least a couple of things needed to back this optimization - a good organizational framework, a supportive non-tribunal environment that encourages transparency and communication, standardized seamless high-frequency clear channels for naturally communicating state, continuous revision and improvement to how teams are working the list goes on... We don't need highly technical managers; we need good quality managers who understand their mission and are good at getting people to execute. Managers are the bread and butter of getting your work done, to often left to support the game of telephone to the elongated management chain. The number of organizations I have seen where the management chain is bloated and appears out of touch with the state of their business is ridiculous, I would say it has been 8 out of 10. Businesses continue to adopt aging broken models and expect them to perform, we need to be agents for change.
Thanks for your perspective Richard. Spans and layers, when properly implemented, measured and actively monitored, do serve to ensure you don't have excessive amount of management or hierarchy. As well, the concept of organizational health reviews that look at whether teams are deviating from these rules help guard against bloat.
I'm sure there's lots to debate about with regards to specific numbers under a manager, director or VP, or what are too many or too few layers to be effective, but fundamentally I've only seen this fail when people use "motivated reasoning" as to why their organization should deviate (needing more layers, more senior management, fewer ICs per manager/director/VP, etc)
love it. I Feel seen. Another problem with junior going beyond 30%, besides onboarding, increases what I call the institutional senior engineers. Those promoted from within with little actual experience in the field.
This kind of broad brush of ratios is really dangerous. The focus should be on value creation - plenty of functions work in many cases just fine as I-shaped from PMs, Design, QA, Architects to Master Data Managers. Such broad brushes miss out on the productivity flow of work through the product development lifecycle. Flatter DevOps can have higher ratios, support and sales engineers too.
I think you’re barking up the wrong tree. Seek what is valuable and remove what is waste. Given this, Ratio based thinking is dangerous.
Org health is fundamentally about two things: 1) How well the team works together, focusing on things like employee satisfaction and culture metrics, promotion velocity, regretted attrition rates; 2) A measurement of how close the org is structurally to these "golden rules" - think of it like a macro-version of being personally healthy (the right work/life balance, physical & mental health). A "healthy" org has each element in balance (junior/senior, IC/management, PM/Dev)
Org Effectiveness, on the other hand, is all about getting the job done efficiently and meeting objectives - shipping high quality product, meeting usage and revenue targets. I'd argue that healthy orgs are more *likely* to be effective, but it's not a guarantee. There are other factors that go into making an org effective - including practices I'm thinking about for a future blog post. And you can even have a very effective org, at least short term, without it being healthy at all (through short-term focused incentives)
On the second question my personal experience with DAOs and Holocracy them is quite limited. The few examples of Holocracy I've seen didn't seem to work too well (Zappos comes to mind) and DAOs are still very new. However, success can vary based on context, so there may still be something to them I haven't learned yet.
Thank you, I appreciate you responding. Your reply inspired me to think of a useful pyramid where org health is at the base and org effectiveness is on top of that, but both levels are also made up of distinct sections. That's as far as I've gotten. I might have a play with it and post something. If I do, I'll be sure to credit you for the inspiration! :-)
What's the definition of "early stages" of a product when 1:1 PM to engineer ratio is considered, and how is it different from Early Life Shipped Products when 1:7 to 1:10 is more acceptable?
Early stage would be during definition or alpha/private beta - pre GA/shipping broadly to customers. When most of the work is still defining what the product should do and how you’re going to bring it to market (and at what price, etc)
I commented about design/UX in response to another request just a bit ago. Marketing is probably similar to what I wrote about design. If you're primarily consumer focused, you could see a 2:1 PM to PMM (product marketing manager) ratio - as the PMMs are doing a lot of inbound/outbound marketing campaigns, driving customer acquisition campaigns and so on. If you're doing B2B products, you could see 10:1 PM to PMM ratio - as you're more focused on moving the needle with analysts, CIO/CTO-level decision makers and enterprise tech publications.
I've seen what I believe is a lot of excess in this area during the "zero interest rate"/free money years. Too much DevRel, too much Product Marketing, and not enough clarity on what results these orgs are really driving. I think both of these roles are incredibly important, and should be staffed & funded well - and I've worked with some great folks in these functions. But it's time to restore some balance there.
Satya and I have built a niche brand where we are focusing on [purpose/benefit]. I think you can benefit a lot from this. The business fee is $1000 and will give you [Special Benefits]. If you are interested, please let me know. Thank you,
Joshua, thanks a lot! I work with and in organisation of 10 up to a few hundred. That's why some layers, etc. weren't relevant to me until now. I can fully support two things in this article from experience:
* The Ratios are important! Being PM-Heavy creates an overhead, often a pulling in differing strategic direction and is thereby making complex situations worse!
* Keep it flat! there is no need for I-shaped organisations - especially if it only about promoting people so there is an excuse to pay them more than others!
**Being “PM heavy” or worse, “PM-manager-heavy,” means you have folks churning out ideas that you don’t have the people to build. Avoid this if you can.**
So true! (and I'm a PM!)
I've seen a similar dysfunction with program manager ratio -- too many people inventing process you don't need/slicing up initiatives into smaller programs and then failing on cross-coordination. Would love your take on the ratio for key roles like program/project management and design.
Although I started as an engineer, and manage engineers (and product now), much of my career was as a Product Manager - and the most unhappy times where when I was in PM heavy orgs.
To answer your other question, these are my personal opinions, and I've seen a lot of variation in how this is handled, but I think the same comment above applies - don't create make-work positions just because people think the role *should* matter.
For TPMs, my thinking has changed a lot over the years. I'd honestly have as few as possible. Engineering managers should be working with each other, and also designing so their products are communicating through hardened APIs between products & automated release processes - not through individual coordination.
For small orgs & companies I'd have no TPMs. If you have confusion about priorities, this is not a problem TPMs will fix, and if you aren't executing well, check what your engineering managers are doing/not doing.
As you become huge, TPMs help with the mechanics on very large projects (especially those that span orgs, time zones, etc) where status updating, escalations, etc are the norm. 1 TPM for an org of 100 is usually plenty, with two preconditions. First, your product managers and engineering managers and senior staff continue to own the day-to-day mechanics of organizing the team and tracking their execution, off-loading this to TPMs is an unnecessary layer of indirection. Second, you need a mechanism for defining org and company priorities that isn't TPMs communicating to TPMs or Orgs negotiating with each other. I actually wrote a bit about the power of OKRs to drive prioritization and make it obvious what everyone should be working on (including across departments): https://joshuaburgin.substack.com/p/using-okrs-to-manage-your-business
People are under the mistaken impression that if they struggle with getting everyone to align, the answer is more low-level processes or people embedded in orgs whose job it is to discuss status with each other. It never, ever works. This is a company decision-making problem.
You also need to avoid what my old boss used to call the "Bee Watcher Watcher" problem (which is named after a Dr Suess poem where people keep adding layers of "watchers" to make sure something happens) https://seuss.fandom.com/wiki/Hawtch-Hawtcher_Bee_Watcher
In terms of Design - it honestly depends on the kind of product and type of company. If you're building developer or enterprise facing products, you're going to see far less designers. UI/UX still matters, but PMs and Eng leadership should know the customer well enough to design the APIs themselves, and to measure adoption. These folks are doing the "user research". Consoles and UI/UX then is more the polish on top of the product. I'd say you only need 1-2 UI/UX people per org of around 100. If you're building consumer-facing products (or games), you might see a UI/UX person per sub-org (more like 1 designer per PM/per 25 engineers or so) because the UI/UX is such a core part of the customer experience, and honestly engineers and PMs are often pretty bad at this ;)
In either case, if you're large enough you'll have a central Design/User Research team working on things that are "pan-product" (or cross-company), for example making sure the console has a common look-and-feel, or that every designer uses the same framework (which can have a real effect on user experience if you don't) and it's hard to ascribe a ratio to this, but it's a small supporting org, and we're talking when you have 500, 1000 or more developers.
Hope this helps and keep the questions coming!
Hi Joshua, thanks for posting, I think there are some good points but also some troubling ideas in what you are sharing. I have spent 30+ years in tech myself and have worked almost every position up to VP for world-class brand name companies and bootstrapping startups. Here are my thoughts; your article is very qualitative, and you are not backing any of your suggestions with good references or data, only personal opinions or experience. You are also mirroring old models and we keep copying broken code. In management, I would suggest much smaller tiger teams, 5-6 max, after that point, it quickly becomes unwieldy to effectively build a high-performing team. The manager-senior manager - director - senior director- vp model is so bloated and dead. Half the time the top-level management is very out of touch with what is going on at the front lines and they are spending all their time operating in the same circles as their peers, they need to be in high contact with their teams on the plant floor. Organizations should be much flatter to have effective communication and quick decision-making - many small teams with managers > 1-3 high-performing directors (if you go past 4 something is very wrong) > 1-2 killer VPs. Cut the cruft and eliminate the excess directors, the senior managers and senior directors, you are just creating a very bloated organization. There are at least a couple of things needed to back this optimization - a good organizational framework, a supportive non-tribunal environment that encourages transparency and communication, standardized seamless high-frequency clear channels for naturally communicating state, continuous revision and improvement to how teams are working the list goes on... We don't need highly technical managers; we need good quality managers who understand their mission and are good at getting people to execute. Managers are the bread and butter of getting your work done, to often left to support the game of telephone to the elongated management chain. The number of organizations I have seen where the management chain is bloated and appears out of touch with the state of their business is ridiculous, I would say it has been 8 out of 10. Businesses continue to adopt aging broken models and expect them to perform, we need to be agents for change.
Thanks for your perspective Richard. Spans and layers, when properly implemented, measured and actively monitored, do serve to ensure you don't have excessive amount of management or hierarchy. As well, the concept of organizational health reviews that look at whether teams are deviating from these rules help guard against bloat.
I'm sure there's lots to debate about with regards to specific numbers under a manager, director or VP, or what are too many or too few layers to be effective, but fundamentally I've only seen this fail when people use "motivated reasoning" as to why their organization should deviate (needing more layers, more senior management, fewer ICs per manager/director/VP, etc)
love it. I Feel seen. Another problem with junior going beyond 30%, besides onboarding, increases what I call the institutional senior engineers. Those promoted from within with little actual experience in the field.
Yes! Having a balance of internally grown talent and external hires is a good way to avoid monoculture. Or as I like to call it “talking to yourself”
This kind of broad brush of ratios is really dangerous. The focus should be on value creation - plenty of functions work in many cases just fine as I-shaped from PMs, Design, QA, Architects to Master Data Managers. Such broad brushes miss out on the productivity flow of work through the product development lifecycle. Flatter DevOps can have higher ratios, support and sales engineers too.
I think you’re barking up the wrong tree. Seek what is valuable and remove what is waste. Given this, Ratio based thinking is dangerous.
Hey Joshua, your knowledge of and thoughtfulness about bureaucratic structures is impressive! I have 2 things I'm wondering.
1 Could you please explain the difference between org health and org effectiveness more explicitly? This didn't sink in for me.
2 More so I'm really intrigued to know if you have a take on completely different org designs like holacracy, self-management or even DAOs?
Org health is fundamentally about two things: 1) How well the team works together, focusing on things like employee satisfaction and culture metrics, promotion velocity, regretted attrition rates; 2) A measurement of how close the org is structurally to these "golden rules" - think of it like a macro-version of being personally healthy (the right work/life balance, physical & mental health). A "healthy" org has each element in balance (junior/senior, IC/management, PM/Dev)
Org Effectiveness, on the other hand, is all about getting the job done efficiently and meeting objectives - shipping high quality product, meeting usage and revenue targets. I'd argue that healthy orgs are more *likely* to be effective, but it's not a guarantee. There are other factors that go into making an org effective - including practices I'm thinking about for a future blog post. And you can even have a very effective org, at least short term, without it being healthy at all (through short-term focused incentives)
On the second question my personal experience with DAOs and Holocracy them is quite limited. The few examples of Holocracy I've seen didn't seem to work too well (Zappos comes to mind) and DAOs are still very new. However, success can vary based on context, so there may still be something to them I haven't learned yet.
Thank you, I appreciate you responding. Your reply inspired me to think of a useful pyramid where org health is at the base and org effectiveness is on top of that, but both levels are also made up of distinct sections. That's as far as I've gotten. I might have a play with it and post something. If I do, I'll be sure to credit you for the inspiration! :-)
What's the definition of "early stages" of a product when 1:1 PM to engineer ratio is considered, and how is it different from Early Life Shipped Products when 1:7 to 1:10 is more acceptable?
Early stage would be during definition or alpha/private beta - pre GA/shipping broadly to customers. When most of the work is still defining what the product should do and how you’re going to bring it to market (and at what price, etc)
Hello!
I’m curious, do you have golden rules around organization of research (design, market, UX, etc.) in this space?
Thank you?
I commented about design/UX in response to another request just a bit ago. Marketing is probably similar to what I wrote about design. If you're primarily consumer focused, you could see a 2:1 PM to PMM (product marketing manager) ratio - as the PMMs are doing a lot of inbound/outbound marketing campaigns, driving customer acquisition campaigns and so on. If you're doing B2B products, you could see 10:1 PM to PMM ratio - as you're more focused on moving the needle with analysts, CIO/CTO-level decision makers and enterprise tech publications.
I've seen what I believe is a lot of excess in this area during the "zero interest rate"/free money years. Too much DevRel, too much Product Marketing, and not enough clarity on what results these orgs are really driving. I think both of these roles are incredibly important, and should be staffed & funded well - and I've worked with some great folks in these functions. But it's time to restore some balance there.
Satya and I have built a niche brand where we are focusing on [purpose/benefit]. I think you can benefit a lot from this. The business fee is $1000 and will give you [Special Benefits]. If you are interested, please let me know. Thank you,
I have a newsletter about organisational values that you may be interested in. Thank you.