Back to Details

organizational-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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
    ).
涵盖内容
  • 设计或重新设计组织的架构+运营模型，以提升响应速度、问责性和客户成果
  • 在集中式与分散式模型（苹果↔亚马逊风格区间）以及职能型与事业部/价值流导向之间做选择
  • 通过最小化依赖和明确决策权限来降低协作成本
  • 设置管理角色与层级，让领导者了解具体工作内容，能够推动专业能力提升，而非仅关注流程
适用场景
  • “为我的产品+技术团队提出重组/组织设计方案。”
  • “我们因跨团队依赖导致效率低下——重新设计团队结构，让我们能够并行推进工作。”
  • “我们的UX体验碎片化——应该集中决策还是强化职能型领导力？”
  • “我们发展迅速，增加了管理层级——帮我们简化结构，回归初创公司的响应速度。”
不适用场景
  • 你首先需要产品战略/愿景（使用
    defining-product-vision
    或
    working-backwards
    工具）。
  • 这主要是人员绩效问题（使用教练/反馈流程，而非重组）。
  • 你需要薪酬等级、职级体系、招聘计划或法律/HR指导（请联系HR/法务部门）。
  • 你需要单一高风险决策流程（使用
    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.
  • If answers aren’t available, proceed with explicit assumptions and label unknowns.
最低要求
  • 组织背景：公司阶段、业务领域、规模，以及涉及的职能范围（例如：产品/技术/设计/数据）
  • 当前架构：团队构成、汇报线（大致即可），以及当前工作的组织方式
  • 核心目标：必须改善的方面（例如：速度、质量、统一UX体验、所有权、成本）
  • 关键问题及示例（例如：决策缓慢、重复工作、所有权模糊、UX体验碎片化）
  • 约束条件/不可协商项（人员编制、时间线、关键发布计划、监管合规要求、领导层偏好）
缺失信息处理策略
  • 从references/INTAKE.md中最多提出5个问题。
  • 如果无法获取答案，基于明确假设推进，并标注未知信息。

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
生成组织设计包（聊天内Markdown格式，或按需提供文件），内容顺序如下：
  1. 组织设计简报（目标、约束条件、设计原则、成功指标）
  2. 现状映射图（团队/职责、依赖热点、决策权限、管理层级）
  3. 运营模型决策（集中式↔分散式 + 职能型↔事业部型的选择依据）
  4. 目标组织蓝图（团队拓扑+职责+领导角色+协作接口）
  5. 运营机制（决策权限、规划节奏、跨团队协作接口）
  6. 过渡计划（实施顺序、沟通方案、人员调整、风险缓解、效果衡量）
  7. 风险/待解决问题/下一步行动（必须包含）
模板参考：references/TEMPLATES.md

Workflow (7 steps)

工作流程（7步）

1) Define what you’re optimizing for (and the constraints)

1) 明确优化目标与约束条件

  • 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.
  • 输入：目标；问题症状；约束条件；时间线。
  • 行动：将“我们需要重组”转化为具体的设计问题：必须改善哪些成果，以及时间要求。确定3–5条设计原则（例如：“最小化依赖”、“关键用户旅程设单一UX负责人”、“减少管理层级”）。
  • 输出：组织设计简报（草稿）+ 成功指标。
  • 检查点：利益相关者能够就核心权衡（例如：速度与UX一致性）以及成功标准达成共识。

2) Map the current org-as-a-system (work, dependencies, decisions)

2) 绘制当前组织系统地图（工作、依赖、决策）

  • 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.
  • 输入：当前团队构成；路线图/工作流；已知的协作摩擦案例。
  • 行动：记录团队职责、依赖关系和决策权限。识别依赖热点、重复所有权和意外审批环节。梳理管理层级，以及管理者不了解具体工作的情况。
  • 输出：现状映射图 + “Top 5协作摩擦循环”列表。
  • 检查点：该地图能够通过具体的依赖/决策瓶颈解释大多数观察到的延迟/重复工作问题。

3) Choose an operating model posture (centralize vs decentralize; functional vs divisional)

3) 选择运营模型定位（集中vs分散；职能vs事业部）

  • 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.
  • 输入：产品架构/耦合度；UX整合需求；人才成熟度；风险容忍度。
  • 行动：将组织定位在两个区间：(1) 集中式（苹果风格）↔分散式（亚马逊风格），以及(2) 职能型↔事业部/价值流型。撰写选择依据和边界规则（哪些必须标准化，哪些可以自主决策）。
  • 输出：运营模型决策 + 边界规则。
  • 检查点：选择与产品耦合度匹配：整合式体验有明确负责人；独立模块可以并行推进，且协作接口清晰。

4) Generate 2–3 viable org options (not one)

4) 生成2–3个可行的组织方案（而非单一方案）

  • 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.
  • 输入：现状映射图；运营模型定位；约束条件。
  • 行动：起草2–3个方案（A/B/(C混合方案)），每个方案包含团队列表、职责、领导角色、协作接口，以及预期的依赖变化。明确管理层级；避免设置无领域/专业背景的“纯人员管理者”。
  • 输出：方案对比表 + 方案说明。
  • 检查点：每个方案都明确说明哪些方面会变快，哪些方面会受影响，以及哪些依赖会被消除，哪些只是转移。

5) Score options and pick a recommendation (with a fallback)

5) 评分方案并确定推荐方案（含备选）

  • Inputs: Options; stakeholder priorities; risk constraints.
  • Actions: Score with 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.
  • 输入：各方案；利益相关者优先级；风险约束。
  • 行动：使用references/RUBRIC.md进行评分。选定推荐方案+备选方案。区分“首日可落地变更”与“后续优化项”，以及所需的运营机制变更（决策权限、节奏、标准）。
  • 输出：推荐方案 + 评分卡 + 需对齐的核心决策。
  • 检查点：推荐方案可落地：团队职责、汇报/领导角色、决策权限清晰明确，无歧义。

6) Design the transition (change plan, comms, and safety rails)

6) 设计过渡方案（变更计划、沟通、安全机制）

  • 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.”
  • 输入：推荐方案；人员约束；发布日程。
  • 行动：制定分阶段过渡计划（试点/分阶段推广）、沟通方案和风险缓解措施。定义成功指标+检查节点（第30/60/90天）。为高风险变更添加回滚触发条件。
  • 输出：过渡计划 + 沟通大纲。
  • 检查点：人员影响风险已明确；关键工作有连续性；“首日决策机制”清晰明确。

7) Quality gate + finalize

7) 质量校验+最终定稿

  • Inputs: Draft pack.
  • Actions: Run references/CHECKLISTS.md and score with 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.
  • 输入：设计包草稿。
  • 行动：执行references/CHECKLISTS.md并使用references/RUBRIC.md评分。最终定稿设计包，并包含风险/待解决问题/下一步行动。
  • 输出：最终组织设计包 + 评分结果。
  • 检查点：如果评分较低，最多再进行一轮信息收集（5个问题）并修订。

Quality gate (required)

质量校验（必填）

  • Run references/CHECKLISTS.md and score with references/RUBRIC.md before finalizing.
  • Always include: Risks, Open questions, Next steps.
  • 最终定稿前，必须执行references/CHECKLISTS.md并使用references/RUBRIC.md评分。
  • 必须包含：风险、待解决问题、下一步行动。

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.
示例1： “我是一家约200人公司的产品VP。团队因跨团队依赖导致效率低下；请提出组织重组方案以提升并行推进能力。” 预期输出：现状依赖图、分散化方案、最小化依赖的目标组织蓝图、过渡计划。
示例2： “创始人/CEO：我们增加了管理层级，导致效率下降。帮我们转向更偏向职能型的模型，确保管理者了解具体工作内容。” 预期输出：运营模型决策（职能型定位）、层级精简计划、领导角色定义、含沟通+风险的过渡计划。
边界示例： “设计重组方案以合理化裁员。” 回应：本工具用于设计架构以提升业务成果；如果驱动因素是裁员，请联系HR/法务部门，并先明确战略/约束条件。