Org design

Organizational Design

Structure an organization to execute its strategy. The work produces four connected deliverables: an operating model, a reporting structure, a role and job architecture, and a transition plan. Org design changes people's jobs, so the discipline is half analysis and half change management. Get the analysis right and botch the transition, and the design still fails.

Structure follows strategy. Every step below traces back to what the organization must do to win. When you cannot trace a box or a line back to a strategic requirement, that box or line is decoration.

A note on inputs before you start. Do not invent headcounts, spans, cost figures, or benchmark ranges. Ask for the org's real numbers. Where you show an illustrative figure to demonstrate a method, label it as an example and flag it for validation against client data. The grading percentages and span ranges in this skill are directional planning heuristics, not measured facts about any specific organization.

---

The Process

Six steps. The judgment concentrates in three of them: linking strategy to structure (Step 1), choosing among structural options (Step 3), and sequencing the transition (Step 5). Spend your depth there. Roles, grading, and governance cadence are more mechanical once the shape is set.

Step 1: Assess Strategic Requirements

Define what the organization must do before you draw anything. Boxes and lines come last, not first.

Strategic priorities. Name the 3-5 things the organization must do well to win. If leadership cannot agree on these, stop. You are being asked to solve a structure problem that is actually a strategy problem, and no org chart fixes an unclear strategy.

Capability requirements. For each priority, name the capabilities it demands and the critical success factors that make each capability work. This is the bridge from strategy to structure. A priority of "win in enterprise accounts" might demand solution-selling capability, deep account management, and cross-product delivery coordination. Those three capabilities will shape three structural choices.

Operating model choices. These decisions shape everything downstream. Make them explicitly and early.

Dimension	Question to Answer
Vertical integration	What do we do ourselves versus outsource?
Centralization	What decisions sit at the center versus the edge?
Geographic structure	How do we organize across locations?
Product/service alignment	Do we organize around what we sell or who we sell to?
Customer segmentation	Do distinct customer segments warrant distinct structures?
Agility model	Traditional hierarchy, agile pods, or hybrid?

Business model analysis. How does the organization create value? What are the major cost drivers, and which are structural (baked into how the org is shaped) versus operational (changeable without restructuring)? Which partnerships or ecosystem dependencies constrain the structural choices you can make?

Capability gap assessment. For each required capability, score current maturity 1-5 against target maturity. The biggest gaps become the structural priorities. A capability sitting at 2 that the strategy needs at 5 is a structural problem, not a training problem. You cannot train your way to a capability the structure actively works against. When you present these scores, show the reasoning behind each one: what evidence puts this capability at 2, and what "5" would concretely look like.

Step 2: Analyze Current State

Diagnose the existing organization honestly. Most redesigns fail here, because the team designs against the org chart instead of against what is actually happening. The org chart is a claim. The real organization is what people do on Tuesday.

Structural baseline. Document, from real data:

• Structure type: functional, matrix, divisional, network, hybrid
• Layers from CEO to front line
• Average span of control by level
• Headcount by function and division

7S assessment. McKinsey's framework earns its place because it forces you past structure into the softer elements that sink redesigns. Rate each element 1-5 for alignment with the strategy, and write two to three sentences per element citing what you observed.

Element	What to Assess
Strategy	Is the strategy clear and shared?
Structure	Does the reporting structure support execution?
Systems	Do processes, tools, and IT support the work?
Shared values	Is there alignment on culture and purpose?
Style	How do leaders actually lead, versus how they say they lead?
Staff	Are the right people in the right roles?
Skills	Do we have the capabilities the strategy needs?

The misaligned elements are your design targets. If structure rates a 4 but systems and skills rate a 2, restructuring will not fix the problem and may make it worse.

Pain point diagnosis. Find the problems people actually experience, not the structural imperfections you find aesthetically annoying. Common symptoms of structural misalignment:

• Slow decisions (too many layers, unclear authority)
• Duplicated effort (overlapping mandates)
• Silos blocking collaboration (wrong or missing integration mechanisms)
• Work falling through the cracks (structural white space nobody owns)
• Talent bottlenecks (wrong spans, dead-end career paths)

Process overlay. Map how work actually flows across the current structure. Where are the handoffs? Where does work slow down or stall? Where have people built workarounds? Workarounds are diagnostic gold. Each one marks a place where the formal structure fails the work, and people routed around it. The informal organization often matters more than the formal one.

Step 3: Design the Future State

Design principles first, then structural options, then the detailed design. Resist the urge to jump to a favorite structure. The principles are what let you defend the choice later.

Design principles. Write 5-7 rules that guide every structural decision. Good principles are specific enough to resolve real trade-offs. "Customer-centric" resolves nothing. "Customer segment leaders hold P&L authority and direct control over product, sales, and service for their segment" resolves a dozen downstream arguments.

Principles that do real work:

• Decisions are made at the lowest level that has adequate information.
• No more than 6 layers from CEO to front line.
• Every role has a single point of accountability.
• Shared services consolidate where scale matters and embed where speed matters.
• Digital and technology capability is built into value streams, not bolted on afterward.

Structural options. Evaluate the viable structures against the strategy. Each has a home and a failure mode.

Structure Type	Best When	Watch Out For
Functional	Single product/service, scale matters, expertise depth needed	Silos, slow cross-functional work
Divisional (product)	Multiple distinct products, end-to-end accountability needed	Duplication, sub-scale functions
Divisional (geographic)	Local market or regulatory variation matters	Inconsistency, duplication
Divisional (customer)	Distinct segments with genuinely different needs	Complexity when segments overlap
Matrix	Two dimensions matter equally (e.g. product AND geography)	Dual-reporting confusion, slow decisions, unresolved conflict
Network/agile	Fast-moving markets, innovation priority, knowledge work	Coordination cost, governance gaps, career-path ambiguity
Platform + value streams	Digital businesses, shared infrastructure across diverse products	Platform team becomes the bottleneck

For each viable option, assess three things and write the reasoning, not a checkmark: how well it supports each strategic priority, its implementation complexity and transition risk, and its cultural fit (how far it sits from how people work today). A structure that scores well on strategy but demands a culture the organization does not have will fail in implementation. Name that gap out loud rather than scoring it away.

A word on the matrix specifically. Teams reach for it because two things genuinely both matter, and the matrix promises to serve both. It usually serves neither, because it moves the unresolved trade-off from the org designer's desk down into every dual-reporting employee's weekly life, where it gets re-litigated forever. Choose a matrix only when you can also specify, in advance, who wins which decisions. If you cannot write that decision-rights grid, you are not ready to run a matrix.

Detail the selected design. Once a structure is chosen, define:

• Top-level architecture: major units, their mandates, and reporting lines
• Structural dimensions: target layers, spans of control, authority distribution
• Integration mechanisms: how units coordinate (cross-functional teams, shared processes, liaison roles, communities of practice). This is where matrix and network structures live or die.
• Governance: decision rights, escalation paths, committee structures
• Work model: co-located, hybrid, or remote-first, and how that choice interacts with the structure you picked

Step 4: Define Roles and Job Architecture

Structure without defined roles is boxes on paper. This step makes the design operational. It is more mechanical than Steps 1, 3, and 5, so move efficiently, but do not skip the accountability definitions. Ambiguous accountability is where good structures rot.

Key role definitions. For every structurally significant role:

• Purpose: why the role exists, in one sentence
• Key accountabilities: the 5-7 outcomes this role owns
• Decision authority: what it decides alone versus escalates
• Relationships: reports to, peers, manages, key stakeholders
• Span of control: target range of direct reports

Span of control guidance. These ranges are planning defaults, not laws. Calibrate to the actual work.

Work Type	Typical Span	Rationale
Routine, standardized work	10-15 reports	Predictable work, light supervision
Knowledge work, moderate complexity	6-10 reports	Balance of coaching and autonomy
Complex, varied, senior work	4-7 reports	High interaction required
Highly creative, R&D, transformation	3-5 reports	Intensive collaboration required

Spans outside these ranges usually signal a problem. Too narrow means you have inserted a layer that exists to give someone a title. Too wide means people are unsupervised or undeveloped. Either way, flag it and ask why the span is what it is.

Job family framework. Group roles into families with consistent leveling:

• Level definitions: what scope, complexity, and autonomy look like at each level
• Competency expectations: the skills and behaviors required at each level
• Career pathways: vertical progression, lateral moves, and diagonal cross-functional moves

Career pathways drive retention. If the new structure quietly removes a path people were counting on, you will lose people you meant to keep. Trace what happens to the ambitious mid-level manager whose promotion ladder just got shorter, and answer it before they ask.

Grading framework. The distribution below is an illustrative reference shape, not a target to force a client's organization into. Real distributions vary widely by industry and maturity. Validate against the client's actual headcount data before presenting.

Grade Band	Typical Scope	Illustrative % of Org
Executive	Enterprise or division-wide accountability	1-3%
Senior management	Function or large-team leadership	5-10%
Middle management	Team leadership, project ownership	15-20%
Professional/specialist	Individual contributor, expertise-driven	30-40%
Operational	Execution-focused, defined processes	30-40%

Step 5: Plan the Transition

The best design on paper fails if the transition is mishandled. People experience restructuring as personal, not organizational. To leadership it is a new operating model. To the individual it is "do I still have a job, and does it still mean anything." Design the transition for the second experience.

Phased implementation. The week ranges below are a starting template. Compress or extend them to the org's size and the depth of the change. A 200-person function moves faster than a 20,000-person enterprise.

Phase 1: Foundation (Weeks 1-4)

• Finalize the design and secure leadership sign-off
• Build detailed role profiles
• Assess current incumbents against new roles
• Identify people implications: moves, redundancies, new hires

Phase 2: Communication (Weeks 5-8)

• Align the leadership team first. They must be advocates, not passengers. A leader who cannot explain the "why" will leak doubt into their whole org.
• Train managers on the rationale and on how to hold the hard conversations
• Communicate to all employees with clarity and honesty
• Run Q&A sessions and answer the hard questions directly

Phase 3: Implementation (Weeks 9-16)

• Match people to roles, with formal selection where roles are contested
• Execute transitions in coordinated waves rather than all at once
• Launch new teams with explicit charters
• Update processes, systems, and governance to match the new structure

Phase 4: Stabilization (Weeks 17-24)

• Watch for emerging issues and unintended consequences
• Support people stretched into bigger roles
• Fine-tune against reality versus design intent
• Measure against the success metrics

Risk mitigation. The transition risks that actually sink reorganizations, and how to handle them:

Risk	Mitigation
Key talent leaving during uncertainty	Communicate early and honestly; put retention arrangements around critical roles before the rumor mill starts
Productivity dip during transition	Phase the change; never reorganize everything at once
Manager resistance to reduced scope	Involve them in the design; offer credible alternative paths
Culture clash in merged teams	Invest in team-building; do not assume shared culture appears on its own
Loss of institutional knowledge	Document critical processes; use overlap periods for handover

Success metrics. Measure whether the redesign worked. Baseline these before the change or the after-numbers mean nothing.

• Role clarity scores (survey, within 3 months)
• Decision speed (time from request to decision, before versus after)
• Employee engagement (within 6 months)
• Cross-functional collaboration effectiveness
• Process efficiency gains against the specific pain points from Step 2
• Leadership effectiveness ratings

Step 6: Establish Governance

A new structure needs governance to run, not just a chart to admire.

Decision rights. For each major decision category, define who decides (final authority), approves (must sign off before execution), recommends (shapes the decision with input), is informed (needs the outcome), and executes (carries it out). Call it RAPID or RACI if you like. The label matters less than actually resolving who does what, especially at the seams between the new units.

Governance cadence. A reference rhythm. Match it to how the business actually runs; do not add forums for their own sake.

Forum	Purpose	Frequency	Participants
Executive committee	Strategic decisions, resource allocation	Weekly/biweekly	C-suite
Operating review	Performance tracking, issue resolution	Monthly	Leaders + 1
Cross-functional sync	Coordination across units	Weekly	Working-level leads
Portfolio review	Investment prioritization	Quarterly	Senior leadership

Review and adaptation. Org design is not a one-time event. Build in checkpoints: a 90-day post-implementation review, a 6-month effectiveness assessment, and an annual check that the structure still fits the strategy. When the strategy shifts, revisit the structure.

---

Key Principles

• Structure follows strategy. When the strategy changes, the structure probably needs to change with it.
• Every structural choice is a trade-off. Centralizing buys efficiency and loses responsiveness. Decentralizing buys speed and risks inconsistency. Name the trade-off out loud instead of pretending the design has no cost.
• Design for the work, then fit people to roles. Designing around specific individuals produces a structure that breaks the day they leave.
• Spans of control follow the nature of the work, not status or seniority.
• The informal organization is as real as the formal one. Design with clear eyes about how work actually flows.
• Restructuring hits people hard. Communicate honestly, treat people with respect, and do not pretend a painful change is painless.
• Simple structures beat complex ones. If it takes a 20-page document to explain how the matrix works, the matrix does not work.
• Design for the next 3-5 years, not just today's irritations, and not for a speculative future that may never arrive.
• Build in mechanisms to adapt. The organization that can restructure quickly beats the one holding out for a perfect structure.