org-design ยท diff
git:20260504.eb1e415 to v2.1.0
126 added, 152 removed. Audit A to A.
---
name: org-design
- description: Design organizational structures, operating models, and role frameworks. Use when restructuring organizations, defining reporting relationships, designing job architectures, aligning org design with strategy, planning spans of control, or building transition roadmaps for new organizational models.
+ description: Designs organizational structures, operating models, role architectures, and transition plans that connect structure to strategy. Use when restructuring a business or function, choosing an operating model (functional, divisional, matrix, agile), defining reporting lines and spans of control, building job families and grading frameworks, allocating decision rights, or sequencing a reorganization and its change management. Covers strategic requirements, current-state diagnosis, future-state design, role definition, transition planning, and governance.
+ license: MIT
+ metadata:
+ category: engagement-delivery
+ version: "2.1.0"
+ author: Anot
---
# Organizational Design
- Structure organizations to execute their strategy through operating models, reporting structures, role frameworks, and transition plans. Org design is a people-affecting discipline that requires connecting structure to strategy and careful change management.
+ 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 Org Design Process
+ ## 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
- Before drawing boxes and lines, define what the organization must do to execute its strategy. Structure follows strategy, not the other way around.
+ Define what the organization must do before you draw anything. Boxes and lines come last, not first.
- **Strategic alignment analysis:**
+ **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.
- - **Strategic priorities**: What 3-5 things must the organization do well to win?
- - **Capability requirements**: What capabilities does each priority demand?
- - **Critical success factors**: What must go right for each capability to work?
+ **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** (the big decisions that shape everything downstream):
+ **Operating model choices.** These decisions shape everything downstream. Make them explicitly and early.
| Dimension | Question to Answer |
|---|---|
- | Vertical integration | What do we do ourselves vs. outsource? |
- | Centralization | What decisions sit at the center vs. the edge? |
+ | 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 customer segments warrant separate structures? |
+ | 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? Which are structural vs. operational?
- - What key partnerships or ecosystem relationships constrain or enable structural choices?
-
- **Capability gap assessment:**
+ **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?
- For each required capability, assess current maturity (1-5) against target maturity. The biggest gaps become the structural priorities. A capability gap that sits at 2 today but needs to be at 5 is a structural problem, not a training problem.
+ **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
- Document and diagnose the existing organization honestly. Most redesigns fail because they don't understand what's actually happening (vs. what the org chart says).
+ 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:**
+ **Structural baseline.** Document, from real data:
- - Structure type: Functional, matrix, divisional, network, hybrid
- - Number of layers from CEO to front line
+ - Structure type: functional, matrix, divisional, network, hybrid
+ - Layers from CEO to front line
- Average span of control by level
- - Total headcount by function/division
+ - Headcount by function and division
- **7S assessment** (McKinsey's framework, useful because it forces you beyond just structure):
+ **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 understood? |
- | Structure | Does the reporting structure support strategy execution? |
+ | 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? |
- | Staff | Do we have the right people in the right roles? |
- | Skills | Do we have the capabilities we need? |
-
- Rate each 1-5 for alignment. The misaligned elements are your design targets.
-
- **Pain point diagnosis:**
+ | 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? |
- Identify the actual problems people experience, not just the structural aesthetics you'd prefer. Common symptoms of structural misalignment:
+ 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.
- - Slow decision-making (too many layers, unclear authority)
- - Duplication of effort (overlapping mandates)
- - Silos preventing collaboration (wrong integration mechanisms)
- - Key work falling between the cracks (structural white space)
- - Talent bottlenecks (wrong spans, missing career paths)
+ **Pain point diagnosis.** Find the problems people actually experience, not the structural imperfections you find aesthetically annoying. Common symptoms of structural misalignment:
- **Process overlay:**
+ - 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)
- Map how work actually flows across the current structure. Where are the handoffs? Where do things slow down? Where do workarounds exist? The informal organization often matters more than the formal one.
+ **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
- Start with design principles, then evaluate structural options, then detail the selected design.
-
- **Design principles** (5-7 rules that guide every structural decision):
+ 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.
- Good design principles are specific enough to resolve trade-offs. "Customer-centric" is too vague. "Customer segment leaders have P&L authority and direct control over product, sales, and service for their segment" resolves actual decisions.
+ **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.
- Examples of principles that actually do work:
+ Principles that do real work:
- - Decisions are made at the lowest level with adequate information
- - No more than 6 layers from CEO to front line
- - Every role has a clear single point of accountability
- - Shared services consolidate where scale matters; embed where speed matters
- - Digital and technology capability is built into value streams, not bolted on
+ - 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 to evaluate:**
+ **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 differences matter, regulatory variation | Inconsistency, duplication |
- | Divisional (customer) | Distinct customer segments with different needs | Complexity if segments overlap |
- | Matrix | Two dimensions equally important (e.g., product AND geography) | Dual reporting confusion, slow decisions, conflict |
- | Network/agile | Fast-moving markets, innovation priority, knowledge work | Coordination cost, governance gaps, career path ambiguity |
- | Platform + value streams | Digital businesses, shared infrastructure with diverse products | Platform team becomes bottleneck |
+ | 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:
- - How well it supports each strategic priority
- - Implementation complexity and transition risk
- - Cultural fit (how far is this from how people work today?)
+ 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.
- **Detailing the selected design:**
+ 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.
- Once a structure is selected, define:
+ **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)
- - **Governance**: Decision rights, escalation paths, committee structures
- - **Work model**: Hybrid, remote-first, or co-located, and how this interacts with structure
+ - **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 clear roles is just boxes on paper. This is where design becomes operational.
+ 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 role that matters structurally):
+ **Key role definitions.** For every structurally significant role:
- - **Purpose**: Why this role exists (one sentence)
- - **Key accountabilities**: The 5-7 things this role is responsible for delivering
- - **Decision authority**: What decisions this role makes independently vs. escalates
- - **Relationships**: Reports to, peers with, manages, key stakeholders
- - **Span of control**: Direct reports (target range)
+ - **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:**
+ **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 direct reports | Work is predictable, less supervision needed |
- | Knowledge work, moderate complexity | 6-10 direct reports | Balance of coaching and autonomy |
- | Complex, varied, senior work | 4-7 direct reports | High interaction needed |
- | Highly creative, R&D, transformation | 3-5 direct reports | Intensive collaboration required |
-
- Spans outside these ranges usually signal a problem: too narrow means unnecessary layers; too wide means insufficient oversight or development.
+ | 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 |
- **Job family framework:**
+ 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.
- Group roles into job families with consistent leveling:
+ **Job family framework.** Group roles into families with consistent leveling:
- - **Level definitions**: What scope, complexity, and autonomy look like at each level
- - **Competency expectations**: What skills and behaviors are required at each level
- - **Career pathways**: Vertical progression, lateral moves, diagonal (cross-functional) moves
+ - **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 matter for retention. If the new structure eliminates career paths people were counting on, you'll lose people you didn't intend to.
+ 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:**
+ **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 | % of Organization |
+ | Grade Band | Typical Scope | Illustrative % of Org |
|---|---|---|
- | Executive | Enterprise/division-wide accountability | 1-3% |
- | Senior management | Function or large team leadership | 5-10% |
+ | 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 org design fails if the transition is botched. People experience restructuring as personal, not organizational.
+ 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:**
+ **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 design and get leadership sign-off
- - Develop detailed role profiles
+ - 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)
+ - Identify people implications: moves, redundancies, new hires
**Phase 2: Communication (Weeks 5-8)**
- - Align leadership team first (they must be advocates, not passengers)
- - Train managers on the rationale, the "why," and how to have conversations
+ - 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; don't hide from hard questions
+ - Run Q&A sessions and answer the hard questions directly
**Phase 3: Implementation (Weeks 9-16)**
- - Match people to roles (selection processes where needed)
- - Execute transitions in coordinated waves
- - Launch new teams with clear charters
- - Update processes, systems, and governance
+ - 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)**
- - Monitor for emerging issues
- - Provide development support for people in stretched roles
- - Fine-tune based on reality vs. design intent
- - Measure against success metrics
-
- **Risk mitigation:**
+ - 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
- Common transition risks and how to handle them:
+ **Risk mitigation.** The transition risks that actually sink reorganizations, and how to handle them:
| Risk | Mitigation |
|---|---|
- | Key talent leaving during uncertainty | Early, honest communication; retention arrangements for critical roles |
- | Productivity dip during transition | Phase the change; don't reorganize everything simultaneously |
- | Manager resistance to reduced scope | Involve them in design; provide alternative career paths |
- | Cultural clash in merged teams | Invest in team-building; don't assume culture just happens |
- | Loss of institutional knowledge | Document critical processes; use overlap periods for knowledge transfer |
-
- **Success metrics:**
+ | 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 |
- Measure whether the redesign is working:
+ **Success metrics.** Measure whether the redesign worked. Baseline these before the change or the after-numbers mean nothing.
- - Role clarity scores (survey-based, within 3 months)
- - Decision speed (time from request to decision, before and after)
+ - 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 improvements
+ - Process efficiency gains against the specific pain points from Step 2
- Leadership effectiveness ratings
### Step 6: Establish Governance
- The new organization needs governance to operate, not just an org chart.
-
- **Decision rights framework:**
-
- For key decision categories, define who:
- - **Decides**: Has final authority
- - **Approves**: Must sign off before execution
- - **Recommends**: Provides input that shapes the decision
- - **Informs**: Needs to know the outcome
- - **Executes**: Carries out the decision
+ A new structure needs governance to run, not just a chart to admire.
- (This is RAPID or RACI by another name. The framework matters less than actually clarifying who does what.)
+ **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:**
+ **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 |
+ | 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 structural review checkpoints:
- - 90-day post-implementation review
- - 6-month effectiveness assessment
- - Annual strategic alignment check
+ **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. If the strategy changes, the structure probably needs to change too.
- - Every structural choice is a trade-off. Centralizing gains efficiency but loses responsiveness. Decentralizing gains speed but risks inconsistency. Name the trade-off explicitly.
- - Org design is about work, not people. Design the structure for the work that needs to happen, then fit people to roles.
- - Spans of control should be driven by the nature of work, not by status or seniority.
- - The informal organization is as real as the formal one. Design with awareness of how work actually flows.
- - Org design affects people deeply. Communicate honestly, treat people with respect, and don't pretend difficult changes are painless.
- - Simple structures outperform complex ones. If you need a 20-page document to explain how the matrix works, the matrix doesn't work.
- - Design for the next 3-5 years, not for today's problems. But don't design for a future that may never arrive.
- - Build in mechanisms for adaptation. The organization that can restructure quickly beats the one with the perfect structure.
+ - 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.