ZIRP 之后的工程领导力：战略、系统和问责

Will Larson 的职业生涯刚好赶在 2008 年危机前开始。他进 Yahoo 时差不多每四个月就有一轮裁员，随后却迎来整整十年：收入、编制、招聘一起往上走。那十年教会领导者怎么建超大团队、怎么不停招人。他在 Uber 时，有些日子要连面六场，坐在会议室里到后来几乎记不清刚聊过谁。今天完全两样：十八个月前经理一半时间在招人，现在一个月面两场，甚至一场都没有。

时间分配一变，能力短板就露出来。以前靠招人就能当顶尖总监的人，如果不会带队、不会钻细节、不会决定团队该多大、人往哪放，现在可能被看成低绩效。团队在被砍、被合并，这些在零利率年代大多可以躲开的事，如今成了工作的核心部分。

Lenny 问，工程师对公司的议价能力是不是也在下降。Larson 认为上一轮其实对工程师并不好：中层最怕的失败之一是走人，于是把工程师当小孩护着，不让他们碰真正重要的难题。那对工程师、团队和组织效率都糟。现在可以把硬问题交出去并真正问责，这才有条件把他们放进高级岗位——也就是他在《Staff Engineer》里写的那条路径。不习惯问责，高级角色就给不出去；工程师一直想要的成长，反而被宠出来的保护挡住了。

Larson 先泼冷水：他见过一些最聪明、也最爱谈系统思维的人，恰恰属于最不成功的那一批。任何框架都有副作用，没有一种能处处套用还次次见效。他在 Stripe 做事故管理时亲身踩过坑：API 一挂客户就丢钱、可能 churn，团队因此做了大量分析，却陷进测量本身，忘了事情有没有真的变好。「量两次、砍一刀」可以，无限量、永远不砍不行。现实和干净模型冲突时，错的永远是模型；那条缝才是学习发生的地方。模型够接近之后，就得去干活。

他把系统思维说成存量和流量。存量是会积起来的东西，比如湖里的鱼、湖边的渔民；流量是两者之间的移动速率。渔民多、效率高，鱼下降得快；鱼也会繁殖，又有一条回流。入门他推荐 Donella Meadows 的《Thinking in Systems》，书里还接到 Rachel Carson《寂静的春天》：食物链底层一点点毒素，往上会被浓缩，小变化在高层变成意外。

放到招聘漏斗上，存量是潜在候选人、已触达的人、以及每一轮面试里的人；流量是各阶段转化率。触达量还取决于 dedicated sourcer 的人数。从 ATS 里拉历史数据，就能看见管道到底在哪漏：招聘经理迟迟下不了决心、发出去的 offer 没人接，或者漏斗入口根本不够。没有模型，公司常常凭感觉改一大套流程。两年前经理慌着发 offer 是真事；今天更常见的可能是另一头。模型把抽象问题变成可以系统动手的东西。

有人抱怨工程或产品没有战略。Larson 反过来问：多数公司任何职能都很少有书面战略，有的只是「我们做最高质量的产品」这种价值口号，你仍不知道下一步做什么。工程、产品和业务其实一直都有战略，只是没写下来，所以各层执行会不一致。它可能很差，但「没有」这件事几乎从不成立。第一条规则是：写下来才能改进。没有文档，你分不清是这个 PM 不行、是他理解错了战略，还是总部那套战略根本不适合这个业务单元。哪怕写得不漂亮，至少有东西可以调试。

他还认为好战略往往无聊到不好意思讲。常见且有效的一条是：只用今天已有的工具。工程师总想引入新语言、新数据库、新云厂商；对绝大多数公司，标准工具箱才是战略。他加入 Carta 时，工程师 Eric Vogel 写下了公司的 standard kit，那就是工程战略。有人会觉得失控，但他觉得无聊的约束能把精力压回公司真正在乎的问题上。

定义战略，他用 Richard Rumelt《Good Strategy, Bad Strategy》的三件套：对现状的诊断、回应诊断的指导方针、落实方针的行动。Rumelt 很怕「惰性战略」——写了要下线旧功能，却没人真去下。工程侧 Larson 更关心它如何澄清未来决策。Uber 在 2014 年左右坚持自建机房、严禁上云，机柜甚至得揭开屋顶用吊车吊进去，却因此能在大约三个月里把中国业务拉起来，进出地缘约束时不被 AWS 或 Azure 的版图卡住。Stripe 守 Ruby 单体，工程师把时间花在面向用户的功能上，而不是给多种语言做工具链。两边都有不少工程师讨厌这些规则。好战略的目标不是讨好所有人，而是决定有限能力投向哪些问题。Lenny 听出共同点是主动加约束。Larson 说坏战略几乎都坏在诊断：人们把愿望投射到约束上，比如「这些项目可以同时做」，指导方针从一开始就不自洽。

想练战略，他建议先读 Rumelt，再读《The Crux》，然后是《Thinking in Systems》，因为战略很大一块是给现实建模、把诊断做准。工程向的还有 Evan Hewitt 的《Technology Strategy Patterns》，以及《The Phoenix Project》这类。他仍觉得缺一本真正的工程战略经典，希望下一本就写这个；即将出版的《The Engineering Executive's Primer》里已经试过一章。

Gergely Orosz 和 ByteByteGo 的 Alex Xu 都想问同一件事：高强度全职之外，他怎么挤出这么多字。Larson 写了大约十六年，粗估上千篇，两本书分别在 Stripe Press 和自己出版，第三本和 O'Reilly 合作。主规则是写能给他能量的，写不下去的就扔。他不为钱写，也很少按档期写，杂志约稿那种定题、改不了、明天必须交的节奏让他很耗。基础设施工程那本书组不起来，他就停了。他会先把整本书写完再找出版社，这类商业书大多能复用；技术入门书章节环环相扣，就没那么容易。

Lenny 也说，追热点会给自己造一份不想干的工作。Larson 完全同意：人人挤向同一件事，两年前是加密货币，现在是 AI 或反 AI，很难写出新东西，也往往不是你真正懂的。创作者最大的风险是停，不是一开始涨得慢。永远有人觉得错过了 Substack、播客或 Medium 的浪。只要持续写出好东西，读者可以跟着你换平台。难的是找到未来十年还能做的事，那比撑一年难得多。他把它看成无限游戏：创作者并不真的在互抢名额，门槛升高只意味着读者能读到更好的内容。

工作流上，关键是选题跟白天的工作重叠，写作是在打磨决策，而不是跟工作抢时间。高职位累，不是因为五分钟回一次 Slack，而是因为难决策必须做对。有孩子之前他常把周六上午留给写作；现在孩子三岁半，多半改到晚上。晚上还能写，前提是真兴奋；九点还不兴奋，人就会去睡觉。若目标是推职业，他建议打磨两三篇真正好的作品，而不是去开每周通讯。若目标是长期持续写，就把几乎所有写出来的东西发出去。他几乎不写不准备发表的东西，也不再花时间「调试」不认识的批评者。

对听播客的产品经理，Lenny 问怎么跟工程师和工程经理处得更好。Larson 看到两类核心问题。有时激励真的错位，比如时间表、对销售说 yes；更常见的是两边还没搞清对方要什么就开始争。职场里没有反派，只有激励复杂的人。叙事会被简化成「PM 为了晋升才答应销售」，现实几乎从没那么薄：公司得把东西卖出去才能转。最大的建议是：在推功能、改方案之前，先确认你真懂对方在乎什么。表面常有硬取舍，但如果你挖到各方真正要的，往往存在一份不更费时、却能让两边都拿到所需的折中——而真正需求经常不是他们嘴上在说的那句。

结构上，他把 EM 和 PM 当成成对的同事，绩效评级一般相同。明显个人不胜任可以例外，比如根本不来上班、团队不认。真正难的是两人都还行、整体执行却转不动。Carta 的 CPO Vrushali 和他一起校准，公司也把这套规则告诉了大家。CEO Henry 还写过把这想法扩到含业务负责人的「三驾马车」。设计主导的公司也可以把设计经理加进来，职能主次因公司而异，没有一刀切。

PM 觉得对面的 EM 靠不住时，他指出一个常被挡住的约束：工程经理觉得有责任给团队有意思的活。增长团队里，PM 要五十个小实验，工程师想做全新的东西，EM 卡在中间。与其假定对方不可靠，不如问为什么他一直在推重写、换语言。你未必同意，但至少能诚实谈那些你看不见的约束，而不是把同事写成「今天这个笨蛋又干了啥」的反派故事。

团队在收缩，董事会上的风险投资人在压工程效率，领导者需要证明编制和资金花得值。最简单的是用基金给的数据，把研发和工程支出跟同行对标。这能给出可辩护的答案，让董事会消停一点，却帮不了你把组织带好。没人因为买 IBM 被开除那种逻辑，最多让董事少生气；董事一怒，你也很难把正经事做成。要知道团队有没有效，去跟工程师聊。他们知道，也通常能指出原因，诊断不一定对，但有面包屑可跟。你不能对董事会说「我聊过了，凭直觉没问题」——他们管的是一整本投资组合，分不清谁的直觉靠谱。

对董事会，他做两件事。一是让工程评估对齐产品和业务目标：工程存在是为了支撑客户，不是为了自己造新奇系统。二是拿出过去六个月真正有价值的工作路线图。清单填得满，别人会给你空间；填不满，担心就是合理的。工具上，他提到《Accelerate》里的前置时间、事故修复时间、失败率等，几十家创业公司在卖这些看板。它们是好的诊断指标，不是「这支团队好不好」的判决。部署慢告诉你该改进哪，并不能说明该不该开人。

专家倾向把每一种不完美的度量都排除掉，最后什么都不报。他宁愿报一点不完美的东西，比如 DORA，把每一个追问当成教育高管认识底下真实状况的机会。指标是为了让看的人理解丰富现实，不是交出一份完美数据集。向董事会或 CEO 汇报时，DORA 够当起点；承认它有问题，再往上把人教明白，比拒绝给任何可测的东西更有用。有人拿故事点向董事会汇报，他认为那完全是假的，只是让人心里舒服一点。

Larson 记得有家公司的高管参观 Facebook 园区，看见墙上的价值观，原样抄回自己墙上。那几乎没起作用，还可能削弱人们对高管判断力的信心。价值观借不来。第一条检验是诚实：公司的决策必须跟它一致。「我们很抠」和「该花就花、换最好的价值」都成立，前提是你们真那么做。用户至上是很好的亚马逊价值，很多公司并不是用户至上，这没关系；不行的是墙上写着用户至上，做决定时明显不是。

第二条是可落地，能用来解决真决策。Stripe 有过「全局优化」：对你的团队引入新语言可能更好，对组织整体更差，那就不做。Uber 没写成条文，隐含价值却是「对你的团队好就行，别管别人，否则我们会变慢」。两者相反，但都诚实、都能用，Uber 那套帮它跑得很快。Lenny 想起还有「鼓励踩脚趾」一类可以被武器化的表述。第三条是可反转：如果没人能合理持相反立场，比如「我们做高质量软件」「我们解决重要的客户问题」，那只是身份宣言，指导不了选择。「我们是一家人」勉强可反，Netflix 就说自己是球队不是家庭。

Lenny 补了一条：有用的价值应能标出谁合不来；它描述公司是谁，而不是希望成为谁。Airbnb 最初有六条，后来砍掉两条，包括「简化」——承认公司其实并不擅长。Larson 同意：如果它对你招的任何人都套不上，就不值得留，尤其公司已经有十七条、需要收到四条好记的时候。诚实、可落地、可反转，过不了这三关的，多半帮不了团队做决定。

节目的 Failure Corner 里，Larson 讲了 Digg v4。Digg 当时输给社交网络，决定整站重写以加上社交能力。重写几乎从救不了已经在挣扎的业务，可他那时刚从 Yahoo 被挖来，资历浅。入职前两天 CEO 被炒，Kevin Rose 回来，团队死赶着上线。那还不是云的年代，他们把现有服务器几乎全部抹掉重装。新站不停崩溃。他留着一张照片：工程师围着大办公区中间的桌子，有人端寿司、香槟杯，全套酒吧——因为网站没起来。那只是第一天。

大约一个月里站点都没真正恢复，只读大概三天就回来了，但大部分用户功能几乎整月不好用。三十天后多数人已经不再试着救站，大概还有五个人在撑。头两天他和同事从零写了一层缓存，站点能半起来，每台服务器仍必须每十二小时重启一次。他不推荐任何人这样上线，那是一串反模式硬凑成的发布。几周后他找到根因：Python 默认参数变量的老坑，写 API 的人没用过这门语言，评审也没抓住。公司还是归零。上线后不久新 CEO 裁员，他入职约九个月时团队从大约一百人收到三十人。可他入行才两年半就成了经理，因为稍微清醒的人都走了或被裁了，只剩「够傻去接」的他。那次机会成了后来一切的内核。

Digg 还能活吗？Larson 说真正一击是 Google 搜索改动。变现主要靠文章页广告，流量大半来自搜索，SEO 一变，迁移的紧迫感才被催出来，他们动手时已经着火。他仍希望 Digg 原来想做的那种产品存在：按朋友在读什么来做社交新闻，再叠一层兴趣相近用户的全球索引。Google Reader 有过类似成分，作为生意却都没做成。被问愿不愿意再接 Uber 中国迁移，他说如果事先问他会拒绝，可没人问，那次同样成了定义性的经历。你不会自愿去扛这些难看的危机，但当它们落到一群你尊重的人中间，一起撑过去，就会变成职业生涯里最值的经验。