@
@EFarraro
Guest
INEFFICIENCIES IN LARGE ORGANIZATIONS
There exists a phenomenon in my many big organizations called 'shipping the org chart'. It means that in your product, users will be able to understand your org chart by how different pieces of the product work (or don't work) together.
Take the fictional org chart below
All 3 teams - DM, Email, and Notifications - have the job of communicating with and notifying the user about various events in the product. However, because each piece of the product is siloed in its own org, it can lead to less-than-ideal experience for actual users.
It also means that in many cases, the tech stack of these teams diverge from each other, and teams end up needing to implement the same logic that one of their peer teams already did.
ORGANIZATIONAL BLOAT
The org chart also leads to organizational bloat and inefficiency as well. Each team is asked to deliver more than the year before, and naturally - asks for more headcount to do it. Teams make their headcount ask and then receive some fraction of that, and then begin hiring.
Over time, this means that organizations inevitably grow over time, often in perpetuity, as expectations and goals increase every year. Pretty soon a small 8 person team is now a 50 person monstrosity.
In this fictional org chart, there are now also new levels of management (to justify the Director-level promo!), adding additional layers between the engineers and the Executive team.
What's worse is that correcting organizational bloat becomes difficult. Managers are often expected to manager larger and larger teams in order to justify a next level promotion. Engineers on teams naturally form friendships and their identity at the company becomes intertwined with the team they're a part of. Moving people between teams or shuttering projects leads to churn and conflict.
It also means that once formed, teams tend to continue to operate and focus on whatever they were originally tasked with doing, even if what they were tasked with doing is no longer important to the business. This is also hard to fix without an executive team that's willing to reprioritize.
Ironically, at large companies, there is simultaneously too much work to do, and also not enough. Big companies have big problems to solve which requires people, but on each individual team, it can often be the case where a team is overstaffed, and there is little interesting or challenging work for engineers to work on. There's typically no incentive to 'give up' headcount, and so by default, teams tend to hoard resources.
This naturally leads to a situation where companies just continue hiring and we end up where we're at today.
CONCLUSION
Unfortunately, org design and solving the problem of companies becoming slow over time is not an easy one to solve, and is more of an art than a science.
In the original example, we might better align the teams by creating a 'Messaging' team lead that focuses on how the product communicates through users in different channels (DM, Emails or Notification) and is expected to align resource allocations and technology to reduce inefficiency between teams.
Another approach, depending on the size of the company, might be to cut out the middle level completely and have a flatter org that is more accountable to the executive team.
All of these approaches have pros and cons and none of them are inherently 'better' than any other. It's common to switch between these models or reorg as the company grows or priorities shift.
One of the most eye opening aspects of Twitter 2.0 has been moving to a flatter, more fluid org structure. Engineers often move fluidly between priorities without regard to reporting structure. The result is the right people work on the right project at the right time. And with a single layer of managers between the Executive team and the engineers, it means less politics and less barriers to actually getting work done.
There exists a phenomenon in my many big organizations called 'shipping the org chart'. It means that in your product, users will be able to understand your org chart by how different pieces of the product work (or don't work) together.
Take the fictional org chart below
All 3 teams - DM, Email, and Notifications - have the job of communicating with and notifying the user about various events in the product. However, because each piece of the product is siloed in its own org, it can lead to less-than-ideal experience for actual users.
It also means that in many cases, the tech stack of these teams diverge from each other, and teams end up needing to implement the same logic that one of their peer teams already did.
ORGANIZATIONAL BLOAT
The org chart also leads to organizational bloat and inefficiency as well. Each team is asked to deliver more than the year before, and naturally - asks for more headcount to do it. Teams make their headcount ask and then receive some fraction of that, and then begin hiring.
Over time, this means that organizations inevitably grow over time, often in perpetuity, as expectations and goals increase every year. Pretty soon a small 8 person team is now a 50 person monstrosity.
In this fictional org chart, there are now also new levels of management (to justify the Director-level promo!), adding additional layers between the engineers and the Executive team.
What's worse is that correcting organizational bloat becomes difficult. Managers are often expected to manager larger and larger teams in order to justify a next level promotion. Engineers on teams naturally form friendships and their identity at the company becomes intertwined with the team they're a part of. Moving people between teams or shuttering projects leads to churn and conflict.
It also means that once formed, teams tend to continue to operate and focus on whatever they were originally tasked with doing, even if what they were tasked with doing is no longer important to the business. This is also hard to fix without an executive team that's willing to reprioritize.
Ironically, at large companies, there is simultaneously too much work to do, and also not enough. Big companies have big problems to solve which requires people, but on each individual team, it can often be the case where a team is overstaffed, and there is little interesting or challenging work for engineers to work on. There's typically no incentive to 'give up' headcount, and so by default, teams tend to hoard resources.
This naturally leads to a situation where companies just continue hiring and we end up where we're at today.
CONCLUSION
Unfortunately, org design and solving the problem of companies becoming slow over time is not an easy one to solve, and is more of an art than a science.
In the original example, we might better align the teams by creating a 'Messaging' team lead that focuses on how the product communicates through users in different channels (DM, Emails or Notification) and is expected to align resource allocations and technology to reduce inefficiency between teams.
Another approach, depending on the size of the company, might be to cut out the middle level completely and have a flatter org that is more accountable to the executive team.
All of these approaches have pros and cons and none of them are inherently 'better' than any other. It's common to switch between these models or reorg as the company grows or priorities shift.
One of the most eye opening aspects of Twitter 2.0 has been moving to a flatter, more fluid org structure. Engineers often move fluidly between priorities without regard to reporting structure. The result is the right people work on the right project at the right time. And with a single layer of managers between the Executive team and the engineers, it means less politics and less barriers to actually getting work done.
1/ BREAKING: We've obtained internal docs from @FoxNews employees. Fox Corp is celebrating Pride by encouraging employees to read about “glory holes,” supporting a group that gives sterilizing hormones to homeless youth, & deployed woke AI to monitor everyone. EXPLICIT CONTENT: