Will Larson：工程管理的修订规则

冷开场里，Will Larson 点出 2010 年代工程管理最糟的一课：一旦进了经理行列，别人就告诉你，从此再也不要做技术决策。今天的风气不是这样。同样让他烦的，是 staff 工程师原则上就能做有趣、对自己有回报的问题。他手下最好的一些工程师想要更有意思的工作。他告诉他们，自己能给的只有苦活，而正是这些苦活会让生意成。

有人在问，中层管理是不是职业陷阱。Larson 说，待在那里的日子很难过。他自己觉得有回报的，是重新扎进写软件的细节——这是一次少有的重新学手艺的窗口。如果你现在在做管理，他认为要么回到细节里，要么就别回了。

Gergely Orosz 介绍 Larson，说要谈工程管理怎么变了，他是最好的对话对象之一。他做了十年工程高管，跨过四家公司，写过工程领导和 staff-plus 层级里读得最广的几本书。Orosz 说，他在这件事上想得很深。

这期讲的是：零利率如何塑造了十年已经不再管用的管理习惯；为什么解决生意真正在乎的问题更重要；以及为什么一线经理往往比中层更适合当工程高管。如果你是工程师或经理，想弄清掺进 AI 之后职业长什么样、通往 CTO 的路现在怎么走，这就是那场对话。

广告之后，Orosz 欢迎 Larson。两人做写作者已经认识多年，也一起待过，但这是第一次当面录。Orosz 想从开头讲起：Larson 是怎么对计算机产生兴趣的？

从五岁起家里就有一台 Mac IIci 这一档的机器——不是最早那批，但很基础。四岁半的孩子能搞懂的，只有 Kid Pix，一个画方块、圆圈和小图形的儿童画图程序。那时谈不上互联网，也没法查东西，所以你就对着机器敲，直到它听话。Larson 说，这到今天仍是写软件的根本。

那时除了多人地下城，他没怎么写真正的软件。Orosz 从没玩过 MUD。Larson 解释那是文字游戏——后来 World of Warcraft 给这套想法加上了画面。高中的路径是 IRC、mIRC，以及带大量正则触发器的 MUD 客户端。正则表达式就是在那儿学会的。认真写软件，要到大学才开始。

进大学时他不知道该学什么——物理、英语，或者经济学，最后这个是因为父亲是经济学教授。他在肯塔基一所小型私立学校里掉进了计算机科学。毕业那年整个专业大约十三人，他那一届毕业四个。入门 CS 课是随机抽到的毕业要求，旁边还有一门基督教史。他更喜欢 CS。

那时就已经打算当职业程序员了吗？Larson 谈职业路径的要点是：名校是电梯。在 Waterloo，学校把学生辅导进软件工作，他们交换面试答案，还有好几年 coop。MIT 和 Stanford 也一样：留在项目里，它就带着你走。那些学生很优秀。可那仍然是电梯。

一年只出四个 CS 毕业生的学校，没有这种路。高一届一个很能干的人，去了肯塔基州 Lexington 写赛马投注软件，公司大概五个工程师——因为他们会找的就是这个。Larson 不确定自己会做什么。他参加 JET Programme 去日本教了一年英语，地点是岐阜县一个偏僻的地方。

大量写作是从那时开始的。他很确定一年合同之后不会再当英语老师，做满一年，对续约没兴趣，回来就想从那儿挤进硅谷。Orosz 问，为什么那时候就已经是硅谷，硅谷当时又是什么样。

起初 Larson 甚至不知道硅谷是什么。他想要一份薪水不错的工作。2007 年毕业，第二年教英语，大约 2009 年初进 Yahoo。起步是东海岸的远程承包，因为写过一组关于 Yahoo BOSS 的博客——Build Your Own Search Service，一个业界没什么水花的产品。

BOSS 上线时他写得很勤：三四篇用 Python 和 Django 调用它的教程，还包括一个搜索库，名字大概叫 Django Springsteen。Yahoo 很兴奋，居然有人在写它。合同就是这么来的。承包满一年必须转正式，转正式就得搬家。

他会变成承包，是因为金融危机之后长达一年的招聘冻结。Yahoo 一轮轮裁员：可以招几个承包，不能招正式员工。到十二个月，合规说要么转正要么走人。转正就得搬。所以搬去加州就有 Yahoo 的工作，不搬就没有。除了要有份工作，他没什么牵挂，于是搬了。

Orosz 说，Yahoo 相对 Google 已经在走下坡，但仍然是家有真本事的公司——WhatsApp 创始人就出在那儿，这事很有名。Larson 觉得 Yahoo 是家值得弄懂的公司。如果你 2007、2008 年进科技圈，开源已经让很多事变得容易。Yahoo 比那些库更早。

2007 年在 Yahoo 怎么跑一台服务器？跑 YApache，他们自己的 Apache 分叉。上面跑 YPHP，他们自己的 PHP 分叉。UI 库是 YUI。安装是 Yinst，一段 Perl 脚本去走依赖，别处用 apt 做的事。那是个节奏很快的地方，但每一层都是他们从零做的。他们甚至有 Kafka 的前身，大概叫 YRepl，一种数据库外的读日志复制工具，是管状态的核心。

他最喜欢的 Yahoo 故事：创始人之一 David Filo，出了名地要审批公司里分配出去的每一台服务器。理论是问责——你得证明自己需要更多机器。实际催生的是黑市。Larson 那组里，一个工程师手里还剩一个取消项目留下的三十台服务器，批不下来的人，他就拿人情和欠条当钱，把机器卖给你。

结果是大批过时、耗电的服务器，从来没人还回去。要上一个项目，就得找到一个喜欢你、手里有闲机器的人。这是关于激励如何催生荒唐局面的一堂很生动的课。Orosz 觉得 Larson 后来做工程负责人时一定还记得。Larson 好奇 Filo 知不知道这个黑市。他猜知道。自上而下的命令并没有改。

离开 Yahoo 他去了 Digg，当时是家有名的创业公司，后来的故事更有名。叙事因人而异，但 Larson 的版本是：Reddit 起来之前，Digg 是那个大型社区站点。Reddit 有子社区，用算法投票。Digg 的首页是中心策划的：质量稳定，少了 subreddit 偏见的问题，换成了中心审核的问题。

有 IRC 频道里，人们拿人情换故事上 Digg 首页。Digg v4 改了算法，有人跟他说会杀了他，因为抢了他们的生计——他们的生意就是卖那个首页的入口。新算法不支持这一套，他们是在字面意义上威胁生命。Digg 当时仍然重要。有一阵它是前十的网站。

他进 Yahoo 的时候，那个网页时代已经在褪，但再早一点，连 Yahoo 首页上的 Yahoo Sports 都还是 NetScaler 上的一个静态文件。Digg 起步就是那种重要的静态页，后来变成动态社区。后来重启过几次，再也没找回流量。Orosz 记得它是前十，所以重写的故事才这么难忘。

从外面看，Digg 仍然受欢迎，抱怨有点像多年后的 Stack Overflow。然后它做了一次大规模重写，灾难随之而来，成了个很刺激的故事：社区很生气，还有点幸灾乐祸，觉得 Digg 搞砸了、活该。Orosz 想听内部的说法，因为是 Larson 在做这件事。

Larson 赶上了上线，也赶上了上线之后。他大约在 v4 发出前三到六个月加入。他入职前那个周五，CEO 被拿掉，创始 CEO Kevin Rose 回来了。他们有一个硬期限，必须上线 Digg v4，一次重写。Digg 3.5 是 PHP 加分布式 MySQL，跑在他们自己拥有的托管机房硬件上——不是能随手拉起来的东西。

V4 想解决好几个问题，但首先是互联网在变。曾经的前十站点正在把流量输给 Facebook，搜索流量也在丢。Google 的算法变化——Panda 之类——正在重塑流量怎么走。对 Digg 来说，Larson 想说大约 60% 到 70% 的流量是从搜索进永久链接页的。

永久链接是 Digg 把别人一篇很棒的博文复制过来，再加一个指向原文的小链接和评论。这些页面常常比源站排得还高。你可以争辩说不该这样；那是今天的看法。当时 Digg 在创造可发现性和对话，Twitter 还没起来，Facebook 也还没有可观的分发。广告也主要卖在这些页上。丢掉那部分流量，公司财务就在往下掉。

从外面看 Digg 像在运转，甚至像在增长。内部他们知道在缩。有过一个月漂亮的盈利，接着算法一变就打过来。那是生死问题。他加入时大约 110 或 120 人。那是 2010 年，融资轮次是一百万或三百万美元，不是 5 亿美元。就算 110 人也已经不小，剩余现金正在很快烧完。

上线在内部也很糟吗？外面的观感是糟透了，社区恨这次改动，深度参与的人不喜欢被打乱。Larson 提到当时有人画了一套精巧的四五集 Digg 对 Reddit 漫画，蓝对红，一场大战。热情很高。这就是热情社区的难处：你把它养起来，再改自己是什么，社区不喜欢。

像 Mr. Baby Man 这样的超级用户，自发给首页供稿的人，丢了自己的生意。上线糟糕有很多原因。首先是技术上没准备好。他们做了很激进的技术决策。Larson 大约三个月前才到，所以他不太揽责——那是他第二份工作，Yahoo 干了两年之后。职业生涯再往后，发生的任何事他都会认。这一次，他说，真不太算他的错。

他们上线在 Cassandra 上。当时的笑话是 Cassandra 是毁掉行业竞争的特洛伊木马，因为谁在上面上线，后来就完蛋。对 Digg，Larson 觉得这是真的。Cassandra 替换的是一套复杂但能跑的分片 MySQL。他会争辩说 Cassandra 基本上不能用。有个团队本该在上线前做负载测试。两天前，他和另一个工程师 Rich 被人拉到一边：负载测试从来没做过。

Rich 和他一样是软件工程师。他们装上 JMeter，试着搞明白。他们跟负责 Cassandra 这件事的 Chris 谈过。Larson 说他做不了读。Chris 说不是这样。他说他做不了写。也不是。然后：他在写的时候读不了；在读的时候写不了。这个，Chris 承认，是真的。两天后就要上线。他们还是上了，没修。

公司觉得自己在死。公司确实在死：钱快没了。那是 Larson 职业生涯里最有意思的一天。他大概早上 8 点到。Orosz 问有意思是不是等于压力大。Larson 让他自己判断。他们决定当天办上线派对。穿燕尾服的餐饮人员端着寿司托盘和香槟走来走去。整个办公室都在庆祝。

房间中央他们拉出一张大桌子，大概有他们现在坐的这张的三四倍，工程师坐在那儿。他们没有足够的硬件同时跑新系统和旧系统，而且硬件是自己的，所以在擦旧服务器、装新软件。回滚不了。派对有预算，多买服务器没有。

一台一台擦，一台一台拉起来，这东西功能上就是起不来。维护中的页面挂了大约 24 小时。香槟和燕尾服还在转。楼上有人在做按摩。某些组——不点名——在打乒乓，他们则在试着把站点拉起来。Larson 称之为魔幻现实主义：站点在崩，日常还在继续。Orosz 说这不是他想象中的上线。Larson 说，这种上线你想象不出来。

这也是他很自豪的一刻。他才到三个月。站点后来是起来了，但问题很多，人就放弃了。一天天有人不再出现。大概只剩六个人还在撑。头两天，还是那个 Rich 和 Larson，从零用 Redis 写了一套缓存，帮站点撑了好几个小时。内存泄漏仍然很大，每个进程一两小时就得重启。滚动重启是唯一能撑住的办法。

调试花了整整一个月。Larson 后来为此写过一篇博客。核心 bug 是给第三方用的 Python API 服务，写的人并不太懂 Python，去调另一层打 Cassandra 的 Python gRPC。当时 Python 里可变默认参数会留在内存里：如果你用 list 当默认值，再往里 append ID，之后每一次调用都还带着曾经传进来的所有用户 ID。内存一直胀，直到他们重启。

他们在中间加了 Memcached；Memcached 会倒，并把 Cassandra 一起拖倒。找到这个 bug 大约四周。找到之后，修起来很简单。站点起来了。一位新 CEO 几乎在 Larson 修好的同一天到任。然后整整一年，全公司被裁光。一场皮洛士式的胜利：它能用了，但你不能让一个中心站点难用或宕一个月。反事实是，留着旧站也会把他们杀死。他不知道他们是不是选错了。当时他对这件事相当火大。

Orosz 问 Larson 是怎么走进工程领导的。两人在 Uber 有一点点重叠，但从没一起做过。Digg 故事的结尾是拆成三块的收购。Digg 给信息流里的广告单元申请了专利——就是你现在在 X 上看到的那种看起来像原生内容的广告——还有更大一摊专利组合。一家公司买了专利。纽约的 BetaWorks 买了 digg.com 品牌，后来又转手。团队去了 Social Code，华盛顿邮报公司旗下、跟 Post 和 Kaplan 并列的子公司，做 Facebook 上的广告。

他待了几年。离开时他想做工程领导，但进不了大角色：他当时管大概十二个工程师，没人会雇他去做一份他还没做过的大工作。十五人创业公司的工程负责人，手下仍然只有五个工程师。规模不在那儿。他当时的想法——后来变了很多——是想要大团队，就得加入一家长得非常快的公司。环顾四周，那就是 Uber。

Orosz 把时间定在 2015 或 2016。Larson 说是 2014，增长刚刚起来，还早。你得在旧金山，才知道 Uber 做得那么好；消息 2015 年传开，2016 年已经全球都知道。Larson 知道，是因为 Digg 的基础设施工程师 Jeremy Grosser 走了，去了 Uber。Digg 做过几乎没别人用的工具。其中一个叫 Clustered，是给基础设施状态用的键值存储，有点像好几年后的 HashiCorp Consul。Larson 觉得用过它的大概只有 Digg、Uber 和 Second Life。

Grosser 把 Digg 的很多技术栈带进了 Uber，他是最早的基础设施工程师之一。他的团队在招人。Larson 一直是通才：Yahoo 招他做前端，他不太确定自己够不够格，后来在 Digg 做前端、Cassandra、后端，什么都做。Uber 雇他去管一个叫「SRE」的团队，其实就是基础设施，他们管这叫 SRE。入职前一周他读了一本 DevOps 的书——也许是 The Phoenix Project——想搞清这份工作是什么。Orosz 猜是 Google 的 SRE 书；Larson 觉得那本当时还没有。

面试很经典：白板上用 Python 做旅行商问题，这评估不了 DevOps 本事。公司招人有点急。他拿到了工作。加入时他管大约六个人，范围极宽。Uber 当时 2000 人、200 个工程师。这六人小组管数据库、Kafka，以及机柜上架之后的服务器——技术运维负责上架和安装——再加上服务开通。有一个两人的开发者体验团队。基础设施里其余的都归他们。

Orosz 想听领导路径：Uber 团队长到多大，然后是 Stripe、Carta、Calm。他加入时团队五六个人。两年后离开时是 70，全是外部招的。Uber 每六个月编制翻一倍。你没法从别的团队偷人；那些团队也在招，也忙不过来。招人是在 Uber 学会的。之前他完全不会。

一个他喜欢的：他们周五下午 4:30 给一个 Eventbrite 工程师发了 offer，对方周一早上 8:00 就来上班。不那么好笑的：有人面了 Uber 四次，被拒四次，Larson 看见他第五次在面。他说不能招这个人，别再浪费对方时间。那个团队还是发了 offer。候选人加入，六个小时内辞职，去了隔壁的 Twitter。他面 Uber 的时间，比在那儿干活的时间还长。

那两年范围涨了很多。今天有些公司让他想起当时的 Uber。他加入时，每个周五他们都在手工把软件在服务器之间重新分配，好撑住机群，因为周五高峰是一周的峰值。周六量可能更大，但摊在更多小时里，因为不是所有人同时下班。那是个很狂的地方。他待了几年。

然后是 Stripe，大约四年，2016 年到 2020 年初。再是 Calm，他第一份 CTO，大约三年半——一次有意的选择。Stripe 做得很好：他加入时估值 55 亿美元，四年后大约 960 亿美元。工作也顺利。和他同一天加入的人大约是第 500 号员工；离开时公司已经 1500 到 2000 人。他在的时候 Stripe 大约每年增长 70%，远低于 Uber 每六个月翻倍。Uber 后来收缩得更狠，是那种节奏的自然后果。

他担心自己全部积蓄都压在一家永远不会上市的公司里，他认为这一点后来也成立，所以部分是为了分散。也是想知道完全带队是什么感觉。在 Stripe 他始终离 CEO 一步：先向第一任经理汇报一年，然后向 David Singleton 汇报，对方以工程负责人加入，后来成了 CTO，一直到 2020 年初。他想要那个位子，也想知道自己能不能做得更好。从那以后一直是在受教育。

然后是几份 CTO：Calm 三年半，Carta 两年，大约一年或一年半前加入 Imprint，直到今天。Orosz 听他当了三次 CTO，想要一个心智模型：工程师会想象这份工作有一些管理，但 CTO 仍然技术、仍然靠近工作。当时怎样，现在又怎样，尤其是有了 AI？

2010 年代做工程经理最糟的部分之一，Larson 说，就是第一课：从此再也不要做技术决策。放下技术决策。那是当时的风气。今天绝对不是。他当时向往的是，CTO 是技术向职业和管理向职业汇合的唯一位置。

他一直相信、现在也相信，作为 CTO，工程经理和 IC 工程师都直接向他汇报。今天他有十四个直接下属；四五个人是 IC，其余是经理。很长一段时间里，许多管理岗位根本不让你当技术领导。爬到两条路重新汇合、又能同时领导技术和管理的层级，是很大一部分吸引力。

外面也有很多糟糕的 CTO 决策。他不是在说刚才点过名的那些人：David Singleton 尤其出色，Stripe 的决策质量总体很高。你可以不同意，但不能说某个判断完全说不通。离开 Stripe，他常常看到说不通的决策，就想也许自己能做得更好。

最近这个阶段他喜欢的是：你不只是可以再进细节——你是必须进。这是回到软件里最好玩的部分。他在 Imprint 一年半里做了 500 多个 pull request，全部进生产，比此前职业生涯加起来还多出一大截。挺酷的，也好玩。而且是以 CTO 的身份在做。

Orosz 问他在 Imprint 是不是不止当 CTO。他加入时是 CTO，现在还带产品和设计。产品、设计、工程向一个人汇报：统一的 EPD 结构。Orosz 这两三年常听到 CTPO——首席技术和产品官——现在设计也折进来。这是趋势吗？

Larson 不知道这算不算趋势。智能体进入主流的一个难点，是你得很快做决定：怎么做、怎么不做、产品和设计怎么采用智能体。如果设计不用新工具——Flow、Figma MCP 之类——他们就会变成瓶颈。那设计归谁？Imprint 一直在试，让开发者来做二线功能的设计。瓶颈解开了。也带来了谁负责的争执：工程师重新设计时错过了设计系统。

在剧烈变化的时刻，有一个能做这些权衡的统一节点，很有力量。他骨子里相信，行业在如何创造软件这件事上的变化，超过他职业生涯里的任何时候，而他是 2008 年底入行的。更早的变化更细，是文化或社会层面的。他创造软件的方式，跟一年前真的不一样。集中机制帮了忙。他本人不认为这是长期趋势。他尽量避免对遥远的未来下判断。一切都在大变。

又一段广告之后，Orosz 想回到做软件、带团队是怎么变的，从大约 2007 年到今天，硅谷这个泡沫仍然值得拿来说。Larson 第一份工作是 22 岁在 Yahoo 当远程承包。组里没有第二个人远程。转正式后经理没换。两年里，他跟那位经理只做过两次一对一。

Orosz 有过类似经历：没有真正的一对一，或者一年一次谈薪酬。晋升是「恭喜，你现在钱多了」。Larson 对超过两次没有任何预期。第一次是经理在旁敲侧击另一个员工的表现，不是给他反馈。第二次是他提了离职：怎么回事？那就是常态。

那位经理看这份工作的方式——Larson 觉得他做得真的很好——是去公司里找一个能让团队产生影响的机会，带回来，让团队去实现。完全没有他在帮 Larson 过上有回报的职业生涯这种想法。那跟他无关。这是 2010 年之前。

在 Digg，Larson 觉得经理基本上都被开了。他当上经理，是因为他是唯一傻到没说不的人。他当时有两年半或三年经验，对管理一无所知。在 Yahoo 他几乎没跟经理打过交道；技术负责人定方向，他搞砸了就会不高兴。那就是全部的领导模型。Digg 最后一年除了他几乎没有管理，而他不知道自己在干什么。

在 Uber 他学到很多，但人人都太忙，那儿也没有管理。沉下去或者自己游。决策做不对，周围的增长规模会把你的团队压垮。真的没有支持。Orosz 说，到 2017 年他当经理时，Uber 已经办了第一期学徒经理项目：一起几天，再配导师。大多数工程经理从来没有这个。Uber 做这个，是因为糟糕的经理正在变成大问题。

Larson 工作过的那个 Uber 极其短视。一个非正式价值观是自己解决：人们不会卡在别的团队上，他们直接自己做。Orosz 记得「让建造者去建造」「做主人不要做租客」，以及别求原谅、把事做完的精神。Larson 觉得那种没有依赖的文化让人有力量。你说自己卡住了，得到的回答是你没卡住，自己想办法。痛苦，但你永远可以负起责来。

他记得给 Uber 中国签采购单，别人谁也签不下来——一张几千万美元的 PO。他大概 27 岁。技术运维负责人 Amir 和他互相盯着，签了。他喜欢那个年代的 Uber 的一点是：从来没人跟进。从公司治理看大概不好，有点临时，但他们不挡彼此的路，也做成了了不起的事。那也是个极难待的地方。人会走、会 burnout，是有原因的。

他大约 2016 年到 Stripe。Stripe 出了名地也没有管理文化。他加入时大概三个经理。其中一个他很爱一起工作的，Raylene，直接下属在 40 到 50 之间，因为 Stripe 读过 Google 那篇几乎不要经理的论文。他们按那个模型走了很久。他是那波经理化里较早的一批。

经理一共三四个人：Raylene、Jorge，再加一两个。Jorge 管大约 30 人的团队，下面大概只有一个经理。Raylene 下面没有经理。混乱，但刚从 Uber 出来，他对混乱很熟，生意也长得很快。Uber 到 Stripe 这段，正是经理角色的文化转变开始坐实的时候：不是核心给予者或决策者，而是协调者。

他写 Staff Engineer（2021 年出版）的一个原因，是收集一起工作过的 staff 工程师的反馈。让他烦的是那种想法：staff 工程师原则上就能做有趣、好玩、对自己有回报的问题。那不是他需要的。他需要他们做生意和可扩展的问题。离开 Stripe 时他的团队大约 250 或 260 人。问题一大堆。最好的一些工程师想要更有意思的问题。他能给的只有苦活，可那苦活会让生意成。

怎么把他们拉回来？很多人觉得这违反了管理契约：经理的义务是给他们想做的有趣工作。十年前这听起来会很荒唐。他并不认为「有趣的工作」这个视角从来就对。真正资深的人，在 Stripe 和他工作过的每个地方，做的都是公司需要的有价值的工作。这种看法从没在高管层站住，但很多进来的人信这个。不点名，他们来的某些公司版本很强：对资深招聘，经理的义务就是给他们好玩的工作。行业在这件事上已经大幅回摆。

Orosz 问这是不是零利率现象。他写过，一个抽象的利率大概如何塑造了融资、招聘，以及没有商业模式却仍然拿到钱的创业公司——再往下，是软件工程师的原型、经理类型和管理决策。音乐大约 2022 年停了，效率变得更重要。很多人，包括他自己，都在问：那个年代做的每一件事，当时到底对不对。

Larson 问 Orosz 有没有读过 Ranjan Roy 的《ZIRP Explains Everything》。Orosz 很喜欢那些文字。Larson 一个后来招进 Uber 的 Digg 同事，和 Roy 一起写 The Margins。那篇文章很有共鸣。他确实觉得 ZIRP 解释了整个 2010 年代：管理风格怎么变、薪资怎么涨，以及招到、谈成、留住成了成功公司和其他公司的差异点，因为你就是留不住优秀的人。

那把筹码交回工程师手里，也造出了另一种环境。公司把自己包装得更轻松、更围着你转、更强调职业发展，常常是在拆自己的台。对 Google 福利文化有一种广泛的评判；他觉得除了也许 Google 和 Meta，没有哪家做得极好的公司有那种福利取向。抛开福利，还有很多别的方式，公司试图聚焦于有回报、有意思的工作。

一个例子：也许工程师不该 on-call——那是二线 SRE 的事。每个跟他共事过的人都知道，工程师为自己的工作 on-call，软件会更好。可公司仍然说，为了享受，让人别为自己上线的东西 on-call，去呼叫那些没参与创造的人。这种取向把优先级的转移暴露出来了。

Orosz 想，那是不是也是经理因为低流失、因为填满编制而受奖的时候。现在听着疯，但填满编制当时很难。一个带 30 人团队的总监可能拿到十个名额，还得是 senior 及以上，不要应届。填不满就算你的，或者名额给别人，可能帮对方晋升——四十多人你也许就能当总监。在那种环境里干得好的经理，多少有点讨好。他们开始把工程师跟业务隔开。

这种隔离后来反咬了很多人，因为现在期望工程师懂生意。你能在创业公司落地就跑，才会有人要。他仍然听到有人离开一家大型可观测性公司去七人创业公司，说糟透了，不让他们做事。那是家七人公司。你怎么会不问生意需要什么、然后去做？他们在别处浸淫了很久。

Larson 觉得激励是很大一块：填编制、管团队、员工问卷结果。那些工具有价值——他从中得到很多——可他记得在快速增长的公司里花很多时间用问卷分数分析经理质量。分数高或低，不等于经理好或坏。有上下文。你得问团队为什么不高兴。分数变成了目标，而不是解释机制，这在很多方面就是懒惰的中层管理。

他讨厌编制对话。那几乎从来不是最有意思的对话。在一个经理不能做技术决策的世界里，他们能用来执行得更快的杠杆，只剩编制或排优先级。Orosz 复述：常规智慧说不要做技术决策，于是精明的经理把精力放在非技术一侧，该做的技术判断投入不足，软的一侧加得过重，包括把团队跟业务隔开。Larson：百分之百。非常对。

他现在跟团队说，招人是解决每个问题最没意思的办法。他们几乎永远不该谈招人。推论是：如果你已经有空着的编制，要更多也不该是这场对话，因为要紧的是招聘吞吐——多要名额你也用不了。他们告诉经理不能想技术解法，那手里还剩什么？流程、排期，或者人。把两个角色劈开的自然后果就是这个。他不是说永远不该拆，但两边都需要有效的领导，否则人就会死盯招人，过去那些膨胀的组织很大程度就是这么来的。

Orosz 转到职业，从创业公司和中型公司的个人贡献者说起。以前有清晰的梯子——Eng 1、Eng 2、senior、staff——以及怎么晋升的清晰故事。Eng 1 和 2 写代码；他们现在更会架构了；人们在谈循环。我们还有职业阶梯吗？经理现在还该操心搭一个吗？

团队的预期当然是你该有阶梯。那种信念——Larson 觉得有研究撑着——是有量规比没有量规决策更公平。锚定职业阶梯这件事会留下来。没有阶梯，你就会低估维护、glue work、把人黏在一起的工作，高估碰巧奏效的闪光之事。他仍然信这个。阶梯上该写什么，就远没那么清楚了。

有咨询公司在小公司之间卖同一套打包好的梯子。那些已经很过时，下一版也还没有。他想今天的人怎么走到 staff 或 principal 时，一直在考虑给 Staff Engineer 加一章，大概未来十年某时会写。那真的是在复杂局面里做决策——穿越含糊。

Stripe 当时想做多区域。试图带这件事的工程师一直说，需要产品来决定跨区域复制怎么工作：在一致性和可用性权衡下支持哪些产品行为。他们想让产品团队做 CAP 定理决策。产品不可能做 CAP 定理权衡。那些工程师当时做的，是找一个卡住的办法。

你需要 staff 或 principal 做的，是靠做权衡来穿越含糊，建立确信，再用原型验证那些假设值不值得、能不能跑。即便有了智能体，这些含糊问题仍然是很强的标记。有些权衡，就像 Orosz 说的理解生意，来自产品含义：用户到底想干什么、产品的单位经济、服务成本、你收多少钱。你得相当宽。决策仍然是 staff 和 principal 工程师产生影响的地方。这一点没变。

他并不觉得智能体特别擅长这些权衡。它们常常连认都认不出来，因为不在上下文窗口里。它们把活在软件之外的隐含之事给定下来了。Orosz 问 Eng 1 和 Eng 2。一位资深工程师跟他说，写代码这件事上 AI 显然已经赶上 Eng 1 和 2，而这正是那些角色很大一部分用途，有人仍然会走到 senior，但不是现在。在 Larson 的组织里，他怎么看待应届和还没到 senior 的人——判断力还不能完全信任、无论招还是培养？

他尽量远离他所谓的人为精确。Eng 1 和 Eng 2 的差别到底是什么？真要说得很具体其实很难。很多公司成功地用三年工作经验来区分。这公平吗？他不确定有没有特别公平的办法。特别差的 Eng 1 你认得出。特别好的 Eng 1 对上 Eng 2，常常是在岗时间、攒了更多上下文。不是他们能不能做某件具体的事，尤其有了编码 harness：他们什么都能做。该不该做，越来越难判断。在方向给得很足的局面里，你甚至感知不到他们的判断力。

细微分法他听得越来越少。时间和层级对很多这类事大概就够了。把标准写到极细是一种假胜利：你让它精确了，但你也进过校准会，看着有人玩量规。有家公司 staff 有带教要求，于是有人出去跟某人聊一次，就把对方报成 mentee。去问那个人，对方不知道为什么有人来找他聊。你衡量什么，就得到什么。

晋升从来都大量依赖判断。你一试图拿掉判断，结果也好不到哪去。用来给人指路的量规有用；归根结底相当主观。对很多这类事，约束比用来做判断的完备量规更有意思。Carta 当时成本压力很大。他有一个比例：staff 工程师相对其余人不能超过这个数。不可能突破。这惹恼了很多人。

他觉得这更诚实地对应十五年前行业的位置：当时多数公司 senior 之上没有角色。Senior 真的是终点职级。随着人们走得更远——二十年、三十年、四十年的软件经验——公司开出了更多层级。那些层级很多是在岗时间的头衔，而不是能力上显而易见的变化。他尽量少为细节操心。一比八之类的硬上限，如果你要管的是成本，真的很有用。管成本的时候，你得诚实承认自己在管成本。那就是 Carta。

在 Imprint 他们不是在管成本，是在管速度和质量，所以比例想都没想过。领导力的一部分，是知道自己在做什么、讲清自己怎么做，让人接受后果。因为 Carta 的上限，他们得把招聘往更不资深的方向挪，于是有管道在填那些层级。很多事从那个修复里跟出来，而且管用。只修比例、不修更前面的漏斗，是修不好的。他现在不像职业生涯早期那么相信对「真实之事」有完美描述。例外太多了。

Orosz 说，他们一起在 Uber、后来在 Stripe 时，senior 是什么相当清楚：你通常可以把一个项目交给他们，如果手下有初级，他们会带。Staff 工程师你可以信任他们给一个单元或多个项目定方向。Eng 1 和 2 能把代码执行出来，问题不太多，也能接受反馈。他们几乎是学徒层级——不是目的地，只是在长。有些公司，包括 Uber，期望你长到某个层级。他们当时正在走到有良好判断力的阶段。

现在人人都更频繁地用 AI harness，包括做 review，代码审查在慢慢消失。他们彼此给的那种非常可见的写代码反馈变少了。Larson 会怎么定义软件工程师这个角色？是不是不一样了，更有野心了？Orosz 觉得它在变得更有野心，又说不太清怎么个野心法，尤其从 CTO 的位子上看。中型及以上公司的 staff 工程师本来就没写那么多代码；他们忙着确保做的是对的事。现在谁都没在写那么多代码，连最小的角色也得决定自己是不是在做对的事。

Larson 说我们还在很早的阶段。有人会告诉你，未来任何规模的公司，软件团队都是五个人。也许是真的；也许我们会到那儿。现在绝对还没到，他也不知道会不会很快到。有些公司工程师很少，却以很能干活的方式烧掉惊人数量的 token，看起来挺酷。软件这个角色要去哪儿？我们会知道的。所以现在待在这个行业才这么好玩。

这门职业的变化，比他入行以来见过的任何事都更极端。对一个始终围着工作结果转的人来说，这是最好玩的一段时间。他也跟一些人聊过，他们的乐趣来自进入心流。他们不再爱软件了，因为他们爱的是做这件事的手艺。最近聊到的一个人在退休：更高效了，可他就是不再享受写软件。他丢掉了心流。

角色正在以一种很有意思的方式转移。Larson 有过这样的想法：软件的实现时间在逼近零。这些系统实际仍然慢。你仍然得做所有决策。它仍然在这些方面不管用，仍然在这些方面扩展得很差，仍然打破用户预期，仍然有错误的单位经济，成不了赚钱的生意。即便写软件真的免费，它仍然会非常、非常难。

今天你看到的是：软件便宜了，工程师就会跑到产品的 PRD 和设计的高保真稿前面。这给想跟工程主导模型共事的设计团队制造了大量问题。他老实说，Imprint 也还在摸这件事。Orosz 也看到机会：工程师戴上设计帽子或业务领域帽子，去跑完整实验。你能跑的实验有限，多了就会把客户搞糊涂，这又回到策略——得有人说不。客户的注意力是有限的。Netflix 不会把 8000 部电影全给你看。

软件变快了，工程师就得发现生意其余部分的约束：领域、客户、现实、单位经济、钱怎么赚。Larson 在 Carta 想过很多。Carta 是低规模生意：不是每秒几十万请求，没有巨大的基础设施问题。它是极度细的生意。cap table 怎么运作非常、非常具体，例外极多。会计必须从可审计的角度做对。你跟对一切该怎么做有强烈主张的律所共事。你可能陷入两个创始人之间的法律战，争的是到底兑现了多少股权。

Carta 后来进入的其他生意，比如基金管理，也同样极度注重细节。有很多生意，领域上下文从来都是难点。他不太清楚这些生意是否已经从 AI 工具里得到那么多好处。Cap table 管理仍然极难，因为细节、法律、跟律所的关系、培训 paralegal。复杂领域的生意仍然有很多护城河。他认为这会变。他不知道怎么变。

每隔两三年就有一个梗：产品工程师是新的王、新的超级英雄。现在轮到 AI 工程师。Larson 说那些人其实就是用 AI 手法的产品工程师，而今天几乎每个产品工程师都是。他一直没太搞懂「AI 工程师」是什么意思。他觉得它的意思是有人用 harness，还想拿很高的薪酬，大概也有他漏掉的细微差别。

你真能让一个人把这些上下文都装进脑子里吗？以前人们会谈那个其实很会设计的前端工程师，或者能写生产前端代码的设计师。那种人一直很少。现在有一点品味的设计师能写生产代码，有好设计品味的前端工程师能做设计。为什么我们还没看到更多？他觉得这是社会约束。

Orosz 也一直在问同一件事。他看到 Linear 的数据，设计师和产品经理提的 PR 在涨。一个工程经理私信他：等等，我们应该看到更多设计师推到生产。他问了大约十家公司；Orosz 又问了另外十家，包括 Linear、Ramp 和 OpenAI。除了稀奇的边角案例，他还没听说设计师在推生产代码。他们会发现 bug、标出来，但仍然要拉一个工程师进来，确认这套做法在代码库里行得通，尤其是原型之外。他们原型做得更多。他想这是不是问责——像换灯泡对上请电工来改家里的线路——或者就是分工。

眼下有一种世界观是：如果你有很好的设计系统并且真的在用，就不需要产品设计师了。Larson 没发现这是真的。即便有好的设计系统，理解组件怎么拼、缺哪些组件、跨屏幕的权衡，同时给出统一体验，仍然很难。Attention is all you need 说的不是人的注意力，但人仍然受注意力约束。出色的产品设计师和设计系统设计师，把事做好的那些细节把他们卡得太死，没有太多时间往外伸。

这必须如此吗？他不觉得。理论上，如果你有很好的设计系统、大量一致性，以及强迫按某种方式使用的 linter，设计系统的人和产品设计师就可以更狠地盯例外。这就是他们在 Imprint 想走到的地方：默认情况由工程按现成设计系统做，产品设计做复杂版本和扩展系统。现在还没那样运转。仍然有点别扭。像深泡在 AI 里的人说的，先假设这是能力问题，你就会走到另一边。对他们来说这仍然是能力问题。他们还在摸。

Orosz 提到 Larson 的文章《The Revised Rules of Engineering Management》。他想强调其中一条：带领域认知、持久的高所有权团队，变得更重要了。Larson 在引用自己在 Uber 的功课：持久的稳固团队会靠攒领域上下文、建立情谊、对一块领域持续工作而感到越来越强的所有权，从而创造奇迹。那是 2014 到 2015 年，十多年前。他仍然觉得非常相关。

Larson 认为这是建可扩展组织的唯一办法。听起来理所当然，其实有点非共识。你在一家 50 个工程师的公司。一个合作方项目延期了。人月神话还在，可有人说我们再调十五个人到这个关键项目上。《人月神话》是 1975 年，第二版 1995 年——五十多年了。我们知道这不管用。很多是做给别人看，制造已经尽了一切可能的观感，这样错过的时候就不是你的错。

它不只是不管用，还会毁掉真正管用的东西：拥有一块领域的小团队。Larson 加入 Stripe 时接手 Jorge 带的团队；Jorge 转去带 Connect。Larson 有 30 人，一个经理管其中四五个人，他直接管 23 或 24 人。他做的第一件事是摸清 pods——有人能拥有的领域。一旦看到进展，除非出了真正的大事，否则他完全不再去想他们，好把注意力放在更大的、你解决不了的问题上。

这套极其管用。他在 Uber、Imprint、Calm 做过同样的事。他加入 Carta 时那里已经是规模化很好的组织，所以他不必做。你把这事做好，人会比你自上而下发号施令做得更好，只因为他们懂，这也让你能把注意力放在公司杠杆最高或最疼的部分。这是一种奇怪的非共识，但它就是管用，可在观感上几乎总是显得不对，所以难做。合作方上线延期，你说你不会把人从重要工作上抽走；关键路径上的团队会一起拼命、把自己烧穿去闯过去，但你不会把所有人都拉过去。

过去你可能会做的，Orosz 说，尤其是在会议和招聘的世界里，是把关键路径团队身上所有废话剥掉：招聘、大学行程、全员会。这比加人管用太多。有时你告诉大家这会是两周的冲刺，谁能投入、包括加班的，事后用休息换。你把他们当成年人。人往往愿意为这一件事扛一次，尤其知道你会用同样的方式还他们。

你要是不这么做，在一家真正在长的公司里，每天都有危机。你把人轮去救危机，就变成每个人每天都有危机，造出一种摧毁感。Larson 记得加入 Stripe 一两年后跟一个人聊。对方比喻 Stripe 当时的跑法，是人站在墙上守城堡，总是跑向快要被攻破的地方。他们跑得越来越快，仍然不能同时出现在每个地方。

他们想切到的是很多人在很多地方。守一块的人必须解决那一块，不必到处都在。要成为快速增长、成功规模化的公司，你必须走到不是同一批人到处跑的模式，因为那些人会彻底 burnout，到某一点无论他们多厉害也盖不住了。有 AI 之后的问题是，那个点是不是远得多。他不确定是。他仍然觉得注意力先于写代码的能力耗尽。

Orosz 一直在用 Slack 的例子想持久的高所有权团队。Google Chat、Mattermost、Microsoft Teams、Slack：聊天里四个大竞争对手。一家创业公司可以让 AI 去抄 Slack，它会抄 UI 或找到开源。首先，大量决策从来没写下来；Slack 的人知道，它们要花年头，你若做得够大也会自己摸到——并发、投递，诸如此类。

把这点搁一边，Slack 上线了 Slack agents：在 Slack 里干活的编码智能体，想得很清楚，来自一个有领域认知的团队。为什么 Google Chat 没上同样的东西？这个例子让 Orosz 意识到，Slack 的大团队大概是有价值的。从 Uber 那些年的眼光看，你会为编制感到惊骇。他们不只是在运营已有的东西；他们持续在重新发明客户会要什么。别人还没回应，尽管智能体已经来了一段时间。Slack 做了一件客观上很好的事。他们是怎么走到的？

Larson 想起某篇关于管理大英帝国的官僚规模的论文：所管理的领土在缩，官僚人数却在涨。公司扩张，造出官僚，造出开销。有时他们只是丢了主线，也丢了行动能力。他的假设——他觉得 Meta 也一样——是真正有意思的产品出来时，总有一两个高度授权、连着创始人、CEO、高管团队的人在往外推，能做那些不受欢迎的痛苦权衡：法务对上公司、产品权衡、不再按一直以来的神圣方式做事。

他对 Slack 的猜测是，有某个赞助者。人们讨厌把高管说得太重，但他确实觉得，高管背书才让人有力量去做难的事。Imprint 三四个月前从 Jira 迁到 Linear。不到四周做完。他决定做的时候，基本上没人觉得这是好主意。他们仍然不到四周做完了，现在大家真的很高兴。它解决了很多问题：有了集中的事务管理，智能体才知道任务在哪、拉下来、做掉、把任务统一起来。没有这个，他们很难管工作量。

在大约 230 人里，他做这件事之前大概只有三个人觉得迁到 Linear 是好主意。他推过去了。现在大家高兴。有时得有人去担这个险。另一面是，你随后用这些风险好不好来评判高管。三个月后没人再谈 Jira。如果大家恨它，他们早该聚起来要把他开掉。很多时候赞助者没有被问责，蠢决定也是这么来的。

这正好接到高管。Larson 做过 CTO，那是一种高管。Orosz 想听他对高管是什么的理解，以及今天从工程师走到那个位子的职业路径——那种喜欢做决策、包括不受欢迎的决策、也喜欢帮人和公司的人。老路是什么，新路又是什么，如果有的话？

老路：你做若干年软件工程师，可以相当短，然后进管理，爬过中层——工程经理、高级经理、总监——然后到 CTO。这里有很多问题。首先，最初被选进管理的人，往往不是最盯着技术那一块的，因为他们在努力晋升进管理。选择偏差偏向会运转的人，这跟技术侧不一定有多少共同点。他们常常碰巧技术也很好，但并没有朝这个方向的强选择偏差。

要当高管，你真的得是个好官僚。这是有意思的难点之一。Larson 很多工作是激励管理：知道如果我们推出这种绩效评估，它会怎么失败，所以不该那么做，该做另一件事。如果你没练过当官僚的回数，你其实运转不了一个职能，因为运转一个职能很大一块就是当官僚。Orosz 问他怎么学会当一个好的。因为必须。他就是个官僚。

在 Uber 其实没有量规。没有结构化面试。他们没有面试该怎么做的结构，所以你得为自己的职能全自己编。面试极多，每一次没发 offer 他都心疼，因为他面了太多。他得把这事想清楚。Stripe 是结构上更完整的公司，有很多结构化流程。他参与了很多，也学到很多。加入时他觉得很多结构并不管用，于是在他们快速增长时一点点迭代、改小块。

那些中层管理工作教他怎么当一个好官僚，而这是成为有效高管的一部分：你学会哪些流程和激励管用。他提到 James C. Scott 的 Seeing Like a State，讲国家如何看见公民、这又如何塑造政策。同一套想法。你从没当过官僚，就无法用官僚的眼睛看。你只能当官僚，就不知道软件实际是怎么做出来的。那非常伤。

Orosz 核对自己有没有听对：要当好的工程高管，工程 VP 或 CTO，你得技术出色——知道它怎么工作，需要时能下手——也得是能运转职能的好官僚。两边都要。走中层这条路，可能发生的是你要么从来就不是好的技术人，要么爬上去时已经不再是：好官僚，不是技术人。如果你明天从出色的技术人直接去创业公司当 CTO，你不会是好官僚。Larson：完全正确。

一线经理往往比中层更有高管直觉，因为他们习惯在细节里干活。他们能为团队或公司做出更好的判断。在这份工作所有非官僚的维度上，他们的判断就是更好。然后在官僚维度上，他们的判断很糟。所以当高管很难，这条职业路也很难。尤其在 2010 年代，你得爬过一层层中层才能学会官僚那一块，那也是获得足以理解它的规模的唯一办法。现在那些层差不多没了。

有意思的是，现在特别看重工作的另一半：更好的决策、理解真正的产品、真正的生意、软件怎么发出去，而他们过去是把这些往下压的。有人问这是更容易还是更难。他不觉得更容易，也不觉得更难。现在要成为官僚难得多——这个词有负面含义——但学会真正运转一个职能，是很难的活。作为 C-level，你常常最后要管三四个职能，往往有一个你自己并不太懂。

在 Imprint 过去一年很大一部分时间他在管客户运营，不是他很深的职能，不过手下有一位出色的负责人。在 Stripe 他管过支持工程和数据工程，两件他自己都没做过。你必须的时候就会那样学会运转一个职能。那些位子很难拿到。你也能更久地做一个更盯细节的领导。所以他觉得未来最好的高管是一线经理：中层选出的是另一套技能。两边都占上从来都难，现在难的方式又新了。

Orosz 问中层是不是在慢慢死掉。Larson 同意日子很难过，尤其如果你是 2010 年代上来的。选出你靠的是赋能、职能官僚那一套。现在人说他们不要这个、也不需要这个。你已经升到一个下不来的顶点，因为执行技能不受重视，量规在你脚下改了。超级挫败。他不知道这一波高管会怎么产生。这条路从来都难走。

Orosz 有两个人来问他建议。一个是工程负责人，大约七个下属，在想自己的未来。另一个下面有三个工程经理向他们汇报，IC 也向 VP 汇报；他们在做 AI 转型，VP 满意，他们仍然在想。两个人都问：我是不是在职业陷阱里？两人都在中层待了多年。他们够技术，但老的下一步——工程 VP——在现在的公司里不太可能。

中层现在很难。这些角色的竞争激烈得多。Larson 自己觉得非常有回报的，是重新扎进写软件的细节。离开 Carta 时他的团队是 250，大概那个数。加入 Imprint 时他带的团队大约 25 人。对他来说这是一个能真正重新学手艺的独特窗口。如果你现在在做管理，要么你得回到细节里，要么世界变得太剧烈，你熟悉的那门手艺三年后将不再值钱。你多少得决定：我是现在退休，还是重新学？

他也想过这个。在 Carta 他本来可以就这样结束。那是他想要的吗？不是。他真的还想参与。他真心相信，我们工作的方式在过去一年里剧烈变了。不是每个地方都变了。有一条很长的尾巴要花很久才赶得上。在他工作的地方，变了很多，对他个人来说也好玩得多。

首先得对往后退一步或横着走一步有点开放。人们想要的非常不同，你得愿意换个角度看。比方说回到一线管理岗位，实际上比中层教育意义大得多。一线管理和写软件的工具已经非常好。编制规划或做绩效评估的工具基本上很糟。那些事上的 LLM 应用也不好。你现在在中层会缺很多。他会试着给自己找一条出去的路。

Imprint 招进来的一个人是 Jasmine，他在 Carta 共事过。她以 VP 身份进来，做一线管理：一位有经验的经理，在 Mux 管过工程。她在写大量软件，这在 Carta 或 Mux 从来没时间，因为她太忙于运转职能。愿意把手重新放回工作上的人非常值钱。如果你是这种人，你得自己说出来，否则没人会给你这个职位。他可以整天招更多这样的人。

Orosz 把它接到零利率年代的工程师：习惯了公司的存在是为了让他们做自己想做的——平台，不是产品，即便生意需要产品——有时他们就走了。他想经理是不是也有一个版本：我以为自己很快会当工程 VP，可那是行业想要的吗？现在公司要的是真正好的一线经理。他认识的最好的工程师，生意说需要产品时会把自我放下，即便他们平台做得极好。

他对 Larson 也有这种感觉：250 人、薪酬、股权、地位，他去了一家没那么出名的创业公司，品牌还没那么响，团队小得多，责任也更小。你把自我留在门外，然后学到的多得多。Larson 说，在很多方面这对他只是好得多的局面。不是「这是一次爆款」。他不是那样想的。这是完美的局面，因为他想要的是回到细节、重新学习这个时代怎么做软件。他认为这才是职业生涯能走得长的钥匙。而且就是好玩得多，有劲得多。

他一直是被骗进管理的那种人，回到 Digg 的故事：他们需要一个经理，他就说了好。然后他们让他当总监，好在收购谈话里看起来有个总监，更像样，可他连一线管理都不会，更别提总监。他们纸面上需要一个。对他来说这就是他想要的，一个独特的机会。对很多人则有一种行业背叛了他们的感觉，觉得自己应得一份已经为之工作过的东西。问题是，他们是对的：他们极其努力地工作过。规则变了。

某些时刻世界看起来非常稳定，我们的行业看起来也非常稳定。2010 年代我们忘了，我们的行业其实非常动荡。每一个十年都变了惊人的幅度。事情跟前一个十年就是完全不同，我们把这点看丢了。在大量稳定里成长起来的人，并不总记得。我们得愿意做横向移动，得有一点谦卑。如果做对公司真正要紧的实际工作算谦卑，那我们就已经搞丢自己在这儿干什么了，因为我们拿钱就是去做对公司有价值的事。这些公司雇我们，没有娱乐取向。

那 TLM 角色呢，tech-lead manager？他们都宣布它死了，是死胡同，那是技术负责人另外还要管一个很小的团队的时候。在零利率年代那就是职业停滞、一个陷阱；Larson 有一篇文章。他现在怎么看这个角色？好笑。它仍然是陷阱，但是个需求很高的陷阱。很多情况下没有替代，所以与其说是陷阱，不如说它就是那儿有的东西。很多公司的管理层级正在变扁。Orosz 开始看到一个总监带着一堆技术负责人，一个大约 30 人的组织里到处是 tech lead。

Larson 看到两种模型。有工程经理，但他们管的范围大得多，所以对个人反而比以前更不下手——管 12、13、14 个人，而不是四到八个。也有总监在管 tech-lead manager，而不是一线经理。不同公司在试不同的东西。这就是他看到行业现在要人的地方。Imprint 招到的一些最好的人，原先在更纯粹的管理角色里，进来之后真的想写软件，两边掺着做，做得非常好。

这种人很难找。几乎是：按出色的工程经理来面他们，然后，你是不是就是因为没在写更多软件而 frustrated？那才是你真正想要的人。他们到现在还没按那种方式面试；只是碰上了几个很棒的人。那才是他们真正想要的角色。这又回到想要有能力做官僚那一块、却并不想做的人——有能力，没有欲望。他觉得眼下特别有效的就是这种人。需要时他们能用上那一套，但默认是真的在写软件，而那才是大部分价值所在。

作为收尾话题，Orosz 想问 Larson 怎么写。他一直是如此高产的写作者；Orosz 仍然喜欢那篇博客，每篇新文章都会看，也订了邮件。他怎么对待写作，又怎么看 AI？现在有大量 AI 写作，不只是 LinkedIn，也包括以前不用 AI 写、现在开始用一点点的作者。

Larson 在网上写了大约二十年。他 2007 年创办 Irrational Exuberance——大概五月或六月——所以快到二十周年。刚开始写的时候，他只是想搞清怎么靠写作网络进一份工作。他做了大量教程：我是这样做成这件事的。那是另一个时代。现在这种东西你会直接问 AI，它会专门给你写一篇很好的教程，也许直接替你做完。

开始在 Uber 工作后，他多写了一点在超大规模上学到的东西。真正起飞是在 Stripe 写的时候，那是一个既有很多可学、又真正爱写作的地方，给他的工作充了电。然后他写了第一本书，Stripe 那些写作的集大成，An Elegant Puzzle，拿到了很多动量。他想一共四本书。大概至少十年不会再写另一本，也许永远不写了。

这件事太有改造力了。人们认识他的时候——并不那么经常——清一色是因为那些书或博客。他真心相信，写作是我们作为个人能真正改进行业形状的独特方式。你做过之后，会冒出一些小事。对 Orosz 来说，是三峰薪酬那篇：首先有个好记的名字，这有帮助，但也是很多人不理解的重要观察。Larson 觉得 Orosz 改了很多人看待薪酬的方式。Patrick McKenzie 有谈判那一套，大概在世界上给人们创造了非常多的财富。

至于他自己的书，他真的觉得改了行业。尤其是 Staff Engineer：那本书造出了 staff-plus 这个概念。还有一些没那么好引用、但起过作用的东西。他在任何公司的工作里，都做不到以这种方式、影响这么多人、这么正面地影响行业。Orosz 记得读 An Elegant Puzzle 和 Staff Engineer，从中拿过很多指引。那就是如此有力量。

然后他想到用 AI 写。他二十年在这上面花了几万小时。他不是手艺导向：他是要把想法弄出来，不是要写最好的博文。Orosz 喜欢那些想法很冲。Larson 是个还不错、读着愉快的写作者，但 Orosz 读他不是因为这个。想法到了，让他去想。呈现过得去；真正打动他的是想法。

Larson 称之为相当极简的写作。Orosz 说有些文章很短。甚至不是长度的事。Orosz 自己写起来啰嗦得多，那是他的自然风格。他喜欢 Larson 的是，没什么可说的时候不浪费一口气，而那就完整了。然后 Larson 想到自己拼起来的所有这些、所有试图改变别人想法的东西。用 AI 写，就是把那些扔掉。

他从没做过一份想收拢海量读者的通讯。更像是：你想读我在写什么，它就是这样。这不是他的生意，不像对 Orosz 那样。尽管如此，他还是聚起了一些人，他们读他写的，这真的很有力量。他知道自己写点什么，常常接下来一周会有几百家公司在谈这个想法。那是如此特权的位置。如果他只是写灌水，就会把它扔掉，而且永远拿不回来。他不会再花二十年做这件事。

想到自己二十年小心攒下的优势，为什么要扔掉？如果没什么要说，他就什么都不说。他不是在制造内容。为了虚无把那些全扔掉，会是毁灭性的一刻。如果是为了什么而扔，他也许能走到那儿。他觉得写 AI 灌水文章只会是一场没有补偿的损失。他不觉得会有人读，而他会扔掉花这么久拼起来的东西。他猜 Orosz 也是同样的感觉。

Orosz 是。写作是他思考的方式。有人问他的社交媒体策略；关注很大程度上是几乎全职研究这个行业、跟工程师聊天的副产品。他开一个草稿，把想法停在另一个窗口的一条推文里，继续写，后来发现它有水花，因为它有意思——或者有争议。那些帖子他并不打磨。他更在意对话。

有时那条推文会分心，但它也在成形想法。他很多写作是观察：你看到这个了吗？这会生出对话。他试过一个用自己存档训练的 Pragmatic Engineer bot，觉得几乎好笑。他的观点会变。那个 bot 会吐出好几年前的东西。他们刚才还在谈 TLM。一个 Will Larson bot 仍然会说 TLM 是陷阱。今天他们在谈这件事要丰富得多。

他告诉人们别把自己的思考过那一层。他看到有人在 LinkedIn 上写，尤其是同行，或者私信他，他们常常用自己真正的声音评论，他就想：你为什么不直接那样写，不完美也行？那才是你。我喜欢那个你。他不喜欢那种无菌的东西，也不喜欢 AI 给几百万人同一副声音，而几百万人开口，本该有几百万种不同的声音。

这接到 Larson 觉得非常相关的一件事：很多人相信要成功就得写内容，可他们并不真想写内容。于是：我真的讨厌写内容，但要晋升、要下一份工作，我就得写。我怎么做？显然是 AI。他一段时间以来一直在推回去。他写过一篇，确切名字忘了，关于怎么成为科技影响者。Orosz 会放链接。标题并不抓人，几乎有点标题党，却是关于如何在科技圈有影响力的最好的一篇。他转给过很多人。谢谢你写了那篇。

Larson 写它的原因，是有人说自己需要写 200 篇、300 篇，每周都写。如果你的目标是露脸，你需要做的是写一篇能传开的。花很多时间。试。把那件事弄清楚。你其实不必写一大堆。写一大堆几乎没有价值，除非你在做一份靠订阅的生意。如果你只是想把想法弄出去，多露一点脸，证明你能写得清楚，你可以写两篇、三篇，两年一篇。你不必写很多。

他想到 Tanya Reilly，博客上写得不多，可她一写就会说出真正有意思的东西。她不是产量型写作者，却能拿出真正有影响力的篇目。Glue work 是最明显的一篇，真正有改造力。即便对写得很多的人，人们也记不住他们写的绝大多数。会留下的是少数几篇。如果人们重新对准真正的目标，也许能见度是一千，一两件好东西远比产量重要。他希望人们如果并不真正——他觉得那并不服务他们的目标——就别再制造产量。

过去一年他见过带着 AI 灌水内容和巨大产量的候选人。他对那些候选人相当纠结。没人在读，你还在继续做。为什么继续做一件没有任何目的的事，因为没人回应？感觉像有人在跑食谱，却不尝成品。这是 cargo cult。他们其实不知道自己为什么在做。在他看来，这其实意味着判断力差，而不是一个努力的有野心的人的标志。

Orosz 请他推荐一本、或几本他喜欢的书。Larson 当然会向任何喜欢花钱买东西的人推荐自己的书。Orosz 说它们都很好。Crafting Engineering Strategy 去年出版，是最新一本，里面有很多有意思的想法。Donella Meadows 的 Thinking in Systems: A Primer 是他经常想到的一本。Orosz 是按 Larson 的推荐读的。Larson 说，老实说，这本书塑造了他对管理和在公司里运转的看法。它其实不是关于运转公司的，但是一套你能用的心智模型。极其有帮助。

真的，任何逼你换一个角度看某件事的书。几年前他花过不少时间想 typing——不是键盘打字，而是如何有更好的类型系统，这跟他日常工作并不那么相关。还有一本很好的书，名字他一时想不起来，关于 TLA+。Orosz：Hillel Wayne？对。Wayne 上过这个播客。极好的书。Larson 日常并不怎么用 TLA+，但那些想法极其有力量：用语言来提高软件的可验证性，而这是我们这个时代最大的问题之一。

如果我们所有的软件都在由别人写——那个别人是智能体——让验证变便宜就非常关键。即便 TLA+ 在很多情况下不是那个工具，去想这个问题也有价值——这也是 typing 真正有意思的原因。眼下这些是有用的几本。Orosz 谢谢他。终于能有这场对话，太棒了。Larson：彼此彼此，谢谢邀请我。

复盘里，Orosz 说他认识 Larson 这么多年，能当面坐下来很好，而传统的工程管理最佳实践和工程职业路径都在变动。一个真正有意思的话题，是经理曾经多么拼命地给工程师找有趣的项目。Larson 回忆在 Stripe，最好的一些工程师要更有意思的问题。那时他就已经顶回去：他能给的只有苦活，意思是并不光鲜的问题，可那苦活会让生意成。

在 2010 年代和 2020 年代初，很多工程师觉得那种做法算不上好的管理。今天它差不多成了默认。作为工程师，尤其到了 senior-plus，要职业稳定和晋升，你会想帮生意解决最紧迫的问题，而这包括对那些问题有共情。

Orosz 也觉得 Larson 对成为出色 CTO 需要什么的看法让人开眼。你需要两样：一个知道该建什么、怎么建的出色技术人，以及一个能运转整个职能的官僚，包括你可能并不专精的职能，比如产品或设计。2010 年代很多经理主要学的是官僚那一块，等到当上 CTO，技术侧已经丢了。今天团队更小、中层更少，许多 CTO 会先是技术人，Larson 觉得这总体也许更好。Orosz 同意。

最后，他感谢 Larson 给中层经理的建议——那些下面还有经理向他们汇报的工程经理。Larson 没有绕弯子。是的，今天待在中层很难。两条路：回到更靠近软件做出来的地方，去更小的团队或做一线经理；或者接受，你主要当官僚、不是技术人的那套专长，几年后可能不太值钱。

Larson 自己走了一步后退：离开 Carta 250 人的工程团队，去 Imprint 带 25 人的团队，是有意识的，为了在 AI 改变这门职业时学会怎么构建。Orosz 觉得鼓舞的是，Larson 不只谈论学习软件工程的新规则，而且自己走了这一步。他指向相关的 The Pragmatic Engineer 深度文章的节目注释，关于零利率与工程，以及工程经理的职业，并请听众订阅、留下评分。