Macro-structure sets the big picture: who owns which businesses, functions, and geographies. Micro-structure makes that picture real. It determines how work is broken into teams, how roles are defined, and how people experience the organization day to day. Poor micro-structure will quietly undermine even a well-thought-through macro-structure: work fragments, accountabilities blur, and managers spend their time coordinating instead of leading.
The goal of this chapter is to give you a practical way to move from high-level design to concrete teams and roles that are clear, coherent, and sustainable.
9.1 Breaking Down Units into Teams and Sub-Functions
Once you have defined business units and major functions, you need to break them down into logical teams and sub-functions. The aim is to create units that own meaningful pieces of the value stream, not to reproduce historic structures or preferences.
A straightforward sequence works well.
First, start from value streams and capabilities, not from existing org charts. For each business unit or function, list:
- The key value streams it contributes to (for example, “lead-to-order,” “order-to-cash,” “idea-to-launch,” “incident-to-resolution”).
- The critical capabilities it must host (for example, account management, product management, planning, analytics, risk assessment, vendor management).
You are asking: what chunks of work need to be owned end-to-end within this unit?
Second, cluster work into sub-functions. Sub-functions are logical groups of related activities that benefit from common leadership, skills, and metrics. For example, within a commercial BU you might define:
- Sales (by channel or segment)
- Marketing (brand, campaigns, digital)
- Pricing and revenue management
- Customer success and service
Within an operations function you might define:
- Planning and scheduling
- Production or service delivery
- Quality and continuous improvement
- Supply management and logistics
Avoid premature granularity. You do not need a separate sub-function for every activity. Start broad and split only when there is a clear reason: scale, specialization, risk, or distinct stakeholder groups.
Third, define teams within sub-functions. Teams are where work actually gets done. A team should have:
- A clear purpose and set of outcomes.
- A coherent work type (for example, transactional, expert, project, or relationship)
- A size and span that are manageable for a single leader.
You will typically see a few recurring team archetypes:
- Transaction teams: handling high-volume, repeatable tasks (claims processing, order entry).
- Expert teams: providing specialist advice or analysis (tax, risk modeling, data science).
- Relationship teams: managing clients, suppliers, or partners (account management, key supplier management).
- Project and change teams: delivering transformations, product launches, or major implementations.
Each archetype leads to different design norms. Transaction teams can have larger spans and more standardized roles. Expert teams are smaller, with higher variability in workload. Relationship teams need clarity on portfolio size and service levels.
Throughout this work, keep a tight line back to the macro-structure. If a BU is accountable for a customer segment, make sure teams within that BU are not sliced in ways that fragment the segment again. If a function is meant to provide enterprise-wide standards, design its sub-units so they can actually set and enforce standards, not just offer advice.
A few practical questions to test the breakdown:
- For each sub-function, can you explain its purpose in one sentence?
- Does each team have a clear “customer” (internal or external) for its outputs?
- Are you designing teams around stable work, or around temporary individuals and preferences?
- Are any teams so small they are effectively “orphan roles” rather than teams?
If you cannot answer these questions confidently, you are not done with micro-structure yet.
9.2 Role Design: Mandates, Accountabilities, Interfaces
Roles are the building blocks of the organization. A good role is not just a job title; it is a clear mandate, a bounded scope of responsibility, and a set of interfaces with others. Poorly designed roles create frustration, duplication, and gaps.
A practical way to design roles is to create a role charter for each key position. The charter should be short and operational, not a long HR job description. At minimum, it should cover:
- Role purpose
- Outcomes and accountabilities
- Scope and decision rights
- Key interfaces
- Required skills and experience (high level)
Role purpose
Captures why the role exists in one or two sentences, in business language. For example:
- “Own revenue and margin performance for the mid-market customer segment in Region X.”
- “Ensure safe, compliant, and efficient operation of all plants in Country Y.”
If you cannot articulate purpose succinctly, the role is either too vague or trying to do too many unrelated things.
Outcomes and accountabilities
Define what the role is accountable for, not just what it does. Outcomes should be relatively few and linked to metrics where possible:
- Revenue, margin, and NPS for defined customers.
- On-time delivery and cost per unit for defined operations.
- Quality, compliance, and timeliness for defined processes.
Be strict about single-point accountability. For each outcome, one role should be clearly accountable, even if others contribute. Joint accountability is a major source of drift. Where joint ownership is unavoidable (for example, in a matrix), clarify who has the casting vote or who is the “tie-breaker” in case of conflict.
Scope and decision rights
Spells out what the role can decide and control without escalation. This goes beyond formal authority to include practical levers:
- Budget size, headcount authority, pricing or discounting thresholds, approval limits.
- Ability to set local procedures, standards, or ways of working within defined boundaries.
A useful test is to list 5–10 recurring decisions related to the role and mark which ones this role should:
- Own outright.
- Recommend with final decision elsewhere.
- Be consulted on.
- Be informed about only.
This can be written directly into the charter in words rather than as a full matrix.
Key interfaces
Define where the role must collaborate closely with others. Interfaces usually fall into:
- Upstream providers of inputs (data, demand forecasts, product definitions).
- Downstream receivers of outputs (customers, operations, finance).
- Peers with shared or adjacent responsibilities (for example, regional vs global, product vs function).
For each major interface, specify the purpose: “align on segment strategy,” “agree quarterly volume plans,” “resolve escalations within 48 hours,” and so on. This keeps interfaces purposeful rather than generic “collaboration.”
Required skills and experience
At the charter level, keep it high level and linked to business needs:
- Types of experience (for example, “led multi-country teams,” “deep understanding of regulatory environment X”).
- Critical capabilities (for example, “data-driven pricing,” “influencing without authority,” “stakeholder management”).
Detailed competency frameworks can sit behind this, but they should not clutter the core design work.
Role design is iterative. You will typically start with charters for top roles in each BU and function, then cascade to the next level. Ensure vertical coherence: the sum of subordinate roles should roughly cover the superior’s scope without large gaps or overlaps.
9.3 Job Profiles, Bands, and Levels
Once you have role charters, you need to place roles into your job architecture: job families, bands, and levels. This keeps the organization internally coherent on pay, career paths, and expectations.
Job families group roles with similar underlying skills and work types: sales, operations, finance, HR, technology, product, risk, and so on. Within each family you typically have:
- Individual contributor paths (for example, analyst, specialist, principal expert).
- Management paths (for example, team lead, manager, director, VP).
When you place a role into a family, ask: “If this role holder left, what pool of similar roles and people would we consider as successors or replacements?” That is usually the right family.
Bands and levels reflect relative size, complexity, and impact:
- Bands are broad, often linked to pay ranges and benefits.
- Levels within bands can reflect seniority steps.
Rather than relying solely on hierarchy, base banding on a small set of criteria:
- Scope of control (size of budget, headcount, revenue, or geography).
- Complexity and variety of work (number of segments, products, or stakeholders).
- Degree of autonomy (freedom to set strategy vs executing within a narrow mandate).
- Impact on enterprise performance and risk.
For example, in a commercial family:
- A segment sales manager for a small region might be one level.
- A global key-account director for a strategic client portfolio would be higher, even if headcount is similar, because strategic impact and complexity are higher.
Avoid title inflation during redesign. It is tempting to rename roles to make people feel recognized without changing scope. That creates long-term inconsistency and cost. Better to:
- Keep titles aligned with band and level expectations.
- Use recognition, development, and compensation within a band rather than constantly adding new senior-sounding titles.
It is also useful to check vertical consistency:
- Are there logical steps from one level to the next in responsibility and complexity?
- Can you describe how a manager role differs from a senior manager or director role in concrete terms?
Examples:
- Manager: owns a team, executes strategy, manages daily performance.
- Senior manager: owns a sub-function or segment, shapes local strategy, manages multiple teams.
- Director: defines strategy for a broader area, influences across units, accountable for major P&L or risk areas.
Job profiles codify this. A job profile is broader than a role charter; it describes a “type” of role (for example, “regional sales manager”) that may exist in multiple geographies. It typically includes:
- Purpose and typical scope.
- Key responsibilities.
- Typical metrics.
- Required experience and qualifications.
During redesign, you do not need to rewrite your entire job architecture. Focus on:
- New or significantly changed roles in the new structure.
- Roles where there is mismatch between current banding and actual scope.
- Critical roles for which clear profiles will help recruitment and succession planning.
9.4 Avoiding Role Fragmentation and Overlap
One of the most common micro-design pathologies is role fragmentation: splitting work into too many small, partial roles, often to accommodate individuals or historical arrangements. Over time, this produces:
- Endless coordination.
- Thin roles that do not build real expertise.
- Gaps where no one feels fully accountable.
You should actively design to avoid both fragmentation and overlap.
Common signs of fragmentation:
- Many roles described as “20% of X, 30% of Y, 50% of Z,” with no clear primary mandate.
- Small “coordinator” roles that shuttle information between others without owning real outcomes.
- Frequent statements like “we all own this” or “it’s a shared responsibility,” with no clear escalation path.
Common signs of overlap:
- Two or more teams claiming ownership of the same outcome (for example, “we own customer experience”).
- Duplicated specialist roles in multiple units when one would suffice (for example, multiple small analytics teams across functions).
- Conflicting instructions from different leaders to the same people or customers.
A few principles help you design against these failure modes.
First, design whole jobs, not fragments. A whole job:
- Has a clear primary purpose and a handful of core outcomes.
- Fills most of the role holder’s capacity with related work.
- Enables the person to see the impact of their work end-to-end in some domain (a process, a customer group, a product area).
Part-time allocations can work, but they should be consciously designed and limited. For example, a specialist might spend 70% in a central CoE and 30% embedded with a BU, with a clear agreement on which outcomes each part supports and who manages performance.
Second, apply the rule of “one neck to ring” for each critical outcome. You can have many contributors, but one role should clearly own the outcome. If you find more than one role claiming accountability for the same outcome, you must either:
- Split the outcome into distinct pieces with separate owners (for example, acquisition vs retention); or
- Make one role primary and define others as contributors with specific responsibilities.
Third, be disciplined about coordination roles. Some coordination is necessary, but “coordinator” roles tend to multiply where structure and processes are unclear. Before creating or retaining a coordinator role, ask:
- Could this coordination be designed out via clearer ownership or better processes?
- Does the coordinator have real authority to resolve issues, or do they only escalate?
- Is the role a stepping stone in a career path or a cul-de-sac?
If coordinators are essentially chasing information across a fragmented landscape, the structural problem is elsewhere.
Fourth, ruthlessly clean up legacy overlaps. During redesign, you will uncover places where:
- Two teams do similar work for different parts of the business with different standards.
- Old initiatives created parallel structures (for example, a “digital team” duplicating functions inside existing units).
- Temporary roles became permanent without ever being re-evaluated.
Make explicit decisions: consolidate, discontinue, or redefine. Avoid the temptation to rename overlapping roles while leaving both in place.
To support this, you can run a simple review across roles in each unit:
- For each key outcome or process step, list all roles that currently touch it.
- Mark which roles should be accountable, which responsible, which consulted, which informed.
- Challenge any outcome with more than one accountable role or with responsibility spread so thin that no one spends significant time on it.
This exercise often surfaces quick wins in simplifying the micro-structure without major disruption.
9.5 Micro-Structure Design Templates and Examples
To make micro-structure design repeatable, it helps to standardize a few simple templates. These are not meant to be bureaucratic; they are a way to ensure you do not miss critical elements.
You can use three basic templates during design: a team template, a role charter template, and a unit overview.
Team template
For every team you design, capture the following on a single page:
- Team name
- Purpose
- Key outcomes
- Scope and boundaries
- Team composition
- Interfaces
- Metrics
Purpose: a one-sentence statement of why the team exists.
Key outcomes: 3–5 measurable outcomes the team must deliver (for example, “achieve X% on-time delivery for Y process,” “maintain error rate below Z”).
Scope and boundaries: what is in and out of the team’s remit; which geographies, segments, products, or processes it covers.
Team composition: indicative number of roles, roles types, and expected spans of control.
Interfaces: key upstream and downstream partners; how they interact (for example, weekly planning meetings with function A, daily hand-offs to team B).
Metrics: the KPIs that will be used to manage team performance.
Use this template to stress-test whether the team is well-formed. If you struggle to define distinct outcomes or boundaries, the team may not be a coherent unit.
Role charter template
For key roles, the charter can simply mirror the structure described earlier:
- Role title
- Reporting line and key direct reports
- Role purpose (1–2 sentences)
- Primary outcomes and accountabilities (3–6 bullets)
- Key decisions owned
- Key interfaces and collaboration requirements
- High-level skill and experience requirements
Stick to business language and avoid generic competency lists. The charter should allow a senior leader to read it and understand both what success looks like and what the role is expected to decide and influence.
Unit overview template
At the sub-function or BU level, it helps to summarize the micro-structure in one view:
- Unit purpose and mandate
- List of teams with their purposes
- Management layers and spans (for example, “3 layers from head of unit to front line; average span of 8–10 for front-line managers”)
- Key cross-unit interfaces (for example, “works with Product for roadmap, with Operations for delivery”).
This overview allows you to see if the unit has become too fragmented (too many tiny teams), too thin (too few managers with enormous spans), or misaligned with the macro-structure.
A simple step-by-step micro-design process
You can combine the above into a straightforward process for each major unit:
- Confirm the unit mandate and main value streams (from macro-structure and diagnosis).
- Define sub-functions based on clusters of work and capabilities.
- Design teams within each sub-function using the team template.
- Draft role charters for key roles (unit head, sub-function heads, major team leads, critical experts).
- Place roles into job families, bands, and levels for consistency.
- Review for fragmentation and overlap across roles and teams.
- Summarize in a unit overview and iterate with the unit leader and HR.
Micro-structure design sanity-check
Before finalizing, run a quick checklist across the micro-structure of each unit:
- Can every manager describe their team’s purpose and outcomes in a few sentences?
- Does every critical outcome have one clearly accountable role?
- Are there teams or roles whose existence you cannot justify in terms of strategy, value streams, or risk?
- Are spans of control and layers consistent with the nature of work and with your overall span-and-layer guidelines?
- Can you explain how a new joiner in any role would know who their “customers” are and what they owe them?
If the answer is “yes” to most of these, your micro-structure is likely serviceable. If not, refine now—before people are placed into roles and the new structure hardens.
Macro-structure sets direction, but it is micro-structure and role design that determine whether people can do great work with clarity and focus. Treat this phase as design work, not as a mechanical re-labeling of old jobs, and you will significantly increase the odds that your new organization delivers on its promise.
