2016 年，Spotify 正在拼命招人，可按公司自己的说法，新来的人反而在拖慢整个公司。公司盯着一个数字：一个新工程师要多少天，才能让自己的第十个合并请求（也就是第十段代码）被合并进去。答案是 60 多天。那年刚加入的工程总监皮娅·尼尔松后来说，看到这个数字，「就像被泼了一盆冷水」。
Spotify 那些小而自主的团队，需要什么就自己做什么。按公司的说法，同一个服务可能有 15 个版本；新人想知道怎么做事，只能拍拍同事的肩膀去问。最省事的办法是集中管起来。尼尔松的团队否掉了：「没人会用。」其余经过见案例。
四种团队
多数团队从头到尾管一条工作流，少数团队帮它们跑得更快。
这是《团队拓扑》的核心。这本书 2019 年出版，作者是马修·斯凯尔顿和曼努埃尔·派斯。书里把团队分成四种：
- 流对齐团队「对齐一条工作流」，通常是业务的一块，从头到尾自己负责。这本书的网站说，这类团队「不为任何目的把活交接给别的团队」。
- 平台团队提供「一个有吸引力的内部产品，来加快流对齐团队的交付」。
- 赋能团队「帮流对齐团队克服障碍」，教会对方缺的技能，然后离开。
- 复杂子系统团队负责「需要大量数学、计算或技术专长」的那一块，免得其他团队人人都得去啃它。
网站说得很坚决，四种就够了：「再加类型或者搞混合体，只会让所有人糊涂。」软件开发者、作家马丁·福勒在介绍这本书时，把流对齐团队称为这个框架里「最主要的一种团队」。
另外三种是干什么的
福勒指出，把业务团队和技术支持团队分开，这种做法「和企业软件一样老」。他觉得新的是背后的理由：一个团队要负责一整条流，自己建、自己运维，要知道的东西就可能多到把人淹没。按福勒的概括，「平台的首要好处，是减轻流对齐团队的认知负荷」。另外两种也一样：赋能团队帮别的团队长本事，好让它们继续独立；复杂子系统团队把一块硬骨头从它们身上接过去。（认知负荷那一页讲的就是这个上限本身。）
这一点改变了平台该怎么做。如果目的是减轻负担，用的人就得愿意用。Spotify 的平台团队把公司里的开发者当成「客户」，先去问他们是什么在挡路：总被打断，东西找不到。于是团队做了 Backstage，一个能查到每个服务、看到归谁管、读到怎么用的地方，同时让各团队继续拥有自己的那部分。Spotify 说，合并第十个改动的时间后来降到了 20 天。这是公司自己的数字，而且同样这些年里，它在新人上手的其他环节也做了改动。
Spotify 并没有用《团队拓扑》的这些叫法。它那些自主团队看起来像流对齐团队，平台团队干的也是平台团队的活，但这种对应是我们的解读。
设想一个有六家门店的咖啡连锁，每个店长都得自己订货、排班、修咖啡机。总部要是有个小团队，统一谈供应商、维护一份维修联系人名单，就像一个平台。可如果店长每订一次货都得提申请、等上好几天，他们也许又会回头自己干。
给智能体分工
用智能体搭系统，也会碰上专门的活该放在哪儿的问题。Claude Code 的子智能体是「处理特定类型任务的专门 AI 助手」。每个子智能体「在自己的上下文窗口里」运行，只「交回摘要」，这样它读过的搜索结果、日志和文件内容，就不会淹没主对话。这很接近复杂子系统团队的角色：细节由专家扛着，依赖它的那一方拿到的是干净的结果。
这种对应并不严丝合缝。子智能体通常是某个智能体临时叫来的帮手，《团队拓扑》讲的却是长期存在的人类团队。但那个问题照样搬得过来：哪些活该由一个团队，或者一个智能体，从头到尾自己扛，哪些活该由别人替它扛？
按 Spotify 的说法，它的平台团队没法命令任何人用自己做的东西。Backstage 得是更好的选择，而不能只是唯一的选择。