注意力天花板

上一篇文章 认为，人类正在走向软件开发过程的末端——基础和审查——而人工智能则处于中间位置。这篇文章是关于当您向团队添加人员时这意味着什么。

长期以来，初创公司的招聘建议有两个方向。 Canonical 创始人的文章普遍认为招聘缓慢：Sam Altman 的 YC Startup Playbook 在其招聘部分开头写道“我关于招聘的第一条建议是不要这样做”，而且大多数 YC 合作伙伴十年来都说过同样的话。与此同时，运营扩展内容——投资者平台、扩展顾问、“如何扩展你的初创公司”文章——提出了相反的建议：提前招聘，根据你要去的地方建立团队，因为招聘需要几个月的时间，而且人员不足的复合速度比人员过剩的速度更快。大多数创始人都会内化这两种立场的某种组合，这种组合因经验和他们最近阅读的内容而异。

注意力一直是招聘考量的一部分——当你的工作分散得太分散时，你就会聘用他人。但这对于执行积压来说是次要的：主要触发因素是工作堆积，而不是判断力下降。注意力上限并不是慢速与快速争论的新话题。这是一个双方都没有询问的不同轴，它从背景因素转变为主要触发因素。

现有的争论是关于相对于需求“多快”增加人员。缓慢招聘的建议是等待更长的时间；领先的建议是行动得更快。两者都认为招聘从根本上来说是对执行需求的回应——问题只是时间问题。这一假设在人工智能出现之前的均衡中是正确的。现在是不正确的。

这个假设是正确的，因为执行成本很高。当您构建的工件需要 PM 编写规范、设计师将其转化为设计、工程师将其转化为代码时，执行层就是其他所有内容的速率限制器。如果您有一名工程师并且他们是瓶颈，那么雇用第二名工程师大约会使吞吐量增加一倍。如果你有一名设计师，而他们是瓶颈，那么雇用第二名设计师可以使设计能力大约翻倍。招聘的经济性由执行的经济性决定，而执行力大致与员工人数成比例，因为每一位额外的专家都可以从积压的工作中承担独立的工作。

扩展实际上从来都不是线性的——在后期的项目中添加工程师可以使其更晚。但每个额外的专家仍然可以承担独立的执行工作，因此协调开销是对收益的征税，而不是消除收益。

缓慢招聘和超前建议都在管理这项税收。慢招聘说“等待更长时间，因为开销比你想象的要大”。领先者表示“行动得更快，因为入职税低于人员不足的成本。”两人都在争论同一个根本问题：边际执行雇佣什么时候才值得其协调成本。

---

当触发器改变时

当执行力转向人工智能时，根本问题就会发生变化。员工数量和吞吐量之间的线性关系被打破，但协调税框架也被打破——因为大部分税收是专门为了协调人类的执行工作而存在的，而执行工作不再由人类来完成。

添加第二个工程师不会再使输出加倍，因为您已经拥有的单个工程师不会在执行方面遇到瓶颈 - 他们在执行的人力输入方面遇到瓶颈。基础输入、架构判断、对人工智能生成内容的审查、关于下一步构建内容的战略要求。

第二位工程师不会像以前并行实施工作那样并行化这些输入。相反，它们引入了协调成本、上下文共享成本，以及需要让两个人根据一个人单方面做出的正确判断来协调一致。对于第二位设计师、第二位产品经理、任何事情的第二位来说也是如此。

基础和审查受益于单个头部的上下文集成，而不是跨多个头部的划分。

这改变了招聘触发因素的实际情况。不再是“我们现在的团队有太多的执行工作”。它是：

当前团队的注意力预算已经耗尽在人工智能的人力投入和对其输出的审查上。

注意力上限是一个真实而具体的东西。在这个时刻，驾驶产品或功能的单个人不再能够充分关注他们所承载的三个负载：

1. 足够仔细地编写基础工件，以便人工智能可以很好地执行它们。
2. 以足够的密度审查人工智能的输出，确保质量不会下降。
3. 做出战略判断，决定下一步要做什么。

当这三者中的任何一个开始被忽视时，你就到了天花板。这种忽视在吞吐量下降之前就出现了，这就是团队经常错过它的原因。

---

天花板是什么样子的

这三种负载在不同团队或不同时间之间并不稳定。审查负担尤其取决于其中有多少是“人工智能声明的验证”以及有多少是“人工智能未解释的内容的重新推导”。仍在调整对其人工智能工具的信任的团队需要支付更高的税。相信代理的结构化声明（即给定的不变量已被检查）的审阅者会阅读简短的摘要并继续前进；不从头开始重新检查不变量的审阅者。在验证仍在重新推导的团队中，注意力上限会更快到达——通常要早得多，这是大多数处于过渡早期的团队，以及所有处于表面上的团队，无论错过的跳过的成本如何，都需要重新推导。这不是推迟聘用的理由。这是认识到上限的到达时间取决于信任基础设施和原始吞吐量的一个原因，并且在上限迫使雇用之前投资于使验证便宜的基础设施。

实际上，它看起来像这样：仔细审查每个人工智能输出的创始人开始浏览。正在进行深入用户研究的产品经理开始重复使用旧的采访记录。正在完善架构标准的工程师开始让漂移累积，因为正确编写约束文档需要花费一周的时间，而他们没有这样的时间。这些都不会立即导致失败。工件仍然在生产，功能仍然在发布，用户仍然在使用它们。但工作的复合质量开始下降，并且这种下降在产品中变得清晰之前几个月是看不见的。

这就是触发器。不是当你跟不上执行的时候，因为执行是被处理的。当收入表明你可以负担得起雇用费用时，情况就不是这样了，因为负担能力从来都不是雇用是否有帮助的约束性约束。当人类对人工智能输入和输出的注意力超出了一个人可以维持的质量时，就会触发这一事件。

注意力上限重新定义了现有辩论的双方。只要注意力预算允许，就保持独立，因为在注意力上限之前的每一次招聘都是没有杠杆作用的摩擦——而且缓慢招聘和超前建议都没有跟踪时机信号。

---

反对意见

对于那些已经内化了现有辩论双方的人来说，这听起来是错误的，因为双方都没有提出这个答案所回应的问题。

但是积压呢？ 不存在旧意义上的积压。积压工作曾经是等待专家执行工作的队列。现在的限制不是执行，而是执行。这是对什么值得执行的判断。积压的“创始人尚未决定是否构建的东西”并不是招聘信号，而是优先级信号。第二个人无法解决优先级问题；他们添加了另一种需要协调的观点。

但是专业化又如何呢？ 专业化在规模上很重要，我将在下一篇文章中指出，最终的专业化深化是团队成长时所采取的形式。但是，专业化论点是在超过上限后雇用特定人员的理由，而不是提前雇用的理由。一个使用人工智能操作的多面手创始人可以覆盖一个小产品的完整执行面。他们无法掩盖的是他们自己的大规模关注。雇用员工是为了扩展注意力，而不是覆盖表面区域——人工智能覆盖了表面区域。

但是韧性怎么样？总线系数？ 这是一个真正令人担忧的问题，诚实的答案是，在人工智能出现之前的均衡中，拥有人工智能的独立创始人的总线系数比三人团队的总线系数更差，而比三人团队的总线系数更好。原因是人工智能运行所需的工件——规则、标准、基础文档——本身就是持久的组织知识，而三个人之间的部落理解则不然。巴士因素问题确实存在，但它不会自动解决更大的团队。

但是增长呢？和更多的人在一起我不会成长得更快吗？ 在这条建议适用的阶段，可能不会。早期成长是通过发现值得成长的事物来控制的。这个发现是一个判断问题，而不是一个执行问题，而且判断不能很好地并行。一旦你发现了这一点——一旦产品与市场的契合度得到实际验证，而不仅仅是希望——增长就变得部分可执行，那时注意力上限就开始受到限制，因为满足不断增长的需求所需的人工智能输入量实际上超出了一个人可以编写的量。这就是雇佣信号。以前没有。

---

这在实践中意味着什么

对于早期创始人来说，这意味着：相对于你的实际影响力而言，你的员工可能过多。您六个月前雇用的第二位工程师产生的边际价值可能比您想象的要少，因为他们本应加速的执行层不再需要加速。你要雇用的产品经理可能会比判断能力更快地增加协调成本。你因没有雇用而感到内疚的设计师可能不会真正解锁任何东西，直到你的注意力已经扩展到太多的表面而无法覆盖。

同样的现实在团队内部的解读却有所不同。如果执行层正在缩小，一些主要由执行定义的角色需要围绕基础和审查重新定义，而这种重新定义是真正的工作，而不是令人愉快的重新标签。工程经理的报告询问他们是否应该成为产品经理，他们也在同样的内部转型中进行操作。重新定义要求专家将其身份的权重从执行技巧转移到判断技巧，这是大多数人尚不具备的词汇。

---

表面膨胀陷阱

使迁移令人困惑的一件事是人工智能扩大了任何特定人可以覆盖的范围。过去需要产品经理来定义问题的工程师现在可以在架构工作的同时进行客户发现。过去需要工程师来验证可行性的产品经理现在可以构建工作原型。

这种扩张是真实且有价值的。但扩展在于“人”可以做什么，而不是任何单个“角色”需要什么。综合产品判断和架构系统推理仍然是具有不同质量标准的不同学科，即使一个人同时实践这两种学科。

风险在于，组织看到人员规模扩大后，得出结论，学科已经合并，然后停止发展任一学科的深度。我写过PM 世界中的一个版本，其中该学科中最有影响力的声音定义了原型设计的角色，因为原型设计成为商品化活动。当注意力达到上限并且团队需要专家时，复合成本就会出现，而他们的判断力从未得到培养，因为这个角色从未被视为自己的事情。

第 4 部分 对使重新定义对组织持久的基础设施有话要说； 第 5 部分 对重新定义发生得更慢的表面有话要说。这两篇文章都不能让个人体验变得轻松。两者都认为这种体验是团队必须驾驭的真实事物，而不是一种转瞬即逝的情绪。

下一篇文章是关于超越注意力上限的团队实际上是什么样的——当专家确实进来时，问题就变成了他们如何一起工作，而不重新引入倒置应该消除的协调开销。