Notes on Organizational Structures
With Twitter's recent change in org structure from functional to centered around GMs, I realized I don't have enough understanding of the trade-offs to have a strong opinion about it. So I decided to do some light reading. Here are my notes.
- Choosing an org model is one of the most important decisions a CEO can make, and one of the few they're entirely responsible for.
- There are two main ways to structure a business. You can build divisions around particular lines of business or you can build functional groups around particular kinds of expertise.
- There's no best model, and both can work well. The best advice is to understand the weaknesses of your current model and compensate for them.
- A common mistake new leaders make is to think that a re-org will be a silver bullet to all current problems.
- In most cases, org designs are not in the extremes of functional vs. divisional, and have a combination of both models. They also tend to work as a pendulum: when there are problems in the org, leaders try to re-org towards the other end.
- In a traditional divisional structure, each division/product line head would be responsible for their own profit and loss line on the corporate balance sheet.
- Microsoft has an executive vice president who’s in charge of Office, a different one who’s in charge of Windows and Devices, and a third one who’s in charge of Microsoft Cloud. There are software engineers working in all three groups, but nobody is in charge of “software engineering” — they are responsible for specific lines of business. That way if something goes wrong with a particular product, it’s a specific person’s fault and there are clear lines of accountability.
- Easier to scale multiple product lines.
- The CEO only needs to hire 1 person to solve the problem of each product, and doesn't need to understand much about each function in order to assess if they're performing well or not.
- Teams are focused on solving a specific problem.
- Each teams scope is clearly defined, and easier to communicate to others.
- Units that work on a specific problem may forget to solve for all 4 P's and actually create a fully functioning business, or how their piece fits into the overall company strategy.
- Multiple units will undoubtedly work on the same technology or solution without collaborating. Overlap and redundancy is almost a certainty in this model.
- This structure makes it harder to sell products as a single suite or ecosystem, as divisions are fighting to aggressively market their specific products to specific customers.
- Engineers may build the same solution multiple times, across business units, instead of shared services.
- General managers are not experts in the functions they manage, so lower quality on each is to be expected.
- Leaders only have incentives to become generalists, and may read this as a lack of career growth opportunity in their area.
- Units may spend a lot of extra time rebuilding processes, tooling, documentation, rituals, etc. because they feel this may be better for their team, which creates bigger disconnect from the rest of the company.
- This model requires more resources, especially of scarce talent like design, that in a functional org can be shared across multiple projects. Here, every unit needs their own designer which often is not used to their full capacity.
- Extreme example: Warren Buffet's Berkshire Hathaway, Microsoft
- In a functional org, each specialty (design, engineering, operations) has an executive who responds directly to the CEO.
- Extreme example: Apple
- Better for one-product companies, like smaller startups, or companies that sell ecosystems.
- When Steve Jobs introduced the functional model, he also slashed the number of product lines, which suggests that this model is better for companies who need to focus on deliver less experiences, but to perfection. It is probably less efficient for companies dealing with multiple product lines or business models.
- Marketing can sell an single, powerful story: "1 + 1 > 2", instead of selling multiple stories to different people.
- Allows for collaboration and product integration.
- Specialists have a clear career path, since they don't need to dilute skills to grow into general managers. This also helps innovation since technology is always being developed by the best people in the industry. General managers who are not tech-savvy or makers may lack this innovative skill.
- The fact there was no Senior Vice President of the Mac made it easier to come out with the iPad. The focus was on new technology and what it can enable.
- You need less managers because each of them has a deeper understanding of their direct report's craft.
- Makers are involved in decision making. At big decision moments, people at the table are specialists, not general managers representing them. Product meetings get less inflated because people managers don't need to be in the room.
- Easier to move people around, since the function manager has a clear view of all the talent available in that area. In business units, people may struggle to find a job internally if the unit is killed or pivoted.
- Harder to scale multiple products that serve different customers.
- The CEO has a harder job, since it's their job to oversee the performance of all products.
- Some products and experiences have nobody accountable to improving them
- This is why Apple is slower on lines like the Mac Pro: The functional organization values collaboration on top corporate priorities above all else, and that means basically everything (iPhone, AirPods, etc) comes ahead of desktop Macs.
- Also why they're bad at delivering digital services, like iCloud.
- Marketing can become disassociated with the product, since they're not embedded in the teams that really understand the pains being solved.
Don't ship the org chart
- This rule is aspirational. Companies always ship the org chart in some way. If you organize around business units, your products will feel more separate and perhaps more targeted, with the seams exposed and resource allocation transparent through delivery speed. If you organize around functions, you'll ship less often, less diverse, more focused products.
Know what problem you're solving
- When re-orging, you owe to the employees to be able to clearly explain why this is being done; which problems are being solved, and also what are going to be the tradeoffs.
Synthetic P&L is always evil
- In large organizations it is very hard to represent how each unit is spending and making money. In reality, many costs are shared, and units depend on one another for multiple things. Efforts to separate P&L is generally distracting, and leads to infighting and lack of focus on actual product outcomes.
Sales and geography
- It is also very hard for a global company to give business units complete ownership about how products are sold across the world. This is generally centrally managed regardless of org model.
People are not necessarily fungible
- When re-orging, it is easy to forget that people are not numbers, and have many particularities that may not work on another structure or team.
You get what you optimize for
- If you choose unit model, know that it is very unlikely that you'll get collaboration. If you choose functional model, know that you'll miss out on product diversification. You can try to minimize the risk, but still it's only a bonus if you can pull it off. You get what you choose to optimize for.