Designing the organization and governance is where your target operating model becomes real for people. This is where you decide who owns what, how power is distributed, how decisions are made, and how leaders actually work together.
If you treat this as just “drawing an org chart,” you will get exactly that: a picture on a slide, followed by months of confusion and informal workarounds. If you design structure and governance as an integrated system, you get clarity, speed, and a platform for scale.
This chapter focuses on four practical questions:
- What should be the primary logic of your structure?
- How will decisions actually get made and coordinated?
- How many layers and spans make sense, and which roles truly matter?
- What patterns and design criteria can you reuse instead of starting from scratch?
6.1 Choosing the Macro-Structure: Product, Region, Function, Platform
The macro-structure is the high-level way you break the company into major units. It answers questions like:
- Do we organize primarily by product, customer segment, geography, function, or platform?
- Where do P&L responsibilities sit?
- What is global vs regional vs local?
There is no universal “right” answer. There are a few recurring archetypes, and your choice should follow from your strategy and value streams, not from fashion or tools.
The main organizing logics are:
- Functional
- Group by capabilities: Sales, Operations, IT, Finance, HR, Risk.
- Works when products are simple or similar, and scale/standardization is critical.
- Risk: functions optimize for their own priorities rather than end-to-end value.
- Product or business line
- Group by product families or business lines with distinct economics or markets.
- Works when product strategies diverge, or when regulatory or risk profiles differ.
- Risk: duplication of functions; harder to maintain global standards and leverage shared capabilities.
- Customer segment or channel
- Group by segments (e.g., Retail, SME, Corporate) or channels (e.g., Direct, Partners, Online).
- Works when different segments need fundamentally different propositions, journeys, and economics.
- Risk: product and tech fragmentation across segments; under-leveraged scale.
- Geography / region / country
- Group by region or country P&Ls.
- Works when local regulation, customer needs, and competitive dynamics vary materially.
- Risk: many local variants; complex global alignment; slower adoption of global platforms.
- Platform / capability
- Group around shared platforms or capabilities (e.g., global operations, engineering platforms, digital products).
- Works when products are delivered via shared tech and operational backbones.
- Risk: can feel remote to commercial teams; risk of disconnect from end customers if not well integrated.
In practice, most organizations end up with a primary axis (e.g., customer segment or product) and one or two secondary organizing layers (e.g., regions, functions). The mistake is to design a full-blown matrix where everything is primary and nothing is clearly accountable.
A pragmatic way to choose your macro-structure:
- Start from your value streams and P&L logic
- Ask: Where does value really get decided?
- If performance is primarily driven by segments, segment-based or product-based P&Ls may be right.
- If it’s primarily driven by local regulation and distribution, regional or country P&Ls may be appropriate.
- If it’s primarily driven by global platforms and scale, a platform or global business-line structure often works better.
- Choose one primary owner of economic performance
- Decide who is on the hook for outcomes: segment head, product head, regional head, or some combination with a clear “first among equals”.
- Draw a line: “This is where P&L accountability sits.” Everything else is support or enabling structure.
- Map supporting functions and platforms around that core
- Decide which functions are embedded locally, which are centralized, and which operate as shared platforms.
- Use your design principles: if you have a principle of “global platforms, local go-to-market,” you likely end up with:
- Global or regional operations and tech.
- Segment- or region-owned sales and P&L.
- Keep the matrix as light as possible
- If you must have dual reporting, be specific:
- Who rates performance?
- Who sets compensation?
- Who decides on hiring, firing, and promotion?
- Where possible, make one reporting line “solid” and the others “dotted” with clearly bounded scope.
- If you must have dual reporting, be specific:
A simple test of macro-structure quality:
- Can you explain to a mid-level manager in two minutes who ultimately owns:
- Revenue and margin for their product/segment?
- Major investment decisions?
- Key customer journeys?
- Does each unit have a clear, understandable “reason to exist” in the value streams?
6.2 Decision Rights, Forums, and Governance Architecture
Even a good structure fails if governance is vague. The biggest complaints in TOM work are often:
- “We don’t know who decides.”
- “We decide the same things over and over.”
- “Everything escalates to the top.”
A robust governance architecture has three components:
- Clear decision rights for the most important decisions.
- A small number of well-defined forums.
- Simple, predictable escalation paths.
You do not need to document every decision in the company. Focus on the critical, recurring decisions that shape performance and risk, such as:
- What products to launch, modify, or retire.
- How to allocate major investment (capex, tech, large hires).
- How to set pricing, discounting, and exceptions.
- How to approve large deals or contracts.
- How to set and enforce risk policies and appetite.
- How to shape organization structure and key appointments.
For these decisions, define:
- Who is accountable for the final decision.
- Who must be consulted, and at what stage.
- Which body, if any, formally endorses or ratifies.
Use whatever decision-rights language your organization prefers, but keep it simple. The key is that, for each critical decision, people can answer:
- “Who has the final say?”
- “Whose input is required?”
- “What is the normal path and timeline for getting this decided?”
Next, define your governance forums—the formal venues where cross-functional decisions and trade-offs get made.
Typical forums:
- Executive committee or group leadership team.
- Business unit leadership teams.
- Investment or portfolio committees.
- Risk and compliance committees.
- Product or journey councils.
- Transformation steering committee during implementation.
For each forum, specify:
- Purpose: what this forum is for and what it is not for.
- Membership: roles, not just names.
- Decisions: which specific decision types it owns.
- Inputs: what material is needed to take decisions (pre-reads, data).
- Cadence and time: how often it meets, how long, and how much of the agenda is decision vs. updates.
You want few, strong forums, not many weak ones. A practical pattern is:
- One enterprise forum (e.g., ExCo) for strategy, portfolio, and major people decisions.
- A small set of business or segment forums for P&L, customers, and product decisions.
- A small set of enterprise-wide enablers forums for tech, operations, and risk.
- A change / TOM steering forum during transformation, which may later wind down or merge with regular governance.
Finally, define escalation rules:
- What issues must be escalated (thresholds, risk, or cross-unit impact).
- What cannot be escalated (decisions that must be resolved at a given level).
- Expected timelines for escalation resolution.
A simple governance “card” for each critical decision or forum can be powerful. The aim is that a manager facing an issue knows:
- “I decide this here.”
- “If stuck, I escalate to that forum, at this time, with this format.”
If you find yourself in workshops drawing boxes but not defining decisions, pause. In TOM design, decisions come first, structure second.
6.3 Designing Spans, Layers, and Critical Roles
Macro-structure and governance define the skeleton. Spans, layers, and roles are the anatomy—they determine whether leaders can actually manage, coach, and decide at the speed your TOM requires.
Spans of control
Span of control is how many direct reports a manager has. There is no magic number, but there are sensible ranges depending on the nature of the work.
Consider:
- Complexity and variability of work: more complexity usually means smaller spans.
- Need for hands-on coaching vs. experienced, self-directed teams.
- Process and system maturity: highly standardized environments can support larger spans.
You are generally looking to:
- Avoid spans that are so small (e.g., 2–3 direct reports) that they signal unnecessary hierarchy.
- Avoid spans that are so large (e.g., 20+) that the manager cannot meaningfully support or evaluate people.
Indicators you have a span problem:
- Many managers with very small teams doing similar work.
- Senior leaders with unmanageable numbers of direct reports, constantly firefighting.
- Layers created mainly to “park” people with manager titles.
Layers
Layers are how many management levels exist between the front line and the top. Flattening can improve speed and reduce cost, but only if you redesign roles and decisions at the same time.
Ask:
- How many layers do we have today from CEO to front line in critical value streams?
- At each layer, what unique decisions or responsibilities exist that are not handled elsewhere?
- Where are two or more layers effectively doing the same kind of management work?
The aim is:
- Enough layers to manage risk, complexity, and people effectively.
- Few enough that information and decisions do not get endlessly filtered and delayed.
If you remove layers, you must also:
- Clarify what decisions move downwards.
- Strengthen capabilities at the levels that absorb new scope.
- Review compensation and title structures to avoid endless exceptions.
Critical roles
Not all roles are equal in a TOM. Some are critical integrators: without them, nothing hangs together.
Typical critical roles include:
- Value stream / journey owners.
- Product owners or category leads.
- Platform or architecture owners.
- Heads of shared services or global process owners.
- Country managers in key markets.
- Risk and compliance leads for high-stakes domains.
For each critical role, define:
- Core accountabilities: what outcomes they are on the hook for.
- Decision rights: where they have final say, where they advise.
- Interfaces: which forums they sit on, which other roles they must work closely with.
- Capabilities: what skills and experience are essential.
It is usually worth building a critical roles map:
- List the roles.
- Identify whether they exist today and how they are currently filled.
- Assess whether you have a strong successor or candidate for each.
In TOM design, it is often more important to get the right people in 20–30 critical roles than to perfect every detail of the org chart.
6.4 Org Design Playbook (Design Criteria and Common Patterns)
You do not need to start from a blank page every time. A short org design playbook gives your leadership team a shared set of criteria and patterns to use when debating options.
You can think of it in two parts:
- Design criteria: how we will judge whether an org option is good.
- Common patterns: tried-and-tested archetypes that can be adapted.
Design criteria
You can tailor the list, but typical criteria include:
- Strategic alignment
- Does this org structure align with our chosen segments, products, and geographies?
- Does it clearly support our priority value streams and customer promises?
- End-to-end accountability
- Can we point to clear owners for each priority value stream?
- Are P&L, customer outcomes, and risk owned by identifiable people or teams?
- Customer and stakeholder proximity
- Are the people who make decisions close enough to customers, markets, and regulators?
- Are there unnecessary layers between front line and decision-makers?
- Simplicity and clarity
- Is the structure easy to explain on one page?
- Does every unit have a clear purpose and value?
- Are matrix relationships limited and explicit?
- Efficiency and scale
- Are we leveraging shared capabilities where it makes sense (operations, platforms, data, support)?
- Are we avoiding unnecessary duplication of similar teams across BUs or countries?
- Resilience and control
- Does the structure support effective risk management and compliance?
- Are control functions appropriately independent where they need to be?
- Talent and culture
- Does the structure create attractive roles and career paths?
- Does it support the culture we want (e.g., collaboration, agility, accountability)?
When comparing alternative designs, require each option to be tested explicitly against these criteria. Do not let the conversation collapse into “this looks nicer” or “this is how we’ve always done it.”
Common patterns
Here are some patterns that recur and can be adapted rather than reinvented.
- Segment-led with global platforms
- Primary axis: customer segments (e.g., Retail, SME, Corporate).
- Secondary: global or regional operations, risk, and technology platforms.
- Good when: differentiation by segment is key, but you still need strong global backbone.
- Product-led with shared commercial and operations
- Primary: product lines or portfolios.
- Shared: salesforce and operations serving multiple products.
- Good when: products drive economics, but the go-to-market model is similar across them.
- Country-led within regional frameworks
- Primary: country P&Ls with strong local autonomy.
- Regions or groups: set standards, provide platforms, coordinate strategy.
- Good when: local regulation and conditions dominate, and global platforms still matter.
- Platform and capability hubs with business “front doors”
- Primary: central platforms (e.g., digital platform, operations hub, analytics hub).
- Business units or segments: act as “front doors” to customers and markets, consuming capabilities from platforms.
- Good when: scale and technology are central, with multiple internal “clients” for the same platforms.
- Global process owners with shared services
- Primary: end-to-end process owners (e.g., “Order to Cash”, “Source to Pay”) sitting above shared service centers.
- Functions and BUs: define policies and requirements, but process owners design and run execution.
- Good when: a large share of work is transactional and can be standardized globally.
These are not rigid templates. They are starting points. You will often combine them: for example, segment-led front ends with global process owners and shared services behind the scenes.
As you refine your design, keep asking:
- Does this structure make it easier or harder for us to deliver the value streams we defined?
- Can our leaders describe, in simple language, how decisions and responsibilities are distributed?
- Would a capable new hire, after one week, understand who their key stakeholders are and how to get things done?
If the answer is yes, you are on the right track. The next step is to connect this organizational design to people, skills, and culture—ensuring that the capabilities and behaviors exist to make the new operating model work in practice. That is the focus of the next chapter.
