How org design influences problem solving

Most startups let their organisational structure organically develop as they scale, but organisational design can surprisingly greatly impact outcomes.

Reporting lines have a big impact on how teams collaborate and what gets prioritised. It’s natural for department leaders to prioritise their department’s success (or perceived success) over company outcomes. Setting better company-wide goals can help with this, but organisational design is sometimes an even better solution.

When reporting directly to the CEO, with no other responsibilities outside of their department:

• An engineering manager will naturally focus on engineer outputs and avoid catastrophic incidents like platform outages. They might not care much about whether the features they build deliver real customer or business value.
• A product leader will naturally focus on product strategy and detailed scopes of work. If development is slow, they’ll leave it to their peers in engineering to solve. If a customer is mad, they’ll hope customer support can deal with it.
• A sales leader will do everything they can to achieve their sales goals. If the business struggles to onboard new customers, that isn’t their problem.
• A support leader will focus on solving tickets. If crucial product feedback lives within these tickets, they might fail to gather and escalate this feedback in a usable way.

Independent leaders of teams tend to care mostly about the things under their control and by which the organisation will judge them. If a leader can succeed in their job by only managing towards the perceived success of their team rather than the business’s overall success, they will often embrace this luxury. Why rock the boat with other teams unless it is necessary? This self-centricity is not their fault; focusing on what you can control is natural. Working in especially large or disempowered organisations trains people to work this way.

The problem with these departmental silos is that pain in one team is often a symptom of a problem in another team¹. Ineffective onboarding could be the fault of the customer success team. However, it could also result from poor sales qualification practices or product functionality gaps. When you solve a problem in the wrong team, you create a less effective and scalable organisation. For example, suppose you solve the onboarding problem in customer success. In that case, you might hire many unnecessary activation managers and support staff when it would be cheaper to improve the product. A product requiring a lot of hands-on help during the customer onboarding phase will struggle to scale compared to a simpler, self-service onboarding experience.

Group teams with similar problems

One way to solve this challenge is to group teams that frequently clash. When leaders own multiple departments, they will consider how one of their teams can help another. The decision of where to solve a problem becomes explicit and intentional. If you want your product strategy to be fantastic and your engineering team to deliver quickly, a single manager accountable for both outcomes will do better. Suppose you want customers to go live within a week of sales closing. In that case, a leader who owns both sales and activation will consider both the activation process and how salespeople can set up new deals for success in onboarding.

Keep executive teams small

To avoid fiefdoms from developing in the first place, startups should employ very small executive teams. Three c-suite executives with multiple department leaders reporting to them is enough to achieve diversity of opinion at the strategic level while ensuring your executives consider the total needs of the business at all times.

Embrace tension between teams when desirable

There are benefits to distance between teams in an organisational structure. Healthy tension can drive better outcomes for the business. If the success of one team is dependent on another, the first team is much more likely to hold the second accountable. Separate outbound and inbound sales teams, for example, can drive fantastic business results by demanding more from each other. The same dynamic can apply to other teams.

When deciding whether teams with shared challenges should work separately or together, consider whether your problem requires more collaboration or accountability. If you require more collaboration, it could make sense to merge your teams. If more accountability is required, segmenting teams into smaller units could work better.

Footnotes