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 team1. 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.
Many startup leaders address growing pains as they arise without thinking about what the root cause of any given problem can tell us about where we should solve it. ↩︎
Privacy and terms
I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.
The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.