Designs organizational structures, operating models, and role frameworks. Useful for restructuring, defining reporting relationships, strategy alignment, spans of control, and transition roadmaps.
npx claudepluginhub anotb/management-consulting-pluginThis skill uses the workspace's default tool permissions.
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.
Plans headcount, org structure, team design, and hiring sequences with benchmarks, cost modeling, and text org charts.
Maps stakeholder influence networks, designs team structures via Conway's Law, defines interface contracts (APIs/SLAs/decision rights), assesses maturity (DORA/CMMC). For org design, restructures, stakeholder mapping.
Maps, analyzes, and redesigns systems behind product experiences with service blueprints, ecosystem maps, process architecture, and dependency diagrams. For dependency analysis and workflow redesign.
Share bugs, ideas, or general feedback.
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.
Before drawing boxes and lines, define what the organization must do to execute its strategy. Structure follows strategy, not the other way around.
Strategic alignment analysis:
Operating model choices (the big decisions that shape everything downstream):
| Dimension | Question to Answer |
|---|---|
| Vertical integration | What do we do ourselves vs. outsource? |
| Centralization | What decisions sit at the center vs. 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? |
| Agility model | Traditional hierarchy, agile pods, or hybrid? |
Business model analysis:
Capability gap assessment:
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.
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).
Structural baseline:
7S assessment (McKinsey's framework, useful because it forces you beyond just structure):
| Element | What to Assess |
|---|---|
| Strategy | Is the strategy clear and understood? |
| Structure | Does the reporting structure support strategy 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:
Identify the actual problems people experience, not just the structural aesthetics you'd prefer. Common symptoms of structural misalignment:
Process overlay:
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.
Start with design principles, then evaluate structural options, then detail the selected design.
Design principles (5-7 rules that guide every structural decision):
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.
Examples of principles that actually do work:
Structural options to evaluate:
| 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 |
For each viable option, assess:
Detailing the selected design:
Once a structure is selected, define:
Structure without clear roles is just boxes on paper. This is where design becomes operational.
Key role definitions (for every role that matters structurally):
Span of control guidance:
| 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.
Job family framework:
Group roles into job families with consistent leveling:
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.
Grading framework:
| Grade Band | Typical Scope | % of Organization |
|---|---|---|
| Executive | Enterprise/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% |
The best org design fails if the transition is botched. People experience restructuring as personal, not organizational.
Phased implementation:
Phase 1: Foundation (Weeks 1-4)
Phase 2: Communication (Weeks 5-8)
Phase 3: Implementation (Weeks 9-16)
Phase 4: Stabilization (Weeks 17-24)
Risk mitigation:
Common transition risks 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:
Measure whether the redesign is working:
The new organization needs governance to operate, not just an org chart.
Decision rights framework:
For key decision categories, define who:
(This is RAPID or RACI by another name. The framework matters less than actually clarifying who does what.)
Governance cadence:
| 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 structural review checkpoints: