让团队参与设计,组织重组才能更顺畅

原标题A smoother reorganization starts by letting teams design it

Joakim Sundén 将领导层的战略与员工对日常工作的了解结合,再让员工自主选择团队。

JSJoakim Sundén讲者 · Better Product Work
频道
GOTO Conferences
发布
2026年11月10日
视频
38:07
阅读
6 分钟
幻灯片
4
原文
英语
在 YouTube 打开
往下滚动阅读时,视频会缩到右下角继续播放。字幕跟随阅读语言。
阅读语言共 2 种语言可读
由 AI 从英语原文翻译。打开“对照原文”可以逐段核对。
摘要

30 秒看懂

一家成长中的 B2B 公司的领导层不满意团队设计的第一版重组方案:它反映的是当下结构,而不是未来战略。他们没有把设计工作收回,而是明确愿景,让团队运用工具继续修改。Joakim Sundén 说,由于员工参与了设计,最终自主选队比管理层预期顺利得多。他提出的条件是清晰度、能力、控制权和支持性的环境。

  1. 1组织图可能忽略团队之间实际发生的工作Sundén 说,自上而下的结构常常忽略技术依赖和日常协作,反而增加交接。
  2. 2没有清晰度和能力的控制权可能带来混乱相反,有能力的人缺乏控制权,会产生挫败感和官僚主义。
  3. 3令人失望的第一版方案暴露了战略信息不足领导层没有用自己的设计取代团队工作,而是明确未来愿景和招聘计划。
  4. 4团队 API 明确了使命和不负责的事项团队描述所需技能、系统和指标,并增加列出其他团队应负责工作的反待办清单。
  5. 5预留一周的选队过程在一个下午基本完成管理层准备应对反对意见,但员工参与设计后,大多数人很快选定团队。
  6. 6领导层保留战略,团队参与塑造边界流程逐步扩大参与,同时让领导层保留约束和最终决定权。

要点建议

  1. 让团队设计结构前,先提供战略方向和清晰的决策边界。
  2. 让控制权与能力和清晰度匹配;补足缺失条件,而不是收回每个决定。
  3. 比较组织方案之前,先就设计标准和取舍达成一致。
  4. 用团队使命、所需技能、系统和明确不负责的事项作为思考工具。
  5. 逐步扩大参与,把组织设计当成持续能力。
全文

按章节阅读整理后的全文

只看原始文稿
01

为什么强加给员工的重组容易引发抵触

Sundén 说,自上而下的组织图常常忽略实际工作流,也缺少员工参与。领导层仍然承担重要的战略责任。

Joakim Sundén 介绍协作式组织设计:这一方法最初在 Spotify 发展起来,后来也用于其他场景。他在 Spotify 工作期间,公司从约八个团队增长到 200 个团队;他现在是 Better Product Work 的创始合伙人。

被问到组织重组让人想到什么时,听众回答裁员、浪费时间和混乱。Sundén 追问:旨在改善组织的过程为何如此经常引发这些反应?

他的解释是,管理层设计结构时往往离日常工作太远。按职能或业务单元绘制的组织图可能忽略系统依赖和实际协作,即便纸面上整齐,也会增加交接。

人们抵触变革,可能是因为目的不清楚或无法影响结果,并不是反对一切变化。Sundén 也批评把重组当作一次固定的大计划:漫长的设计尚未落地,环境可能已经变化。

他承认领导者选择自上而下方法有其原因:领导层负责战略和结果,预算或裁员可能限制参与,只让管理层开会也似乎比让一百人参加更快。但他认为表面速度可能掩盖代价高昂的浅层分析。

这并不是反对领导层作决定。领导者了解市场和战略,实际工作的人了解日常协作、痛苦的接口和技术依赖。设计问题在于如何结合这两类知识。

02

实现有效控制权的四个条件

控制权需要清晰度、能力和支持性的环境。领导者可以补足缺失条件,而不是只替团队作决定。

听众提出参与需要动力、时间、知识、信任、沟通和共同目标。Sundén 把条件归为控制权、清晰度、能力和环境:人们需要权力、清晰的目标与边界、相关技能,以及支持参与的环境。

这一模型借鉴了潜艇舰长 David Marquet 的工作。Sundén 的团队增加了环境这一维度,并认为控制权的大小应与团队具备的清晰度和能力相匹配。

环境中的控制权、清晰度与能力
幻灯片 1 / 4环境中的控制权、清晰度与能力四条件模型描述团队作出有意义决定所需的要素。

给人控制权却缺少足够清晰度或能力,可能导致混乱或停滞;让有能力的人面对清晰目标却没有控制权,则会造成挫败和官僚主义。有效区间是责任与行使责任所需的能力和信息相匹配。

管理者每次面对优先级问题都直接规定先做 A、再做 B、再做 C,可能觉得自己在帮忙,却收回了控制权。Sundén 建议追问团队缺少什么信息、能力或条件,并帮助补足,让团队下次能自己决定。

让控制权与能力和清晰度匹配
幻灯片 2 / 4让控制权与能力和清晰度匹配准备不足却赋予过多控制权可能引发混乱;控制权过少则导致挫败。

环境可能削弱名义上的授权。团队或许能选择按钮颜色,但实际产品由其他利益相关者决定;也可能受制于旧系统和目标不同的其他团队。必须结合这些约束看待授权。

03

改变组织实施变革的方式

一家 B2B 公司组建跨职能变革团队、描述目标,并教授组织设计的共同语言。

案例是一家成长中的 B2B 公司:在压力下,它回到了自上而下确定优先级和微观管理任务的方式。Sundén 的团队没有先画新组织图,而是先改变组织实施变革的方式。

跨职能变革团队包括工程经理、开发、测试、人力与文化、销售和高管。引导者先示范以结果为中心的流程,再与团队共同实践,逐步转为指导团队自己运行,并用领先和滞后指标评估进展。

他们介绍产品运营模式,并讨论成功的授权团队可能是什么样子。随后变革团队为自己的公司共同描述具体未来:两年后什么会不同,团队实际拥有哪些决定权。

他们通过演讲、录像和读书会教授 Team Topologies。共同概念包括与价值流对齐的团队、平台团队,以及传播测试自动化等专长的赋能团队。目标是建立讨论不同设计的共同语言。

一个有用概念是“断裂面”:系统或组织能够自然拆分的接缝。地点、业务领域、监管要求或不同变化速度都可能提示边界,但任何一项都不能单独决定答案。

04

第一版设计暴露战略清晰度不足

团队就目标和取舍达成一致;随后领导层分享更清楚的未来愿景,让团队修改提案。

团队就优化目标达成一致,列出约束和经验规则:多样性、地点、团队规模、责任归属、可扩展性、自主权、认知负荷和公司未来愿景。他们为这些标准赋予权重,以比较方案并明确权衡。

就目标与设计取舍达成一致
幻灯片 3 / 4就目标与设计取舍达成一致团队权衡了规模、责任归属、可扩展性、自主权等标准。

小组起草了初版团队使命和结构。领导层感到失望,因为提案反映的是当前组织,而不是他们希望的未来。团队没有把工作收回管理层,而是追问缺少哪些战略信息。

领导层完善并分享了 2026 年愿景、产品战略、路线图和预期招聘计划,团队随后重新设计。这样改变了参与者掌握的信息,同时保留领导层的战略责任。

05

明确团队使命并扩大参与

团队 API、共享白板和迭代工作坊帮助参与者比较方案并为增长做准备。

下一个工具是团队 API:草拟每个团队的使命、类型、所需能力、指标、系统和可能的工作。参与者调整模板,还增加“反待办清单”,列出他们认为应由其他团队负责的工作。这些文档是思考工具,而不只是记录。

明确团队使命和所需能力
幻灯片 4 / 4明确团队使命和所需能力团队 API 帮助参与者思考职责、系统和技能需求。

设计转到共享白板,让更多人异步参与,并根据标准比较方案。小组扩大到开发团队,吸收建议、反复迭代,形成既适用于当前人员规模、又考虑未来增长的设计。

由于当前人员不足以组成所有未来团队,组织先按现状组合工作,同时标出未来随着人数增加可以拆分团队的接缝。这样,增长从一开始就是设计的一部分。

06

自主选队与顺利重组背后的条件

管理层为选队预留一周,但大多数人很快完成选择。Sundén 把结果归因于事先建立的条件。

随后团队邀请员工自主选择团队。管理者担心人际冲突或偏好会导致结果不可行。Sundén 说,选择时既考虑个人偏好,也要求大家依据公司共同确定的目标和约束思考。

管理层准备了一周的说明、每日问答和待命会议来处理困难。但员工大多在周一下午就把名字填到团队中,很少有人来投诉。管理者形容这次重组异常平静、顺利。

Sundén 把这一体验归因于员工从一开始就参与,减少了意外。他希望组织设计成为团队可以持续改进的能力,而不是等组织债务积累后才重新进行的痛苦一次性事件。

他用四个条件总结变化:创造协作环境,澄清目的和决策边界,教授设计能力,并逐步增加团队控制权。领导层保留战略、愿景、约束和最终决定权;团队参与塑造使命、边界、接口及自己的团队选择。

顺序很重要:改组织图之前先改变环境,让人理解问题后再请他们解决,并随着清晰度和能力提升逐步扩大参与。Sundén 希望创造让人们能持续自行改进组织的条件。

同频道的其他文章

9 张幻灯片49:56EN → 简体中文
GOTO Conferences· 2026年11月9日Barbara Oakley:让 AI 支持学习,而不是替代学习Barbara Oakley · Oakland University她将记忆、练习和好奇心,与判断 AI 生成答案的能力联系起来。EducationAI in EducationNeuroscience+2
29:42EN → 简体中文
GOTO Conferences· 2026年11月6日Artie Shevchenko 与 Titus Winters:AI 时代的代码健康Titus Winters, Artie Shevchenko · Adobe两位作者讨论复杂性、人工审查、测试,以及为什么接口和状态在 AI 辅助开发中值得关注。Software engineering开发流程与测试编程智能体+1
2 张幻灯片42:40EN → 简体中文
GOTO Conferences· 2026年11月5日Daniel Terhorst-North:用生成式 AI 拓宽工作,而不只是加快速度Daniel Terhorst-North · Dan North & Associates一位软件实践者分享 AI 辅助教学工具如何引出“相邻工程”、更大步长的测试先行和外部护栏。Software engineeringHuman-AI Collaboration开发流程与测试+1
2 张幻灯片44:42EN → 简体中文
GOTO Conferences· 2026年11月4日Adam Tornhill:面向 AI 的健康代码与可持续智能体开发Adam Tornhill智能体编程可以加速交付,但复杂度可能抵消收益。Adam Tornhill 介绍代码健康度研究与大规模重构案例。Software engineering编程智能体开发流程与测试+1
幻灯片51:06EN → 简体中文
GOTO Conferences· 2026年11月4日Kent Beck:AI 编程、森林与人的需求Kent BeckAI 会放大软件团队原有的工作方式。Kent Beck 呼吁保留未来的选择,并围绕人的需求设计工具。Software engineering编程智能体Developer productivity+1
7 张幻灯片40:04EN → 简体中文
GOTO Conferences· 2026年11月2日Sophia Drossopoulou:如何在开放世界中验证可信代码Sophia Drossopoulou · Imperial College London当可信代码调用未知对象时,能力、有作用域不变量和明确的信任假设有助于推理其影响。Code review & verificationProgramming LanguagesSoftware engineering