据谷歌三位高管后来出书时的回忆，2001 年 7 月，谷歌快满三岁，有几百名员工。工程负责人韦恩·罗辛对手下的经理不太满意：工程师是好工程师，经理当得却不怎么样。
于是他和拉里·佩奇、谢尔盖·布林想了个激进的办法：把工程部门的经理全部撤掉，所有软件工程师直接向罗辛汇报。罗辛和埃里克·施密特给这个新架构起了个名字，叫「去组织」（disorg）。
两位创始人很喜欢。他们来自大学，在那里，学生围着项目聚在一起，谁也不「被管」。公司和干活的工程师之间，凭什么要隔一个经理？
刚开始给谷歌当教练的比尔·坎贝尔不信这一套。按他的谷歌同事后来写他的那本书里的说法，一天晚上，他拉着佩奇和布林沿走廊走，随便找了个工程师，问他想不想要个经理。
想，工程师说。「我想要一个能让我学到东西的人，一个能帮我们拍板的人。」
堆在门口的问题
按那本书的说法，谷歌的工程部门没有经理，撑了一年多，2002 年快结束时把经理请了回来。《哈佛商业评论》讲的原因是：太多人直接跑去找佩奇，问的是「报销、同事矛盾，还有其他各种鸡毛蒜皮的事」。
就算单件不难，堆在一起，也会把那扇门堵住。
1933 年，一位名叫格莱库纳斯的管理顾问，想给这条队伍算个数。他指出，经理不只是要和每个人打交道，还得顾着这些人彼此之间怎么打交道，两两之间，几个人一伙之间。全算上，带四个人，要顾的关系有 44 种；加到五个人，变成 100 种。这是他的模型里可能出现的关系，不是实测出来的管理负担。可它说明了一件事：要顾的东西，比人数涨得快得多。他的结论是，除了例行工作，一个经理直接带的人不该超过五个，最好只有四个。
四个还是三十个
问题来了。谷歌后来认定，经理确实重要。它的「氧气计划」研究小组 2009 年初提出了第一批研究问题，就是想把这件事弄清楚。小组的联合负责人尼尔·帕特尔对《哈佛商业评论》说：「我们其实是在努力证明反面，证明经理不重要。还好，我们失败了。」可同一篇文章也写到，在谷歌，「一个工程经理带 30 个直接下属并不少见」。
三十个，是格莱库纳斯上限的六倍。两边都可以是对的，因为格莱库纳斯的算法，假设这些人彼此都离不开，经理得把这些关系全装在脑子里。他自己也引过英国将军伊恩·汉密尔顿的一条经验：「组员担的责任越小，组可以越大。」各自负责一摊、多数事情自己商量着解决的工程师，需要经理的，主要是教人和拍板。每件活都牵动其他所有活的团队，需要的就多得多。
美国的大多数经理，离三十个还远。盖洛普 2025 年的数据显示，平均每个经理带 12.1 人，比 2013 年第一次统计时多了将近一半。中位数却一直在五六个人。是少数特别大的团队，把平均数拉了上去。
想象一位经理，因为同事的岗位被裁，刚刚接手了另一个组。现在她手下有十四个人。日程表塞满了一对一谈话，收件箱塞满了小审批。没人问她什么难题。她只是来不及一一处理，问题就开始在她门口堆起来，就像当年堆在佩奇门口那样。
该派几个 AI
一个把活分给其他智能体的 AI，也有管理幅度的问题。它的瓶颈不是抽不出时间谈话，而是判断一件活需要几个帮手，再给每个帮手交代清楚。
Anthropic 搭研究系统时，由一个领头的智能体把问题分给子智能体。早期版本常常估错活的大小。工程师列出的错误里，有一条是「为简单的问题派出 50 个子智能体」。
于是他们把配人手的经验规则写进了提示词：「查简单的事实，只需要 1 个智能体、3 到 10 次工具调用；直接比较，可能需要 2 到 4 个子智能体，每个 10 到 15 次调用；复杂的研究，可能用 10 个以上子智能体，职责划分清楚。」
按这些经验规则，十个以上的帮手可以，但得先让每一个都清楚哪一块归自己。