中层技术经理要么重新学技术，要么考虑退休：前 Stripe 工程高管警告，未来三年工程管理将彻底变样

曾在 Stripe、Uber 担任工程管理职务，后来出任 Carta、Calm CTO 的 Will Larson，最近给同行们提出了一个相当不客气的建议：要么退休，要么重新学习技能。 他甚至预测，未来三年，我们今天所熟悉的工程管理职业可能不复存在。

更有意思的是，Larson 已经用自己的职业选择践行了这一判断。他曾在 Carta 管理约 250 人的工程组织，后来却主动选择加入规模更小的 Imprint，负责约 25 人的技术团队。从管理数百人到管理几十人，在传统技术高管的职业晋升路径上，这看起来像是一次倒退。

在最新一期 The Pragmatic Engineer 播客中，Larson 结合自己在硅谷多家科技公司的经历，重新审视了工程经理、资深工程师和 CTO 的职责，并提出了一个颇具冲击力的问题：那些曾经帮助工程经理晋升的能力，为什么今天反而可能成为他们的职业负担？ AI 编程的兴起，正在让这场变化进一步加速。

A：要么重新深入技术一线，要么考虑退休。未来三年，传统工程管理的那套能力可能不再被市场需要。

Q：为什么过去被认为是职业陷阱的 TLM（Tech Lead Manager，技术负责人兼经理），现在反而成了抢手人才？

A：企业需要既懂管理、又能亲自写代码的人。最理想的工程经理，是有能力处理复杂管理事务，却更愿意把时间花在软件开发上的人。

Q：AI 都开始写代码、做 Code Review 了，软件工程师还剩下什么价值？

A：软件实现的成本正在快速下降，但理解业务、判断该做什么、处理复杂约束并验证结果，依然需要工程师。

A：更多人意味着更多沟通和协调成本。真正高效的团队需要长期稳定、清晰的责任边界，而不是遇到问题就不断往里面塞人。

A：两者都必须是。既要懂技术、产品和软件交付，也要懂组织运作、激励机制和管理流程。只擅长其中一方面，都很难成为优秀的高管。

Q：为什么 AI 能迅速复制 Slack 的界面，却很难复制 Slack 的产品能力？

A：真正难以复制的是长期积累的领域知识、产品决策和团队协作经验。而要让这些积累转化为新产品，还需要有人敢于打破规则、推动不受欢迎的决策。

A：我花了近 20 年建立自己的写作声誉，为什么要用 AI 垃圾内容毁掉它？如果没有值得表达的观点，我宁愿不写。一两篇真正有影响力的文章，远比几百篇没人看的内容更有价值。

Will Larson： 我大概五岁时，家里就有一台早期的 Macintosh 电脑。那时候我最喜欢用一个叫 Kid Pix 的儿童绘图程序，可以画正方形、圆形和各种简单图案。

当时几乎没有互联网，遇到问题也没什么地方可以查，只能自己不断尝试，直到弄明白怎么操作。某种程度上，这和后来写软件的过程很像：不断动手尝试，直到找到解决办法。

不过，我小时候其实没有真正写过多少程序。到了高中，我开始接触 IRC（互联网中继聊天）和 MUD（多人文字冒险游戏）。这些工具支持触发器、正则表达式和简单脚本，我就是在那个时候学会使用正则表达式的。但真正开始编写软件，已经是上大学之后了。

Gergely Orosz：你在大学里为什么选择计算机科学？当时就打算成为职业程序员吗？

Will Larson： 刚进大学时，我其实不知道自己想学什么。物理、英语、经济学都考虑过。我父亲是经济学教授，所以经济学也算是一个很自然的选择。

我就读的是肯塔基州一所规模很小的私立大学。学校要求学生修读一些通识课程，其中包括计算机科学导论。我上完之后发现自己很喜欢，于是逐渐转向计算机科学。

我们学校的计算机科学专业非常小。我毕业那年，整个专业可能只有 13 名学生，而同届毕业生只有 4 人。

这和滑铁卢大学、MIT、斯坦福这样的学校很不一样。在那些学校，学生通常有非常明确的软件工程职业路径。比如滑铁卢大学有成熟的 Co-op（带薪实习）体系，学生之间还会交流面试经验、练习面试题。只要能够顺利完成学业，往往就有一条相对清晰的道路进入科技行业。但在我们学校，根本没有这样的路径。

我记得上一届有个非常优秀的毕业生，最后去了肯塔基州列克星敦一家开发赛马博彩软件的公司，那里可能只有不到五名工程师。这已经是他当时能够找到的不错的机会。所以，我毕业时也不知道自己究竟会去哪里。

Will Larson： 我 2007 年大学毕业，之后参加了日本的 JET 项目，在岐阜县一个非常偏远的地方教了一年英语。

那段经历让我更加确定，自己不会长期当英语老师。我的合同只有一年，我也完全没打算续约。于是，我开始大量写技术文章，尝试寻找进入软件行业的机会。

2009 年初左右，我开始为 Yahoo 工作。有意思的是，最初我并没有直接进入硅谷，而是在美国东海岸远程担任 Yahoo 的合同工。这份工作实际上是我写博客写出来的。

当时 Yahoo 推出了一个叫 Yahoo BOSS（Build Your Own Search Service）的产品，允许开发者基于 Yahoo 的搜索能力构建自己的服务。我围绕它写了三四篇技术教程，包括如何使用 Python、Django 集成 Yahoo BOSS，还做了一个相关的 Django 搜索库。

那个产品当时似乎没有获得太多开发者关注，所以 Yahoo 团队看到有人主动写教程，就对我产生了兴趣。最终，这些文章帮我获得了一份合同工作。

当时正值金融危机之后，Yahoo 一直在裁员，基本冻结了正式员工招聘，但还能雇用少量合同工。我就是在这样的背景下加入公司的。按照当时的规定，合同工工作满一年后，要么转为正式员工，要么结束雇佣关系。后来，我也因此获得了转正的机会。

Gergely Orosz：2009 年左右的 Yahoo 已经开始被 Google 超越，但它仍然是一家很有技术实力的公司。你在那里经历了什么？

Will Larson： 我一直觉得 Yahoo 是一家非常有意思的公司。如果你在 2007 年、2008 年进入软件行业，会发现很多开源软件已经让开发工作变得相对容易。但 Yahoo 成立得更早，早在这些开源基础设施成熟之前，就需要解决大规模互联网服务的各种问题。所以，Yahoo 内部几乎所有东西都是自己造的。

比如，运行 Web 服务器用的是 YApache，也就是 Yahoo 自己维护的 Apache 分支。编程语言有 YPHP，是他们自己的 PHP 分支。前端有 YUI（Yahoo User Interface Library）。甚至软件安装和依赖管理也有一套内部工具，叫 Yinst。它是用 Perl 编写的脚本，用来处理软件安装过程中的依赖关系，有点类似 Ubuntu 上的 APT。他们还有一套类似后来 Kafka 的系统，我记得可能叫 YREPL。它通过日志复制来管理状态，不完全依赖数据库本身的复制机制。

对一个刚进入行业的工程师来说，这是一段非常特别的经历。你会发现，这家公司为了支撑自己的业务，几乎从头构建了整套技术基础设施。

我还记得一个特别有意思的故事。Yahoo 联合创始人 David Filo 当时会亲自审批公司分配的每一台服务器。这套制度最初的目的是强化责任意识。如果你想申请更多服务器，就必须证明自己确实需要这些资源。但实际结果却是，公司内部出现了一个服务器“黑市”。

我们团队有位工程师，手里掌握着大约 30 台服务器，都是之前一个被取消的项目留下来的。他一直没有把这些服务器归还公司。如果你的项目申请不到新服务器，就可以去找他借。当然，这不是正常的资源分配，而是靠人情、交换帮忙或者欠个人情来完成。某种程度上，他就像在私下出租这些服务器。

结果，Yahoo 内部积累了大量老旧服务器。这些机器的能耗效率很低，但大家都不愿意归还，因为一旦交出去，下次需要资源时可能就申请不到了。为了让自己的项目顺利上线，你必须先找到一个愿意借服务器给你的人。

这让我觉得非常有意思。一项原本为了提高资源使用效率的管理制度，最后竟然制造了完全相反的激励，让所有人都倾向于囤积资源。

Will Larson： 没错，这件事给了我很深的启发。我有时也很好奇，David Filo 是否知道公司内部真的存在这样一个服务器黑市。我猜他可能知道，但即便如此，这项自上而下的管理规定也没有改变。

Gergely Orosz：离开 Yahoo 后，你去了 Digg。当时它还是一家非常知名的互联网公司，你为什么决定加入？

Will Larson： 当年的 Digg 是一个非常重要的网站，一度跻身全球访问量前十。它最初依靠人工筛选内容，决定哪些文章能够登上首页，后来逐渐发展成一个动态的内容社区。

这种模式有自己的问题。因为首页流量非常有价值，一些用户会通过 IRC 频道交换利益，想办法让特定内容登上首页。甚至有人以此为生，靠出售首页曝光机会赚钱。

后来我们在 Digg v4 中修改了推荐算法，切断了这类操作空间。结果，有人威胁要杀了我，因为新算法毁掉了他们的生计。这不是夸张，他们真的发出了人身威胁。

不过，Digg 当时面临的最大问题并不是社区内部的利益纠葛，而是整个互联网的流量分配方式正在发生变化。

Gergely Orosz：我记得 Digg 当时非常受欢迎，但后来进行了一次大规模重写，也就是 Digg v4，结果引发了灾难。从外部看，这似乎是一家发展不错的公司突然把自己搞垮了。内部究竟发生了什么？

Will Larson： 我是在 Digg v4 上线前三到六个月加入公司的。入职前的那个星期五，CEO 刚刚被撤换，创始人 Kevin Rose 重新回来担任 CEO。公司随后给 v4 的发布设定了一个非常紧迫的期限。

当时 Facebook 正在崛起，Digg 的用户流量开始受到冲击。与此同时，Google 搜索算法的调整也在改变流量分配方式。Digg 大约 60%—70% 的流量来自搜索引擎，主要进入网站的永久链接页面。这些页面收录了用户分享的文章、原始链接和相关评论，有时在 Google 搜索结果中的排名甚至高于原始内容。

我记得公司曾经有过一个月的盈利，但随后搜索算法发生变化，流量开始持续下滑。我们很清楚，如果不采取行动，公司可能很快就无法继续经营。

当时 Digg 大约有 110—120 名员工。放在今天，这不算什么特别大的规模，但在 2010 年，创业公司一轮融资可能只有 100 万到 300 万美元，养活一百多人已经是很大的开支。我们的现金正在迅速耗尽。所以，公司决定进行一次彻底重写，试图扭转局面。

Gergely Orosz：那次上线到底出了什么问题？是技术没准备好，还是社区用户无法接受变化？

Digg v3.5 主要使用 PHP 和分片 MySQL，虽然架构比较复杂，但至少能够正常工作。到了 v4，我们做了一个非常激进的决定：用 Cassandra 替换原来的分片 MySQL 系统。

当时业内甚至有个玩笑，说 Cassandra 是 Facebook 放出来摧毁竞争对手的“特洛伊木马”，因为谁用了 Cassandra，谁就可能陷入麻烦。对 Digg 来说，这个玩笑几乎成了现实。

上线前两天，我和另一名工程师 Rich 突然被叫过去。原本负责 Cassandra 压力测试的团队根本没有完成测试，现在要求我们两个人在两天内把它做完。我们只能临时安装 JMeter，边学怎么使用，边尝试进行压力测试。

测试过程中，我发现 Cassandra 的读写存在严重问题。我去找负责 Cassandra 项目的 Chris，告诉他系统无法正常读取数据。他说这不可能。我又说写入也有问题，他还是说不可能。最后我只能把问题说得更明确：如果正在写入 Cassandra，我就无法读取；如果正在读取，我就无法写入。这一次，他承认了。可问题是，我们还有两天就要上线了。最终，这个问题没有解决，系统还是按计划发布了。

Gergely Orosz：明知道系统有这么严重的问题，还是上线了？当天是什么情况？

Will Larson： 那可能是我整个职业生涯中最不可思议的一天。公司决定为 Digg v4 举办一场盛大的上线派对。办公室里到处都是穿着礼服的餐饮服务人员，端着寿司和香槟。大家准备庆祝新版本发布。与此同时，工程师们坐在办公室中央的一张大桌子旁，拼命尝试让系统运行起来。

更糟糕的是，我们没有足够的硬件同时运行新旧两套系统。当时 Digg 使用的是自己购买、部署在托管机房里的服务器，无法像今天使用云服务一样随时扩容。为了部署新系统，我们必须一台接一台地清空旧服务器，重新安装软件。这意味着我们根本没有回滚的条件。

结果，新系统根本没能正常启动。网站大约有 24 小时只能显示维护页面。而在办公室里，香槟还在端来端去，楼上有人在接受按摩，还有人在打乒乓球。工程师们却在拼命抢救一个正在崩溃的网站。整个场景荒诞得像魔幻现实主义。

Gergely Orosz：这确实不是一般人能想象到的上线场景。后来你们是怎么把网站救回来的？

Will Larson： 我们最终让网站勉强运行起来了，但问题远没有结束。随着故障持续，越来越多的人不再参与抢修。最后大概只剩下六个人，继续努力维持网站运行。

最初两天，我和 Rich 从零开始，在 Redis 之上写了一套缓存系统。它让网站至少能够连续运行几个小时。但系统仍然存在严重的内存泄漏。为了维持服务，我们不得不每隔一两个小时就滚动重启所有进程。我花了大约四周时间，才最终找到核心问题。

当时我们开发了一套供第三方调用的 API 服务，使用 Python 编写。负责开发的工程师对 Python 并不十分熟悉。这套服务还会调用另一个 Python 服务，再访问 Cassandra。问题出在 Python 函数的默认参数上。如果把一个可变对象，比如列表，设置为函数的默认参数，那么这个对象可能在多次函数调用之间被重复使用。

我们的代码恰好犯了这个错误。每次 API 接收到用户 ID，就会把它追加到默认列表里，但这个列表不会随着函数调用结束而清空。结果，随着请求不断增加，列表里积累的用户 ID 越来越多。原本只应该返回本次请求对应的用户对象，最后却会把此前请求过的用户对象也带出来。

这不仅造成内存持续增长，还让中间的缓存服务不断崩溃，最终进一步拖垮 Cassandra。这个问题花了我大约四周才定位出来，但找到之后，修复本身非常简单。

Gergely Orosz：所以你们最终修好了系统，但 Digg 还是没能挽回局面？

Will Larson： 是的。从技术角度看，我们最终成功了，系统恢复了运行，我对此仍然感到自豪。但对于一个以网站访问和用户社区为核心的公司来说，主要服务连续一个月都难以正常使用，造成的损失已经无法挽回。后来，新 CEO 上任，接下来一年里，公司基本完成了裁员。

不过，回头看，我也不能确定当时彻底重写就是一个错误决定。如果我们什么都不做，继续运行旧网站，Digg 可能同样会倒下。公司原本就面临严重的流量下滑和资金压力。所以，我不知道还有没有更好的选择。只是当时经历这一切，确实让我非常沮丧。

Gergely Orosz：经历 Digg 之后，你是怎么走上工程管理道路的？我们后来都在 Uber 工作过，虽然没有直接共事。

离开时，我开始认真考虑如何进入更高级别的工程管理岗位。当时我大概管理着一支 12 人的工程团队，但想应聘大型公司的高级管理岗位时，就遇到了一个很现实的问题：没有管理过大规模团队，就很难获得管理大规模团队的机会。

如果去一家只有五名工程师的小型创业公司，即使成为工程负责人，也很难积累大型组织所需要的管理经验。所以我当时的想法是，如果想管理更大的团队，就必须加入一家正在高速增长的公司。我开始寻找这样的机会，最后注意到了 Uber。那是 2014 年初，Uber 的高速增长才刚刚开始。

Gergely Orosz：2014 年的 Uber 还处于发展早期，当时只有身在旧金山的人才知道它增长得有多快。你是怎么发现这个机会的？

Will Larson： 没错。2014 年，如果你不在旧金山，可能根本不知道 Uber 发展得有多好。直到 2015 年，相关消息才开始广泛传播，2016 年它已经成为全球关注的公司。

我之所以注意到 Uber，是因为之前在 Digg 共事的一名基础设施工程师 Jeremy Grosser 加入了那里。

这里还有一段有意思的技术传承。Digg 当年开发过不少内部工具，其中一个叫 Clusto，用来管理基础设施的状态信息，本质上有点像键值存储系统。它的功能与后来 HashiCorp 的 Consul 有些相似，但出现得早得多，大概在 2008 年或 2009 年。

据我所知，真正使用过 Clusto 的公司可能只有 Digg、Uber 和 Second Life 背后的公司等极少数几家。Jeremy 是 Uber 最早的一批基础设施工程师之一，他把 Digg 的不少技术栈也带了过去。当时他的团队正在招聘，我就这样发现了机会。

Gergely Orosz：你之前主要做什么技术工作？加入 Uber 后又负责什么？

Will Larson： 我一直是个比较典型的全栈通才型工程师。最初在 Yahoo，我被招聘去做前端开发，但坦白说，我也不确定自己当时是否真的具备足够的前端能力。后来在 Digg，我既做前端，也做 Cassandra、后端开发，基本上什么都干。

Uber 招聘我去管理一个 SRE 团队。但严格来说，那并不是真正意义上的 SRE 团队，只是一个被称作 SRE 的基础设施团队。有意思的是，接下这份工作时，我对 SRE 其实也没有特别系统的认识。入职前一周，我还在临时读相关书籍，想弄清楚这个岗位究竟应该做什么。我记得当时可能读的是一本 DevOps 相关的书，也可能是《凤凰项目》（The Phoenix Project），具体已经记不清了。

Will Larson： 我刚加入 Uber 时，公司大约有 2000 名员工，其中工程师约 200 人。我负责的团队只有大约 6 个人，但职责范围非常广。数据库、Kafka、服务器运行管理、服务部署与资源配置，几乎所有基础设施都归我们负责。

当然，也有一些例外。比如，公司有一支两人的开发者体验团队，还有专门的技术运维团队，负责服务器上架和物理安装。但服务器部署完成之后，后续的管理基本就是我们的工作了。所以，虽然只有六个人，我们却要支撑整个 Uber 的基础设施。这是一段非常特别的经历。

Gergely Orosz：从 Uber 到后来的 Stripe、Carta，你的管理职责是怎么一步步扩大的？在 Uber 的团队最终发展到了什么规模？

Will Larson： 我刚加入时，团队大约只有五六个人。两年后我离开 Uber 时，这个团队已经扩大到了 70 人，而且这些增长全部来自外部招聘。

当时 Uber 最惊人的地方，就是工程师人数大约每六个月翻一番。在这种增长速度下，你根本没办法简单地从其他团队调人。因为所有团队都在快速扩张，大家都缺人，工作负荷也都非常重。所以，我们只能不断从外部招聘新工程师。

我真正学会如何招聘，就是在 Uber 的这段经历中。加入 Uber 之前，我其实完全不知道该怎么招聘。但 Uber 当时招人的速度实在太快了，我只能在实践中不断学习。

我记得有个从 Eventbrite 过来的工程师，我们下午四点给他发了 Offer，他下周一早上八点就来上班了。后来我管理了他大约一年半。还有一个更离谱的故事。有个人已经参加过四次 Uber 面试，而且四次都被拒绝了。后来我竟然又看到他来参加第五次面试。我当时就说，不能再这样浪费人家的时间了，已经面试过四次了。

没想到，第五次面试的团队真的给了他 Offer。他接受了，也正式入职了。但他只工作了六个小时就辞职了，因为他同时拿到了 Twitter 的 Offer，而 Twitter 的办公室就在附近，可能只隔了一个街区。所以，这个人花在 Uber 面试上的时间，竟然比他正式在 Uber 工作的时间还长。

类似的故事还有很多。那两年里，我们的团队从六个人扩张到七十人，负责的业务范围也不断扩大。整个公司都处于一种近乎疯狂的增长状态。

我记得当时每到周五，我们都要手动调整服务器上的软件部署，努力确保系统能够撑过晚高峰。因为周五下班时间通常是 Uber 一周中最繁忙的时段。周六的总订单量可能更高，但分布在更长的时间里，而周五大量用户会集中在下班时段叫车。

Gergely Orosz：后来你去了 Stripe，并在那里工作了大约四年。为什么又决定离开，去担任 CTO？

Will Larson： 我在 Stripe 工作了大约四年，从 2016 年到 2020 年初。我加入时，公司大约有 500 名员工。离开时，已经增长到 1500—2000 人左右。在我任职期间，Stripe 的员工规模每年大约增长 70%。这个速度已经相当快了，但比起 Uber 每六个月翻一番的增长速度，还是温和得多。当然，Uber 后来收缩得也远比 Stripe 激进，这某种程度上也是超高速扩张的自然结果。

一方面，我担心自己的大部分积蓄都集中在同一家尚未上市的公司上。我当时甚至觉得 Stripe 可能永远不会上市，而至少到现在，这个判断还没有被推翻。所以，离开也有分散个人财务风险的考虑。另一方面，我真的很想知道，完整地领导一家公司的工程组织究竟是什么感觉。

在 Stripe，我已经非常接近公司的最高管理层。第一年我向 Jeff Winter 汇报，后来一直向 David Singleton 汇报，直到 2020 年初离职。David 最初加入 Stripe 时担任工程负责人，之后升任 CTO。也就是说，我距离 CTO 的位置只有一步之遥。

但我一直在想：如果真正坐到那个位置上，我能不能把某些事情做得更好？我觉得自己应该去尝试一下。后来事实证明，这确实是一段很有教育意义的经历。

Will Larson： 是的。我先在 Calm 担任了大约三年半 CTO，之后在 Carta 工作了两年，再后来加入了 Imprint。到现在，我在 Imprint 已经工作了一年到一年半左右。

Gergely Orosz：你已经在三家公司担任过 CTO，我很想问一个最基本的问题：CTO 究竟是做什么的？我想很多工程师都曾经向往过这个职位。因为在我们的想象中，CTO 既承担管理职责，又能保持技术深度，离实际工程工作并不遥远。你自己也写过关于工程高管职业发展的书。经历了这么多公司之后，你现在如何理解 CTO 的职责？尤其是在 AI 出现之后，你觉得这个角色发生了什么变化？

Will Larson： 我觉得，2010 年代担任工程经理最糟糕的一件事，就是当你刚进入工程管理岗位时，通常学到的第一条规则是：“从现在开始，你再也不应该做任何技术决策了。”我当年真的就是被这样告知的。当时整个工程管理领域都推崇这种理念：成为管理者，就意味着要学会放手，把技术决策交给工程师。但今天，这套理念已经不再适用了。

过去，我一直觉得 CTO 这个职位很有吸引力，因为它似乎是工程师职业发展中唯一一个能让技术路线和管理路线重新汇合的位置。在大多数工程管理岗位上，你通常不被允许继续扮演技术领导者的角色。但到了 CTO 这个层级，你终于可以同时领导技术和组织。

所以，我一直坚持一个做法：在担任 CTO 时，让工程经理和个人贡献者（Individual Contributor，IC）同时直接向我汇报。比如，现在我有 14 名直接下属，其中四五人是 IC，其余是管理者。我希望自己始终能够同时接触技术和管理两方面的工作。

当然，我也见过很多糟糕的 CTO 决策。我并不是在批评之前提到的某个具体的人，尤其是 David Singleton，他非常出色。Stripe 整体的决策质量也很高，有时候你可能不同意某项决定，但很少会觉得它完全没有道理。不过，在其他一些经历中，我确实遇到过让我无法理解的技术决策。我当时就想，如果自己坐在那个位置上，或许能够做得更好。

而最近这几年，我最喜欢的变化是：技术管理者不仅重新被允许深入技术细节，甚至开始被要求这样做。这让我重新找回了参与软件开发的乐趣。

在 Imprint 工作的一年半里，我提交了超过 500 个最终进入生产环境的 Pull Request。这个数量甚至远远超过了我此前整个职业生涯提交的 PR 总数。对我来说，这是一件非常令人兴奋的事。

Gergely Orosz：你加入 Imprint 时担任 CTO，但现在似乎还承担了更多职责？

Will Larson： 是的。我最初是以 CTO 的身份加入 Imprint，现在还负责产品和设计团队。也就是说，工程、产品和设计都由我统一管理。

Gergely Orosz：这是一种新的行业趋势吗？过去两三年，我开始越来越多地听到 CTPO（首席技术与产品官）这个职位，也就是让一个人同时负责技术和产品。现在甚至连设计团队也开始归同一个人管理。

Will Larson： 我不确定这是不是一种普遍趋势。但随着 AI Agent 越来越多地进入实际工作流程，我观察到一个很大的挑战：组织必须能够快速做出决策，而且要不断决定哪些事情该做、哪些事情不该做。

比如，Agent 应该如何进入产品开发流程？产品团队应该怎样使用它？设计团队又应该怎样调整工作方式？如果设计师还没有使用 Claude 的设计工具、Figma MCP 等新工具，那么设计环节就可能成为整个开发流程的瓶颈。但如果让工程师直接承担一部分设计工作，又会出现新的问题：设计职责究竟应该由谁负责？

我们在 Imprint 就尝试过一种由开发者主导设计的模式，主要用于优先级相对较低的功能。这种方式确实缓解了设计环节的瓶颈，但也带来了大量摩擦。比如，工程师主导设计时，有时没有严格遵循设计系统，最终产品出现了一些设计不一致的问题。这时候，谁应该为这些问题负责？是工程团队，还是设计团队？

所以，我认为，在这样一个剧烈变化的时期，让工程、产品和设计拥有统一的决策负责人，可以更快地协调这些权衡。

从根本上说，我相信软件行业正在经历我整个职业生涯中最剧烈的一次开发方式变革。我从 2008 年底开始从事软件开发，从来没有见过这样的变化。过去我经历的很多变化，更多发生在组织文化、社会环境或者协作方式上。但这一次，我们创造软件的方式本身正在发生深刻变化。

Gergely Orosz：我们不妨回顾一下你进入软件行业以来的变化。从 2007 年左右到今天，硅谷公司的软件开发方式和团队管理方式究竟发生了什么变化？当然，硅谷科技公司只是整个软件行业中的一部分，但它仍然是一个很有代表性的观察对象。

Will Larson： 我刚进入软件行业时，管理方式和今天非常不一样。当时我大概 22 岁，在 Yahoo 担任远程合同工。团队其他成员都在办公室工作，只有我是远程办公。后来我转为正式员工，前后两年一直向同一个经理汇报。

但在这两年里，我和经理总共只进行过两次一对一沟通。当时根本没有今天这种定期一对一会议的概念。我们可能一年才谈一次，主要是讨论薪酬调整，甚至谈不上正式的绩效评估。经理可能只是告诉你：“干得不错，给你涨工资了。”晋升也很简单。有人会来通知你：“恭喜，你升职了。”本质上就是告诉你，现在可以拿更多钱了。

而且，我完全没有期待过经理会和我进行更多的一对一沟通。事实上，我们仅有的两次谈话，也都跟我的职业发展没什么关系。第一次，他想了解另一名员工的工作表现，试图从我这里判断那个人是不是做得不太好。第二次，则是因为我提出了离职，他来问问究竟发生了什么。除此之外，我们几乎没有什么正式沟通。当时这完全正常。

但我觉得他其实是一位很优秀的经理。他对自己职责的理解是：在公司内部寻找能够让团队创造价值的机会。他会到处了解公司的业务，寻找真正重要、值得团队投入的项目，然后把这些机会带回来。接下来，我们负责把东西做出来，确保它能够正常运行。这就是当时的工作方式。

至于他是否应该帮助我获得一段有成就感的职业生涯，我想他根本没有考虑过这个问题。对他来说，那可能完全不属于经理的职责。

这是 2010 年之前的事情。后来到了 Digg，情况也没有好到哪里去。当时公司几乎把所有经理都解雇了。我之所以成为经理，基本上是因为别人问我要不要做时，我是唯一一个傻到没有拒绝的人。那时候我总共只有两年半到三年的工作经验，对管理一无所知。而且，我之前在 Yahoo 几乎没有和经理打过交道。平时主要是技术负责人决定技术方向，如果我把事情搞砸了，他们就会来表达不满。

所以，到了 Digg，我虽然挂着经理的头衔，但实际上根本不知道自己应该做什么。公司也没有什么成熟的管理体系，尤其是最后那一年，几乎谈不上真正的管理。

后来我在 Uber 学到了很多东西