| name | complexity-equation |
| description | 当团队扩张后效率反而下降、沟通成本暴增时；当创始人不理解"为什么人多了
反而更慢"时；当企业在扩张和稳定之间犹豫不决时；当组织设计要做调整时。
触发信号："三个人干得挺好的，加了第四个人反而乱了？"、"部门越来越多，
协调越来越难"、"增长要不要放缓？人多了是不是有问题？"
不适用于：个人层面的时间管理问题、初创期人数极少时的线性复杂度场景。
|
| source_book | 《Scaling Up》 Vern Harnish |
| source_chapter | 第2章 Barriers |
| tags | ["complexity","organizational-design","scaling","growth-barriers"] |
| related_skills | ["complexity-enemy(composes-with)"] |
Complexity Equation（复杂度乘法方程）
R — 原文 (Reading)
"Add a third person, and the degree of complexity triples from two to six. Add a fourth, and it quadruples to 24. Expanding from three to four people grows the team only 33%, yet complexity may increase 400%."
— Vern Harnish, Scaling Up, 第2章 Barriers
I — 方法论骨架 (Interpretation)
复杂度乘法方程揭示了企业扩张的隐性代价：人数线性增长，复杂度指数增长。
公式的本质：每增加一个人，与所有人的沟通节点都要重新计算。
两个人=1条关系；三个人=3条关系；四个人=6条关系；五个人=10条关系。
这叫"组合数增长"——n个人产生的连接数 = n(n-1)/2。
数字说话：
- 2人 → 1连接
- 3人 → 3连接（+200%）
- 4人 → 6连接（+100%，但团队只增33%）
- 5人 → 10连接
- 10人 → 45连接
关键洞察：增长不是问题，缺乏管理增长的系统才是问题。
复杂度不是要不要面对的选项，而是成长的必然副产品。
解决方案不是"不增长"，而是"提前建立消化复杂度的机制"：
流程（Process）、规则（Disciplines）、沟通节奏（Rhythm）。
A1 — 书中的应用 (Past Application)
案例 1: 团队从3人到4人的"死亡陷阱"
- 问题: 3人团队运转流畅，加了第4个"聪明人"后反而频繁开会、协调成本暴增
- 方法论的使用: 用复杂度公式解释——不是第4个人不行，是连接数从3跳到6，
团队没有为此准备额外的流程和沟通机制
- 结论: "4人门槛"需要引入明确的会议节奏和决策流程
- 结果: 创始团队开始重视"加人不加乱"的组织设计
案例 2: 30人扩张到50人的中层管理危机
- 问题: 快速扩张期，管理层抱怨"信息传不下去"，部门墙越来越厚
- 方法论的使用: 50人产生的连接数是1225，30人是435——人增加了67%，
连接数增加了近3倍。没有对应的信息流通机制，必然出现失真
- 结论: 在这个规模必须引入结构化的沟通机制（周会、简报、可视化看板）
- 结果: 引入Rockefeller Habits中的会议节奏工具，情况显著改善
案例 3: 复杂度的"隐性税"
- 问题: 创始人抱怨"我明明雇了更多人来分担，怎么我还是这么累"
- 方法论的使用: 展示数字：6人团队有15条连接，每条连接都在消耗
创始人的协调能量。更多人意味着更多连接，更多连接意味着更多潜在冲突和决策节点
- 结论: 解决方式不是减人，而是建立不依赖创始人的决策系统
- 结果: 创始人对"系统化"而非"靠人"有了全新理解
A2 — 触发场景 (Future Trigger) ★
用户会在什么情境下需要这个 skill?
- 团队从3-5人向10人以上扩张的阶段——开始感觉到协调成本上升，
但还没意识到这是结构性的
- 创始人在"要不要招人"的问题上纠结——感觉招了人效率反而下降，
怀疑是不是招错了人，而不是系统设计问题
- 公司出现"部门墙"或"沟通断层"——部门之间互相甩锅，
信息在传递过程中失真或消失
- 在做组织架构设计或汇报线调整——想要理解增加一个层级
或者增设一个部门会对复杂度产生什么影响
- 讨论"公司可不可以再快一点扩张"——需要量化理解
扩张速度与组织消化能力之间的关系
语言信号 (用户的话里出现这些就应激活)
- "我们人也不多啊，怎么感觉协调起来这么累？"
- "加了一个人之后好像更慢了，是不是招错了？"
- "部门之间好像有墙，信息传着传着就没了"
- "我一个人扛不住了，是不是该招个副总？"
- "增长太快是不是有问题？要不要放慢脚步？"
- "三个人干得挺好，加了第四个反而出问题了"
与相邻 skill 的区分
- 与
Growth Paradox（成长悖论） 的区别: 成长悖论是"为什么越大越累"
的哲学层面解释；复杂度方程是这个悖论的数学层面量化工具
- 与
PACe（流程问责表） 的区别: PACe是复杂度管理的具体落地工具，
复杂度方程是"为什么要用PACe"的原因解释
- 与
Rockefeller Habits 的区别: Rockefeller Habits是复杂度管理的
一套具体习惯清单；复杂度方程是这些习惯存在的理论依据
E — 可执行步骤 (Execution)
当 skill 被激活后，agent 应按以下步骤执行:
-
【量化现状】计算当前团队的连接数
- 公式：连接数 = n(n-1)/2（n=总人数）
- 问用户："你现在团队有多少人？" → 计算并展示连接数
- 完成标准: 用户看到连接数，理解"为什么现在协调成本这么高"
-
【预测未来】模拟扩张后的复杂度增长
- 问："如果你计划扩张到X人，连接数会变成多少？"
- 计算并对比：现在是多少，扩张后是多少，增长百分比
- 判停条件: 若用户说"现在还早"，则聚焦当前规模，不需要预测
-
【制定对策】引入复杂度消化机制
- 每个连接本质上需要三类机制之一来消化：
① 流程（标准化，减少临时沟通需求）
② 节奏（固定会议/周报，让信息定期流通）
③ 规则（明确谁决策什么，减少关系协调）
- 根据用户当前痛点，选择优先级最高的1-2个机制落地
- 完成标准: 用户理解"加流程不是管束，而是降低每个人的协调负担"，
并产出一个具体的"下月引入机制"清单
B — 边界 (Boundary) ★
不要在以下情况使用此 skill
- 个人时间管理问题：一个人管很多任务，复杂度方程不适用——
这是个人认知负荷问题，不是人际连接问题
- 10人以下极度扁平的小团队：此时连接数还处于可管理的范围，
不需要过度工程化；这个skill的预警价值大于干预价值
- 纯创意/研发类工作：当团队产出主要依赖少数人的深度思考而非协作时，
复杂度方程的意义打折——不是所有连接都能产生价值
作者在书中警告的失败模式
- 用"增加人手"解决复杂度问题：实际上增加了更多连接，
让问题更严重；正确的应对是增加"消化复杂度的机制"
- 过早引入复杂组织架构：在连接数还很低时就设立多层汇报线，
人为制造不必要的连接，增加复杂度而非管理复杂度
- 认为"我们公司不一样"：创始人总觉得自己的团队特殊，
可以绕过复杂度规律；但这个规律是数学性质的，不以行业为转移
作者的盲点 / 时代局限
- 原书对"远程工作/异步协作"对复杂度的影响没有充分讨论；
远程团队的部分连接转为异步，连接质量而非连接数量成为更关键的变量
- 方程是静态快照，没有考虑"连接强度"差异——
有些连接是高价值的深度协作，有些只是低价值的例行通知
- 对"复杂度爆炸的临界点"没有给出精确的人数阈值；
不同文化、不同流程成熟度的企业临界点差异很大
容易混淆的邻近方法论
- 彼得原理（组织层级增加导致的问题）：关注"人放在错误层级"，
不关注连接数本身
- 组织生命周期理论（Greiner）：描述的是成长阶段与危机的对应关系，
复杂度方程是这个理论中某个危机的解释机制而非完整框架
- Mckinsey 7-S：关注组织内部一致性，复杂度方程关注
人际连接数量的可量化维度，维度不同但互补
相关 skills (阶段 3 填充)
- depends-on: [growth-paradox, pac-e]
- contrasts-with: [peter-principle, greiner-lifecycle]
- composes-with: [rockefeller-habits, fac-e, cash-conversion-cycle]
审计信息
- 验证通过: V1 ✓
- 测试通过率: N/A (待测试)
- 蒸馏时间: 2026-04-26
