complexity-equation

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?

1. 团队从3-5人向10人以上扩张的阶段——开始感觉到协调成本上升， 但还没意识到这是结构性的
2. 创始人在"要不要招人"的问题上纠结——感觉招了人效率反而下降， 怀疑是不是招错了人，而不是系统设计问题
3. 公司出现"部门墙"或"沟通断层"——部门之间互相甩锅， 信息在传递过程中失真或消失
4. 在做组织架构设计或汇报线调整——想要理解增加一个层级 或者增设一个部门会对复杂度产生什么影响
5. 讨论"公司可不可以再快一点扩张"——需要量化理解 扩张速度与组织消化能力之间的关系

语言信号 (用户的话里出现这些就应激活)

• "我们人也不多啊，怎么感觉协调起来这么累？"
• "加了一个人之后好像更慢了，是不是招错了？"
• "部门之间好像有墙，信息传着传着就没了"
• "我一个人扛不住了，是不是该招个副总？"
• "增长太快是不是有问题？要不要放慢脚步？"
• "三个人干得挺好，加了第四个反而出问题了"

与相邻 skill 的区分

• 与 Growth Paradox（成长悖论） 的区别: 成长悖论是"为什么越大越累" 的哲学层面解释；复杂度方程是这个悖论的数学层面量化工具
• 与 PACe（流程问责表） 的区别: PACe是复杂度管理的具体落地工具， 复杂度方程是"为什么要用PACe"的原因解释
• 与 Rockefeller Habits 的区别: Rockefeller Habits是复杂度管理的 一套具体习惯清单；复杂度方程是这些习惯存在的理论依据

---

E — 可执行步骤 (Execution)

当 skill 被激活后，agent 应按以下步骤执行:

1. 【量化现状】计算当前团队的连接数

   • 公式：连接数 = n(n-1)/2（n=总人数）
   • 问用户："你现在团队有多少人？" → 计算并展示连接数
   • 完成标准: 用户看到连接数，理解"为什么现在协调成本这么高"

2. 【预测未来】模拟扩张后的复杂度增长

   • 问："如果你计划扩张到X人，连接数会变成多少？"
   • 计算并对比：现在是多少，扩张后是多少，增长百分比
   • 判停条件: 若用户说"现在还早"，则聚焦当前规模，不需要预测

3. 【制定对策】引入复杂度消化机制

   • 每个连接本质上需要三类机制之一来消化： ① 流程（标准化，减少临时沟通需求） ② 节奏（固定会议/周报，让信息定期流通） ③ 规则（明确谁决策什么，减少关系协调）
   • 根据用户当前痛点，选择优先级最高的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