The Working Definition
Organization design is not the same thing as an org chart. The chart is a map of visible structure. The design is the set of choices behind the map: how work is divided, who has authority, how teams coordinate, where decisions are made, and what capabilities the organization is building.
A good design does not remove all tension. It chooses the tensions that are worth carrying. A functional structure may deepen expertise but make product tradeoffs slower. A product structure may improve focus but duplicate specialists. A matrix may improve coordination but create ambiguity if decision rights are not explicit.
The point of organization design is not to find the "right" structure. It's to make the tradeoffs explicit and match the structure to the work the organization needs to do right now.
Useful test: if two people look at the structure and cannot tell who owns a decision, an outcome, or a handoff, the design is not yet clear enough.
When Organization Design Matters
Org design matters whenever the current structure starts shaping behavior in ways the organization no longer wants. The symptoms are usually operational, not abstract:
- Decisions are slow because too many teams need to approve the same work, or because decisions escalate to a leader who doesn't have context.
- Managers are overloaded because the structure grew faster than leadership capacity. One person is managing 12 reports across unrelated workstreams.
- Teams optimize locally while customer or product outcomes fall between functions. Sales sells features that don't exist. CS discovers implementation gaps too late.
- Accountability is fuzzy because new roles were added, but old accountabilities were never retired. Two people think they own the same outcome. Nobody owns the handoff between them.
- Strategy shifted but structure didn't. The company pivoted to enterprise but still has a small-deal sales structure. The company went multi-product but still has a single product org.
If none of these sound familiar, the current design is probably working well enough. Don't redesign a functioning organization for theoretical reasons.
The Star Model: Five Elements Of Design
Jay Galbraith's Star Model is the most useful framework for thinking about organization design because it makes clear that structure is only one of five interdependent elements. Changing one without adjusting the others creates misalignment.
1. Strategy
What is the organization trying to accomplish? Growth, efficiency, geographic expansion, product diversification, margin improvement? The strategy determines what the design needs to enable. A structure built for cost efficiency will not support rapid product innovation.
2. Structure
How is the organization grouped? Who reports to whom? How many layers exist? This is the part most people think of as "org design," but it's only one element. See Organization Structure Types for a deeper treatment.
3. Processes
How does work flow across the structure? Planning processes, approval workflows, escalation paths, and coordination mechanisms. A clean structure with broken processes will still produce slow decisions and dropped handoffs.
4. Rewards
What behaviors and outcomes does the organization incentivize? Compensation, promotion criteria, recognition, and performance evaluation. If the structure says "collaborate across teams" but rewards say "hit your individual target," the rewards win.
5. People
What capabilities does the organization need? Hiring profiles, skill development, leadership pipeline, and career paths. A design that requires leaders who don't exist yet needs a plan for how to develop or hire them.
Why all five matter together
Most org design failures happen because leaders change the structure but leave the other four elements unchanged. The classic example: a company shifts from functional to product teams. The org chart changes. But the planning process still runs through functional VPs. Incentives still reward functional depth. Career paths still run vertically through functions. The result: a product structure on paper and a functional organization in practice.
Practical rule: whenever you change one element of the Star Model, audit the other four. At minimum, ask: "Does this change create a contradiction with how we plan, how we incentivize, or what capabilities we need?"
Symptom-To-Element Diagnostic
When you see an operational problem, this table helps you identify which element of the design is most likely the root cause. Start here before deciding to restructure.
| Symptom | Most likely element | What to investigate |
|---|---|---|
| Decisions are slow | Processes or Structure | Map who is involved in the slow decisions. Is it too many approval layers (structure) or an unclear decision process (processes)? |
| Teams don't collaborate | Rewards or Processes | Are teams rewarded for cross-functional outcomes? Is there a coordination mechanism (shared metric, regular sync, liaison role)? |
| Nobody owns this outcome | Structure | Is there a role explicitly accountable for this outcome? If yes, does their reporting line give them authority over the inputs? See Role Clarity. |
| We keep hiring but can't scale | People or Structure | Are the new hires placed in the right teams? Does the structure allow them to be effective, or does onboarding bottleneck through overloaded managers? |
| Good people are leaving | Rewards or People | Are career paths clear? Are promotions tied to the work the structure needs? Are people being managed by someone who can develop them? |
| Strategy changed but nothing feels different | All five | The strategy shifted but the design didn't follow. Audit each element against the new strategy to find the gaps. |
| Managers are overloaded | Structure | Check spans, layers, and role scope. See Span of Control. |
If the root cause is Processes or Rewards, you probably don't need a reorg. Fix the process or change the incentive. If the root cause is Structure, a restructure may be necessary, but only after you've confirmed that process and reward changes can't solve it. See Reorg Planning Guide.
Org Design As Ongoing Practice, Not One-Time Event
Most companies treat org design as a periodic event: a reorg happens, the chart is redrawn, and everyone goes back to operating. Then the structure drifts for 12-18 months until the pain builds up enough for another reorg.
Better organizations treat design as a continuous practice. This doesn't mean constant restructuring. It means regularly checking whether the current design still fits the current work:
- Quarterly: Review spans and flag any manager whose load has changed significantly due to hiring, attrition, or scope changes.
- Semi-annually: Audit decision rights for the 10-15 most important decisions. Have they drifted? Are they still in the right place?
- Annually: Check whether the structure still matches the strategy. If the company's priorities shifted, identify which teams, roles, or processes need to adjust.
- At every major strategy change: Run the Star Model audit. Strategy changed, so at least one other element needs to change too.
The org chart should be a living document. If it only gets updated during reorgs, it's stale most of the time, which means people make structural decisions without an accurate picture.
Worked Example: A Company That Outgrew Its Design
A B2B SaaS company grew from 40 to 120 people in 18 months. It was functionally organized: Engineering, Product, Sales, Marketing, CS, People, Finance. This worked well at 40. By 120, several things were breaking:
- Engineering had 45 people but only one VP. She had 8 direct reports (6 engineering managers + an architect + a QA lead) and was spending all her time on cross-team coordination, not strategy.
- Product decisions took 2-3 weeks because Product, Sales, and CS each escalated conflicting priorities to the CEO.
- Customer Success reported to the CRO alongside Sales, but CS priorities (retention, adoption) consistently lost to Sales priorities (new revenue).
- Three "pods" had formed organically (engineers + a PM + a designer working together) but they didn't appear on the org chart and their leads had no formal authority.
Strategy: The company was shifting from new-customer acquisition to retention and expansion. The design needed to support a customer-led growth motion.
Structure: The functional structure created cross-functional bottlenecks. The CEO was the only integration point for product-market decisions. The VP Engineering span was unsustainable. The organic pods were a signal that the work wanted to organize differently than the chart showed.
Processes: Planning ran through functional VPs, not through the cross-functional pods that were actually building features. This created a mismatch between how work was planned and how it was executed.
Rewards: Engineering was evaluated on output (stories shipped). Product was evaluated on strategy alignment. CS was evaluated on renewal rate but didn't have influence over the product roadmap that drove renewals.
People: The three informal pod leads were ready to become formal team leads. Two of the engineering managers needed coaching on how to manage in a product-team model instead of a purely functional model.
Structure: Formalize the three product teams (each: 1 PM, 1 designer, 4-6 engineers, 1 CS representative). Create an Engineering Director layer: two directors, each overseeing 2-3 teams, reporting to the VP Engineering. Move CS out from under the CRO and into a standalone function reporting to the CEO.
Processes: Shift planning from functional to team-based. Each product team owns a customer outcome and plans quarterly against it. Functional VPs shift to capability and career development.
Rewards: Product teams are evaluated on customer outcomes (adoption, retention), not functional output. Shared metrics between teams that need to coordinate.
People: Promote the three pod leads to formal team leads. Provide management coaching for the EMs transitioning to product-team model.
What didn't change: Sales stayed under the CRO. Marketing stayed functional. Finance and People stayed as-is. Not every function needed to change for the core problem to be solved.
Common Org Design Traps
Designing around people instead of capabilities
"Sarah is great at ops and strategy, so let's give her both." This creates a role shaped like a person rather than like the work. When Sarah leaves, the replacement needs two completely different skill sets that rarely coexist. Design the role around what the organization needs, then find or develop the person who fits.
Copying another company's structure
Spotify's squad model, Amazon's two-pizza teams, and Apple's functional org all work for those specific companies given their specific strategies, scale, and culture. Copying the structure without the context is cargo-cult org design. Use frameworks, not templates.
Reorganizing when the problem is process
If approvals are slow because the approval process requires five signoffs, adding a new reporting line won't help. You need fewer signoffs. Moving boxes on a chart doesn't fix broken workflows, see the diagnostic table above.
Changing the chart without changing the operating model
The org chart says "product teams" but planning still happens in functional silos, performance reviews still run through functional VPs, and budgets still flow through functions. The chart changed; the operating model didn't. People will follow the operating model, not the chart.
Designing for the org you want instead of the one you have
The future-state chart assumes three leaders who haven't been hired yet, a culture of autonomous teams that doesn't exist, and a planning process that hasn't been built. Design for the current capabilities and build toward the aspirational state in stages.
Sources And Further Reading
- Jay R. Galbraith, Designing Organizations: An Executive Guide to Strategy, Structure, and Process.
- Henry Mintzberg, Structure in Fives: Designing Effective Organizations.
- David A. Nadler and Michael L. Tushman, Competing by Design: The Power of Organizational Architecture.
- Melvin E. Conway, "How Do Committees Invent?"
- Matthew Skelton and Manuel Pais, Team Topologies.
- Amy Kates and Jay R. Galbraith, Designing Your Organization: Using the STAR Model to Solve 5 Critical Design Challenges.
Continue Reading
Now that the design model is clear, learn how different structural groupings work and when to use each one.
Next guideOrganization Structure Types
Functional, divisional, matrix, and hybrid structures: what each optimizes for, what each sacrifices, and when to transition.