Most organizations jump straight from pain to org charts. This chapter instead gives you a small, practical toolkit of frameworks to structure your thinking: the classic levers of org design, the main structural archetypes, and proven models like 7S and the Star Model. You’ll learn how to link strategy to capabilities and structure, and how to choose and apply frameworks that fit your specific context rather than following fashion.
3.1 Classic Levers: Structure, Processes, People, Technology, Culture
Most “org design” conversations start with structure—boxes and lines. In practice, structure is one of five core levers that must be managed together: structure, processes, people, technology, and culture. If you move only one lever, you typically just push problems elsewhere.
Structure defines how work is grouped and who reports to whom. It sets the formal power lines:
- What are the major units (businesses, functions, regions)?
- Who holds P&L ownership versus support accountability?
- How many layers exist between the CEO and front line?
- How many direct reports does each leader have?
Good structural choices align with how value is created: which products, customers, or geographies matter most; where scale or specialization is needed; and where risk must be tightly controlled. Poor choices show up as confused accountability and endless escalation.
Processes are the repeatable flows of work that cut across units: how you plan, decide, develop products, serve customers, and manage risk. A “good” structure with broken processes still yields slow, painful execution. For example, you may place all customer segments under one leader, but if the sales-to-delivery handoff process is unclear, customers still experience fragmentation.
People covers roles, skills, and leadership. You can design the smartest structure in the world, but if critical roles are underpowered or filled with the wrong profiles, it will not perform. People levers include:
- Defining critical roles and expected capabilities.
- Matching individuals to roles based on strengths, not convenience.
- Designing realistic spans of control and job scopes.
- Building pipelines for future leaders into the structure.
Technology enables or constrains how you can group work and manage collaboration. Historically, co-location requirements drove structural choices; today, collaboration tools and digital platforms allow different models. However, technology also introduces dependencies: global platforms favor centralization, while fragmented systems often force redundant roles across units. As you design structure, you should know what your core platforms can and cannot support.
Culture is how things really get done: norms, behaviors, and unwritten rules. Culture and structure interact in predictable ways. A highly consensus-driven culture placed in a design requiring fast, unilateral decisions will struggle. A culture of strong local entrepreneurship may resist heavy centralization more than a culture used to centralized control. You can use structure to nudge culture (for example, creating cross-functional teams to foster collaboration), but you must be realistic about how far the culture will stretch in the short term.
A practical way to keep the five levers integrated is to ask, whenever you propose a structural change:
- What processes must change or be created for this structure to work?
- What roles and capabilities become critical in the new design?
- What technology implications does this have (data, systems, tools)?
- How does this align with, or challenge, existing cultural norms?
If you cannot answer those questions, you are not doing organizational design; you are just redrawing the org chart.
3.2 Common Org Models: Functional, Divisional, Matrix, Networked, Agile
While each company is unique, most organizations use variations of a few archetypal models. Knowing these models, and their typical strengths and risks, helps you design consciously rather than reinventing from scratch.
Functional structure groups people by expertise: marketing, operations, finance, HR, technology, and so on. It is common in smaller or more focused businesses, or where efficiency and depth of expertise matter most.
Strengths:
- Deep specialization and professional standards.
- Economies of scale within functions (shared tools, training, processes).
- Clear communities of practice and career paths.
Risks:
- Weak end-to-end accountability for customer outcomes.
- “Silo” mentality; cross-functional coordination is slow and political.
- Strategic trade-offs are escalated to the top because no one function owns the whole picture.
Divisional structure (or business unit model) groups around products, customer segments, or geographies. Each division often has its own P&L, with functional resources embedded locally.
Strengths:
- Clear accountability for results by division or segment.
- Decisions closer to customers and markets.
- Ability to tailor offerings and operations to different contexts.
Risks:
- Duplication of functional capabilities across divisions.
- Internal competition for resources and customers.
- Harder to maintain enterprise-wide standards and one-company experience.
Within divisional models you typically choose a primary basis of grouping:
- Product or business line – best where product economics and innovation cycles differ materially.
- Customer segment – best where needs and economics differ sharply by segment.
- Geography – best where regulatory conditions, logistics, or cultural differences dominate.
Matrix structures overlay two (sometimes three) dimensions—for example, regions and product lines, or functions and business units—and assign joint accountability. Leaders may have dual reporting lines, and decisions are made through shared governance.
Strengths:
- Ability to reflect multiple critical dimensions (e.g., global product consistency plus local adaptation).
- Shared ownership of cross-cutting priorities.
- More flexible deployment of resources across units.
Risks:
- Ambiguity about “who is really the boss.”
- Slower decisions due to joint sign-offs and negotiation.
- High demands on leadership behaviors and conflict resolution.
Matrix models can work, but only if you are very explicit about who decides what and how conflicts are resolved. Many “bad matrices” are actually good designs executed with weak decision-rights clarity.
Networked or platform models emphasize small, loosely coupled units connected by common platforms and standards rather than rigid hierarchies. Central teams manage shared infrastructure (data, technology, brand, ways of working), while semi-autonomous units innovate at the edge.
Strengths:
- High adaptability and innovation at the periphery.
- Efficient use of common platforms and assets.
- Attractive to entrepreneurial talent.
Risks:
- Potential for fragmentation if platform standards are weak.
- Harder to manage accountability if interfaces are vague.
- Requires strong central “platform leadership” with clear authority over standards.
Agile or squad-based models organize work around stable, cross-functional teams (squads) aligned to products, journeys, or value streams. These teams are often grouped into tribes, supported by chapters (functional communities) and centers of excellence.
Strengths:
- Short decision cycles and rapid iteration.
- Strong end-to-end ownership of products or journeys.
- High engagement where teams are empowered and protected from churn.
Risks:
- Over-application in parts of the business that do not need agile (e.g., stable back-office processes).
- Difficulty maintaining functional depth and standards if chapters are weak.
- Requires disciplined portfolio and capacity management to avoid overload.
Most sizable organizations end up with hybrid designs: for example, a divisional core with agile product teams inside, supported by some shared services and centers of excellence. The key is to be explicit about the dominant model in each part of the business and to design the interfaces between them.
When you consider which model to use, ask:
- What must be owned end-to-end for us to win (products, customer journeys, regions)?
- Where do we derive scale and expertise (functions, platforms, shared services)?
- Which dimensions must leaders see simultaneously (e.g., global product and local market), and where is a matrix truly worth the cost?
The answers will guide you to the right “mix” of archetypes.
3.3 Design Logic: From Strategy to Capabilities to Structure
Frameworks are useful only if they are anchored in a clear design logic. Without it, teams jump straight from strategy presentations to drawing org charts. A more disciplined sequence is:
- Clarify the strategy and value agenda.
What are the specific ways the organization plans to win in its markets over the next 3–5 years? For example: capture share in mid-market customers, shift mix to recurring revenue, lead on service reliability, or expand into adjacent markets. - Identify critical capabilities and value streams.
For each strategic priority, ask: what must we be great at to deliver this? Capabilities might include solution selling, rapid product innovation, advanced analytics, cost-efficient operations, or regulatory risk management. Value streams are the end-to-end flows that deliver outcomes, such as “acquire and onboard customers,” “develop and launch products,” or “settle and report transactions.” - Determine the primary ownership logic.
Decide which capabilities and value streams require a single accountable owner. This is where structural choices become concrete:- If superior product innovation is key, you may want strong product units with clear P&L.
- If delivering a seamless customer journey is key, you may want segment- or journey-based units.
- If efficiency and risk control in operations are key, you may favor centralized functions and shared services.
- Choose the structural archetype and grouping.
Based on the ownership logic, choose a primary basis for grouping units (product, customer, geography, function) and decide where you will accept duplication versus where you need centralization and shared platforms. - Design roles, interfaces, and governance around that logic.
Once you know who owns what, you can define:- Which decisions they make.
- Which processes they lead.
- How they interface with others.
- What governance forums exist to align across units.
A simple checklist to test whether your design is strategy-led:
- Can each top-level unit explain which part of the strategy it owns?
- Can you map each strategic priority to a clearly accountable leader or unit?
- Do your critical capabilities sit in places where they have enough power, resourcing, and clarity?
- Do value streams cross as few structural boundaries as practical, consistent with risk and efficiency?
If you cannot draw a straight line from strategy → capabilities → structure for each major design choice, you are likely optimizing for convenience, personalities, or history—not for the future.
3.4 Comparative Approaches: McKinsey 7S, Galbraith Star Model, Operating Model Frameworks
Several well-known frameworks can help you make sense of organizational choices. Used correctly, they act as lenses rather than prescriptions.
The McKinsey 7S Framework looks at seven elements: strategy, structure, systems, skills, staff, style, and shared values. It reminds you that structure is only one piece of a larger alignment equation. In org design work, 7S is particularly useful for:
- Checking alignment: does the proposed structure fit the strategy, systems, and culture (style/shared values)?
- Identifying non-structural issues: for example, you may discover that the real constraint is skills or systems, not structure.
- Planning implementation: you can use 7S as a checklist for what else must change besides the org chart.
The Galbraith Star Model also offers a holistic view, with five points: strategy, structure, processes, rewards, and people. It is especially pragmatic for org design because it places structure among other core design decisions you must make together. Practically, the Star Model encourages you to ask:
- How should we structure units and roles to support the strategy?
- Which processes and information flows cut across that structure and must be designed explicitly?
- How do rewards and performance management reinforce the behaviors needed in the new design?
- How do we select, develop, and deploy people within this structure?
“Operating model” frameworks vary in terminology, but most cover similar dimensions: structure and governance, processes and activities, technology and data, people and capabilities, and sometimes culture. They are useful when your mandate is broader than structure alone—for instance, when you are redesigning the organization as part of a digital or functional transformation.
In practice, you do not need to choose a single framework and apply it rigidly. Instead, you can:
- Use 7S or a similar model at the outset to align the leadership team on the full scope of change.
- Use the Star Model or equivalent to structure design workshops and decision areas (structure, processes, rewards, people).
- Use an operating-model lens to ensure that technology, data, and process implications of structural choices are addressed.
What matters is consistency: pick one or two frameworks that your team understands, and stick with them throughout the design and implementation. Constantly switching models confuses people and dilutes alignment.
3.5 Choosing the Right Framework for Your Context
With many frameworks and models available, the risk is “framework shopping” instead of decision-making. The right approach is the one that helps your leadership team make clear, coherent choices and execute them. You can choose frameworks by asking three questions.
1. What is the scope and depth of the change?
- If you are primarily moving boxes (e.g., consolidating business units, changing reporting lines), a lightweight org design approach with a focus on structural archetypes, decision rights, and spans/layers may be enough.
- If you are changing how the business operates end-to-end (new business model, major digital transformation), an operating model framework that includes processes and technology is more helpful.
- If you are also shifting culture, leadership behavior, and capabilities, consider using 7S or the Star Model to keep non-structural levers visible.
2. How mature is the organization in dealing with frameworks?
- If the leadership team is not familiar with formal models and has limited patience for theory, it is better to use simple visuals and language (“who owns what”, “how we group work”, “how decisions get made”) than introduce multiple complex frameworks.
- If your organization already uses a particular model (for example, a corporate-wide operating model framework), aligning your org design to that shared language often increases traction and reduces confusion.
3. What decisions do you actually need to make?
Work backwards from the decisions on the table:
- Are you debating how to group units (functional vs product vs geography)? Then focus on archetypes and design logic from strategy to structure.
- Are you trying to clarify decision rights in a matrix environment? Then use a decision-rights tool (such as RACI or RAPID) and governance-focused lenses.
- Are you wrestling with end-to-end performance (e.g., customer journey, time-to-market)? Then use a value-stream or process lens and consider agile or networked models where appropriate.
A short practical guideline:
- Use one core strategy-to-structure logic (strategy → capabilities/value streams → structure) as your spine.
- Add one holistic alignment framework (7S, Star, or a corporate operating model) to ensure you do not ignore critical levers.
- Add one or two specific tools where needed (decision-rights frameworks, span-and-layer guidelines, agile playbooks).
Resist the temptation to layer many frameworks. The measure of success is not whether you have applied every model correctly, but whether your top team can clearly explain why the organization is designed the way it is, what trade-offs were made, and how that design will help deliver the strategy.
