漫长的蜕变 (The Long Becoming)

作者：Alfred Lin (Sequoia Capital) | 来源：SandHill.io #283

Shopify 的 Tobi Lütke、Duolingo 的 Luis von Ahn 和 Klarna 的 Sebastian Siemiatkowski 都走过了一条熟悉的道路：一份大胆的内部备忘录成为公开的制品。接下来是头条新闻。然后，几个月后，是澄清或退缩。Klarna 暂停了招聘冻结。Duolingo 收回了“取代”的框架。Shopify 软化了语言，但并未放弃原则。

我们在公开帖子和头条新闻中看到的只是冰山一角。我们没有看到的是表面之下的挣扎。成为一个你并非生于其中的范式（Paradigm）的“原住民（Native）”意味着什么？蜕变（Becoming）比声明要难得多。

二十年来，我们一直使用“赋能（Enabled）”和“原生（Native）”来区分技术范式转变的采用者。云赋能（Cloud-enabled）意味着将现有应用程序迁移到 AWS。云原生（Cloud-native）意味着从第一行代码开始就针对云进行设计。这两条路径在早期看起来很相似，几年后就会产生巨大的分歧。

同样的鸿沟再次出现。AI 赋能（AI-enabled）公司将 AI 助手添加给现有的销售团队，并衡量节省了多少封电子邮件。AI 原生（AI-native）公司则会问：如果我们今天从零开始，我们将如何自下而上地构建每一层？

我们交谈过的最先进的 AI 创始人发现，真正的重新设计（你的产品、流程、工作流程和公司）是区分从 AI 中获取价值的公司与未获取价值的公司的最大单一因素。这是一种从第一性原理出发进行重建的意愿。对他们来说，这是一个“重构（refounding）”的时刻。

在实践中，这种蜕变看起来像什么？它通常不性感，就像解决一系列瓶颈。你解决了一个，限制速率的步骤就会转移到其他地方：

第一个瓶颈是采用（Adoption）。人们真的在使用这些工具吗？于是开始出现 Token 消耗排行榜。但它是生产性的还是仅仅是刷 Token？Chainguard 的 CEO 引入了“Token 规则”：工程经理的 Token 消耗量必须接近其直接下属的中位数。低于中位数意味着领导缺乏指导经验；远高于中位数，则需要去教导，而不是囤积杠杆。

第二个瓶颈是工程速度（Engineering velocity）。当人们有效地使用工具后，你的前 5-10% 的工程师现在的生产力是一年前的五倍。现在的任务是培训团队的其他人，让最高分位数的速度成为其他人的标准。

第三个瓶颈是产品速度和产品体验质量。工程师可以交付，但公司决定构建什么内容的速度能跟上吗？曾经需要几个季度的路线图现在只需要几周。拥有卓越品味和判断力、能产生伟大产品创意的 PM 和设计师成为了限速器。这也是大多数公司停滞不前的地方。你把工程速度放大成了一个对准错误目标的消防水管。

第四个瓶颈是建立自己的开发操作系统（Operating system for development）。AI 原生公司不断发现微小的瓶颈，移除它们，并将它们编码到他们的开发操作系统中：自定义的评估工具、工单路由代理、代码审查代理等。他们意识到大部分系统都不会持久。AI 原生组织毫无仪式感或怀旧情绪地构建、丢弃和重建，因为重建的成本很低。

第五个瓶颈是如何组织团队。用 AI 可以让更小的团队做更多事、移动更快，但这也会带来混乱。在人工智能时代，必须重新思考如何拆分组织中的工作拼图、对齐团队并将其融合。

这个漫长的蜕变过程是不舒服的，但在我们构建未来时也是令人振奋的。这些挣扎大多不会成为吸引眼球的头条新闻。而这恰恰说明了它们有多重要。