What is Organizational design and Why It Matters

Most org charts exist because someone had to put something in a slide deck. That's the wrong reason to design an organization, and it shows: unclear ownership, duplicated work, teams that don't talk to each other until something breaks.

Organizational design is the deliberate choice of how you divide work, who has authority over what, and how different parts of the company coordinate. Done well, it makes strategy executable. Done poorly, it adds friction to everything.

What is Organizational Design?

Organizational design is the process of structuring an organization to align its people, roles, and processes with its strategy. It determines who reports to whom, who owns which decisions, and how different parts of the company work together.

What Organizational Design Actually Covers

Organizational design has 5 main components:

1. Organizational Structure is how you group people: into departments, teams, divisions, and reporting lines. A customer success team that reports to sales has different incentives than one that reports to the product org.
2. Coordination is how those groups work together. Who talks to whom, in what forum, and with what frequency.
3. Centralization is where decisions get made. A company where the CEO approves every hire operates completely differently from one where team leads have full headcount authority. See how decentralized organization structures work in practice.
4. Specialization is how narrowly you define roles. Deep specialists vs. generalists is a real tradeoff with real cost implications.
5. Formalization is how much you write down: job descriptions, approval processes, escalation paths.

Together these define who does what and how work moves through the company.

Why Organizational Design Matters More Than People Admit

Poor organizational design has predictable symptoms: nobody knows who owns a decision, the same argument gets had in 3 different meetings, good hires leave because they can't get anything done.

These aren't culture problems or people problems. They're structural problems. Fixing them requires changing the structure, not running a values workshop.

A company that has its reporting lines, decision rights, and coordination mechanisms right can execute faster with the same headcount. One that doesn't will struggle to execute even with excellent people.

McKinsey's Organizational Health Index research, drawn from over 8 million survey respondents across 2,500+ organizations, shows that companies in the top quartile of organizational health deliver 3 times the total shareholder returns of those in the bottom quartile.

Meanwhile, Gallup's State of the Global Workplace report found that only 23% of employees globally are engaged at work, a gap that traces directly to unclear direction, role ambiguity, and poor coordination, all structural problems organizational design is meant to solve.

A common example: A B2B SaaS company with separate sales and customer success teams, each reporting to different executives, will regularly produce conflicts over renewal ownership. That's not a relationship problem. It's a structural one. Putting both functions under a single Chief Revenue Officer typically resolves it in 90 days.

The reverse is also true. A company that has clear reporting lines, defined decision rights, and explicit coordination mechanisms can execute faster with fewer people. One practical tool for maintaining that clarity at scale is a live org chart, so employees always know where they sit and who to turn to.

How to Approach Org Design

Start with strategy

Your structure should reflect what you're trying to do, not what was convenient to build 3 years ago. A company shifting from product-led growth to enterprise sales needs different roles and reporting lines than one staying PLG.

Define your operating model

Before drawing boxes on a chart, get clear on the core processes that deliver value. What has to happen, in what order, and who needs to be involved?

Map roles and decision rights. For each key decision: who makes it, who has input, who gets informed. Gaps here are where projects stall.

Connect the groups. Decide how teams relate to each other. Who are the integration points between sales and product? Between legal and engineering? Don't leave this to chance.

Plan for change. An org design that works at 50 people often breaks at 150. Build in a review cadence, at least annually, and adjust as the business changes.

6 Common Organizational Design Models

Holacracy removes management layers and distributes authority to self-governing teams. It's attracted a lot of attention and produced mixed results. Zappos ran the most publicized experiment with it.

The Spotify model uses squads (small autonomous teams), tribes (collections of squads), chapters (people with similar skills across squads), and guilds (informal communities of interest). It works well for product-led organizations but tends to break down when copied wholesale by companies with different contexts or less mature engineering cultures. Self-managing teams require clear norms and explicit coordination to function without manager oversight.

Hub and spoke centralizes shared functions (legal, finance, HR) at headquarters while business units or regions run with more autonomy. Common in multinationals.

The Galbraith Star Model says you need alignment across 5 things: strategy, structure, processes, rewards, and people. If any of these point in different directions, the org will underperform.

McKinsey 7-S groups organizational elements into "hard" factors (structure, strategy, systems) and "soft" ones (shared values, skills, style, staff). The argument is that both sets have to be consistent with each other.

Burke-Litwin is more useful for organizations going through major change. It maps the relationships between leadership, culture, structure, systems, and performance, specifically to understand what to change and in what order.

None of these models is correct. They're ways of thinking about a problem that every company has to solve for itself.

The useful question is: given what we're trying to do, where are the biggest gaps between our current structure and what we need?

Start there.