organizational-design

Original source / Raw SKILL.md

---
name: "organizational-design"
description: "Design or redesign an org structure and operating model by producing an Organizational Design Pack (design brief, current-state map, operating-model decision, target org blueprint, transition plan). Use for org design, reorgs, team topology, functional vs divisional structures, and centralized vs decentralized decision-making. Category: Leadership."
---

# Organizational Design

## Scope

**Covers**
- Designing or redesigning an organization’s **structure + operating model** to improve speed, accountability, and customer outcomes
- Choosing between **centralized vs decentralized** models (Apple ↔ Amazon spectrum) and **functional vs divisional/value-stream** orientations
- Reducing coordination tax by **minimizing dependencies** and clarifying **decision rights**
- Setting management roles/layers so leaders **know the work** and can drive craft, not just process

**When to use**
- “Propose a reorg / org design for my product + engineering organization.”
- “We’re slow due to dependencies—redesign teams so we can run in parallel.”
- “Our UX is fragmented—should we centralize decisions or strengthen functional leadership?”
- “We grew fast and added layers—help us simplify and get back to startup speed.”

**When NOT to use**
- You need product strategy/vision first (use `defining-product-vision` or `working-backwards`).
- This is mainly a people-performance issue (use coaching/feedback workflows, not a reorg).
- You need compensation bands, leveling, hiring plans, or legal/HR guidance (involve HR/legal).
- You need a single high-stakes decision process (use `running-decision-processes`).

## Inputs

**Minimum required**
- Org context: company stage, domain, size, and which functions are in-scope (e.g., Product/Eng/Design/Data)
- Current structure: teams, reporting lines (rough is fine), and how work is currently organized
- Primary goals: what must improve (e.g., speed, quality, integrated UX, ownership, cost)
- Key symptoms with examples (e.g., slow decisions, rework, unclear ownership, fragmented UX)
- Constraints/non-negotiables (headcount, timeline, critical launches, regulatory/compliance, leadership preferences)

**Missing-info strategy**
- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md).
- If answers aren’t available, proceed with explicit assumptions and label unknowns.

## Outputs (deliverables)

Produce an **Organizational Design Pack** (Markdown in-chat, or files if requested) in this order:
1) **Org Design Brief** (goal, constraints, design principles, success metrics)
2) **Current-State Map** (teams/charters, dependency hotspots, decision rights, layers)
3) **Operating Model Decision** (centralized ↔ decentralized + functional ↔ divisional rationale)
4) **Target Org Blueprint** (team topology + charters + leadership roles + interfaces)
5) **Operating Mechanisms** (decision rights, planning cadence, cross-team interfaces)
6) **Transition Plan** (sequencing, comms, staffing moves, risk mitigations, measurement)
7) **Risks / Open questions / Next steps** (always included)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)

## Workflow (7 steps)

### 1) Define what you’re optimizing for (and the constraints)
- **Inputs:** Goals; symptoms; constraints; timeline.
- **Actions:** Translate “we need a reorg” into a design problem: what outcomes must improve and by when. Pick 3–5 design principles (e.g., “minimize dependencies”, “one UX owner for critical journeys”, “reduce layers”).
- **Outputs:** Org Design Brief (draft) + success metrics.
- **Checks:** Stakeholders can agree on the top tradeoffs (e.g., speed vs UX coherence) and what would count as success.

### 2) Map the current org-as-a-system (work, dependencies, decisions)
- **Inputs:** Current teams; roadmap/work streams; known friction examples.
- **Actions:** Document team charters, dependencies, and decision rights. Identify dependency hotspots, duplicated ownership, and surprise approvers. Capture management layers and where managers don’t know the work.
- **Outputs:** Current-State Map + “top 5 friction loops” list.
- **Checks:** The map explains most observed delays/rework with concrete dependency/decision bottlenecks.

### 3) Choose an operating model posture (centralize vs decentralize; functional vs divisional)
- **Inputs:** Product architecture/coupling; UX integration needs; talent maturity; risk tolerance.
- **Actions:** Place the org on two spectrums: (1) centralized (Apple-like) ↔ decentralized (Amazon-like), and (2) functional ↔ divisional/value-stream. Write the rationale and guardrails (what must be standardized vs allowed to diverge).
- **Outputs:** Operating Model Decision + guardrails.
- **Checks:** The choice matches product coupling: integrated experiences have explicit owners; independent surfaces can run in parallel with clear interfaces.

### 4) Generate 2–3 viable org options (not one)
- **Inputs:** Current-state map; operating model posture; constraints.
- **Actions:** Draft 2–3 options (A/B/(C hybrid)), each with team list, charters, leadership roles, interfaces, and expected dependency changes. Make management layers explicit; avoid “people managers” without domain/craft context.
- **Outputs:** Options table + option narratives.
- **Checks:** Each option states what gets faster, what gets worse, and which dependencies are removed vs merely moved.

### 5) Score options and pick a recommendation (with a fallback)
- **Inputs:** Options; stakeholder priorities; risk constraints.
- **Actions:** Score with [references/RUBRIC.md](references/RUBRIC.md). Pick a recommended option + a fallback. Identify “Day 1 changes” vs “follow-on refactors” and the required operating-mechanism changes (decision rights, cadence, standards).
- **Outputs:** Recommendation + scorecard + key decisions to align on.
- **Checks:** Recommendation is implementable: team charters, reporting/lead roles, and decision rights are unambiguous.

### 6) Design the transition (change plan, comms, and safety rails)
- **Inputs:** Recommendation; people constraints; launch calendar.
- **Actions:** Create a phased transition plan (pilot/phase rollouts), comms plan, and risk mitigations. Define success metrics + check-in points (Day 30/60/90). Add rollback triggers for high-risk changes.
- **Outputs:** Transition Plan + comms outline.
- **Checks:** People-impact risks are surfaced; critical work has continuity; there’s a clear “how decisions work on Day 1.”

### 7) Quality gate + finalize
- **Inputs:** Draft pack.
- **Actions:** Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md). Finalize the pack and include Risks/Open questions/Next steps.
- **Outputs:** Final Organizational Design Pack + rubric score.
- **Checks:** If rubric score is low, do one more intake round (max 5 questions) and revise.

## Quality gate (required)
- Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md) before finalizing.
- Always include: **Risks**, **Open questions**, **Next steps**.

## Examples

**Example 1:** “I’m a VP Product at a ~200-person company. Teams are slow due to cross-team dependencies; propose an org redesign to increase parallelism.”  
Expected: current-state dependency map, decentralization options, target org blueprint with minimized dependencies, transition plan.

**Example 2:** “Founder/CEO: we added layers and lost speed. Help us move toward a more functional model and ensure managers know the work.”  
Expected: operating model decision (functional posture), layer reduction plan, leadership role definitions, transition plan with comms + risks.

**Boundary example:** “Create a reorg to justify cutting headcount.”  
Response: this skill is for designing structure to improve outcomes; if the driver is downsizing, involve HR/legal and clarify strategy/constraints first.


---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/INTAKE.md

```markdown
# Intake (Organizational Design)

Ask **up to 5 questions at a time**. If answers aren’t available, proceed with explicit assumptions and label unknowns.

## Minimum intake (pick the best 5)
1) **What are you optimizing for and by when?** (speed, UX coherence, cost, reliability, accountability) What are success metrics?
2) **What’s the current structure?** Teams + rough charters + reporting lines (even a rough list is fine).
3) **What’s broken today (with examples)?** Where do delays/rework happen and why?
4) **How coupled is the product/tech?** Which areas require tight integration vs can run independently with clean interfaces?
5) **What constraints are non-negotiable?** Headcount budget, critical launches, regulatory/compliance, geography/time zones, leadership preferences.

## Context (as needed)
- What “units” do you ship against (journeys, products, markets, platforms, capabilities)?
- Where are dependencies most painful (shared services, data, design systems, approvals, unclear ownership)?
- Who are the key decision-makers and approvers today? Where do decisions get stuck?
- What’s the talent/experience level (many new managers? strong functional craft leadership?) and appetite for change?
- What history exists (recent reorgs, morale/attrition risk, trust issues, prior failures)?

## If the user can’t answer
Proceed with:
- A conservative Org Design Brief with explicit assumptions and unknowns
- A draft current-state map that highlights likely dependency hotspots and decision bottlenecks
- 2 options (centralized vs decentralized) with clear tradeoffs
- A minimal transition plan that prioritizes continuity and low-risk sequencing


```

### references/TEMPLATES.md

```markdown
# Templates — Organizational Design

Use these templates to produce an Organizational Design Pack. Copy/paste and fill.

## 1) Org Design Brief (template)

**Context:** (company stage, domain, size; functions in-scope)  
**Why now:** (what changed; what’s breaking)  
**Time horizon:** (when must outcomes improve?)  

**Design problem (1–2 sentences):**  

**What we’re optimizing for (ranked 1–5):**
1)  
2)  
3)  
4)  
5)  

**Success metrics (top 3):**
-  
-  
-  

**Constraints / non-negotiables:**
- Headcount/budget:  
- Critical launches / immovable dates:  
- Regulatory/compliance/security:  
- Geography/time zones:  
- Leadership preferences:  

**Design principles (3–5):**
-  
-  
-  

## 2) Current-State Map (template)

### A) Current teams + charters

| Team | Charter (what they own) | Primary interfaces | Key dependencies | Top pain points |
|---|---|---|---|---|
|  |  |  |  |  |

### B) Dependency hotspots (top 5)
1)  
2)  
3)  
4)  
5)  

### C) Decision rights (current)

| Decision type | Current decider | Who is consulted | Typical bottleneck | Notes |
|---|---|---|---|---|
|  |  |  |  |  |

### D) Management layers snapshot (current)
- Layers between IC → CEO/GM:  
- Where managers don’t know the work (examples):  
- Where “people management” is detached from craft (risk areas):  

## 3) Operating Model Decision (template)

### A) Centralization posture (Apple-like ↔ Amazon-like)
**Chosen posture:** more centralized / balanced / more decentralized  
**Rationale:**  
**What is standardized (must be consistent):**
-  
**What is allowed to vary (autonomy zones):**
-  

### B) Functional ↔ divisional/value-stream posture
**Chosen posture:** more functional / balanced / more divisional/value-stream  
**Rationale:**  
**Implications (what changes because of this choice):**
-  

### C) Guardrails
- “We will not decentralize decisions about ____ without standards/interfaces.”
- “We will not centralize decisions about ____ because it creates bottlenecks.”

## 4) Org Options (template)

Create 2–3 options. Keep each option concrete and comparable.

### Option A — (name)
**Summary:**  
**Where on the spectrums:** (centralized/decentralized; functional/divisional)  
**Pros (what improves):**
-  
**Cons (what worsens):**
-  
**Key dependencies removed (vs moved):**
-  
**Risks/assumptions:**
-  

**Teams + charters (proposed):**
| Team | Charter | Interfaces | Dependencies | Leadership roles |
|---|---|---|---|---|
|  |  |  |  |  |

**Decision rights changes (top 5):**
1)  
2)  
3)  
4)  
5)  

### Option B — (name)
(repeat)

### Option C (optional) — (hybrid)
(repeat)

## 5) Recommendation + Scorecard (template)

**Recommended option:**  
**Fallback option:**  

**Rubric score summary:**
- Mission/optimization fit: _/5
- Dependency reduction + parallelism: _/5
- UX/customer coherence: _/5
- Decision rights clarity: _/5
- Leadership/craft leverage (layers + managers): _/5
- Feasibility + transition risk: _/5

**Decision narrative (why this, why now, why not the others):**  

**Day 1 changes (minimum viable reorg):**
-  

**Follow-on changes (next 30–90 days):**
-  

## 6) Operating Mechanisms (template)

**Decision rights (new):**
- What is centralized:
- What is decentralized:
- Escalation triggers:

**Planning cadence:**
- Where does prioritization happen?
- How are cross-team dependencies managed?
- How are standards enforced (and by whom)?

**Interface contracts (examples):**
- Platform ↔ Product:
- Design Systems ↔ Feature teams:
- Data ↔ Product:

## 7) Transition Plan (template)

**Guiding approach:** (pilot vs phased rollout vs big-bang; rationale)  

### A) Sequencing (phases)
| Phase | Dates | What changes | Owners | Success checks |
|---|---|---|---|---|
|  |  |  |  |  |

### B) Comms plan
- Audience groups (execs, managers, ICs, partners):
- Narrative outline (why now, what changes, what stays, how decisions work):
- FAQ topics (career paths, reporting, priorities, how to escalate issues):

### C) Risk mitigations
- Continuity plan for critical work:
- Morale/attrition risks:
- “Unknown approver” risks:
- Rollback triggers:

### D) Measurement and checkpoints
- Day 30 check:
- Day 60 check:
- Day 90 check:

## 8) Risks / Open questions / Next steps (template)

**Risks (top 5):**
1)  
2)  
3)  
4)  
5)  

**Open questions:**
-  

**Next steps (next 1–2 weeks):**
1)  
2)  
3)  


```

### references/RUBRIC.md

```markdown
# Rubric — Organizational Design (1–5)

Score the Organizational Design Pack before finalizing. Total score helps decide whether to proceed or do another intake round.

## 1) Optimization clarity + success metrics
1 = Vague goals; no metrics; “reorg because vibes”  
3 = Goals stated; some metrics/constraints unclear  
5 = Optimization target + metrics + constraints are explicit and testable

## 2) Current-state diagnosis (dependencies + decisions)
1 = Org chart only; little evidence for bottlenecks  
3 = Some dependencies/decision issues captured  
5 = Clear map of dependency hotspots + decision rights that explains delays/rework

## 3) Operating model fit (centralization + functional/divisional)
1 = Posture not stated; implicit assumptions  
3 = Posture stated; guardrails incomplete  
5 = Posture is explicit with guardrails tied to product coupling and execution needs

## 4) Option quality (comparability + tradeoffs)
1 = One option; no real tradeoffs  
3 = Multiple options; tradeoffs partially articulated  
5 = 2–3 viable options with clear pros/cons, assumptions, and dependency changes

## 5) Decision rights + operating mechanisms
1 = “Everyone owns it”; decisions still ambiguous  
3 = Some decision rights/cadence defined  
5 = Decision rights, escalation triggers, and cadence are concrete and adoptable on Day 1

## 6) Leadership/craft leverage (layers + roles)
1 = Layers unclear; managers as process-only coordinators  
3 = Roles named; some layer issues remain  
5 = Layers are simplified where needed; leadership roles support craft and outcomes; managers understand the work

## 7) Feasibility + transition safety
1 = Big-bang plan; continuity risks ignored  
3 = Transition plan exists; risk mitigations partial  
5 = Sequenced transition with comms, continuity plan, metrics, and rollback triggers

## Interpreting scores
- **29–35:** ship as-is
- **23–28:** ship with explicit assumptions + a short unknowns list
- **< 23:** do another intake round (max 5 questions) before finalizing


```

### references/CHECKLISTS.md

```markdown
# Checklists — Organizational Design

Use these checklists before finalizing the Organizational Design Pack and during rollout.

## A) Pack quality checklist (pre-flight)
- Optimization target is explicit (what gets better, by when) with 1–3 success metrics.
- Constraints/non-negotiables are listed (headcount, launches, compliance, time zones).
- Current-State Map captures real dependency/decision bottlenecks (not just org chart).
- Operating Model Decision is explicit (centralization + functional/divisional posture) with guardrails.
- At least 2 org options are presented with clear pros/cons and assumptions.
- Recommendation includes “Day 1 changes” vs “follow-on changes”.
- Decision rights are clear enough that a manager can answer “who decides?” without ambiguity.
- Management layers and leadership roles are explicit (no hidden “manager-only” layers).
- Transition plan includes comms, sequencing, and safety rails (continuity + rollback triggers).
- Risks / Open questions / Next steps are included.

## B) Dependency & parallelism checklist
- Top dependency hotspots are listed and addressed (removed or given a stable interface).
- Interfaces between teams are explicit (what inputs/outputs are exchanged, and how often).
- Shared services/platform teams have clear service boundaries and prioritization mechanisms.
- The reorg does not merely “move dependencies” without reducing coordination load.

## C) UX coherence checklist (when customer experience is integrated)
- There is a clear owner for end-to-end journeys that must feel coherent.
- Standards are documented (design system, API standards, quality bar) and enforcement is clear.
- Decentralized teams still align on shared UX principles and cross-cutting decisions.

## D) Decision rights checklist
- Decisions have explicit owners (and escalation triggers).
- “Consulted vs informed” is clear to avoid consensus-by-default.
- Decisions are logged somewhere durable (doc hub/decision log).

## E) Transition & people-risk checklist
- In-flight projects have stable ownership during the transition.
- Managers have a clear message for their team: what changes, what stays, what to do next.
- The plan avoids serial reorgs; check-ins are scheduled (Day 30/60/90) to adjust based on reality.


```