Org Chart Design for Scaling Companies

I personally use a few specific principles when thinking about organizational charts. Most of these are common recommendations in some form, but few companies intentionally outline them and advise their C-level executives around such design.

Principle #1: teams at any level should have mutually exclusive responsibilities.

This is obvious when you think of things like “technology team vs. sales team” but also within the teams… A sales team should be further broken down into mutually exclusive responsibilities across lead gen vs. closing, or specific verticals, or geographies. You can see there are many ways to break this down; the point is that in each option, every team has their own set of responsibilities.

Principle #2: teams at the VP level and above should be structured to generate a healthy tension between leaders; teams below the VP level should be structured to avoid tension all together.

First of all, it’s important to accept that junior managers and individual contributors often lack the experience and comfort with tension across team members. As such, they should not be expected to manage such tension or make decisions based on organizational tradeoffs (e.g., prioritizing a product plan over a sales opportunity). Everything below the VP level should be designed to work cohesively together.

A case in point on the sales side: a BDR team produces leads for an AE team, which further qualifies those leads and then closes deals. These separate teams work together and BDRs enable AE success; there is very little the BDR team could do that might cause organizational tension with the AE team.

On the other hand, VPs and above have the maturity and experience to manage tension in a healthy manner (and if they don’t, then they are not a good fit for the role). A hypothetical example here could be the healthy tension between sales and product… Sales teams sometimes want to overpromise product features and change roadmaps to help their sales opportunities, while product teams want to manage product roadmaps coherently with a broader product strategy. This balance needs to be understood and decided upon by the VP of Product and VP of Sales, rather than between individual sales people and individual product managers.

Principle #3: teams should be designed in a modular fashion.

Individual team members should be able to operate without dependence on external teams for their day-to-day work. This doesn’t mean there is a lack of collaboration; instead, it means that the day-to-day work of individual contributors should never be overly dependent on other team members.

Note the intentional use of “overly dependent” here. These principles are heuristics and there needs to be leeway here in particular, especially with growing teams and scaleup companies.

Principle #4: the reporting structure should align with the org chart.

This means that the actual “solid line” reporting structure needs to be exactly the same as whatever team org chart exists.

Principle #5: management and decision-making within a team should be up to the leader of the team.

This is actually a result of the above principles… If a team is modular, well-defined, and has mutually exclusive responsibilities relative to other teams, then there is no need for the broader leadership team to micromanage the team.

Principle #6: Each team should have a well-documented playbook.

The only thing one should require of an individual team is a playbook that documents the above and clarifies responsibilities, objectives, and so on.