本篇判断：杀死快团队的，往往不是慢，是那个看起来最公平的动作——把所有团队拉到同一个节奏上。快团队每周发的东西是周抛的，它踩着的底座是年抛的；统一节奏等于逼补给线按冲锋速度行军。
本篇解决读者的什么问题：下次把全公司拉齐发版日历之前，先盘清你的快团队欠着谁——数据底座、部署稳定性、接手人的培养、事故兜底，这四行账不在任何一条快指标里，但每空一行，快就少撑一个季度。
适用边界：本篇讲的是给快团队供货的慢工作，不是慢本身——只产出惯性、不产出耐久性的慢，同样在挨批之列。快慢分组是判断框架，不是可以照抄的模板；全部失效情形，见文末「这套盘点什么时候失效」。
全公司只剩一个钟
先说一个大多数管理者都做过的动作：把所有团队拉到同一个节奏上。
统一的迭代，统一的周报，统一的发版日历。直觉里，这叫对齐，叫公平，叫管理健康——凭什么他们两周发一版，你们一个月动不了？节奏不一致，报表没法看，汇报没法排，资源没法统筹。于是钟越调越齐。
今天我想把这个直觉拆开给你看。大多数公司的死法不是太慢，而是全公司只剩一个钟之后，那些天生快不了的活——数据底座、部署稳定性、接手人的培养——被逼着到快指标里排队。排不进去，就一轮一轮被往后放；放无可放，就悄无声息地断供。
快团队当时没感觉。路断在三季度之外。
一家反着来的公司：四年三版组织
先讲一家反着来的公司。
Airtable 的 CEO Howie Liu 在 Lenny 的访谈里复盘过他们的组织重组，他说四年里改了好几轮。这段案例账值得完整摆一遍，因为它几乎是组织设计教科书的倒叙——从最常见的那种分法开始。
**第一版：按功能分组。**最早搜索一个组，移动端一个组，各自守着自己那块产品面积。好处也实在：守着一亩三分地，那块代码谁都没他们熟。但他说的毛病更要命——每组的任务天生就是「把自己那块再改进一点」，没人抬头看整体。每个组都算称职，合起来是一家只会在原地精修的公司。
**第二版：按业务支柱分。**后来改成企业业务管规模化，要撑得起上万到两万个席位的部署；另设自助体验、AI、方案、基础设施几根柱子。分完柱子至少能整体想问题了——比如把整个上手体验当成一件事来重做，而不是每个功能各改各的。这是大多数公司羡慕的状态：有全局，有支柱，有归属。
**第三版：按节奏拆。**但整体感归整体感，他还是觉得拖，而且越往 AI 上使劲越明显——「你看 Cursor 这些公司，每周都在发大东西」，人家几条路线图拧成一股绳，一个产品在狂奔。于是最近一次重组，他把工程组织拆成两个节奏。
快的部分官方名字叫 AI Platform，目标很直白：接近每周发一批新能力，要好到用户「下巴掉下来」。
另一部分在慢节奏那边，做的是需要预谋的重注。他举的例子是自研数据底座 HyperDB：要扛几亿行数据。他说得很明白，这种东西不可能拿一个草台原型，一周之内发出来。
把这三版放在一起看，分法本身就在讲话：
| 版本 | 分组逻辑 | 得到了什么 | 代价 |
|---|---|---|---|
| 第一版 | 按功能分组 | 每块代码都有最熟它的人 | 每组只看自己那亩地，没人抬头看整体 |
| 第二版 | 按业务支柱 | 能整体想问题，上手体验当一件事重做 | 他自己还是觉得拖，追不上 AI 原生公司的发版速度 |
| 第三版 | 按节奏拆两条轨 | 快轨接近每周发一批；慢轨养 HyperDB 这种几亿行的底座 | 两条轨要分别配人、配目标、配考核（本文后面展开） |
慢轨上那个 HyperDB，值得单独停一下。它没有 demo，没有故事——这种重注要是埋在某个功能组的待办里、或某根支柱的长期投入清单里，就永远排不出自己名下的时间和人；节奏被单独拆出来，它才第一次有了这两样东西。
快团队每周发的东西是周抛的，它踩着的底座是年抛的。
两半怎么咬合：快的那半制造尝鲜，慢的那半接住种子
有意思的是他怎么描述这两半的关系。他说慢思考不是更好或更坏，是「人本来就需要快思考和慢思考」——Lenny 在旁边接了句，那本书就摆在他身后。组织拆两条轨，不是谁改造谁，是把两种本来就该并存的思考方式，各自给了一条专线。
分工其实咬得很紧：快的那半制造尝鲜，新能力带来眼球、带来新用户，大企业也来试水；慢的那半负责接住这些种子，让它们长成更大的部署。快轨发的每一批「下巴掉下来」的能力，都是撒进池子里的种子；种子能不能长成能撑上万席位的大部署，靠的是慢轨把底座一寸寸铺到那里。
他见过的许多 AI 原生公司，一大挑战都在这里：顶部流量做得很宽，进来全是「AI 游客」；有时难就难在，怎么把游客变成长期增长。游客是快轨的产出，长期增长是慢轨的产出——只有快轨的公司，等于一家只有门口热闹、没有内装的店。
Lenny 听完的原话是，他从没见过这种分法。一个管理者试了几轮组织方案，最后靠把节奏拆成两个，才追上 AI 原生公司的发版速度。
说白了，快团队不是自己跑得快，是被慢团队驮着跑；驮它的那匹马饿死了，它一步也迈不动。
大多数公司的做法，正好相反
问题是，大多数公司的做法正好反过来。
数据底座、部署稳定性、接手人的培养——这些活没有 demo，没有故事，每个迭代排优先级的时候都排不进去。它们是快团队脚下那条路，可路的维护记录，不在任何一条快指标里。发版数、迭代速度、需求吞吐，每一张快报表的统计口径里，都没有「路还结实」这一栏。
这时候管理层把全公司压进同一张发版日历，听起来还挺公平：凭什么他们两周发一版，你们一个月动不了？
可慢工作没法用慢指标自证，全公司只剩一个钟，它就只能在快指标里排队：这个季度，你们到底发了什么？
底座团队答不上来。答不上来，下一轮预算就砍你。**底座的价值是台阶状的，快指标只认坡度。**底座三年的产出曲线是平的，第四年突然抬一个台阶——所有依赖它的快团队同时快一截。可坡度报表上的那三年平线，在任何一轮降本讨论里，长得都像闲着。
统一节奏在直觉里等于公平，在账本上等于逼补给线按冲锋速度行军。前线按冲锋速度考核，补给线也按冲锋速度考核，于是补给线的每一分力气都改去修车，路没人养了。
更扎眼的是后果的落点：做决定的是离快指标最近的人，先被砍的是慢团队，最后饿死的，是踩着那条路冲锋的快团队。决策链、预算链、死亡链，三链的顺序严丝合缝——这不是哪个管理者坏，是一口钟驱动的组织里，账本天然这么算。
另一种慢工作：交接，跟人有关的那种
慢工作还有另一种样子，跟代码无关，跟人有关。
GitHub 的 Ryan Salva 在同一档访谈里讲过 Copilot 的交接：研究团队孵出来的东西，要交到产品团队手上往下走——谁接、怎么接、研究团队什么时候放手，他有完整的交代。
这一步最容易走的剧本，是研究团队功成身退，产品团队一句「接下来我们走」。交接邮件发出去，日历画上勾，两边都体面。
他们没这么干。他们的交接账，一步步是这样的：
| 交接动作 | 具体做法 | 背后的判断 |
|---|---|---|
| 调人进产品团队 | 刻意把一部分研究员调进产品团队，限定一段时间，专门做知识转移 | 懂业务的脑子不能靠文档继承，得人跟着活走 |
| 围着人配班子 | 再围着他们把接手的班子配齐 | 交接不是交文档，是让接手的队伍在真人旁边长出来 |
| 招聘也为交接服务 | 招人是为了给研究员建缓冲，好让他们将来能全身而退，回去琢磨下一个登月项目 | 编制预算按交接需要排，不按部门边界排 |
| 分批撤回 | 从产品立项算起大约一年半之后，研究员才开始分批撤回原来的研究团队 | 撤人跟着成熟度走，不跟着日历走 |
他有一条硬判据：研究员什么时候能撤，「不能按日历定，得等到接手的人已经到位、真的在干这份活、把该有的技能都补齐」。
他还补了两句，都值得抄在本子上：路线图不能外包给研究团队，离客户反馈最近、负责维护产品的那支队伍必须自己握着路线图；创新也不能整个外包出去，产品团队要自己对用例和客户负起责来。这两句合起来是说：研究团队可以借出去，责任不能借出去。
懂业务的脑子、压得住场的经验、对客户的脸熟——这三样，没有一样是发一封交接邮件能长出来的。
交接完成的标志不是日历到了，是接手的人把活真正干起来了。
两盆冷水
写到这，先泼两盆冷水，免得这篇被读歪。
第一盆：慢不天然正确。Airtable 重组之前按功能分组的那些团队，也是一种慢——那种慢只产出惯性，不产出耐久性。值得养的不是慢本身，是在给未来供货的那种慢。判断标准只有一个问题：这份慢，明年会给快团队供什么货？答不上来的慢，跟统一日历一样是组织病，只是症状相反。
第二盆：别把快慢分组当模板抄。这句话是我自己划的边界，Howie 没说过——他讲的只是他们四年里几轮重组之后的当前形态；而且整个分组故事是他在访谈里的自述，我没进他们内部核过数据。Copilot 那条交接判据也一样，是方法论主张，不是测出来的交接效果。两段案例都是当事人在同一档访谈里的复盘，拿来当组织设计的对照样本可以，拿来当实验结论不行。
补一点我自己的经验口径：我上一家公司做了六年，见过支援部门在每一轮降本里第一批被优化；今年我一个人搭自己的系统，进展最大的几步，恰恰全花在那些永远不会出现在任何 demo 里的活上。前者是组织层面的反复上演，后者是一个人的版本——规模差了几个量级，机理是同一个：快，是慢工作喂出来的。
快团队欠谁：四个空行的盘点
给你两件能直接带回团队的东西。
第一件，「快团队欠谁」盘点。别问你的团队快不快，先拉四个空行：
| 空行 | 问的是什么 | 答不出来时，快团队脚下断的是什么 |
|---|---|---|
| 数据底座谁在养？ | 底座的容量、性能、架构，有没有人名下有这段时间 | HyperDB 这类重注没人下，快轨的新能力开始撞天花板 |
| 部署稳定性谁在看？ | 线上事故的预防、监控、演练，是不是有主的事 | 快轨越跑越抖，每次发版都在赌运气 |
| 接手的人培养到哪了？ | 关键活有没有第二个人在长，长到哪一步了 | 关键人一动，活就断档——只能靠日历硬扛交接 |
| 出了事故谁兜？ | 事故的兜底、复盘、追责机制落在谁身上 | 出事就临时抓人，抓到谁谁倒霉，没人再敢接慢活 |
四个问题里有空行的团队，快不了三个月。
第二件，交接判据。轮岗可以，撤人不行——撤人的唯一条件，是接手者已经接得住：技能补齐、在岗运转。在那之前，人不能动。判据只有一句话，用的时候盯三个状态：到位、在干、补齐——三个都成立，才谈撤；缺任何一个，日历上画的那个撤人日期就是假的。
这套盘点什么时候失效
两件工具的失效边界，也照实说。
第一，真的一人公司或者纯交付小队，依赖清单大片空行照样活得好，空行不说明问题。一个人自己就是底座、就是稳定性的看护人，四个空行全空，快照跑——盘点是给有分工的组织用的。
第二，公司本来就在清盘收割，耐久性投资不划算，压快节奏反而是对的。明知这条业务两年内退场，再往底座里投年抛的重注，是把钱埋进不再收割的地里。
第三，业务要关停或者人根本招不到的时候，日历是唯一可用的止损线，别让任何交接判据挡在止损前面。交接判据说「接手者没补齐不能撤」，止损线说「这个业务下月就没了」——止损优先，判据让路。
盘点和判据都是工具，工具认得清自己管不到的地方，才配被信任。
路在，快才有意义
所有人都在教你怎么用 AI 把团队变快，一人公司做十亿美金的故事人人都爱听。
没人问一句：快团队脚下的路，是谁在铺，铺路的人吃几成口粮。这问题不性感，但它决定你的快能撑几个季度。
你下次开会拉节奏之前，先把你团队脚下的路盘一遍。
路在，快才有意义。
所有人都在教团队变快，没人问铺路的人吃几成口粮——这个追问值得再往前推一步：为什么铺路的活偏偏在每一张快报表里天然隐身？另文《小团队的人效神话，漏算了谁？》把这本度量账拆开算过，人效口径漏掉的，恰恰就是这批供货的慢工作；而交接判据在客户现场长什么样，可对照《FDE驻进客户现场以后，怎样避免永远出不来？》——驻场撤不出来，病根同样是按日历撤人，不等接手的人真的接住。