工程思维：顶级技术领导者如何思考战略、写作与领导力
工程思维：顶级技术领导者如何思考战略、写作与领导力
嘉宾：Will Larson ｜ Carta CTO、前 Stripe/Uber/Digg 技术负责人 ｜ 领域：工程领导力与产品战略
背景与引子
过去几年，工程领域经历了剧烈震荡。从零利率时代的高歌猛进，到如今的勒紧裤腰带，技术团队正在经历前所未有的收缩与重塑。招聘冻结、团队裁撤、效率至上——这些关键词构成了当前工程领导者必须面对的新常态。
但危机往往孕育着转机。在这场访谈中，Will Larson 结合自己在 Stripe、Uber、Digg 的亲身经历，以及多年写作与咨询的沉淀，为我们带来了关于工程战略、团队领导、写作成长的一手思考。
他曾写出《Staff Engineer》和《An Elegant Puzzle》两本工程领域的经典著作，即将出版新书《The Engineering Executive’s Primer》。作为技术管理者与写作者的双重身份，他的洞察既来自一线实践，又经过了系统化沉淀。
这场对话覆盖了工程战略制定、系统思维应用、EM-PM 协作、工程师效能度量等核心议题，既有方法论层面的深度拆解，也有大量真实案例的细节还原。无论你是工程师、技术管理者，还是产品经理，都能从中找到可迁移的启发。
一、Will Larson 是谁
Will Larson 是当今工程领域最具影响力的思考者之一。
他目前担任 Carta CTO，此前在 Stripe 担任工程总监，负责核心支付系统的可靠性与扩展性。更早之前，他在 Uber 参与了中国业务的技术迁移，在 Digg 经历了那场著名的产品重写灾难。他职业生涯起步于 Yahoo，亲眼见证了 2008 年金融危机后技术行业的动荡。
但真正让他在行业里建立广泛影响力的，是他的写作。他的博客 will.blog 是工程技术人员和技术管理者的必读之地，16 年间发布了超过一千篇文章。他的两本书——《Staff Engineer》和《An Elegant Puzzle》——已经成为工程管理的经典参考文献。
他即将出版的新书《The Engineering Executive’s Primer》面向技术高管群体，但他说这本书同样适合想要理解 CTO 思维方式的产品经理或业务负责人。
在访谈中，他说自己写作的最大的秘诀是「只写让自己兴奋的内容」。他不追热点，不写自己不关心的话题。正是这种长期主义的坚持，让他成为了行业里少数真正兼具深度与影响力的声音。
二、核心观点 TOP10
1. 工程领域正在经历范式转变：从「哄着工程师」到「把他们当作成年人对待」
过去十年招聘市场宽松，管理者害怕人才流失，开始无原则地迁就工程师。但这种做法实际上是害了他们——不给他们真正的挑战，就无法把他们放到 senior 角色。Will 认为当前的行业调整反而给了一个回归正轨的机会：我们可以让工程师承担真正的责任，同时要求他们承担责任。
2. 系统思维的本质是「股票与流量」
系统由股票（累积的事物）和流量（从一个股票到另一个的移动）构成。Will 在 Stripe 带领团队改进事故管理时，曾经沉迷于测量和分析，却忽略了是否真的在改进。他说：「我们不是在优先考虑改进，我们是在优先考虑测量。」系统思维的关键不是让模型完美，而是理解模型与现实的冲突在哪里——那里才是真正的学习机会。
3. 几乎所有公司都有战略，只是不成文
当工程师抱怨「没有产品战略」时，事实往往是战略存在，只是没有写下来。策略的第一条规则是：如果你写下来，你就可以改进它。口头传播的战略在被不同的管理层级理解时会产生失真，但书面文档至少可以被 debug 和迭代。
4. 好战略的核心是约束：「我们决定不做什么」
Uber 的「不用云」策略让工程师怨声载道，但它让公司在三个月内完成了中国市场的技术部署。Stripe 的「只用 Ruby 单体」策略限制了工具选择，却把工程师的精力聚焦在产品创新上。好的战略不是让所有人满意，而是决定把有限的资源投入到哪里。
5. 坏的策略通常源于「诊断失真」
策略大师 Richard Rumelt 认为，策略由诊断、指导方针和行动三部分构成。Bad strategy 往往始于诊断错误——人们把自己希望为真的东西强加给约束条件。Uber 当年相信「可以同时做所有项目」就是典型的案例。
6. 写作的秘诀是「只写让你兴奋的东西」
Will 写了 16 年、超过一千篇文章。他的方法论很简单：只写自己真正在思考的内容，不写给任何人看。他不追热点，不接受 deadline 驱动的约稿。当一个主题不再让他兴奋，他就停下来。这种方式让他保持了 16 年的持续输出。
7. EM-PM 协作的核心是「对齐激励」
很多 EM-PM 冲突的根源是双方不理解对方的真实需求——而不是利益真的对立。Will 建议在解决冲突之前，先确保自己真正理解对方在乎什么。同时，Carta 的实践是把 EM 和 PM 的绩效评分绑定——他们共享同一个绩效评级，这让激励机制自然对齐。
8. 度量工程师效能，起点比完美重要
DORA metrics（部署频率、变更前置时间、MTTR、变更失败率）是有价值的诊断工具，但不是完美的衡量标准。很多人因为找不到完美的指标而放弃测量，这是错误的。起点不重要，重要的是开始测量，然后教育利益相关者为什么这个指标有局限性。
9. 公司价值观的三个检验标准：诚实、适用、可逆
好的价值观必须描述公司真正在做的事，而不是希望成为的样子。好的价值观还必须能指导具体决策（「优化全局」还是「只管自己团队」）。像「诚信」这样的泛化价值观缺乏适用性——没有人会说他们不诚信，所以它不能帮助你做任何决策。
10. 失败是成长最重要的催化剂
Digg v4 重写是 Will 职业生涯最痛苦的经历：公司在他入职两天前 CEO 被解雇，他被迫在技术能力不足的情况下带领团队完成几乎不可能的任务，网站宕机一个月，团队从 100 人裁撤到 30 人。但正是这段经历让他在两年半就成为工程负责人，塑造了他后来所有的管理风格。他现在回忆说：「那是我整个职业生涯的种子。」
三、关键洞察
1. 「现实永远不会错，你的模型才会错」
当系统思维模型与现实产生冲突时，Will 的原则是：永远相信现实。这听起来显而易见，但实际执行中，人们（包括他自己）常常会为了维护自己精心构建的模型而忽视数据。他举例说，在 Stripe 做事故分析时，团队陷入了「我们有一个完美的分析框架」的陷阱，却没有停下来问：我们的系统真的变好了吗？当你发现自己陷入无休止的分析时，问一个简单的问题：我们最后一次真正做出改变是什么时候？
2. 「好战略最大的问题是它太无聊了」
Uber 的「不用云」和 Stripe 的「只用 Ruby」是极其无聊的策略，但正是这种无聊聚焦了所有人的精力。Will 直言：「好的策略不是让所有人满意，策略的目的是决定我们把有限的能力投入到哪些我们真正在乎的问题上。」追求让所有人都满意的策略，实际上是放弃了聚焦的机会。
3. 「写作最大的风险是放弃，而不是成长太慢」
太多人在内容创作的早期就放弃，原因是觉得自己错过了风口、已经太晚了。Will 的观点是：如果你做的事情能让你做十年，那就去做。Stackoverflow 太晚了、Substack 太晚了、播客太晚了——但最终成功的，往往是那些找到自己节奏并坚持下去的人，而不是第一批入场的人。
4. 「PM 和 EM 的激励错位，往往源于不理解对方真正的需求」
Will 观察到很多 EM-PM 冲突被简化为「对方是坏人」的叙事。实际上，业务需要销售、工程需要质量、个人需要晋升——这些激励在短期内可能确实冲突，但通过深度理解对方的真实需求，往往能找到让多方都满意的妥协方案。这种能力需要的是深入挖掘，而不是站队。
5. 「价值观必须能够过滤掉一部分人」
如果一个价值观适用于所有人，它就没有任何意义。「诚信」是一个典型的例子——没有人会说自己不诚信，所以它不能作为任何决策的依据。好的价值观应该像文化筛选器，明确地告诉候选人：「如果你不认同这个，你可能不属于这里。」Netflix 的「我们是一个运动队，不是一个家庭」就是一个有清晰过滤能力的价值观。
四、精彩金句
「工程师经常被当成需要保护的孩子，而不是被给予责任和让他们真正成长的成年人。」
「现实永远不会错，你的模型才会错。当你的模型与现实冲突时，那个差距才是真正值得学习的地方。」
「好的策略不是让所有人满意，策略的目的是决定我们把有限的能力投入到哪些我们真正在乎的问题上。」
「如果你只是写大家想要的内容，最终你只是在和所有人竞争同一件事。」
「大多数人在 6 个月后不会记得我们今天做了什么决定。所以，做一个合理的决定，然后继续前进。」
「最难共事的人往往是最有能力、最勤奋的人——但他们从未学会如何让别人愿意和他们合作。」
五、实战案例
Stripe 的事故管理陷阱
在 Stripe，Will 和团队花了大量时间分析事故原因，设计了一套精密的系统来追踪每个问题的根因。但他们逐渐发现：团队在测量方面做得越来越好，但系统实际上没有改进。他们花了很长时间才意识到自己陷入了「分析瘫痪」——把优先级放在了测量上，而不是实际的改进上。这个教训后来成为他思考系统思维的核心案例：测量是手段，不是目的。
Digg v4：一场教科书式的失败重写
2012 年，面临来自 Twitter 和 Facebook 的社交竞争，Digg 管理层决定彻底重写产品 v4 版本。决策本身就是一个经典的工程反模式——全面重写几乎从来没有成功过。雪上加霜的是，Will 入职前两天 CEO 被解雇，整个团队人心惶惶。
迁移当天，工程师清空了所有服务器重装新系统，结果网站直接崩溃。整个重写过程持续了一个月，期间网站基本不可用。团队从 100 人裁撤到 30 人，最终产品勉强上线，但公司也已无力回天。
但 Will 从中获得了宝贵的加速成长机会：他在这个过程中被迫成为工程负责人，实际管理整个技术团队。两年半的职业生涯就开始独立负责，这在正常环境下是绝不可能的。他后来所有的管理风格都受这段经历深刻影响。
六、行动建议
1. 用「股票与流量」框架建模你面临的问题
找到你当前最头疼的工程问题——招聘漏斗、事故响应、代码质量。把这个问题拆解为「股票」（累积的量）和「流量」（在不同状态间移动的速率）。然后去拿真实数据，验证你的模型哪里不对。这个差距就是学习的起点。推荐阅读 Donatella Meadows 的《Thinking in Systems》。
2. 把你的工程策略写下来，即使它现在很糟糕
如果你不知道自己的工程策略是什么，就从问这个问题开始：「过去一年，我们做出的最重要的技术决策是什么？这些决策背后的逻辑是什么？」把答案写下来。这个文档的价值不在于它有多完美，而在于它可以被 debug 和改进。「没有策略」从来不是真的——只是没有写下来。
3. 找到与工作直接相关的写作主题
与其在工作之外寻找「个人品牌建设」的时间，不如把写作变成工作的一部分。你在解决的技术挑战、你在思考的管理问题、你从失败中学到的东西——这些都是值得写的素材。这样写作就不再是额外负担，而是思考的副产物。
4. 把 EM 和 PM 的绩效绑定
如果你管理一个技术团队，尝试与配对的 PM 共享绩效评分。这个机制会强迫你们在利益冲突时进行真正的对话，而不是各自向自己的老板汇报不同的版本。最初的对话会很痛苦，但最终会建立更深的信任。
5. 先开始度量，完美可以以后再追求
不要等待完美的指标。找到 DORA metrics 中任何一个你能获取的数据，开始记录并向你的管理层展示。当他们质疑指标局限性时，那正是教育他们的机会——让他们理解工程复杂性的机会。每一次这种对话，都在提升整个组织对工程的理解。
七、我的总结
这场访谈的核心价值，在于它展示了「工程思维」的本质——不是某个工具或方法论，而是一种面对复杂问题时的思考习惯：把问题拆解为系统，观察现实与模型的差距，在约束中寻找聚焦，用写作倒逼思考，最终在失败中找到加速成长的路径。
Will Larson 的独特之处，在于他既是深度的一线实践者，又是长年的写作者。这两种身份互相强化：写作让他系统化了实践经验，实践经验给了写作真正的重量。
对于所有在技术领域工作的读者，他的建议可以归结为一句话：找到你能做十年的事情，然后持续做下去。无论是系统思维、策略制定还是写作，时间会奖励那些愿意在一件事上深入积累的人。
📺 播客信息
- 发布时间：2024-01-07
- 时长：1小时16分钟53秒
- 播放量：38110 次观看
- 原版视频：『YouTube』