编译 | 蔡芳芳
如果你是一名中层技术经理，过去十几年积累的管理经验，可能正在迅速贬值。
曾在 Stripe、Uber 担任工程管理职务，后来出任 Carta、Calm CTO 的 Will Larson，最近给同行们提出了一个相当不客气的建议：要么退休，要么重新学习技能。他甚至预测，未来三年，我们今天所熟悉的工程管理职业可能不复存在。
更有意思的是，Larson 已经用自己的职业选择践行了这一判断。他曾在 Carta 管理约 250 人的工程组织，后来却主动选择加入规模更小的 Imprint，负责约 25 人的技术团队。从管理数百人到管理几十人，在传统技术高管的职业晋升路径上，这看起来像是一次倒退。
为什么一位曾经管理数百名工程师的技术高管，会认为自己熟悉的职业道路正在失效？
在最新一期 The Pragmatic Engineer 播客中，Larson 结合自己在硅谷多家科技公司的经历，重新审视了工程经理、资深工程师和 CTO 的职责，并提出了一个颇具冲击力的问题：那些曾经帮助工程经理晋升的能力，为什么今天反而可能成为他们的职业负担？AI 编程的兴起，正在让这场变化进一步加速。
1 太长不看版
A：要么重新深入技术一线，要么考虑退休。未来三年，传统工程管理的那套能力可能不再被市场需要。
Q：为什么过去被认为是职业陷阱的 TLM（Tech Lead Manager，技术负责人兼经理），现在反而成了抢手人才？
A：企业需要既懂管理、又能亲自写代码的人。最理想的工程经理，是有能力处理复杂管理事务，却更愿意把时间花在软件开发上的人。
Q：AI 都开始写代码、做 Code Review 了，软件工程师还剩下什么价值？
A：软件实现的成本正在快速下降，但理解业务、判断该做什么、处理复杂约束并验证结果，依然需要工程师。
Q：为什么给一个进度落后的项目增加 15 名工程师，反而可能让事情更糟？
A：更多人意味着更多沟通和协调成本。真正高效的团队需要长期稳定、清晰的责任边界，而不是遇到问题就不断往里面塞人。
Q：一名优秀的 CTO，究竟应该是技术专家还是管理专家？
A：两者都必须是。既要懂技术、产品和软件交付，也要懂组织运作、激励机制和管理流程。只擅长其中一方面，都很难成为优秀的高管。
Q：为什么 AI 能迅速复制 Slack 的界面，却很难复制 Slack 的产品能力？
A：真正难以复制的是长期积累的领域知识、产品决策和团队协作经验。而要让这些积累转化为新产品，还需要有人敢于打破规则、推动不受欢迎的决策。
Q：AI 可以帮人高效写作，为什么你却拒绝用它大量生产文章？
A：我花了近 20 年建立自己的写作声誉，为什么要用 AI 垃圾内容毁掉它？如果没有值得表达的观点，我宁愿不写。一两篇真正有影响力的文章，远比几百篇没人看的内容更有价值。
2 从技术博客进入 Yahoo：一场服务器“黑市”带来的管理启蒙
Gergely Orosz：你最早是怎么对计算机产生兴趣的？小时候就喜欢编程吗？
Will Larson：我大概五岁时，家里就有一台早期的 Macintosh 电脑。那时候我最喜欢用一个叫 Kid Pix 的儿童绘图程序，可以画正方形、圆形和各种简单图案。
当时几乎没有互联网，遇到问题也没什么地方可以查，只能自己不断尝试，直到弄明白怎么操作。某种程度上，这和后来写软件的过程很像：不断动手尝试，直到找到解决办法。
不过，我小时候其实没有真正写过多少程序。到了高中，我开始接触 IRC（互联网中继聊天）和 MUD（多人文字冒险游戏）。这些工具支持触发器、正则表达式和简单脚本，我就是在那个时候学会使用正则表达式的。但真正开始编写软件，已经是上大学之后了。
Gergely Orosz：你在大学里为什么选择计算机科学？当时就打算成为职业程序员吗？
Will Larson：刚进大学时，我其实不知道自己想学什么。物理、英语、经济学都考虑过。我父亲是经济学教授，所以经济学也算是一个很自然的选择。
我就读的是肯塔基州一所规模很小的私立大学。学校要求学生修读一些通识课程，其中包括计算机科学导论。我上完之后发现自己很喜欢，于是逐渐转向计算机科学。
我们学校的计算机科学专业非常小。我毕业那年，整个专业可能只有 13 名学生，而同届毕业生只有 4 人。
这和滑铁卢大学、MIT、斯坦福这样的学校很不一样。在那些学校，学生通常有非常明确的软件工程职业路径。比如滑铁卢大学有成熟的 Co-op（带薪实习）体系，学生之间还会交流面试经验、练习面试题。只要能够顺利完成学业，往往就有一条相对清晰的道路进入科技行业。但在我们学校，根本没有这样的路径。
我记得上一届有个非常优秀的毕业生，最后去了肯塔基州列克星敦一家开发赛马博彩软件的公司，那里可能只有不到五名工程师。这已经是他当时能够找到的不错的机会。所以，我毕业时也不知道自己究竟会去哪里。
Gergely Orosz：那你后来是怎么进入硅谷的？
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 内部积累了大量老旧服务器。这些机器的能耗效率很低，但大家都不愿意归还，因为一旦交出去，下次需要资源时可能就申请不到了。为了让自己的项目顺利上线，你必须先找到一个愿意借服务器给你的人。
这让我觉得非常有意思。一项原本为了提高资源使用效率的管理制度，最后竟然制造了完全相反的激励，让所有人都倾向于囤积资源。
Gergely Orosz：这应该也是你后来成为工程管理者时，一直记得的教训吧？
Will Larson：没错，这件事给了我很深的启发。我有时也很好奇，David Filo 是否知道公司内部真的存在这样一个服务器黑市。我猜他可能知道，但即便如此，这项自上而下的管理规定也没有改变。
3 Digg 灾难性重写内幕：上线当天开香槟庆祝，网站却瘫痪了
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 的发布设定了一个非常紧迫的期限。
从外部看，Digg 似乎还在正常发展，但内部情况已经相当糟糕。
当时 Facebook 正在崛起，Digg 的用户流量开始受到冲击。与此同时，Google 搜索算法的调整也在改变流量分配方式。Digg 大约 60%—70% 的流量来自搜索引擎，主要进入网站的永久链接页面。这些页面收录了用户分享的文章、原始链接和相关评论，有时在 Google 搜索结果中的排名甚至高于原始内容。
这既是 Digg 的重要流量来源，也是广告收入的核心来源。一旦搜索流量下降，公司的财务状况就会迅速恶化。
我记得公司曾经有过一个月的盈利，但随后搜索算法发生变化，流量开始持续下滑。我们很清楚，如果不采取行动，公司可能很快就无法继续经营。
当时 Digg 大约有 110—120 名员工。放在今天，这不算什么特别大的规模，但在 2010 年，创业公司一轮融资可能只有 100 万到 300 万美元，养活一百多人已经是很大的开支。我们的现金正在迅速耗尽。所以，公司决定进行一次彻底重写，试图扭转局面。
Gergely Orosz：那次上线到底出了什么问题？是技术没准备好，还是社区用户无法接受变化？
Will Larson：两方面都有，但技术上的准备确实非常不足。
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 工作过，虽然没有直接共事。
Will Larson：Digg 最后经历了几次不同形式的资产出售。它的一部分专利被收购，其中包括信息流原生广告相关的专利；Digg.com 网站品牌被另一家公司收购；工程团队则被 SocialCode 收购。SocialCode 当时隶属于拥有《华盛顿邮报》等业务的公司，主要从事 Facebook 广告相关业务。我跟随团队去了 SocialCode，又在那里工作了几年。
离开时，我开始认真考虑如何进入更高级别的工程管理岗位。当时我大概管理着一支 12 人的工程团队，但想应聘大型公司的高级管理岗位时，就遇到了一个很现实的问题：没有管理过大规模团队，就很难获得管理大规模团队的机会。
如果去一家只有五名工程师的小型创业公司，即使成为工程负责人，也很难积累大型组织所需要的管理经验。所以我当时的想法是，如果想管理更大的团队，就必须加入一家正在高速增长的公司。我开始寻找这样的机会，最后注意到了 Uber。那是 2014 年初，Uber 的高速增长才刚刚开始。
4 加入高速扩张的 Uber：两年内将团队从 6 人扩张到 70 人
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），具体已经记不清了。
Gergely Orosz：当时你管理的团队有多大？承担哪些职责？
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 一周中最繁忙的时段。周六的总订单量可能更高，但分布在更长的时间里，而周五大量用户会集中在下班时段叫车。
现在有些公司的发展状态会让我想起当年的 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 的位置只有一步之遥。
但我一直在想：如果真正坐到那个位置上，我能不能把某些事情做得更好？我觉得自己应该去尝试一下。后来事实证明，这确实是一段很有教育意义的经历。
Gergely Orosz：所以你后来先后担任了三家公司的 CTO？
Will Larson：是的。我先在 Calm 担任了大约三年半 CTO，之后在 Carta 工作了两年，再后来加入了 Imprint。到现在，我在 Imprint 已经工作了一年到一年半左右。
5 成为工程经理后，就不应该再做技术决策了？
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 年底开始从事软件开发，从来没有见过这样的变化。过去我经历的很多变化，更多发生在组织文化、社会环境或者协作方式上。但这一次，我们创造软件的方式本身正在发生深刻变化。
6 从“自己解决问题”到“让工程师开心”：工程管理是怎么变味的？
Gergely Orosz：我们不妨回顾一下你进入软件行业以来的变化。从 2007 年左右到今天，硅谷公司的软件开发方式和团队管理方式究竟发生了什么变化？当然，硅谷科技公司只是整个软件行业中的一部分，但它仍然是一个很有代表性的观察对象。
Will Larson：我刚进入软件行业时，管理方式和今天非常不一样。当时我大概 22 岁，在 Yahoo 担任远程合同工。团队其他成员都在办公室工作，只有我是远程办公。后来我转为正式员工，前后两年一直向同一个经理汇报。
但在这两年里，我和经理总共只进行过两次一对一沟通。当时根本没有今天这种定期一对一会议的概念。我们可能一年才谈一次，主要是讨论薪酬调整，甚至谈不上正式的绩效评估。经理可能只是告诉你：“干得不错，给你涨工资了。”晋升也很简单。有人会来通知你：“恭喜，你升职了。”本质上就是告诉你，现在可以拿更多钱了。
而且，我完全没有期待过经理会和我进行更多的一对一沟通。事实上，我们仅有的两次谈话，也都跟我的职业发展没什么关系。第一次，他想了解另一名员工的工作表现，试图从我这里判断那个人是不是做得不太好。第二次，则是因为我提出了离职，他来问问究竟发生了什么。除此之外，我们几乎没有什么正式沟通。当时这完全正常。
但我觉得他其实是一位很优秀的经理。他对自己职责的理解是：在公司内部寻找能够让团队创造价值的机会。他会到处了解公司的业务，寻找真正重要、值得团队投入的项目，然后把这些机会带回来。接下来，我们负责把东西做出来，确保它能够正常运行。这就是当时的工作方式。
至于他是否应该帮助我获得一段有成就感的职业生涯，我想他根本没有考虑过这个问题。对他来说，那可能完全不属于经理的职责。
这是 2010 年之前的事情。后来到了 Digg，情况也没有好到哪里去。当时公司几乎把所有经理都解雇了。我之所以成为经理，基本上是因为别人问我要不要做时，我是唯一一个傻到没有拒绝的人。那时候我总共只有两年半到三年的工作经验，对管理一无所知。而且，我之前在 Yahoo 几乎没有和经理打过交道。平时主要是技术负责人决定技术方向，如果我把事情搞砸了，他们就会来表达不满。
这差不多就是我接触过的全部管理模式。
所以，到了 Digg，我虽然挂着经理的头衔，但实际上根本不知道自己应该做什么。公司也没有什么成熟的管理体系，尤其是最后那一年，几乎谈不上真正的管理。
后来我在 Uber 学到了很多东西，但那里的情况同样极端。所有人都忙得不可开交，基本没有人教你怎么管理团队。你只能靠自己摸索，能不能撑下来全凭本事。如果你没有及时做出正确的决定，公司高速增长带来的压力就会直接压垮你的团队。所以，那时候几乎没有任何管理支持。
Gergely Orosz：这很有意思，因为我在 2017 年成为 Uber 工程经理时，公司刚刚推出第一批工程经理培养计划。当时我参加了为期几天的培训，还有专门分配的导师，可以和其他人讨论管理问题。当然，那套培训还是公司内部自己摸索出来的，比较初级。但至少已经开始形成正式制度。在那之前，绝大多数工程经理从来没有接受过类似培训。我想 Uber 后来之所以推出这套计划，也是因为公司逐渐意识到，管理者能力不足已经成为一个很严重的问题。
Will Larson：这很合理。我在 Uber 工作时，公司文化非常强调自己解决问题。我不一定记得当时价值观的准确表述，但核心精神大概就是：遇到问题，不要因为其他团队没有配合就停下来，而是自己想办法解决。
Gergely Orosz：我记得当时有两条价值观，分别是“Let Builders Build”（让建设者放手去做）和“Be an Owner, Not a Renter”（做主人，不做租客）。结合起来，意思差不多就是自己承担责任，找到办法把事情做成。
Will Larson：没错。当时 Uber 有一种非常强烈的文化，就是尽量不让跨团队依赖成为工作的障碍。如果你说自己被其他团队卡住了，得到的回答往往是：你没有被卡住，你需要自己找到解决办法。这种文化有时候非常痛苦，但我也觉得它很有力量，因为你始终有机会主动承担责任，把问题解决掉。
我记得有一次，我们需要为 Uber 中国的业务签署采购订单，但怎么也找不到合适的人审批。当时我可能只有 27 岁左右。负责技术运维的 Amir 和我面面相觑，最后觉得，既然没人能签，那我们就自己签吧。于是，我们真的把采购订单签了。让我印象特别深刻的是，后来根本没有人来追问这件事，也没有任何后续调查。
当然，从公司治理的角度看，这种做法可能相当随意，甚至有些问题。但我非常喜欢当时 Uber 的一点：大家不会相互设置障碍，所以我们能够完成很多不可思议的事情。与此同时，那也是一个极其艰难的工作环境。
Gergely Orosz：所以，后来很多人离开 Uber，或者因为过度工作而精疲力竭，也不是没有原因的。
Will Larson：完全正确。到了 2016 年，我加入 Stripe，发现那里的管理文化同样很不成熟。Stripe 当时甚至以缺少管理者而出名。
我加入时，公司可能只有三四名工程经理。其中一位叫 Raylene，我非常喜欢和她共事，但她当时大概有 40—50 名直接下属。Stripe 之前研究过 Google 在早期尝试减少甚至取消经理岗位的做法，也曾经沿着类似的方向发展。
Gergely Orosz：但 Google 后来发现，这种做法行不通。
Will Larson：是的。不过，Stripe 最初确实很长一段时间都没有建立完整的管理体系。我加入时，正好赶上公司开始大规模引入工程经理。除了 Raylene，还有 Jorge 等少数几名管理者。Jorge 大概负责 30 人的团队，下面可能还有一名经理；Raylene 则直接管理几十个人，没有中间管理层。
那也是一个非常混乱的时期。不过，经历过 Uber 之后，我已经很习惯这种混乱了。而且 Stripe 的业务同样增长得非常快。我觉得，正是在 Uber 到 Stripe 的这段时期，行业对工程经理职责的理解开始发生明显变化。
工程经理逐渐不再被视为直接做事的人或决策者，而是变成了帮助别人完成工作的协调者和支持者。这种理念开始真正成为主流。
我在 2021 年出版《Staff Engineer》这本书，部分原因就与当时的一些经历有关。那时，我正在收集曾经共事过的资深工程师的反馈。有一种观念让我非常困扰：很多人认为，Staff Engineer 的主要职责，就是去解决那些自己觉得有趣、能够带来个人成就感的技术问题。
但这根本不是我需要他们做的事情。我需要这些资深工程师去解决业务真正面临的问题，包括系统扩展性、基础设施瓶颈等。
当我离开 Stripe 时，我负责的团队大约有 250—260 人。这样规模的组织每天都会遇到大量棘手的问题。可我手下一些最优秀的工程师会告诉我：“我想做点更有意思的事情。”而我的回答基本上是：“我这里只有一堆苦差事可以给你，但正是这些苦差事，才能让公司成功。”
所以，我当时一直在思考，怎样才能让这些工程师重新把注意力放到公司真正需要解决的问题上。但不少人觉得，我这样的要求违背了工程经理与员工之间默认的约定。在他们看来，我作为管理者的职责，就是为他们提供有趣的、符合个人兴趣的工作。
Gergely Orosz：这和十年前的管理方式相比，变化确实太大了。
Will Larson：是的。但我始终不认为这种观念是正确的。如果你观察 Stripe 真正处于高级别岗位的人，或者我在其他公司见过的顶尖工程师，就会发现，他们承担的始终是公司最需要、最有价值的工作。那种“公司应该为我提供有趣工作”的观念，从来没有真正成为高管层的主流。但当时很多新加入公司的工程师确实抱有这样的期待。
我不想点名具体公司，不过，有些公司在这方面的文化特别明显：他们认为，管理者对高级工程师的责任，就是确保这些人能够做自己喜欢的工作。我觉得现在整个行业已经明显从这种观念中退了回来。
Gergely Orosz：这种变化是否与零利率时代有关？我们经常讨论这个问题。利率听起来是一个非常抽象的宏观经济指标，但它可能在很长一段时间里深刻影响了科技行业。低利率影响了风险投资，影响了创业公司的融资能力。很多甚至还没有找到可持续商业模式的公司，也能够获得大量资金。而这些资金又进一步影响了软件工程师的招聘、职业发展模式、工程经理的职责，以及企业内部的管理决策。直到 2022 年前后，环境突然发生变化，企业开始重新强调效率。现在回过头来看，我也经常问自己：我们在那个时期建立起来的所有管理方式，当时真的合理吗？
Will Larson：你有没有读过 The Margins 上那篇《ZIRP Explains Everything》？
Gergely Orosz：读过。我很喜欢他们的文章，我们也会把链接放出来。
Will Larson：我在 Digg 有位同事 John Durek，后来我又把他招到了 Uber。他也是 The Margins 的作者之一。
所以我读过那篇文章，而且非常有共鸣。我确实认为，零利率政策（ZIRP）几乎可以解释整个 2010 年代工程管理方式的变化。
当时，科技公司的薪酬不断上涨，对优秀工程师的争夺越来越激烈。一家科技公司能不能成功，很大程度上取决于它能否招到优秀人才、说服候选人接受 Offer，以及留住这些人才。如果做不到这些，公司就很难和竞争对手抗衡。于是，工程师在雇佣关系中的议价能力大幅提高。这最终创造了一种与过去完全不同的工作环境。
当时，为了争夺工程师，很多公司开始把自己包装成更加轻松、更加关注员工个人发展的工作场所。它们强调职业成长，希望员工能够从工作中获得成就感，做自己感兴趣的事情。
但我觉得，这些做法有时候反而会损害公司的长期利益。
人们经常批评 Google 那种提供大量员工福利的企业文化。不过，除了 Google 和 Meta，真正取得巨大成功的公司中，可能很少有企业把员工福利做到那种程度。但即使不考虑免费餐饮之类的福利，还有很多其他方式可以体现这种变化。
比如，有些公司开始认为，软件工程师不应该承担自己开发系统的值班工作，可以把 On-call 交给专门的 SRE 团队。这让我觉得很奇怪。因为我共事过的工程师几乎都知道，让开发软件的人亲自承担线上值班责任，通常会让软件质量变得更好。可有些公司为了改善工程师的工作体验，宁愿让没有参与软件开发的人去处理系统故障。
这其实非常能说明问题：公司的优先级已经发生了变化。
Gergely Orosz： 这种变化也体现在工程经理的考核方式上。当时，管理者的一项重要成绩就是团队流失率低，也就是能够留住员工。另一项则是能不能完成招聘指标。现在听起来可能有点不可思议，但那个年代，填满招聘名额真的很困难。
比如，你是一名管理着 30 人团队的工程总监或者高级工程经理，公司今年给你 10 个招聘名额。如果你招不到合适的人，尤其是高级工程师及以上级别的候选人，就可能影响你的绩效。这些名额甚至可能被分配给其他管理者。而如果另一个管理者成功招满了人，团队从 30 人扩大到 40 多人，他就可能获得晋升机会，比如从高级工程经理升任总监。
于是，在这种环境下表现出色的管理者，逐渐变得有些过度迎合员工。他们不仅要尽力留住工程师，有时候还会刻意让工程师远离业务压力。我现在反而觉得，这种做法可能给很多人带来了长期的负面影响。
因为今天的工程师越来越需要理解业务，知道公司靠什么赚钱、真正需要解决什么问题。具备这些能力的人，才更容易受到企业欢迎，也才能在创业公司快速发挥作用。但我仍然听到一些故事：有人以前在大型科技公司工作，后来加入一家只有七个人的创业公司，却抱怨说：“这里太糟糕了，他们什么都不让我做。”我就很困惑。你加入的是一家只有七个人的创业公司，而且你已经是一名经验丰富的工程师，为什么不主动去问：“公司现在最需要解决什么问题？那我们就去把它解决掉。”这些人在之前的工作环境里待了太久，已经习惯了另一套工作方式。
Will Larson：我觉得你说得很对，这背后很大程度上就是激励机制的问题。当然，招聘指标、团队规模、员工满意度调查，这些管理工具本身都很有价值。我自己也会使用，而且确实能从中获得很多信息。
我记得在那些高速增长的公司，我们花了大量时间分析员工调查结果，试图据此判断工程经理的管理水平。但调查结果必须结合具体情况理解。员工满意度高，不代表经理一定优秀；满意度低，也不代表经理一定糟糕。
至于团队规模，我其实非常讨厌围绕 Headcount（人员编制）展开的讨论。我觉得这几乎从来不是最值得讨论的问题。不过，回到当时的环境，如果工程经理不能参与技术决策，那么想让团队更快完成工作，他们能够使用的最直接手段，就只剩下增加人手了。
Gergely Orosz：你的意思是，在零利率时代，行业普遍认为工程经理不应该参与技术决策，这实际上迫使那些聪明、有能力的管理者，把大量精力投入非技术事务？他们可能因此忽视技术层面的投入，没有及时做出本来应该做的技术决策，却过度关注流程、沟通和人员管理，甚至刻意帮助团队隔离业务压力。因为这些才是他们被允许施加影响的地方。
Will Larson：完全正确。我现在经常告诉自己的团队：招聘几乎是解决任何问题时最没意思的一种办法。我们通常根本不应该首先讨论招人。而且还有一个相关的问题：如果你连现有的招聘名额都没有填满，却还在申请更多名额，那同样没有意义。因为真正限制你的，是招聘速度。既然你连已经获批的人都招不进来，再增加编制也解决不了问题。
回头看，我们当年基本上是在告诉工程经理：你们不能思考技术解决方案。那他们还剩下什么？流程、排期，以及人员。所以我认为，当工程管理和技术领导被彻底分割之后，管理者过度依赖招聘来解决问题，几乎是一种必然结果。
这并不是说我们完全不应该区分管理者和技术专家的职责。但要形成有效的领导力，管理者必须同时具备技术和组织两方面的判断能力。否则，他们就很容易把注意力过度集中在招聘和团队规模上。而这也是过去一些工程组织变得异常臃肿的重要原因。
7 AI 开始写代码了，工程师的晋升阶梯还成立吗？
Gergely Orosz：接下来我们谈谈职业发展，先从个人贡献者，也就是不直接承担人员管理职责的工程师开始。你觉得，对于今天在创业公司或中型企业工作的软件工程师来说，职业发展机会发生了什么变化？
过去，我们有一套相对清晰的职业阶梯：Engineer 1、Engineer 2、Senior Engineer、Staff Engineer。每个级别对应什么能力、怎样才能晋升，基本都有明确标准。但现在 AI 编程工具已经能够完成很多原本由初级工程师承担的编码工作，而且它们正在变得越来越擅长软件架构设计。我们甚至已经开始讨论让 AI Agent 在循环中持续执行开发任务。那么，传统的工程师职业阶梯还有意义吗？我们是否还应该保留它？如果你是一家公司的工程经理，现在还应该花精力去制定和维护工程师的职业晋升体系吗？
Will Larson：这是个很好的问题。我觉得，至少从工程团队的期待来看，大家肯定还是希望公司能够提供明确的职业晋升阶梯。不过，传统的职业评价体系确实存在一些问题。比如，那些维持系统正常运转、改善团队协作的工作——无论你称它们为维护性工作、Glue Work，还是其他什么——往往得不到足够的重视。相比之下，那些看起来更亮眼、更容易展示成果的工作，往往会获得过多关注。
这种倾向确实存在，所以我仍然支持建立工程师职业晋升体系，我认为它依然有价值。但问题是，今天的职业阶梯究竟应该包含哪些评价标准，已经变得越来越复杂，也越来越难以确定。
我不知道现在是哪家咨询公司在向企业出售职业晋升体系模板，但我发现，很多规模不大的公司使用的职业阶梯几乎一模一样，就像从某个地方买了一套现成的标准文件。我觉得这些体系已经非常过时了，可我们又还没有建立起能够取代它们的新版本。
不过，如果讨论今天什么样的工程师应该晋升到 Staff Engineer 或 Principal Engineer，我的判断其实比较明确。我一直想为《Staff Engineer》这本书写一些补充内容，也许未来十年里的某个时候终于会动笔吧。我最想讨论的，就是如何在复杂、不确定的情况下做出决策。
首先是处理模糊问题的能力。
我记得在 Stripe 工作时，我们曾经推进一个多区域部署（Multi-region）项目。负责这个项目的工程师不断向我提出类似的问题：我们需要产品团队决定跨区域复制应该怎么做；或者，当系统面临一致性、可用性和网络分区容错之间的取舍时，产品应该支持什么样的行为？
他们实际上是在要求产品团队替自己做 CAP 定理相关的技术权衡。但产品团队怎么可能独立做出这种决定？我觉得，这些工程师当时实际上是在给自己寻找一个无法继续推进工作的理由。因为只要产品团队没有明确回答，他们就可以说需求还不清楚，所以项目无法继续。
但对于 Staff Engineer 或 Principal Engineer 来说，我期待的是完全不同的做法。你需要能够在模糊的情况下主动做出权衡，形成自己的判断，并通过原型验证这些判断是否成立。 比如，你可以先提出一个合理的技术方案，明确它依赖哪些假设，再通过实验判断这些假设是否有价值、能不能真正落地。你不能指望所有问题都有人提前替你定义清楚。
所以，处理这类模糊问题的能力，至今仍然是我判断一名工程师是否达到高级别的重要标准。即使有了 AI Agent，这一点也没有改变。复杂系统里依然存在大量需要人来做出的权衡。
而且，正如我们前面讨论的，很多权衡已经超出了纯技术范畴。你不仅需要理解技术如何工作，还要理解技术选择会对产品产生什么影响。要理解这些影响，就必须知道用户真正想完成什么任务，理解产品的单位经济模型（Unit Economics）：服务一个客户需要付出多少成本，公司又向客户收取多少钱。
因此，今天要真正解决复杂而模糊的问题，工程师反而需要具备更广泛的知识。但我认为，Staff Engineer 和 Principal Engineer 的核心价值一直没有改变：他们必须能够做出重要决策，并通过这些决策产生影响。
我也不认为 AI Agent 特别擅长这类权衡。很多时候，Agent 甚至意识不到某些权衡的存在，因为相关信息可能根本不在它的上下文窗口里。这些因素往往非常微妙，属于软件系统之外的隐性背景，比如业务约束、产品目标，以及其他没有被明确写进代码或文档的信息。
Gergely Orosz：那我们再看看初级工程师的职业发展。最近有一位高级工程师跟我说，AI 在编写代码方面显然已经达到了 Eng1、Eng2 的水平，因为过去我们对这些初级工程师的主要期待，就是能够把代码写出来。他还认为，AI 迟早会达到高级工程师的水平，只是目前还没有完全做到。我一直记得这个观点，因为它确实有一定道理。
那么，在你的组织里，你现在怎么看待 Eng1、Eng2，以及刚毕业加入公司的工程师？这些人还没有积累足够的实战经验，也没有经历过太多复杂项目，因此尚未形成能够让你完全信任的专业判断力。在招聘和培养他们时，你会怎么考虑？
Will Larson：有一种做法是我一直尽量避免的，我称之为“人为制造的精确性”（Artificial Specificity）。比如，Eng1 和 Eng2 到底有什么区别？如果你真的试图给出一个非常具体、清晰的定义，就会发现这件事其实相当困难。很多公司采用了一种看起来很有效的办法：按照工作年限区分，比如有三年经验就可以达到 Eng2。但这种划分真的公平吗？我也不知道有没有一种特别公平的方法，能够准确区分 Eng1 和 Eng2。
当然，如果一个 Eng1 的能力明显不达标，通常比较容易判断。但如果比较一名非常优秀的 Eng1 和一名 Eng2，差别往往没有那么明显。很多时候，他们之间的差距主要来自工作时间、承担过的岗位职责，以及随着经验积累而逐渐形成的上下文理解。并不是说 Eng2 一定能够完成某项工作，而 Eng1 就一定做不到。
尤其是现在有了各种 AI 编程工具和 Agent 执行框架（Coding Harness），工程师能够完成的任务范围已经大大扩展。现在的问题越来越不在于他们能不能把某件事做出来，而在于他们能不能判断，这件事究竟应不应该做。
而且，在某些情况下，初级工程师会得到非常具体的工作指令，你甚至没有机会观察他们自己的判断力。所以，我现在越来越不愿意把 Eng1、Eng2 之间的差别定义得过于精细。很多时候，工作年限、职级这些相对简单的标准，可能就已经足够了。
我担心，如果我们试图把每一项晋升标准都写得特别具体，最后可能只是获得了一种虚假的成就感：看起来标准终于精确了，但实际效果未必更好。你肯定参加过晋升校准会议。有些人特别擅长研究评分标准，然后专门按照这些标准准备自己的晋升材料。
我记得在之前工作过的一家公司，想晋升 Staff Engineer，必须满足一项指导其他工程师的要求。结果，有些人真的会专门去找别人聊一次天，然后把对方登记成自己的被指导者。他们简直是在四处收集徒弟。
但如果你去问那些所谓的被指导者，对方可能会一脸困惑：“我也不知道他为什么找我聊天，我们就只聊过一次。”这就是典型的“你考核什么，人们就会想办法完成什么”。
所以，我认为晋升从来都离不开主观判断。如果你试图彻底消除主观判断，最终也未必能得到更好的结果。有一套评价标准来指导大家，当然有价值。但说到底，晋升仍然是一件相当主观的事情。相比制定一套无所不包、试图精确衡量每个人的评分体系，我现在反而更看重一些明确的约束条件。
Gergely Orosz：比如你在 Carta 采取过的做法？
Will Larson：对。Carta 当时面临很大的成本压力，需要控制整个工程组织的支出。所以，我直接设定了一个比例限制：Staff Engineer 的人数不能超过工程团队总人数的一定比例。这个上限不能突破。这让很多人非常不满，但我觉得，这种做法至少更加坦诚。
如果回到大约 15 年前，大多数公司的工程师职业阶梯其实到 Senior Engineer 就结束了。对于绝大多数工程师来说，高级工程师已经是职业发展的最高级别。后来，随着越来越多的人拥有 20 年、30 年甚至 40 年的软件开发经验，企业才逐渐增加了更多高级技术职级。
但这些新增加的级别，很多时候更多是在反映一个人的工作年限、承担过的职责，以及职业发展阶段，并不一定对应某种能够被精确定义的能力差异。
所以，我现在不太纠结这些级别之间的细微区别。如果公司的目标是控制成本，那么规定 Staff Engineer 与其他工程师之间的比例，比如 1:8，实际上是一种很有效的办法。因为当你真正想做的是控制成本时，就应该坦率地承认自己是在控制成本。Carta 当时就是这种情况。
但在我现在工作的 Imprint，我们并没有把控制成本作为主要目标。我们更关注开发速度和质量，因此也没有考虑设置类似的人员比例限制。
我觉得，领导者的一项重要职责，就是清楚自己究竟想实现什么目标，向团队解释准备采用什么方法，然后让大家理解并接受这种选择带来的后果。
在 Carta，因为我们设定了固定的高级工程师比例，就必须调整招聘结构，减少对高级工程师的招聘，增加初级和中级工程师的招聘，让更多人能够从内部逐步成长到高级岗位。这一限制实际上推动了后续一系列调整，而且效果相当不错。
但如果我们只是简单限制高级工程师的人数，却不同时调整招聘渠道和人才培养体系，这套办法也不可能成功。
总之，和职业生涯早期相比，我现在越来越不相信，我们能够为所有事情制定一套完美、精确且永远正确的定义。
现实中的例外实在太多了。
8 AI 时代的软件工程师正在重新定义
Gergely Orosz： 说到这些职级标准和岗位期待，我觉得还有一个变化值得讨论。以前我们在 Uber 工作、你后来在 Stripe 工作时，大家对不同级别工程师应该承担什么职责，其实有一套比较清楚的共识。
当然，我同意你说的，Eng1、Eng2 和 Senior Engineer 之间的边界有时候比较模糊，但至少在过去将近十年里，行业逐渐形成了一些共同理解。
比如，对于一名高级工程师，你通常可以放心地把一个完整项目交给他。如果团队里有初级工程师，他也应该能够指导他们。对于 Staff Engineer，你可以信任他为一个业务单元或者多个项目制定技术方向。
至于 Eng1、Eng2，他们主要需要具备良好的编码能力，能够可靠地完成任务、接受反馈，并在实践中不断成长。说起来，这两个级别其实有点像学徒阶段。Eng1 升到 Eng2 并不是职业生涯中多么重大的晋升，也不应该是一个人长期停留的目标。他们还处在成长过程中，需要不断积累经验，最终形成成熟的技术判断力。有些公司，包括当年的 Uber，甚至明确要求工程师必须在一定时间内成长到某个级别。
但现在情况变了。我们越来越多地使用 AI 编程工具和 Agent 执行框架，甚至连代码审查也开始交给 AI。传统的人工 Code Review 正在逐渐减少，工程师亲自编写代码、相互审查并提供反馈的机会，也没有过去那么多了。那么，你现在会怎样定义软件工程师这个岗位？它和过去相比，是否已经发生了根本变化？我们对工程师的要求是不是变得更高了？我自己感觉，今天的软件工程师似乎需要承担更多责任，但又很难准确描述这种变化究竟体现在哪里。尤其是从 CTO 的角度，你怎么看待这个问题？
Will Larson：你问的是整个软件工程师岗位，还是某个具体级别，比如 Eng3？
Gergely Orosz：我问的是整个软件工程师岗位，因为我觉得每个级别的工作内容都发生了很大变化。以前在中型及以上规模的公司，Staff Engineer 可能本来就不需要写太多代码，因为他们大部分时间都在确保团队做的是正确的事情。但现在，几乎所有级别的工程师都不再需要亲自编写那么多代码了。即使是最低级别的工程师，也必须开始思考：我们现在做的事情究竟对不对？我采用的方法是不是正确？
Will Larson：首先，我觉得我们现在仍然处在非常早期的阶段，还无法确定软件工程师这个岗位最终会演变成什么样子。你肯定会听到一些人预测，未来无论公司规模多大，软件开发团队都只需要五个人。也许他们是对的。也许未来某一天，我们真的能够做到这一点。但至少现在，我们离那种状态还很远。
我也不知道我们会不会很快走到那一步。不过，确实已经有一些公司，只依靠很少的工程师，就能够消耗数量惊人的 Token，并且把这些 Token 真正转化为生产力。看到这种变化，确实让人非常兴奋。
软件工程师这个职业究竟会走向哪里？我想，我们只能慢慢寻找答案。这也是为什么我觉得，现在是进入软件行业以来最有意思的时期。我们的职业正在发生变化，而且变化的剧烈程度，超过了我入行以来见过的任何一次。
对我来说，这段时间特别有趣。我一直非常关注工作最终能产生什么结果，而现在，我们能够以前所未有的速度把想法变成现实。
但我也和一些工程师聊过，他们从编程本身获得快乐，喜欢沉浸在代码里的那种心流状态。现在，这些人反而开始不喜欢软件开发了，因为他们真正热爱的，是亲手编写软件的过程。
前不久，我和一位工程师聊起这件事。他告诉我，自己已经决定退休了，因为他不再享受编程的过程。“现在我的工作效率更高了，但我就是不喜欢这种工作方式。”过去那种沉浸在代码中的心流状态，已经找不回来了。
所以，我认为软件工程师的角色确实正在变化，而且变化的方向非常有意思。
我最近一直有个想法：软件的实际实现时间，正在趋近于零。但即使你能够瞬间把软件写出来，整个系统仍然可能存在大量问题。你依然需要做出各种决策，依然会遇到功能无法正常运行、扩展性不足、用户体验不符合预期等问题。你还可能发现，产品的单位经济模型根本不成立，服务客户的成本太高，最终无法形成一门赚钱的生意。所以，即使编写软件真的变得完全免费，做好软件仍然是一件极其困难的事情。
现在我们已经开始看到这种变化带来的问题。如果软件实现几乎不需要成本，工程师的开发速度就可能超过产品团队编写 PRD 的速度，也可能超过设计团队制作高保真设计稿的速度。工程师已经把功能做出来了，产品需求和设计稿却还没跟上。对于需要和工程团队协作的设计师来说，这会带来很多新问题。我们在 Imprint 也正在摸索如何适应这种由工程师主导的开发模式。坦率地说，我们还没有完全解决问题。
Gergely Orosz：但这也可能创造新的机会。如果一名工程师同时具备设计能力，或者理解业务领域，他就可能独立完成从构思到实验验证的整个过程。当然，企业能够同时开展的实验数量终究是有限的。所以我在想，当软件开发越来越快，工程师是不是必须开始理解企业其他环节的约束？比如业务领域本身、客户需求、现实中的运营限制，以及你刚才提到的单位经济模型——产品究竟怎样才能赚钱。
Will Larson：我在 Carta 工作时，经常思考这个问题。Carta 的业务规模并不大。这里说的规模，是指它不需要每秒处理几十万次请求，也不存在那种特别庞大的基础设施扩展问题。但它的业务极其复杂，细节非常多。比如股权结构表（Cap Table）的管理，规则非常具体，而且异常情况特别多。再加上会计处理，整个系统的复杂程度就更高了。
Gergely Orosz：而且这些细节都很重要。看起来可能只是一个很小的问题，但你必须处理正确。
Will Larson：没错。从审计角度来说，准确性非常重要。你还需要与律师事务所合作，而律师事务所往往对每个流程应该如何执行都有非常明确、具体的要求。有时候，你甚至会卷入两名创始人之间的法律纠纷。他们可能正在争论，某个人究竟已经获得了多少归属股权。Carta 后来进入的其他业务领域，比如基金行政管理，同样需要处理大量细节。
所以，很多行业真正困难的地方，一直都是对业务领域的理解。而我现在还不确定，这类高度依赖专业领域知识的业务，究竟从 AI 工具中获得了多大程度的改善。
即使有了 AI，股权结构表管理仍然非常困难。你需要理解大量细节、法律规定，还需要维护与律师事务所的关系，包括培训那里的律师助理，让他们知道如何使用你的产品。这些看起来很细碎的事情，实际上共同构成了业务的复杂性。
我认为在今天这个时代，那些具有复杂专业知识和业务规则的公司，仍然拥有相当强的竞争壁垒。至于这种壁垒未来会发生什么变化，我还不知道。但我相信它最终也会改变。
Gergely Orosz：科技行业似乎每隔两三年就会追捧一种新的工程师角色。前些年，大家都在说产品工程师有多厉害，现在风头又转向了 AI 工程师（AI Engineer）。
Will Larson：没错。所谓 AI 工程师，本质上似乎就是那些会使用 AI 技术的产品工程师。
Gergely Orosz：但现在几乎所有产品工程师都在使用 AI。
Will Larson：没错。所以，我一直不太明白 AI Engineer 到底意味着什么。按我的理解，它可能就是指那些会使用 AI Agent 执行框架，而且希望因此拿到更高薪酬的人。当然，这个词可能还有其他更微妙的含义，只是我没有理解到。但真正的问题是：我们能不能让一个人同时掌握完成整个产品所需要的全部背景知识？
过去我们经常讨论，能不能找到一名同时具备优秀设计能力的前端工程师，或者一名能够编写生产级代码的设计师。这样的人一直非常稀缺。但现在，一个具备基本设计品位的设计师，已经可以借助 AI 编写生产代码；反过来，一个有良好审美的前端工程师，也可以借助 AI 完成设计工作。既然如此，为什么我们还没有看到大量这样的人出现呢？
Gergely Orosz：这也是我最近一直在思考的问题。我看到过 Linear 的一些数据，显示设计师和产品经理提交的 PR 数量正在增加。后来有位工程经理给我发消息，说他一直在调查这个现象。他觉得，既然 AI 编程工具已经这么强大，我们理应看到越来越多的设计师直接把代码推到生产环境。
他问了大约十家公司，我又另外询问了十家左右，包括 Linear、Ramp、OpenAI 等。但到目前为止，除了极少数特殊案例，我几乎没有听说设计师真正独立将代码部署到生产环境的情况。
设计师现在确实会使用 AI 发现 Bug、定位问题，也会制作更多原型。但一旦涉及正式产品代码，他们通常还是会找工程师参与，确认修改方案能否在现有代码库中正常工作。
我在想，这会不会与责任归属有关？就像我虽然会换灯泡，但如果家里的电路需要进行稍微复杂一点的改造，我还是会找专业电工。即使我可以通过看书学会相关操作，也不意味着我愿意承担其中的风险。所以，这究竟是责任问题，还是专业分工的问题？
Will Larson：我也不确定。现在有一种观点认为，只要企业建立了一套足够完善、真正得到使用的设计系统，就不再需要产品设计师了。但至少从我的经验来看，即使有很好的设计系统，这种说法也不成立。你仍然需要理解不同组件应该如何组合，发现设计系统中缺少哪些组件，以及当不同页面之间出现设计冲突时，应该怎样权衡，才能让用户获得一致的产品体验。这些依然是非常困难的工作。
我知道《Attention Is All You Need》这篇论文讨论的并不是人类的注意力，但我确实认为，人的注意力仍然是一种重要的限制。优秀的设计师、产品设计师和设计系统设计师，需要投入大量精力关注细节，才能把自己的工作做好。他们往往没有那么多时间再去承担其他领域的工作。
当然，这是不是一种无法改变的限制？我认为不是。理论上，如果企业拥有非常完善的设计系统，组件之间高度一致，而且有大量自动化规则和检查工具，能够确保每个组件都按照正确方式使用，那么设计师就可以把更多精力放在例外情况上。
这也是我们在 Imprint 正在尝试的方向。我们希望，普通的产品设计需求可以由工程师直接利用现有设计系统完成。产品设计师则更多地处理真正复杂的设计问题，设计系统团队负责不断扩展和完善组件体系。但目前还没有完全实现。实际推进起来仍然有些困难。
不过，借用那些深度研究 AI 的人的说法，我倾向于认为，这只是一个所谓的“技能问题”（Skill Issue），我们最终能够解决。只不过现在对我们来说，它确实还是一个尚未解决的技能问题。
9 为什么增加 15 名工程师，反而可能毁掉一个项目？
Gergely Orosz：说到这里，我想起你写过的一篇文章《Revised Rules of Engineering Management》（工程管理的新规则）。其中有一条我特别想讨论，你写的是：建立长期稳定、具有高度主人翁意识的团队，因为领域知识正在变得更加重要。
我引用一下你的原话：“我在 Uber 学到的最重要的一课是，长期稳定的团队能够创造奇迹。随着时间推移，团队会不断积累领域知识，形成成员之间的默契，并对自己负责的领域建立越来越强的主人翁意识。”
这是你在 2014 年、2015 年左右从 Uber 获得的经验，距今已经超过十年了。而你现在似乎认为，这一点变得更加重要。
Will Larson：我认为这是建立高水平工程组织的唯一途径。有意思的是，这个观点听起来似乎理所当然，但在实际工作中，它并不是所有人都认同的做法。
假设一家公司有 50 名工程师，现在有一个非常重要的合作伙伴项目，而且已经延期了。这时，管理层往往会决定：“我们再调 15 个人过去，集中力量把这个关键项目做完。”但这正是《人月神话》早就讨论过的问题。
Gergely Orosz：《人月神话》最初出版于 1975 年，第二版是 1995 年。
Will Larson：对。也就是说，五十多年前我们就已经知道，向延期的软件项目增加人手，并不能解决问题。但企业还是不断重复这种做法。我觉得，很多时候，这其实是一种姿态。管理层希望让所有人看到，公司已经竭尽全力解决问题。这样一来，即使项目最后还是延期，也可以说：“我们已经把能做的都做了。”
实际上这种做法不仅解决不了问题，还会破坏真正有效的组织方式：建立能够长期负责某个业务领域的小团队。
我刚加入 Stripe 时，接手了 Jorge 原来负责的团队。他当时转去了公司的另一个部门，我记得好像是去负责 Connect 业务。那时，我手下大约有 30 人，只有一名经理负责其中四五个人，剩下的二十三四个人都直接向我汇报。
我做的第一件事，就是重新划分团队。我开始思考，哪些人可以组成一个相对独立的小组，每个小组又应该负责什么领域。一旦这些小团队开始正常运转、取得进展，我基本上就不再操心他们的日常工作了。除非出现特别严重的问题，否则我会让他们自己决定怎么做。这样，我就能把精力集中到那些团队自己解决不了的问题上，以及整个组织更重要的事情上。
这套方法效果非常好。我在 Uber 也采用过类似做法，后来到了 Calm 和 Imprint，我又做了同样的事情。Carta 是个例外，因为我加入时，它已经建立了比较成熟、能够支撑较大规模的工程组织，不需要我重新做这件事。
我觉得，这种组织方式之所以有效，是因为真正长期负责某个领域的人，往往比管理者更清楚这个领域需要什么。 如果让他们自己做决定，他们通常能够比接受自上而下的指令做得更好。与此同时，管理者也能把注意力放在整个公司最重要、最棘手的问题上。
所以，尽管这听起来有点违反常识，但我始终认为，这是一种非常有效的管理方式。问题在于，从外部看，这种做法几乎总是显得不太正确。这也是为什么它很难坚持。
比如，公司有一个重要合作伙伴的产品即将上线，项目进度已经非常紧张。你却告诉大家：“我不会把其他团队的人调过来，他们正在做的事情同样重要。我们就让负责这个项目的团队集中精力，全力冲刺，哪怕这段时间会非常辛苦。”
在旁人看来，这可能显得你没有充分调动资源。但我认为，这比把所有人都拉过来帮忙要好得多。
Gergely Orosz：而且，你其实还可以采用另一种办法。尤其是在零利率时代，工程师除了开发工作，还要参加大量会议、招聘面试、校园招聘活动等。如果某个团队正在负责关键项目，你完全可以暂时免除他们这些额外事务，让他们专心完成手头的工作。比如，不需要参加招聘面试，不需要去大学参加招聘活动，也不需要出席全员大会。这实际上比增加人手有效得多。
有时候，你还可以直接和团队沟通：“接下来两周，我们需要集中冲刺。如果有人愿意在这段时间额外投入一些工作时间，希望大家能够支持。项目结束之后，可以安排补休。”你可以建立合理的激励机制，把员工当作成年人来对待，直接和他们商量。在工作之外的生活中，我们也经常会为了某件重要的事情，在短时间内额外付出一些精力。尤其是当你知道，自己的付出之后会得到相应回报时。
Will Larson：没错。如果不这样做，就会出现一个很严重的问题：在一家真正高速增长的公司里，几乎每天都会发生新的危机。如果你每次遇到危机，都把其他团队的人调过来救火，那么结果就是，所有人每天都在处理危机。这会让整个组织陷入一种精疲力竭的状态。
我记得加入 Stripe 一两年后，曾经和一位同事讨论过这个问题。他用了一个特别形象的比喻：Stripe 过去的工作方式，就像一群人站在城堡的围墙上抵御敌人。哪里快要守不住了，大家就赶紧跑到哪里去支援。他们越跑越快，但问题是，无论跑得多快，他们都不可能同时出现在所有需要防守的地方。
而我们想建立的，是另一种组织方式：让不同的小团队分别驻守不同的位置。每个团队都必须解决自己负责区域的问题，但也正因为如此，他们不需要每天跑到其他地方救火。这是两种完全不同的选择。
对于一家正在快速扩张的公司来说，最终必须建立起第二种工作方式。不能永远依赖同一批能力最强的人，让他们到处处理紧急问题。因为这些人迟早会被耗尽。而且，当公司的规模增长到一定程度时，无论他们多么优秀，都不可能再覆盖所有问题。
当然，AI 带来了一个新问题：这种模式能够支撑的规模上限，是不是比过去高得多了？我还不确定。我仍然认为，工程师的注意力会先于他们编写代码的能力耗尽。
10 好产品背后，往往有一个敢于做出不受欢迎决策的人
Gergely Orosz：说到长期稳定、具有高度主人翁意识的团队，我最近还想到了一个例子：Slack。
现在市场上有 Google Chat、Mattermost、Microsoft Teams 和 Slack 等几款主要的团队协作产品。如果你让 AI 复制一个 Slack，它完全可以照着 Slack 的界面做一套出来，或者直接寻找现成的开源项目。
但有意思的地方在于，Slack 背后存在大量从来没有被完整记录下来的产品决策。这些决策涉及并发处理、消息送达、不同平台之间的兼容性，以及各种细节问题。Slack 内部的工程师知道为什么要这样设计，因为他们花了很多年才逐渐积累起这些经验。当然，如果你自己开发一款类似产品，随着业务规模不断扩大，你最终也会遇到这些问题，并且不得不重新摸索解决方案。
但我们先不讨论这些基础能力。最近，Slack 推出了 Slack Agents，把编程 Agent 很好地集成到了 Slack 的工作流程里，让 Agent 能够直接在 Slack 中执行任务。这个功能的体验非常好，整个集成明显经过了认真设计。你能感觉到，背后是一支对产品领域非常熟悉的团队，而且他们显然已经和相关合作伙伴进行了大量幕后协作。
这让我开始思考：为什么其他竞争对手还没有推出类似的东西？Google Chat 同样拥有非常优秀的工程师，其他几家公司也都有熟悉自己产品领域的团队。但至少从我看到的情况来说，它们似乎还没有做出相应的回应。
AI Agent 已经出现一段时间了，可 Slack 不仅做出了反应，还推出了一个客观上相当出色的产品功能。当然，现在其他公司完全可以模仿它。但问题是，Slack 为什么能够率先做出来？
我开始意识到，Slack 内部那些长期负责产品的员工，可能确实创造了非常大的价值。我敢肯定，如果我们知道 Slack 究竟雇用了多少人，可能会感到震惊。就像我以前在 Uber 工作时，外界也经常会问：“Uber 为什么需要这么多人？”
但这些员工的价值，并不只是维持现有系统的正常运行。他们还在不断思考，当外部世界发生变化时，客户接下来会需要什么，并且持续重新设计自己的产品。
相比之下，其他竞争对手似乎没有及时回应这轮 AI Agent 带来的变化。Slack 不仅回应了，而且做得很好。现在这个功能已经摆在那里，所有竞争对手都可以复制。但 Slack 究竟是怎么走到这一步的？
Will Larson：我记得有一篇论文研究过大英帝国的官僚体系。很有意思的是，即使帝国统治的领土不断缩小，官僚机构中的人数却仍在持续增加。公司其实也有类似的倾向：随着时间推移，组织会不断膨胀，增加管理层级和各种额外的流程。有些公司发展到最后，甚至已经丧失了快速行动的能力。
但我的一个判断是，当一家大公司推出真正出色、令人眼前一亮的产品时，背后往往有一两个被充分授权的人。他们与创始人、CEO 或高管团队有直接联系，能够推动项目落地，也敢于做出一些不受欢迎的艰难取舍。
这些取舍可能涉及法务与业务之间的冲突，也可能是产品方向上的权衡，甚至意味着打破公司内部那些长期以来被视为不可触碰的规则。
我猜 Slack 的情况可能也是如此。它背后应该有某位高层在支持这个项目。我知道，很多人不喜欢把成功过多归功于高管，但我确实认为，如果想让团队突破现有规则、完成一件困难的事情，高管的支持和授权非常重要。
举个我们自己的例子。大约三四个月前，Imprint 决定把项目管理工具从 Jira 迁移到 Linear。整个迁移过程不到四周。当初我决定做这件事时，几乎没有人觉得这是个好主意。公司大约有 230 人，支持这个决定的可能只有三个人。但我还是坚持推进了。
为什么要迁移？因为我们需要一套集中统一的任务管理系统，让 AI Agent 能够知道任务在哪里、获取任务并执行，同时把不同来源的任务统一管理起来。之前使用 Jira 时，我们很难有效管理这些任务和工作负载。
最终，我们不到四周就完成了迁移。现在大家都很高兴做了这个决定，之前困扰我们的很多问题也得到了解决。但在迁移之前，绝大多数人根本不相信这会是个好主意。
有时候，确实需要有人愿意承担风险，顶着反对意见把事情推进下去。不过，这件事还有另一面：既然高管有权要求整个组织承担风险，那么我们也必须根据这些决策的结果来评价他们。
迁移到 Linear 三个月后，已经没人再提 Jira 了。至少没有人对这次改变感到不满，大家反而很满意。但如果结果完全相反，所有人都讨厌 Linear，那他们就应该联合起来要求解雇我。
问题是，现实中很多高管并没有真正为自己的决策承担责任。这就是高管拥有充分授权的另一面。一方面，他们可以推动团队做出伟大的产品；另一方面，我们有时也会放任他们做出极其愚蠢的决定，却没有让他们为此付出代价。
11 从工程师到 CTO：过去的晋升路径出了什么问题？
Gergely Orosz：这正好引出了我想讨论的下一个话题：高管。你自己担任过 CTO，也就是公司高管。我想请你谈谈，在你看来，高管究竟意味着什么？今天，一名普通工程师如果想走到那个位置，应该经历怎样的职业发展路径？比如，一名工程师可能会想：“我喜欢高管这个角色，可以做出重要决策，包括那些不受欢迎的决定，还能够帮助团队和公司取得成功。”那么，过去从工程师走向高管的路径是什么样的？现在有没有发生变化？
Will Larson：过去的路径大致是这样的：你先做几年软件工程师，这个阶段可能相当短。然后转向管理岗位，一路在中层管理体系里晋升，最终成为 CTO。
Gergely Orosz：也就是从工程经理，到高级工程经理，再到总监。
Will Larson：没错。但我认为，这条路径存在很多问题。
首先，它意味着那些最早被选拔进入管理岗位的人，往往并不是最专注于技术工作的人，因为他们当时的目标就是获得管理岗位的晋升机会。接下来，随着他们不断向上晋升，组织会越来越倾向于选择那些擅长在管理体系中运作的人。而这种能力，与技术能力并没有必然联系。当然，有些管理者的技术水平也非常出色，但整个晋升体系并没有特别强调技术能力。
但话说回来，要成为一名真正优秀的高管，你确实必须善于处理组织管理中的各种官僚事务。这也是一个很有意思的矛盾。比如，我现在有大量工作都与激励机制的设计有关。我需要能够预判：“如果我们推出这样一套绩效考核制度，它会在哪些地方出问题？员工会怎样应对？最后会产生什么意料之外的后果？”然后，我可能会得出结论：这套制度根本不应该推行，我们应该采用另一种方案。
所以，如果你没有长期在管理体系中处理这些问题的经验，没有真正经历过组织运作中的各种复杂情况，你实际上很难管理好一个完整的职能部门。因为管理一个部门，很大一部分工作确实就是处理这些组织和流程问题。
Gergely Orosz：所以，你必须先学会成为一个优秀的“官僚”。
Will Larson：我自己就是这么一路学过来的。或者说，当时的环境逼着我必须学会这些事情。
在 Uber，我们几乎没有成型的招聘评估标准，也没有结构化的面试流程。至少在我工作期间，工程团队的面试应该怎么组织、怎么评估候选人，都需要我们自己摸索。而且当时招聘量非常大。每次面试完一个人，最后却没有发出 Offer，我都会觉得特别痛苦，因为我们已经投入了大量时间。所以，我必须想办法改进整个招聘流程。
后来到了 Stripe，情况就不一样了。Stripe 是一家组织流程更加完善的公司，已经建立了大量结构化的管理制度。我参与了其中很多流程的设计和改进，也从中学到了不少东西。
Gergely Orosz：你相当于被卷入了这些工作，然后逐渐掌握了其中的门道。
Will Larson：完全正确。而且我刚加入 Stripe 时，觉得很多现有流程其实并不好用。公司增长得非常快，所以我花了不少时间去调整和改进其中的一些环节。回头来看，正是这些中层管理岗位上的经历，让我学会了如何成为一个优秀的“官僚”。而这确实是成为一名高效高管所需要的能力之一。
你必须知道什么样的流程有效，什么样的流程只会制造麻烦；什么样的激励机制能够发挥作用，什么样的机制会产生反效果；以及什么样的组织结构能够支撑业务发展。
有一本书叫《Seeing Like a State》（《国家的视角》），作者是 James C. Scott。我觉得，在硅谷工作的人似乎都应该读过这本书。它讨论的是国家如何看待和管理社会，以及这种视角怎样影响政策的制定与执行。企业管理其实也有类似之处。如果你从来没有做过这些组织管理工作，就很难理解管理体系是怎样运转的，也不知道应该如何从组织管理者的角度看待问题。但反过来，如果你只会处理官僚事务，却不知道实际工作是怎么完成的，不知道软件究竟是怎么开发出来的，那同样非常危险。
Gergely Orosz：我确认一下，你的意思是不是：一名优秀的工程高管，无论是工程副总裁（VP of Engineering）还是 CTO，都需要同时具备两种能力。一方面，他必须非常懂技术，理解软件是如何开发出来的，必要时能够亲自动手，甚至始终保持一定的技术实践；另一方面，他又必须善于管理组织，懂得如何建立流程、设计制度和协调资源。
但如果沿着传统的中层管理晋升路径一路往上走，可能会出现一种情况：这个人最初就不是特别优秀的技术专家，或者在不断晋升的过程中逐渐脱离了技术。最后，他成为了一名非常出色的组织管理者，却不再真正懂技术。
反过来，如果你让一名技术能力特别强的工程师直接成为高管，比如明天就让他去一家创业公司担任 CTO，那么恭喜你，他很可能完全不懂如何管理组织。
Will Larson：我觉得你理解得完全正确。这也是为什么我认为，高管是一份非常困难的工作，通往高管岗位的职业路径也很难走。尤其是在 2010 年代，你必须经过一层又一层的中层管理岗位，才能逐渐学会如何管理复杂的组织。当时，这几乎是获得大规模组织管理经验的唯一途径。
但现在，这些中间层级正在逐渐消失。与此同时，高管工作的另一半能力却变得越来越重要：做出更好的决策、真正理解产品和业务，以及理解软件是如何开发和交付的。过去一段时间，这些能力反而没有得到足够重视。
所以有人问我，现在成为高管究竟更容易了，还是更困难了？
我觉得很难简单判断。只是今天想要学会管理复杂组织，变得更加困难了。
我知道，“官僚”这个词听起来有些负面，但真正学会如何管理一个职能部门，是非常困难的事情。到了 C-level 高管这个层级，你往往需要同时管理三四个不同的职能部门，其中可能还有你自己并不熟悉的业务。
比如，过去一年中的大部分时间，我在 Imprint 还负责客户运营团队。我对这项工作有一定了解，但远远谈不上精通。好在我们有一位非常出色的负责人，不过我仍然必须学习如何管理这个部门。
类似的事情我经历过很多次。在 Stripe，我曾经负责支持工程团队，也负责过数据工程团队，而这些都不是我自己长期从事过的工作。
当你不得不管理一个自己并不熟悉具体业务细节的部门时，就必须学会另一套管理方法。但现在的问题是，越来越难找到能够让你积累这种经验的岗位。
另一方面，今天的工程管理者却有机会在更长的职业阶段里保持对技术细节的深入理解。
所以我认为，未来最优秀的工程高管，很可能来自那些仍然深入一线的工程经理。 因为传统的中层管理晋升体系，过去一直在筛选另一套完全不同的能力。
至于怎样才能同时获得这两种能力？现在非常困难。但过去也一样困难，只是难的地方不同。
12 中层技术经理要么重新学技术，要么考虑退休
Gergely Orosz：那你怎么看待中层管理岗位的未来？你是否同意，中层管理正在慢慢消失？
Will Larson：现在确实是中层管理者非常艰难的时期，尤其是那些在 2010 年代成长起来的人。当时，他们是按照另一套标准被选拔和培养的。那套标准强调授权、赋能，以及如何通过组织流程来管理团队。但现在，企业开始说：“我们不想要这些东西了，也不需要这么多这样的管理者。”
于是，你可能已经沿着这条职业道路走到了相当高的位置，却发现自己无法继续晋升。因为下一个层级需要的是另一套能力：更深入地理解实际工作，能够亲自参与执行，掌握具体的技术和产品细节。而这些能力，恰恰是过去的管理体系长期不太重视的。
最令人沮丧的是，你一直在按照公司要求的标准发展自己，结果走到一半，评价标准突然变了。很多中层管理者现在就被困在这样的处境里。
至于未来会怎样培养出新一代高管，我也没有明确答案。但成为高管一直都不是一件容易的事情。
Gergely Orosz：说到这里，我想请你给两位工程管理者一些建议。他们都向我咨询过自己的职业发展问题，我把他们的情况介绍一下，你可以判断他们面临的是不是同一种困境。
第一位是一家公司的工程负责人，手下大约有七名直接汇报的员工。他看到中层管理岗位正在发生的变化，开始担心自己的未来。第二位也是工程负责人，向他汇报的有三名工程经理（EM）和三名个人贡献者（IC），他本人则向工程副总裁汇报。他一直在推动部门的 AI 转型，也承担了其他一些管理工作。工程副总裁对他的表现很满意，但他仍然处于副总裁之下的管理层级。
这两个人都在问：我是不是陷入了某种职业困境？他们原本的晋升路径都很清晰，下一步应该就是工程副总裁。但在目前的公司里，这个机会显然很难出现，甚至根本不太可能。你有这么丰富的管理经验，会建议他们采取什么行动？
Will Larson：对中层管理者来说，现在确实是一个艰难的时期。这类岗位的竞争也越来越激烈。但就我个人而言，重新回到软件开发的具体工作中，是一件让我非常有成就感的事情。
我离开 Carta 时，管理的团队大约有 250 人。而我刚加入 Imprint 时，负责的团队只有大约 25 人。对我来说，这恰好是一个重新学习技术、更新自己能力的难得机会。
如果你现在还在管理岗位上，我认为你只有两个选择：要么重新深入技术细节，要么接受一个现实——三年之后，你所熟悉的那套职业能力可能已经不再被市场需要。
所以，你必须认真考虑一个问题：我是现在退休，还是重新学习？
我自己也思考过这个问题。我完全可以选择就此退出，不再继续工作。我也问过自己，这是不是我真正想要的生活。但答案是否定的。我仍然非常希望参与这个行业的发展。而且我真心相信，过去一年里，我们的工作方式已经发生了根本性的变化。当然，并不是所有公司都完成了这种转变，还有大量企业需要很长时间才能跟上。但至少在我工作的环境里，变化已经非常巨大。而对我个人来说，现在的工作反而比过去有趣得多。
所以，我给这些管理者的第一个建议是：你必须愿意接受职业上的后退，或者横向转岗。市场需要的能力已经发生变化，你必须愿意换一种方式看待自己的职业发展。
比如，重新回到一线工程经理岗位，可能比继续留在中层管理岗位更有学习价值。现在，一线工程经理和工程师能够使用的工具已经非常强大。但如果你负责的是人员编制规划、绩效考核之类的工作，情况就完全不同了。坦率地说，这些领域的工具仍然非常糟糕。现有的大语言模型应用也没有很好地解决这些问题。
所以如果你一直停留在中层管理岗位，可能会错过大量正在发生的技术变化。如果是我，我会想办法离开这种状态。
举个例子。我在 Imprint 招聘过一些人，其中有一位叫 Jasmine。我们之前在 Carta 共事过，后来她加入了 Imprint。她入职时的头衔是副总裁，但实际负责的是直接管理一支工程团队。
Gergely Orosz：所以，她虽然是副总裁，实际上却在做一线工程经理的工作？
Will Larson：没错。她是一位经验非常丰富的一线工程经理，之前她还曾在 Mux 负责工程团队。现在，她重新回到一线，亲自参与了大量软件开发工作。这在 Carta 时几乎是不可能的，因为她根本抽不出时间写代码。而在 Mux，她同样忙于管理整个职能部门，没有时间深入具体的开发工作。但现在，她有机会重新做这些事情，而且做得非常出色。
那些愿意重新回到一线、亲自动手的人，现在非常有价值。如果你愿意接受这样的工作，一定要主动让别人知道。否则，招聘方可能根本不会考虑你，因为他们会觉得，以你过去的职位和经历，你肯定不愿意接受这样的机会。但如果能找到更多这样的人，我非常愿意继续招聘。
Gergely Orosz：这让我想起我们前面讨论过的一个现象。在 2010 年代，尤其是零利率时代，工程师似乎逐渐习惯了这样一种想法：公司和经理应该尽可能满足自己的职业发展愿望。比如，有人会说：“我只想做平台工程，不想做产品开发。即使公司现在需要我做产品，那也不是我想干的事情。”如果公司不能满足他的要求，他宁愿离职。有些人也确实这么做了。我在想，现在的管理者身上是不是也出现了类似的情况？
当然，我不想对刚才提到的那两位工程负责人做过多假设。但从更普遍的角度看，一些管理者可能会觉得：“我已经沿着这条职业道路走了这么多年，原本以为自己很快就能成为工程副总裁，我也希望继续朝这个方向晋升。”可问题是，行业现在还需要这么多这样的岗位吗？其他公司真的需要这样的管理者吗？
恐怕不是。现在企业更需要的，可能是非常优秀的一线工程经理。
Will Larson：没错。
Gergely Orosz：这和我们刚才讨论的工程师其实很像。我认识的那些最优秀的工程师，往往都愿意放下自己的身段。当公司告诉他们，现在更需要有人做产品开发时，他们可能会说：“我确实很擅长平台工程，但既然公司现在需要产品工程师，那我就努力成为最优秀的产品工程师。”
我觉得你自己的经历也是这样。你原来管理着一支 250 人的团队，无论薪酬、股权还是职位地位，应该都已经相当不错了。但你后来选择加入一家当时还没有那么出名的创业公司，接手一支规模小得多的团队，承担的管理职责也少了很多。某种程度上，你也是把自己的身份和地位放到了一边。而正因为做出了这样的选择，你反而学到了更多东西。
Will Larson：对我来说，加入 Imprint 在很多方面其实是一个更好的选择。我从来没有把它看作职业上的降级，因为这正是我当时想要的机会：重新深入技术细节，学习在今天这个时代应该如何开发软件。回头看我的职业经历，我一直是那种稀里糊涂被推上管理岗位的人。就像前面讲过的，当时公司需要一名经理，于是我答应了。
Gergely Orosz：结果你从那以后就一直被“骗”着做管理了。
Will Larson：没错。后来他们甚至让我当了总监，因为公司正在谈收购，需要组织架构里有一个总监，这样看起来更像样一些。但当时的我连一线团队都不知道该怎么管理，更别说担任总监了。他们只是需要在组织架构上有这么一个人。说起来还真是感谢他们。
所以，加入 Imprint 对我来说是一个难得的机会，而且正好符合我想做的事情。
不过，我也能理解很多管理者现在的感受。他们觉得自己被整个行业背叛了，觉得自己过去付出了那么多努力，理应得到相应的回报。而且他们说得没错。他们确实非常努力地工作了很多年。但问题是，规则已经变了。
有些时候，世界看起来非常稳定，我们所在的行业似乎也有一套明确、可靠的职业发展规则。尤其是在 2010 年代，我们几乎忘记了，科技行业其实一直是一个变化极其剧烈的行业。
回顾过去几十年，每隔十年，整个行业都会发生翻天覆地的变化。新的十年与上一个十年相比，往往已经完全不同。但在那段相对稳定的时期成长起来的人，有时候会忘记这一点。
所以，我认为我们必须愿意接受横向转岗，也必须保持一点谦逊。如果你仍然热爱亲自做技术工作，就应该愿意重新回到这些工作中去。
Gergely Orosz：那你怎么看 TLM（Tech Lead Manager，技术负责人兼经理）这个岗位？我们以前都认为，这是一条没有太大发展前途的职业道路。当时的 TLM 通常是技术负责人，同时还要管理一支规模很小的团队。在零利率时代，我们都明确表达过，这样的岗位很容易让人陷入职业发展的死胡同。我记得你还专门写过一篇文章，提醒工程师这可能是一个陷阱。现在你怎么看这个岗位？
Will Larson：这就很有意思了。它依然是个陷阱，但现在却是一个需求非常旺盛的陷阱。而且在很多情况下，你已经没有其他选择了。所以与其说它是陷阱，不如说它正在成为企业实际需要的一种岗位形态。
现在很多公司的管理层级正在被压缩。我观察到，企业大致在尝试两种不同的组织模式。一种是继续保留工程经理，但让他们管理更大规模的团队。过去一名工程经理可能只管理四到八个人，现在可能要管理十二三个人，甚至十四个人。这样一来，他们实际上比过去更难亲自参与技术工作，因为管理职责变得更重了。另一种模式是，由工程总监直接管理多名 TLM，而不再通过传统的一线工程经理来管理团队。
不同公司正在尝试不同的做法，但我认为，这两种变化都反映了当前企业对工程管理人才的新需求。
我们在 Imprint 招到的一些最优秀的人才，恰恰来自过去那些比较纯粹的管理岗位。他们加入之后，非常希望重新参与软件开发，而且在同时承担管理和编码工作方面表现得非常出色。
当然，这样的人并不好找。你几乎需要先按照优秀工程经理的标准来面试他们，然后再判断：如果没有足够多的机会亲自写代码，这个人会不会感到不满？我们真正想找的，就是那种不写代码反而会觉得难受的工程经理。
但这种人很难通过传统的招聘流程筛选出来。至少到目前为止，我们还没有建立一套特别有效的方法，只是幸运地找到了几位非常优秀的人。不过，这确实是我们非常希望招聘的角色。
这又回到了前面讨论的那个问题：我们希望找到那些有能力处理复杂管理事务，却并不热衷于做这些事情的人。他们具备管理组织、建立流程和协调资源的能力，但并不希望把全部时间都花在这些工作上。我发现，现在最有效的工程管理者往往就是这样的人。他们在需要的时候能够处理管理问题，但平时更愿意亲自编写软件。因为在今天，软件开发仍然是他们能够创造大量价值的地方。
13 “我花了 20 年建立写作声誉，为什么要用 AI 垃圾内容毁掉它？”
Gergely Orosz：最后，我想聊聊你的写作。你一直是一位非常出色的作者，我也一直很喜欢读你的博客。每次有新文章，我都会去看，还订阅了你的邮件更新。我很好奇，你是怎么理解写作这件事的？又怎么看待 AI 写作？现在越来越多人开始用 AI 生成内容，不只是 LinkedIn 等社交平台上的帖子，一些原本坚持自己写作的作者，也开始尝试让 AI 参与写作了。
Will Larson：我已经在网上写了将近 20 年。2007 年，我创办了自己的博客 Irrational Exuberance。我记得可能是在那年的五六月份开始写的，所以现在距离 20 周年已经不远了。刚开始写博客时，我的目的其实很简单，就是希望通过写作建立一些行业联系，最终找到一份工作。那时候，我写了大量技术教程，基本上就是告诉别人：“我是怎么把这件事做出来的。”但那是一个完全不同的时代。今天，如果你想知道怎么完成某项技术任务，直接问 AI 就可以了。它不仅能给你生成一篇很好的教程，甚至可能直接帮你把事情做完。
后来我去了 Uber，开始写一些自己在超大规模系统和工程组织中学到的东西。真正让我的写作产生更大影响的，是在 Stripe 工作的那段时间。Stripe 有太多值得学习的东西，而且整个公司都非常重视写作。这种氛围给了我很大的动力。后来，我把在 Stripe 积累的很多思考整理成了第一本书《An Elegant Puzzle》，也因此获得了更多关注。到现在，我一共写了四本书。未来至少十年，我可能都不会再写新书，甚至可能永远不写了。
但写作确实彻底改变了我的职业生涯。虽然认识我的人并没有那么多，但如果有人知道我，基本上都是因为读过我的书或者博客。我一直相信，写作是一种非常独特的方式，它让一个普通人也有机会改变整个行业的思考方式。
比如，你提出过薪酬的“三峰分布”（Tri-modal Compensation）这个概念。首先，这个名字就非常容易让人记住；更重要的是，你指出了一个很多人此前没有意识到的现象。我觉得，你改变了很多人理解薪酬和谈判薪酬的方式。Patrick McKenzie 关于薪酬谈判的文章也是如此。他的写作影响非常大，可能帮助世界各地的很多人获得了更多收入。我记得他好像还尝试统计过自己的文章究竟帮读者多赚了多少钱，不过不确定他现在是否还在做这件事。
至于我自己的书，我认为《Staff Engineer》确实对行业产生了一些影响。尤其是 Staff+ 这个概念，这本书帮助它成为了一个被广泛讨论的工程师职业层级。当然，我写过的其他一些东西可能没有那么容易被引用，但也产生了实际影响。无论我在哪家公司工作，都不可能仅仅通过自己的本职工作，以这样的规模、这样积极的方式影响这么多人。
Gergely Orosz：我记得读《An Elegant Puzzle》和《Staff Engineer》时，也从中获得了很多指导。
Will Larson：这就是写作特别有力量的地方。说到 AI 写作，我已经花了近 20 年、数万小时来积累自己的写作成果。我其实不是那种特别追求文字技巧的作者。相比于写出一篇文笔多么漂亮的博客，我更在意能不能把自己的想法表达清楚。
Gergely Orosz：这恰恰是我喜欢你文章的原因。你的观点总是非常有冲击力。我觉得你的写作水平不错，但吸引我的主要不是文字本身有多好读，而是文章里提出的想法。它们会让我停下来思考。我读你的文章时，关注的是你究竟提出了什么观点，而不是你用了多么精彩的表达方式。当然，你的表达也完全没有问题。
Will Larson：对，我的写作风格确实比较简洁。
Gergely Orosz：而且你有些文章非常短。我自己写文章通常比你啰嗦得多，这一点你应该很清楚。但你的文章不一样。如果一个观点只需要很短的篇幅就能讲清楚，你不会为了凑字数继续写下去。讲完了，就是一篇完整的文章。
Will Larson：所以，当我回头看自己写过的所有东西，以及那些我试图改变人们看法的观点时，我会觉得，如果现在开始用 AI 生成内容，就等于亲手毁掉这些积累。
我从来没有把博客当成一门需要不断扩大订阅用户规模的生意。我的想法一直很简单：如果你愿意读我写的东西，那就来读。这不像你的写作业务，需要考虑订阅和商业运营。但这些年来，我确实积累了一批读者，而这种影响力非常宝贵。我知道，如果我发表一篇文章，接下来的一周里，可能就会有数百家公司开始讨论文章中的观点。能够处在这样的位置，是一件非常幸运的事情。
如果我开始大量发布 AI 生成的垃圾内容（AI Slop），这一切可能就毁了。而且我再也不可能花另一个 20 年把它重新建立起来。
我花了将近 20 年，才一点点积累起今天的优势。为什么要亲手把它扔掉？所以，如果我没有什么值得说的，就干脆不写。我没有兴趣为了持续发布内容而硬凑东西出来。对我来说，如果毫无意义地毁掉这些积累，那会是一件非常痛苦的事情。如果放弃这些东西能够换来某种真正有价值的回报，我或许还可以考虑。但如果只是为了用 AI 多生产一些文章，那完全是得不偿失。
Gergely Orosz：我非常理解你的感受。对我来说，写作本身就是思考的过程。
其实，我以前很少谈自己是怎么使用社交媒体的。有时候别人会问我：“你的社交媒体运营策略是什么？”因为我现在有不少关注者。但这些关注者，更多只是我长期坚持做同一件事所产生的副产品。我每天几乎都在研究行业里发生的事情，和工程师交流，思考各种技术与职业发展问题。这些事情占据了我大部分工作时间，有时候几乎就是全职在做。
通常，我会先开始写一篇文章。在写草稿的过程中，突然冒出一个想法，于是我会打开另一个窗口，把这个想法发成一条推文，然后继续写文章。等我回头再看时，发现那条推文已经引发了不少讨论。可能是因为这个观点比较有意思，也可能是因为它存在争议。有时候，我甚至会故意把自己还没有完全想清楚的观点发出去，看看大家怎么回应。
我把这些东西戏称为“脑子里突然冒出来的屁话”（Brain Farts）。当然，这也不完全准确，因为我确实认真思考过这些问题，只是还没有形成特别坚定的结论。相比于推文本身，我其实更在意它能引发什么讨论。有时候，讨论会让我分心，但也会反过来帮助我完善想法。我的很多文章都始于一个观察：“这种变化真的正在发生吗？你们也注意到了吗？”然后，大家开始交流，我的想法也在这个过程中逐渐成形。
至于 AI，我记得前段时间很流行一种做法：把某位作者过去写过的所有文章都喂给 AI，做成一个可以和读者对话的机器人。有人甚至做过一个 The Pragmatic Engineer 的聊天机器人。我其实不太喜欢这个主意，但还是试用了一下。结果非常滑稽，因为我的观点一直在变化，我会不断修正自己对行业的判断，但那个机器人只会把我几年前说过的话重新吐出来。
比如，我们刚才讨论了 TLM。如果你做一个 Will Larson 机器人，它可能会非常肯定地告诉你：“TLM 是个职业陷阱。”但我们今天已经讨论了，这个问题其实复杂得多。
所以，我经常劝别人，不要把自己的表达完全交给 AI。尤其是在 LinkedIn 上，有时候我看到同行发布一篇明显经过 AI 润色的文章，或者有人私信我时，反而会用非常自然、真实的语气交流。我就会想：为什么不直接用你自己的方式写出来呢？哪怕不够完美，那也是你。
我喜欢真实的你，不喜欢那种被 AI 处理得干干净净、却毫无个性的文字。 而且我特别不喜欢 AI 写作的一点是，它让数百万人开始使用几乎相同的表达方式。原本，数百万人应该拥有数百万种不同的声音。
Will Larson：这让我想到另一个相关的问题。现在很多人相信，如果想在职业上取得成功，就必须持续发布内容。但他们自己其实并不喜欢写作。于是，他们会说：“我真的很讨厌写文章，但如果想获得晋升、找到下一份工作，我又必须建立个人影响力。那我该怎么办？”答案似乎很明显：用 AI。
但我一直想反驳这种想法。我以前写过一篇文章，标题好像是《如何成为科技行业的影响力人物》（How to Be a Tech Influencer）之类的。
Gergely Orosz：这个标题听起来有点标题党的味道，但我认为，它可能是我读过的关于如何在科技行业建立影响力的最好的一篇文章。这是我最喜欢的文章之一，我转发给过很多人。顺便说一句，谢谢你写了这篇文章。
Will Larson：谢谢。我写那篇文章，就是因为看到很多人觉得，自己必须写两三百篇文章，必须每周更新，必须不断发布内容，才能建立影响力。但如果你的目标只是让更多人认识你，那么你真正需要的，可能只是一篇能够引起广泛关注的好文章。你应该花大量时间打磨它，反复验证自己的观点，想清楚究竟什么值得写。
你根本不需要写那么多东西。除非你经营的是一门依靠订阅收入的内容生意，否则大量发布文章几乎没有什么特别的价值。如果你只是想传播自己的想法，让自己在行业里获得一点知名度，或者证明自己能够清晰、有逻辑地表达观点，那么你写两三篇文章就够了。甚至每两年写一篇，也完全可以。
比如 Tanya O'Reilly。她的博客更新并不频繁，但每次写文章，往往都有非常有意思的观点。其中最典型的就是《Being Glue》，那篇文章产生了很大的影响。她并不是靠大量发布内容建立影响力的，而是靠少数几篇真正有价值的文章。
即使是那些写作非常高产的人，读者最终记住的，也只是其中极少数几篇。所以我认为，如果大家能够重新想清楚自己写作的真正目的，就会发现：如果你只是希望建立一点行业影响力，那么一两篇真正出色的文章，远比大量普通文章更重要。
我真希望那些并不喜欢写作的人，能够停止为了数量而不断生产内容，因为这根本无法帮助他们实现自己的目标。过去一年，我面试过一些候选人。他们在网上发布了大量明显由 AI 生成的低质量内容。坦率地说，这会让我对他们产生很大的疑虑。
因为我会想：你写了这么多东西，根本没有人在看，也没有人回应，但你为什么还在继续？为什么要持续做一件明显没有产生任何效果的事情？
这就像一个人只会照着菜谱做饭，却从来不尝自己做出来的东西究竟是什么味道。这是一种典型的盲目模仿（Cargo Culting）。他们只是照着别人成功的表面形式去做，却根本不理解自己为什么要这样做。
所以，对我来说，这种行为体现出的反而是判断力不足。我不会因此觉得：“这个人真有上进心，真努力。”恰恰相反，我会怀疑他是否有能力判断一件事情到底值不值得继续投入。
Gergely Orosz：最后一个问题。有没有什么书是你特别推荐的，或者最近读过觉得很有收获的？
Will Larson：首先，我当然会向所有喜欢花钱买东西的人推荐我自己的书。我去年出版了《Crafting Engineering Strategy》。还有一本对我影响非常大的书，就是刚才提到的《Seeing Like a State》。坦率地说，这本书很大程度上塑造了我对管理和企业组织运作的理解。虽然它本身并不是一本企业管理书，但它提供了一套非常有用的思考框架。
总体来说，我特别推荐那些能够迫使你换一个角度思考问题的书。比如，前几年我花了不少时间研究类型系统（Type Systems）。这里说的不是键盘打字，而是编程语言中如何设计更好的类型系统。这件事与我日常工作并没有特别直接的关系，但我仍然觉得很有价值。
还有一本非常好的书，是关于 TLA+ 的，我一下子想不起书名了。
Gergely Orosz：是 Hillel Wayne 写的吗？
Will Larson：对，就是他。
Gergely Orosz：他之前也来过我们的播客。他写的《Practical TLA+》很有名。（编者注：《Practical TLA+》由 Hillel Wayne 于 2018 年出版，介绍如何利用 TLA+ 形式化规约与模型检查，在软件实现前发现设计缺陷，尤其适用于并发和分布式系统。）
Will Larson：非常棒的一本书。虽然我在日常工作中并不经常使用 TLA+，但书中讨论的思想非常有力量：如何借助形式化语言，提高软件的可验证性。而这恰恰是我们这个时代面临的一个重大挑战。如果未来越来越多的软件都由 AI Agent 来编写，那么如何以更低的成本验证这些代码是否正确，就会变得极其重要。
即使 TLA+ 在很多情况下并不是最合适的工具，思考这类问题本身也非常有价值。这也是为什么我觉得类型系统如此有意思。所以，这些是我最近比较推荐的阅读方向。
Gergely Orosz：谢谢你，Will。今天终于有机会和你好好聊这么久，真的非常开心。
Will Larson：我也很开心，谢谢你邀请我来。
播客原链接：
https://newsletter.pragmaticengineer.com/p/the-revised-rules-of-engineering
声明：本文为 InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。
热门跟贴