内部订单页面只改一个字段，也可能暴露整条决策路径。负责页面的团队了解字段、使用者和回滚办法，但请求仍要在三个队列里等待，因为三个部门分别拥有应用的一部分。这是说明机制的例子，不是对某家公司的报道。
工作到底在哪里？实现也许只需一小时，决策路径却可能占去一周。
一场关于组织官僚流程的讨论提出了比“会议太多”更具体的观点：组织的安排可能制造出员工随后努力消除的繁文缛节。这是关于结构的论点，并非适用于所有慢团队的已证实疗法。它引出一个有用的问题：哪些等待仅仅来自权限的划分？
追踪决策，不要只看组织架构图
选一类经常出现的决策即可，例如数据模式变更、客服政策例外，或导出文件新增字段。从有人掌握足够信息、可以提出修改时开始，到修改被接受或拒绝时结束。记录每一步由谁负责、需要判断什么、何时可以行动。
要区分交接和检查。交接把请求转给另一个负责人；检查验证真实约束。两者经常一起出现，却不是一回事。
在订单页面的示例中，一个团队可能检查字段是否暴露个人数据。这项检查有明确理由。第二个团队可能只是重复讨论优先级，因为实施团队无法自行安排工作队列。这是所有权边界。删掉会议，边界仍然存在。
| 跨越的边界 | 要回答的问题 | 何时保留 |
|---|---|---|
| 从产品到实施 | 现在值得做这项修改吗？ | 接手团队掌握不同且必要的优先级信息 |
| 从实施到安全 | 访问范围是否改变？ | 修改跨越权限或数据边界 |
| 从实施到运营 | 修改能运行并在故障后恢复吗？ | 运营团队确实承担发布或恢复后果 |
| 团队间知会 | 谁需要知道？ | 知会会影响行动；通知不一定需要否决权 |
这张表是概念性诊断工具，没有给出改变某种组织结构的实测效果。团队生产力指南讨论工具；这里要问的是某次交接本身是否必要。
决策距离才是有用的单位
组织架构图中的方框说明谁向谁汇报，却没有说明一个决策要走多远，才有人可以为行动负责。决策距离，就是从问题到有负责人采取行动之间，背景信息传递、排队和否决的顺序。
- 修改请求问题已知等待
- 队列所有权边界重建背景
- 背景交接重新说明原因授权
- 决策明确负责人
距离之所以重要，是因为背景信息会在传递中流失。每次交接都有人需要重新解释字段为何重要、可能发生什么，以及已经排除哪些方案。接手方可以要求更完整的说明，发起方也可以补写一份，但重建情境的工作并未消失。
因此，“多沟通”经常不能解决问题。更好的记录能帮助必要的边界运作，却不能让不必要的边界产生价值。如果相同事实要在三个会议室里重复说明，缺少的往往是决策权，而不是另一套幻灯片。
在商店与邮件系统之间同步数据时，代价很具体。理解“活跃客户”业务含义的人，可能不在负责字段映射的团队。如果每次修正都要等通用平台团队审查，映射队列就替代了明确的共同责任。团队可能需要清晰契约：本地业务规则归工作流负责人，传输、身份验证和恢复归平台负责人。
审批何时真正保护工作
“多一道审批能发现错误。”有时确实如此。安全、同意、财务控制和共享接口变更，可能影响提出请求的团队以外的人。只为让图表变好看而删掉这些检查，是不负责任的。
更好的测试是问每次跨越到底发现什么。如果审查者经常找到权限错误，就保留控制，并改善交给他的材料。如果审查者只是为了知会而收到同一请求，从不改变决定，就把否决权改为记录或通知。如果两个团队都自称对同一结果负责，先解决责任冲突，再压缩日程。
可以用有限实验观察。选一类低风险决策，明确负责团队、不可跨越的约束、必须保留的证据，以及纠错办法。比较改变前后少量同类请求：总耗时、等待时间、返工和撤销。这些是待收集的指标，并非来源提供的数据。
重组需要成本。人们要学习新角色，失去熟悉的求助途径，也可能发现旧架构掩盖的约束。从决策路径开始。汇报关系的改变可以随后发生，但不应成为第一个交付物。
最短路径有时只差一个明确的决策权限。
常见问题
怎样判断组织结构是否造成延迟？
追踪一类具体且重复的决策，记录每位负责人、等待队列和必要审批。找出只增加等待、却没有增加信息、控制或责任的边界，并在改变前后测量同一条路径。
所有决策都应交给一个团队吗？
不应如此。共同承担的安全、法律、同意和财务风险可能需要独立审查。只有团队掌握背景、拥有权限并能承担后果时，才把决策权移过去。
重组后应该测量什么？
针对同一类决策，比较耗时、交接次数、返工和有害撤销。审批更快但错误代价更高，不能算明确改善。