以 Staff 的方式工作

别人给过我的最好的建议之一，我也会把它转告给其他 Staff 工程师，那就是：有一种误解，认为当上 Staff Engineer 之后，你就能掌控自己的工作，所有人都会听你的、照你说的做。实际情况恰恰相反！— Katie Sylor-Miller

很多工程师执着于 Staff 及以上（Staff-plus）的职业通道，是因为工程经理那条路会议太多，或者需要和太多同事协作——如果你抱着这种心态进入 Staff-plus，那可要做好大吃一惊的准备。Staff Engineer 名义上是 Senior Engineer 之后的下一级，但它实际上是一个完全不同的角色，你会越来越多地把时间花在那些以前很少做、甚至从没做过的事情上。

Staff-plus 角色有一段明显的新手学习曲线，一开始大多数人都会栽跟头。挑战之一在于，你做的很多工作的反馈周期要慢得多。当你把写代码时那种即时的 REPL 快感，换成导师辅导、关系建设和战略推进那种起伏不定、进展缓慢的工作时，延迟的反馈一开始会让人相当沮丧。

本章讲的就是如何跨过这道学习曲线，学会以 Staff Engineer 的方式工作，并找到那些既能让个人获得满足感、又能给组织带来变革的工作内容。

本章主题

在为本书做的访谈中，也包括我自己带领和辅导 Staff-plus 工程师的经验里，有几个话题反复出现，是个人成长的关键。它们不是这个角色的全部，但最可能让你产生超大影响，也最容易让你一不小心做出断送职业生涯的事。

做重要的事，把有限的工作时间用在刀刃上，尤其是在职业越往后、生活中的牵挂越来越多的时候。
撰写工程战略，指导你的组织用架构、技术选型和组织结构来支撑公司的业务目标。
打理技术质量，在公司不断生长、不断转向的过程中，维护架构和软件的质量。
与授权方保持一致，从而长期做一个有效的领导者。技术领导角色依赖的是别人（通常是管理者）授予的权威，而能不能一直拥有这种权威，取决于你是否始终一致、值得信任、行为可预期。
要领导，先跟随。对事情该怎么做有鲜明的看法，是有力的领导工具，但同样重要的是，要学会把你的愿景和同事、领导的愿景融合在一起。
学会永远不错，从“争对错”转向“求理解、求沟通”。别再把社交资本浪费在修复被冲突搞僵的关系上，学会和优先级、视角不同的人协作。这样还有个附带好处：在你经理面前抱怨你的人会变少。
给别人创造空间，让团队的成长超过你个人的贡献。
建立同行人脉，在做艰难决策时有人可以商量，也能在角色自带的权威开始让人不敢说真话时，还有人愿意给你诚实的反馈。

细心的读者会发现，What do Staff engineers actually do? 一章中讨论过的两个关键主题没有出现在这份清单里：一是“mentorship and sponsorship（指导与提携）”，二是“being glue（做胶水）”。这两个概念对 Staff-plus 工程师的成功都至关重要，但我认为关于这些话题的经典文章已经存在，读它们比读我稀释过的转述更有价值。关于指导与提携，去读 Lara Hogan 的 What Does Sponsorship Look Like?；关于做胶水，去读 Tanya Reilly 那篇带出这个说法的文章 Being Glue。

当你有意识地在这些方面练习，你会慢慢从刚晋升的 Staff Engineer 成长为受信任的组织领导者。不过，这些覆盖不了你做的全部事情。有时你会发现自己的角色惊人地像工程总监（Engineering Director），有时又觉得和职业生涯早期的某些工作似曾相识。

职责范围如此之广，正是描述这些角色难的原因之一。如果你关注的某个话题这里没有讲，可以去看附录 Additional resources for learning。

做重要的事

我现在更喜欢用“energized（有劲头）”而不是“impactful（有影响力）”。“Impactful”感觉是以公司为中心，虽然那也很重要，但“energized”更向内看。正是找到让我有劲头的工作，让我在 Stripe 待了这么久，去追求有影响力的工作。— Michelle Bu

每个人的时间都是有限的，在这场生命倒计时里，我们只会拿出一部分投入工作。即使是对事业最投入的人，生活里也有工作之外的很多事：照顾家庭和孩子、锻炼、做别人的导师也被别人指导、爱好，等等。这是丰富人生的标志，但副作用是：职业越往深走，能用来工作的时间会越来越少。

如果你还在职业上不断往前走，那么即使能用来工作的时间在缩水，外界对你影响力的期望却会一直涨。你可以试试少睡觉，或者牺牲那些让你感觉完整的工作之外的活动，但你终究会发现，工作对你的牺牲无动于衷，并不会因此奖赏你。只有让职业的节奏配上生活的节奏，你才能长期坚持下去。

可以说，管理好自己的节奏，是漫长而成功的职业生涯的核心挑战：越往上走，要求你在越少的时间里做出越多的成绩。这两者之间的那条窄路越往后越窄，但只要方法得当，依然走得通。

先聊聊几种常见的翻车方式：snacking（吃零食）、_preening（梳妆作秀）_和 chasing ghosts（追逐幽灵）。然后再进入正题：到底怎样才能做真正重要的事？

别吃零食

Hunter Walk 建议大家在安排工作优先级时避免“snacking（吃零食）”。如果你的组织运转得不错，总有一天，既高影响又容易的事会被做完。这时你就面临一个选择：向右走，做难而高影响的事；还是向下走，做容易而低影响的事。后一种选择——容易而低影响——就是 Walk 所说的 snacking。

当你很忙的时候，这些“零食”会给你一种成就感，让心理上很满足。但做它们你基本学不到什么东西，别人做也一样能做成（而且对某些人来说，这反而是个不错的成长机会），和做更高影响的事相比，机会成本巨大。

在两个大成果之间，拿一点时间吃点零食、保持动力，是可以的，但你要对自己诚实：到底有多少时间花在高影响的工作上，多少花在低影响的工作上。职位越高，工作越靠自己安排，如果不有意识地跟踪自己的工作，很容易发现自己几乎没做什么高影响的事。

别沉迷作秀

“snacking”是“做容易而低影响的工作”这个大类，其中还有一个特别诱人的子类，我叫它“preening（梳妆作秀）”。作秀是做低影响、高曝光的工作。很多公司把高曝光和高影响混为一谈，到了分不清作秀和影响的地步，所以你经常会看到某些公司最资深的工程师，大部分时间都在做那些价值可疑、却总能在公司大会上被表扬的事。

如果只看短期晋升，那么迎合你所在组织评价影响力的毛病就是最优路径：去尽情作秀吧。但如果你想让自己成长到能胜任复杂度不断上升的当前角色，或者能跨组织成功，那就更需要在“被重视的工作”和“自我成长”之间取得平衡。

这也是选公司时要考虑的重要因素！深挖一家公司到底看重什么，确认它和你想成长的方向一致。如果一家公司的领导层只把精力放在表演式的“紧急”和表忠心上，那你在这家公司要想成功，就得靠这些，那就别意外。

更糟的是，要把作秀做成功，需要对“你到底有没有真实影响”的质疑近乎免疫，而你的精力一旦被作秀吸走，真功夫必然受损。一般来说，这要求你是某位高管特招进来的亲信，或者你的言行举止正好符合这家公司心目中“领导的样子”。如果这两条你都不占，那你拿自己的好判断去换公司的成功，最后还是会失败：同样是缺乏真实影响，长得像“领导”的人能一路向上，你却会被问责。

别追逐幽灵

很多人以为，公司作为理性的优化机器，不会在低影响、高投入的项目上花太多时间。可惜，实际情况并不总是这样。新高管加入公司后，立刻推动战略转向，却从根本上误判了真正的挑战，这种事常见得惊人。上家公司的幽灵死死抓住他对新公司的理解，让他把“熟悉的”误当成“关键的”。

作为资深领导，你得管住自己的 ego，别把大把投入砸进毫无意义的大工程里。当你在面试时被反复告知“请你来就是为了解决某个烂摊子”“你是新请来的救世主”，要做到这一点会出奇地难。当然，你的直觉是对的！先花时间理解现状再动手，勤勉一定会有回报。

前不久有人跟我讨论，说新上任的资深领导是_故意_推动大变革的，哪怕他们怀疑这些努力会失败。这样做会让组织越来越依赖这位新领导，也能保证做成的功劳都记在新领导本人头上，而不是团队头上。如果这就是你的领导方式，请记住：你这样很糟糕，先好好修修自己，直到整个公司的福祉和成功对你来说比“显得自己不可或缺”更重要。

生存攸关的问题

不吃零食、不作秀、不追幽灵之后，就该从另一个方向想了：你该做什么？第一个要找的，就是公司有没有生存攸关的风险。公司永远处在一场不断迭代的淘汰赛里，在“活到未来”和“赢得未来”之间走钢丝。如果眼下这一轮快要输了，那就永远先盯这里。

没钱了是最明显的一种，就像我在 Digg 的经历，但生存攸关的问题不一定都是缺钱，比如 Twitter 当年的 fail whale 稳定性危机，或者 Covid-19 大流行带来的剧变。

如果公司正在经历危急时刻，那就去那里投入。这一关过不去，其他什么都没意义。

去有空间、也被关注的地方发力

生存攸关的问题通常_不是_你投入产出比最高的地方，但在墙塌下来的时候，效率本来就不该是第一位的。生存危机当前就该一拥而上；但如果问题还没到生死存亡的地步，对往人已经扎堆的地方再加码，就要多留个心眼。大家都爱追领导最重视的事，但盯着的人太多，反而很难做出有意义的影响。

相反，最有效的发力点，是那些对公司重要、但还有足够空间让你真正做事的地方。哪些优先级未来会变得关键，你可以提前把功课做足？哪些领域现在做得还 ok，有你的支持就能做到 great？

有时你会发现，有些工作明明_值得_被关注，组织却就是关注不起来，通常是因为领导层不看重这类工作。在一些公司，这是开发者工具；在另一些公司，这是 inclusion（包容性）工作；在大多数公司，这是胶水工作。

这种没人关注的工作几乎总是有大把空间，你能很快做出进展，_感觉_上是很值得投入的机会。但到某个时候，这份工作会需要支持，而为公司天生就忽视、贬低的工作争取支持，是非常难的。早期的胜利会被冷漠和错位慢慢侵蚀，最初的影响会被时间一点点收回。

这意思是 inclusion 工作就不该做吗？不，这不是我想让你得出的结论。有时一个领域正因为组织不关注，才更需要你去推动组织开始关注。让一家公司学会重视它本来不在乎的东西，是你能做的最难的工作，而且经常失败，所以能少做就少做，但该做的不能少。作为资深领导，你有超越“公司眼中的影响力最大化”的道义责任，只是要认清阻力有多大，把握好发力的时机。

促进成长

一个经常投入不足（也就是说，有大把空间）、同时杠杆又很高的领域，是培养你身边团队的成长。_招聘_一般参与的人很多，通常都在优化招聘漏斗，但入职引导、指导和辅导在很多公司被完全忽视，尽管它们对公司工程效率的影响_至少_和招聘一样大。

如果你每周哪怕只拿出几个小时培养身边的人，很可能在你的技术方案和 pull request 早被遗忘之后，这会成为你留下的真正遗产。

做编辑

很多项目离成功就差一处小改动，离打开新机会就差一次快速调整，离达成共识就差一场谈话。我把这些小改动、快调整、短谈话叫做给团队的做法做 editing（编辑）。

凭你的组织人脉、在公司各处建立的关系，加上经验带来的预判能力，你常常只用花最小的力气，就能改变一个项目的结果，这是你能做的最有价值的工作之一。

它特别有价值，因为它快、容易，对你和被你帮助的人都是很大的激励，用得好影响巨大。（当然，用不好打击也很大，所以方式方法很重要！）

把事情做完

一种特殊的编辑，是帮那些总是差一点收不了尾的项目收尾。常见的情况是：一位资历尚浅但很有才华的工程师，活儿已经在干了，却拿不到支持，或者不知道怎么把项目裁剪到可交付的规模。这时你辅导一下同事，怎么微调项目让它能落地，再借出你的影响力推开关键的卡点，经常能把六个月的苦战变成两周的冲刺，而影响几乎一样大。

只有做完的项目才产生价值，让项目越过终点线，就是它从风险变成杠杆的神奇时刻。花在“把工作做完”上的时间，永远花得值。

只属于你的事

最后一类重要的工作，是只有你能做成的事。当然，有些活儿你干得更快、干得更好，但更重要的是那些“你不做就没人做”的事。

这类工作是你特别擅长和真正热爱的交集。可能是写出大家_真会照着做_的公司技术战略，可能是说服一位优秀候选人加入，可能是改变 CEO 对偿还技术债的看法，也可能是精心打磨一个 API。

不管是什么，“你不做就没人做”的事，是你做出重要成绩的最大机会，而且职业越往后，这个类别会越窄、越深。

为什么这很重要

假设二十年后你在面试一个新角色。面试你的人能搞懂你在之前每个项目、每家公司的真实影响吗？不可能，我保证他们搞不懂。相反，你会被一系列相当主观的东西评判：你积累的名气、你的头衔和待过的公司、你的口碑，以及你在面试中的表现。

你躲不开主观的面试，但你可以有意识地从有价值的工作中积累真本事。事实上，这是你职业生涯唯一靠谱的长期赌注：专注于重要的工作，做能让你成长的项目，选那些看重真本事的公司。

撰写工程战略

我觉得写工程战略难，是因为好的战略都很无聊，写无聊的东西也挺无聊的。而且我觉得人们一听到“战略”就想到“创新”。— Camille Fournier

很少有公司真正理解自己的工程战略和愿景。这种不确定带来的一个后果，是行业里都觉得这类文档很难写。有时聊起来像在谈什么玄学，但它们只是普通的文档。现实是：好的工程战略都很无聊，而且写出有效的战略比写出糟糕的战略_更容易_。

要写工程战略，就写五篇设计文档，把其中的共同点抽出来，那就是你的工程战略。要写工程愿景，就写五个工程战略，推演它们两年后的样子，那就是你的工程愿景。

如果你忍不住想把最聪明的想法塞进去，那就先做个准备工作：把你所有最妙的想法写进一个大文档，然后删掉它，再也别提。从脑子里倒掉这些想法，头脑清爽了，才能开始干正事。

长期有用的工程战略和愿景，是自下而上、反复迭代的组织学习的结果。因此，所有学习都会贡献于组织的战略和愿景，但你的贡献不必那么抽象。即使你不直接负责这项工作，也有现在_立刻_就能动手、推进组织战略和愿景的务实步骤。

何时写、为何写

在进入写有效战略和愿景的具体做法之前，先问个好问题：“我到底什么时候、为什么要写它们？”战略是主动对齐的工具，让团队又快又有信心地行动。有了战略，人人——而不只是少数被授权的人——都能快速自信地做决策，而这些决策本来可能要花一周的讨论。战略也是一块块砖，把无数种可能的未来收窄到能写出靠谱愿景的程度。如果你发现同一个讨论已经重复了三四遍，就是时候写战略了。当未来模糊到看不清值得投什么，就是时候再写一个愿景了。如果这两条你都没遇到，那就先去做别的工作，过段时间再回来。

写五篇设计文档

设计文档描述你在具体项目中的决策和权衡。你们公司可能叫它 RFC 或者 tech spec，也有更奇怪的名字，比如 Uber 曾经莫名其妙地叫它 DUCKS，后来才统一成 RFC。一份好的设计文档讲清楚具体问题是什么，把可能的解法过一遍，再解释所选方案的细节。格式有很多，入门可以看看 Design Docs, Markdown, and Git、Design Docs at Google，以及 Technical Decision-Making and Alignment in a Remote Culture。

一个项目要不要写设计文档，靠个人判断，但有几条规则我觉得好用：凡是能力会被众多后续项目复用的项目，都要写设计文档；对用户有实质影响的项目，也要写；凡是超过一个月工程量的工作，都要写设计文档。

五篇设计文档是写有效战略的理想原料，因为设计文档有坏战略最缺的东西：扎根现实的具体细节。两个善意的同组工程师，对抽象战略的理解都可能完全不同；但落到实现具体方案时，想继续错位就难多了。

写的时候有几点建议：

**从问题出发。**问题陈述越清楚，解法越明显。如果解法不明显，就花更多时间把问题讲清楚。如果卡在怎么描述问题上，拿给五个人看，问他们缺什么：旁观者总能看到真相。
**模板保持简单。**多数公司都有设计文档模板，跟着用挺好。但这些模板常常被塞进太多目标，承载太多反而让人不想写。设计文档模板越精简越好，让作者选最有用的章节，只对风险最高的项目坚持要 exhaustive（巨细无遗）的细节。
**一起收集意见，自己动手写。**指望你一个人拥有写好某篇设计文档所需的全部上下文，基本不可能。动笔太深之前，先收集相关视角的输入，特别是那些要依赖你的设计文档产出的人。但别把这种协作延续到写作本身。多数人当写手比当改稿人强：把一篇众人合写的东西改清楚，通常比指定一个人把它写清楚更难。广泛收集视角，独自落笔。只是注意，在和别人评审之前，别先爱上自己写的东西。
**求好不求完美。**写一篇不错的文档、赶紧拿给别人看，好过一拖再拖、只为好上那么一点。给别人的设计提反馈时尤其要记住这点：很容易掉进“别人的设计也要达到我最好一篇的水平”的陷阱。越资深越要注意，别把每篇设计都推到自己巅峰的 bar（一味拔高是有毒的）。推到“好”就行，别盯着“我的最好”当质量线。

写出色的设计文档需要大量练习。如果想提高，我最好的建议是：项目做完之后，把自己的设计重读一遍，研究实现偏离计划的地方——是什么造成了偏离？当然，还有：一直写，别停。

把五篇设计文档合成为战略

等组织攒够五篇设计文档，坐下来放在一起读一遍。找那些在多篇设计里都出现过的、有争议的决策，特别是那些很难达成一致的。我最近的一个例子是：反复纠结 Redis 到底能当 durable storage（持久存储），还是只能当 cache（缓存）。与其每次设计文档评审都从零吵起，不如把我们最近几次关于用 Redis 的决策复盘一下，想想当初怎么做出的决定，写下来变成战略？

好的战略指导权衡，并解释背后的理由。坏的战略只给政策、不给解释，把政策和当初的上下文割裂开。没了上下文，战略很快就看不懂了——当初为啥这么定？——上下文一变，也没法跟着调整。写自己的战略时，可以参考 A Framework for Responsible Innovation 和 How Big Technical Changes Happen at Slack。

如果你是 Good Strategy, Bad Strategy 的信徒——那本书彻底改变了我对战略的看法——你会发现，这里对战略的定义就是那本书里的“diagnosis（诊断）”加“guiding policies（指导原则）”，而“coherent action（连贯行动）”留给了设计文档。

我写战略文档最好的建议是：

**从现状出发。**做战略很容易被固有的巨大不确定性冻住，但你得一头扎进去，先写起来。等缺的信息齐了再动手是行不通的：每份缺的文档缺着都有它的原因。你写的东西肯定要改，写得特别烂反而能更快发现要改。从现状出发，永远是开始的最佳位置。
**写具体的。**写到开始泛泛而谈就停笔。如果你写不出具体的，就等写出更多设计文档再来。具体的陈述带来对齐，泛泛的陈述只带来对齐的幻觉。
**有立场。**好的战略都有立场。没立场就给不了决策清晰度。但只有立场还不够，还得把推导过程亮出来。
**亮出推导过程。**小时候上数学课，满分要求写出解题步骤。写战略也一样，必须亮出你立场背后的理由。亮过程能让第一版文档更可信，更重要的是，上下文变了，别人才能接上、改下去、往前走。

有些你写过的最好的战略，当时可能觉得太显而易见、不值得写。“什么时候要写设计文档？”就是值得写的战略。“不同场景用哪种数据库？”是值得写的战略。“从单体迁到服务怎么分阶段？”也值得写。放下“战略必须是 brilliant（ brilliant 秀）”的执念，我们就能写出多得多、也随意得多的战略。最后没人用，大不了废弃掉。

把五个战略推演为愿景

战略攒多了，越来越难说清它们之间怎么相互作用。比如你的一个战略是 Run less software（少自己造轮子），多依赖云服务，另一个战略是 prefer offloading complexity to the database（尽量把复杂度甩给数据库）。这时发现一个数据库，能接走大量复杂度，但云厂商偏偏不提供，怎么调和？

拿出最近的五个战略，推演它们的权衡在未来两三年会怎么展开。消掉矛盾、织起线索，你就写出了工程愿景。终稿会给你 Tanya Reilly 所说的 robust belief in the future（对未来的坚定信念），让你更容易看清已有战略之间的关系，写新战略时也更容易经久耐用。

要写出有用的愿景，有几点要抓住：

**写两三年后。**公司、组织、技术都变得太快，想太远注定翻车。写个半年就过期的愿景也不行——半年里你现实地能写出几个战略？聚焦两三年后；公司够成熟的话， horizon（视野）可以再放远一点。
**扎根业务和用户。**有效的愿景扎根在服务用户和业务上。这种紧密连接让愿景和领导团队的核心价值观——用户和业务——保持一致。坏的愿景把技术 sophistication（复杂度）本身当存在理由，这种看法公司领导永远不认。
**乐观，但别狂妄。**愿景要有野心，但不能狂妄。要可能，但要是可能里的最好版本。写“每个项目都按时做完、无大挫折时能做成什么”；别写“资源无限时能做成什么”。
**保持具体。**愿景越具体越有用。泛泛的话谁都同意，但调和不了冲突的战略。比你觉得舒服的程度再细一点。愿景里的细节常常是 illustrative（示意性的）而非 declarative（拍板性的），是让你尝尝未来的味道，而不是给出绑定承诺。
**控制在一到两页。**现实是长文档没人读。写个五六页，读者读着读着就跑了（或者飞快略过，根本不过脑）。逼自己写紧凑，需要完整细节的那小部分人，用链接链到别的文档就行。

愿景写完后，大家通常第一步就是在工程组织里广而告之。愿景背后有这么多功课——一个战略要五篇设计文档，一个愿景要五个战略——写完难免兴奋。也正因为太兴奋，当回应几乎总是平淡时，很容易失落。回应平淡有几个原因：第一，愿景的核心读者是写战略的人，本来就是小圈子；第二，好的愿景往往太 obvious（显而易见），让人觉得无聊多过兴奋。

别用最初的兴奋度衡量愿景。拿两年前的设计文档和上周的设计文档对比一下读读，有明显进步，你的愿景就是好的。

管理技术质量

当我能帮助改进一份立意良好、确实解决真实需求，但起草团队因经验或上下文不足而写不出好方案的提案时，我会觉得自己特别有影响力。在这种情况下，一份结构良好的计划可以大幅缩小范围，同时拿到大部分价值，从而更快地展现影响力。——Dmitry Petrashko

如果说工程师、工程经理和技术高管们能在一件事上达成一致，那大概就是：技术质量正处于危机之中。有一种诊断和药方很容易想到：我们的工程师不重视质量，我们需要招聘更好的工程师，或者把现有的工程师重新培训一遍。当然，如果你觉得更顺口，也可以把这里的“工程师”换成“产品经理”或“高管”。这个叙事很有说服力，有明确的反派，还能顺手把责任从工程领导身上推开。但是，和所有把责任推给最没有话语权的人的叙事一样，它既无用，又是错的。

一旦你接受了“技术质量低是因为决策质量差”这个前提，你就会开始寻找判断失误的人，而公司里总得有人来背锅。是前任 CTO 吗？是那个正对着你紧张微笑的 Staff Engineer 吗？还是所有人都有问题？有没有可能，以上都不是，甚至连你自己也没错呢？

在大多数情况下，技术质量低不是危机，而是预期中的常态。工程师在做决策时，通常都会做出合理的质量决策，而成功的公司会随着规模扩大、转型，或向高端企业用户上移，不断提高自己的质量 bar。在一家运转良好且成功的公司里，你过去的大多数技术决策，都达不到你今天的质量门槛。

与其说这是一种失败，不如说，弥合当前技术质量与目标技术质量之间的差距，是有效工程领导力中常规且必不可少的一部分。

问题所在

作为工程领导团队，你的目标是以恰当的技术质量水平维持运转，同时把尽可能多的精力投入到核心业务上。你必须在多个时间尺度上平衡质量，而这些时间尺度的需求往往是冲突的。例如，为了赶下周的截止日期、把关键合作项目送上线，你要做的工作，和为了下个季度快十倍地发布新功能而搭建平台，是完全不同的两件事。

正如公司的技术质量 bar 会随时间推移而变化，你管理技术质量的方法也会随之演进：

修复造成现实问题的热点
推行已知能提升质量的最佳实践
优先投入能让质量在软件演进中得以保持的杠杆点
在组织改变软件的方式上对齐技术方向
度量技术质量，以指导更深入的投入
组建技术质量团队，打造保障质量的系统和工具
运行质量专项，度量、跟踪并建立问责

在深入探讨这套工具箱时，请记住：选择那个大概率管用的、最便宜、最直接的工具。技术质量是一场长期游戏。这里没有所谓胜利，只有不断学习，并赢得继续上桌的资格。

逐级上台阶 把眼前的问题一路深挖，直到找到一个值得解决的通用问题，这件事有一种独特的乐趣。但同样重要的一种本能是：快速解决当前局面，然后去处理下一个最紧迫的问题。

在为你的团队和组织思考该做哪些质量改进时，最有效的方式通常是从最轻量的方案入手，只有当前面的努力在规模压力下撑不住了，才逐步走向更重的方案。如果连让团队用好代码 lint 都推不动，那你想推全面的质量专项注定会失败。虽然重方案在规模大了之后可能更有效，但它们也难执行得多得多。

所以，先做快的事！

即使没做成，你从“推简单的东西失败”中学到的，也比从“推难的东西失败”中学到的更多、更快。然后你就能更快地进入改进后的第二轮。随着时间推移，你会走向更全面的方案，但没必要着急。在没有真正需要之前，别急着抛弃早期组织的轻快、快乐和单纯，去招惹企业级协同的种种凶险。

把这些阶段说成是一级级往上走的线性楼梯很方便，但真实组织很少这么用。更常见的是：修一个质量热点，推一条最佳实践，开始做架构评审，废掉那个架构评审，再回去盯一阵子热点。过早的流程带来的摩擦大于价值，很快就会暴露出它的无效。如果某件事不奏效，先努力一阵子让它奏效，实在不行，就庆祝它的终结。

热点

面对质量问题时，第一反应常常是认定这是流程失效，因此必然需要流程方案。

比如一次发布引发了故障，一定是因为作者没有正确遵守代码测试流程，所以现在我们要求每次提交都必须带测试——这下就能治治那些懒惰的开发了！

有个关于 Sarbanes-Oxley 法案的老笑话：它并不能降低风险，只是让出事之后知道该怪谁。可惜的是，这个笑话不带任何幽默地适用于很多组织推流程的方式。问责有它的作用，但比起建立流程式问责，更重要的是理解手头的问题，并直接去修它。

推行流程要求人改变工作方式，这事不该轻易动手。与其一上来就做流程改进，不如先戴上性能工程师的帽子。度量手头的问题，找到问题最集中的地方，精确地盯着那一块打。

前面那个没测就发布的例子，也许直接给发布这位工程师反馈、让他改改测试习惯就够了。或者，也许你更应该承认是软件设计本身太容易出错，转而采用《A Philosophy of Software Design》中讲的“把错误定义到不存在”的思路。

如果你遇到的是研发效能问题，也许是优化测试耗时，把 Docker 编译步骤搬到内存盘上，或者用《Software Design X-Rays》里讲的技术，找到最值得改进的那几个具体文件。

系统思考是我职业生涯中遇到过的最具变革性的思维技术。但有时候，它也会像海妖的歌声一样，把你引向修理一个本该直接扔掉的系统。你当然可以推一个新的培训项目，教团队怎么写更好的测试，但也许你直接删掉那个贡献了 98% 测试失败的测试文件就行了。这就是优先处理热点的“不讲道理的有效性”，也是它应该成为你提升技术质量时第一个使用的技术的原因。

到某个时候，你可能会发现，组织制造质量问题的速度，超过了你修热点的速度，这时候就该进入推行最佳实践的阶段了。

最佳实践

我曾在一家没有团队规划流程的公司工作过。久而久之，工程负责人对无法预测交付日期越来越恼火，于是强制要求大家用 Scrum。命令下来后，一位经理在 wiki 上写下了 Scrum 流程。发布了一则“我们在用 Scrum”的公告。经理们告诉各自团队去用 Scrum。任务完成！

当然，没有人真的开始用 Scrum。大家还是按以前的方式做事。承认错误是件尴尬的事，所以工程负责人宣布推行大获成功，也没人忍心说破。

这个悲伤的故事正是很多公司推行最佳实践的写照，也是最佳实践名声这么差的原因之一。理论上，组织应该先推行最佳实践、再去修质量热点，但我建议先做热点、再做实践。推行最佳实践要求的组织成熟度和领导力成熟度，需要一些时间才能长出来。

在推行一项新实践时，请记住：好的流程是演化出来的，而不是命令出来的。先研究别的公司是怎么落地类似实践的，把你打算的做法写下来，找几个积极的团队先试点，把粗糙的边角磨平，根据遇到的挑战改进文档，然后再进一步推广。仓促上马的流程就是失败的流程。

同样重要的是限制同时推行的流程数量。

如果你让团队同时采用多个新实践，你就是在用自己的左手抢右手的注意力。事后想回滚或调整其中某一条、归因效果也会更难。这话听起来有点专断，但我越来越相信：在任何一个时间点，只推一条最佳实践。把所有精力集中到让这一条成功，而不是分散到好几条上。

一次只推一条新实践，也会逼你认真思考优先级。选下一条流程听起来容易，但常常分不清哪些是真正的最佳实践，哪些只是听起来熟、出名而已。真正的最佳实践必须有研究支撑，而这个话题上最好的研究来源就是《Accelerate》。

《Accelerate》里的建议都是数据驱动的，都相当不错，其中我发现早期最值得推的几条是：版本控制、基于主干开发、CI/CD、生产可观测性（包括谁写的系统谁 on-call），以及小而原子的变更。还有很多我想鼓吹的实践（谁还没经历过几年鼓吹内部文档的生涯呢），但我已经不像以前那样信任自己的直觉了。

从修热点转向推最佳实践的时机，是热点多到修不过来的时候。下一个转折，从最佳实践转向杠杆点，是在你发现自己想在手头这条还没跑顺之前，就推下一条最佳实践的时候。这时候别去提高“在推最佳实践”的并发上限，而是换下一个工具。

杠杆点

在热点一节，我们讲了用性能工程师的心态找到真正值得修的问题。优化很适合解决已经存在的问题，但它天然不适用于未来：性能工程最大的罪过，就是在未经证实的问题上花力气。

但是，当你观察软件随时间如何变化时，会发现有少数几个地方，多投一点力气，就能在长期保住质量，既能防止严重的质量翻车，又能降低未来质量投入的成本。

我把它们叫做质量杠杆点，其中影响最大的三个是接口、有状态系统和数据模型。

_接口_是系统之间的契约。好的接口把客户端和封装的实现解耦。经久耐用的接口暴露出底层全部的本质复杂度，而不暴露一点偶然复杂度。令人愉悦的接口是急切而明辨、明辨而急切的。

_状态_是任何系统中最难改的部分，这种抗拒变化的特性让_有状态系统_成为另一个关键杠杆点。状态比其他系统更快变复杂，又有惯性，越往后越难改。再叠加上安全、隐私、合规方面的业务义务，改有状态系统就更难了。

_数据模型_是接口和状态的交汇点，把有状态系统的能力收敛到应用认为合法的范围。好的数据模型是刚性的：只暴露它真正支持的东西，不让非法状态表达出来。好的数据模型容忍随时间的演进。有效的数据模型一点都不耍小聪明。

当你在工作中识别出这些杠杆点时，多花点时间认真对待。如果是接口，就对着 mock 实现先接六个客户端试试。如果是数据模型，就拿六个真实场景来套。如果是有状态的，就演练故障模式，检查一致性行为，按生产场景建立性能基线。

把学到的东西 pull 到一份技术方案文档里，在团队内 socialize。听听行业里同行的反馈。即使已经开始做了，也要听现实的声音，保持随时可改。

投资杠杆点有个隐藏的好处：你不需要全组织对齐也能做。写技术愿景、推最佳实践都需要那种 buy-in，所以我建议先从杠杆点入手。但如果你已经把够得着的杠杆点红利吃完了，也许就到了推动更广泛组织对齐的时候。

技术方向

高效的组织会把大多数力气都投向同一个共同愿景。如果把每个技术决策画成格子上的一根向量，这些向量指向越一致，长期能做成的事就越多。反过来，我合作过的一些最厉害的工程师，造出的向量模极大，方向却偏了。他们想领导组织，最后却伤害了组织。

对齐技术方向有一个百试百灵的办法：把相关决策都路由到同一个 title 里带 Architect 的人那里。这招很管用，但难扩展，而且架构师的决策质量会随着他远离一线真实代码、真实流程而退化。另一个极端是让每个团队完全独立决策。但允许用什么工具都行的组织，最后就是所有工具都没人好好支持。对齐技术方向的基本工具是：

直接给反馈。 遇到不对齐，第一反应常常是改流程，但先从给相关同学直接反馈开始。你缺他的上下文，正如他缺你的上下文，一次快速的对话常常能省下几年不必要的流程。
打磨你的工程策略，从技术方案，到策略，再到愿景。
把做法封装进工作流和工具。 写清楚愿景的文档有帮助，但有些人就是不会看你的文档。精心设计的工具创造的工作流，比培训和文档更能培养习惯。例如，新建一个服务要先去一个网站，网站要求你贴上这个服务的技术方案链接。另一个例子是：如果服务没有建好 on-call 配置，没有当前 on-call 人，甚至这个人没开推送通知，就不让部署到生产。
在新人 onboarding 时培训。 习惯养成之后再改非常难，如果你想让人采用新实践，这会让你很挫败。但如果人在加入时就 pointing in the right direction，习惯的惯性就会帮你保持对齐。
利用 Conway 定律。 Conway 定律说，组织造出的软件会反映组织的结构。如果组织结构很烂，就会造出紧耦合、一团乱麻的软件。但如果组织设计得好，它同样会成为质量的助力。
管理技术变革，用架构评审、投资策略和结构化的新工具引入流程。大多数不对齐都来自缺上下文，而这些正是把上下文注入决策的组织杠杆点。很多组织一上来就用这一招，但这是我最不推荐先开的一箱工具。没有讲清楚的愿景，怎么做一致的架构评审？等人家设计完了再告诉人家策略，为什么不在 onboarding 时就说？

无论你用哪些方法对齐技术方向，这都是按月、按年计的工作。不存在你写完愿景文档、全组织立刻被它的 brilliant 折服、当场对齐的世界。更可能的是：文档先吃灰，直到你投入精力去 building support。

大多数公司把上面从修热点到对齐方向的技术组合起来，就足以管好技术质量了，希望你也是。但很多人会发现这些还不够，那就走向更重的方案。而第一步永远是：度量。

度量技术质量

软件工程里想度量的愿望，一般都跑在度量能力前面。《Accelerate》给出了度量效能的指标，对定位流程和工具问题很有力，但这些指标都是代码 merge _之后_才开始的。你怎么度量代码库的质量，才能找到差距、提出行动计划，并评估改进的效果？

有些过程度量和有效变革是相关的。例如，你可以度量每个 pull request 改了多少文件，默认小 PR 质量更高。你也可以度量每个文件多少行代码，默认超大文件很难扩展。这两个都可能很有帮助，我甚至建议你度量它们，但我觉得它们最多是代码质量的代理指标。

我的经验是：_可以_有意义地度量代码质量，关键是把质量的定义做得极其精确。质量定义得越细，度量代码库就越有用，对想改进自己那块质量的同学指导性也越强。这个方法在《Building Evolutionary Architectures》和《Reclaim unreasonable software》里有比较详细的描述。

质量定义里可以考虑的代表性成分：

静态类型的代码占比多少？
多少文件有配套测试？
代码库的测试覆盖率是多少？
模块间公有接口有多窄？
多少比例的文件在用推荐的 HTTP 库？
冷启动后接口能否在 500ms 内响应？
多少函数有危险的读后写行为？或者对主库做了不必要的读？
多少接口把所有状态变更都放在单个事务里？
多少函数持有粗粒度锁？
有多少热点文件，在超过一半的 pull request 里都被改到？

欢迎不同意其中某些条目应该进_你的_代码库的质量定义：你的定义应该针对你的代码库和你的需求。重要的是做出精确、可度量的定义。制定定义时会有争论，定义也一定会随时间改。

定义做出来之后，真正的挑战是埋点，没有埋点就没有有用的指标。埋点复杂度是实践中落地这些技术的最大摩擦点，但如果你能挺过去，你会解锁一个相当 phenomenal 的东西：真实、动态的质量分数，可以跟踪趋势，还能带来概念对齐给不了的清晰对齐。

定义并埋点之后，下一步是在投_质量团队_还是投_质量专项_之间选。专职团队容易协同、带宽可预期，一般是更容易的起点。

技术质量团队

_技术质量团队_是一支专门为代码库创造质量的软件工程团队。你可能叫它 Developer Productivity、Developer Tools 或 Product Infrastructure。不管叫什么，这支团队的目标都是在全公司的软件里创造并保持质量。

这不是有时说的 QA 团队。虽然两种团队都会在测试上投钱，但技术质量团队的职责宽得多，从工作流到构建到测试再到接口设计。

从零组建这样一支团队，先固定在三到六人。小团队逼你对 roadmap 无情地按影响力排序，也保证你聚焦在可落地的事上。久而久之，这支团队会攒下需要维护的系统，需要随之扩大投入，Jenkins 集群就是常见例子，这时就按整个工程组织的规模来配人。经验法则都比较 tricky，但大概可以是：每十五个产品工程师，配一个做开发者工具的工程师，基础设施投入另算。

这类团队很少配产品经理，一般由一到多个 Staff-plus 工程师和工程经理搭档来填这个角色。有时会配 TPM，但通常是跨入下一节讲的_质量专项_之后的事。

组建并运营这类团队，成功的一些基本功是：

信指标，不信直觉。 每个项目都要有度量方法。质量是复杂系统，直觉很容易骗你。同样，你在公司越资深，你的经验就越不代表大多数人的经验。坑你都知道，遇到新坑第一个有人来帮你，但大多数人没有。指标让你诚实。
保持直觉新鲜。 代码和流程都在变，你每远离产品功能开发一周，直觉就 stale 一分。大多数人发现 team embedding 和团队轮换是保持直觉 relevant 的最好办法。也有人靠盯聊天记录找问题，以及和产品开发保持健康的 1:1 节奏。最厉害的人两者都做，还随手开着指标 dashboard。
倾听用户、向用户学习。 有个流行的说法叫“taste level”，好像有些人天生就知道什么是好。能做出有效质量投入的人确实差异巨大，但这不是天赋。最厉害的人会深挖用户到底想完成什么，_并且_把用户需求排在实现约束前面。
工具的采用率和易用性远比 raw power 重要。 强大但难用的工具只会有几个死忠用户，大多数人会绕着走。慢下来，把细节做对。藏起所有偶然复杂度。看一个工程师第一次用你的工具，全程别帮他。把 gap 改掉。再做十次！如果你不对自己的工具做用户研究，那你的质量投入团队就 doomed 了。 4. 少做事，把事做好。 当你为整个工程组织 build 东西时，做好任何一件事都会加速整个组织。做砸任何一件事，包括那种差一点就 great、但毛边太多的东西，都会拖住所有人。虽然“把最重要的几件事做好，胜过做一堆平庸项目”几乎永远成立，但在你想给全组织推工具和工作流时更是如此（组织级在制品上限在这里同样适用！）。 5. 别囤积影响力。 中心化质量团队和被它支持的团队之间有根本张力。常常是中心化团队偏好的全局最优方案，让一小撮领域或负载 atypical 的团队极其难受。代表性例子：公司后端都用 JavaScript，不让机器学习工程师用 Python 生态，因为不想维护两套生态。另一个例子：公司统一用 REST/HTTP2/JSON 做所有 API，某个团队偏想用 gRPC。这里没有完美答案，但重要的是建立一个深思熟虑的处事方式，在探索的收益和标准化的收益之间平衡。

用好上面的方法，一支成功的质量团队会 unquestionably 比同样人数直接做产品开发产出更高。确实，折现的开发者生产力（按折现现金流的精神）才是理论上正确的度量这种团队影响的方式。只是理论上，因为这种计算基本是在评估你的自信。

即使你很成功，你的 backlog 里也永远躺着一堆高影响、但没带宽做的事。组织做团队资源决策并不纯理性，你可能会发现重要项目没人做，想给团队招人也批不下来。

团队手里高影响的事多到做不完，这是好信号：如果你做项目不用挑，那就说明你想得还不够广。所以 backlog 长不一定就要扩质量团队。但如果你发现有关键的质量工作没人接，那也许就到了探索启动_质量专项_的时候。

质量专项

_质量专项_根本不是计算机代码，而是一个专职团队牵头的、维护全组织技术质量的 initiative。质量专项承担达到组织目标软件质量水平的广泛职责。这类专项不常见，但你大概见过类似的：负责公司事故复盘和整改的事故专项。

运行质量专项的技术部分就是前面讲的那些，所以这里聚焦怎么把专项管好。第一步是找一位 TPM，跟你 co-lead 这个专项，负责运转它的机制。组织型专项的信息面工作，没 TPM 也能推进不少，但那是陷阱。在大组织里一个人 solo-drive 专项，会被协同开销压垮。

运营组织型专项是个大话题，写过的人很多，但核心打法是：

找到专项 sponsor。 没有 empowered sponsor，你改变不了组织的行为。组织之所以是今天这样，是因为这是它当前约束下的最优解，没有有分量的人帮你 shifting 约束，你动不了它。
做出可持续、可复现的指标。 很多跑专项的人每周花四个多小时手工维护数据集。这不行。数据会有洞，后面没法跟自动化接，你也会累到没力气做真正带来改变的事；刷新指标 dashboard 本身没有任何价值。
给每个受影响团队定专项目标，并给他们一条能走通的路。 专项必须给每个受影响团队定具体目标。比如降低他们测试的 flakiness，或更快地关事故整改。但更重要的是把成功地图给人家！太多专项只管向别的团队提要求，不告诉人家怎么做到。你是这个领域的专家，别把策略外包，让每个团队各自重新发明一遍。
造出帮团队达标的工具和文档。 给团队指了明路之后，想想你怎么帮他们改！可能是给出“长这样就对了”的 golden example，或一个把难啃代码按新模式重构好的示例 pull request。可能是给一个验证迁移正确的测试脚本。可能是自动生成转换提交，测好、验好、合好，全程不用工程师手写。凡是能不让每个团队都深挖一遍你想攻的问题域的，就别让他们挖。
做出目标 dashboard，广而告之。 把每个团队的目标传达下去之后，给 dashboard 帮他们看清现状、目标，以及（希望的）路上的正反馈。最好的 dashboard 既是每个团队工作的记分牌，又能给每个团队下一步往哪使劲的 breadcrumbs。
在三个不同的 zoom level 上，你的 dashboard 都要能打。完全 zoom out 帮你评估专项的影响。完全 zoom in 帮单个团队看清还剩多少活。中间一层帮组织 leader 管住自己的团队（也帮你的 sponsor 对这些 leader 提具体、可执行的要求）。
给掉队的同学发程序化 nudge。
大家都很忙，不会总把你专项的目标放前面。也可能他们一开始改得很好，后面又滑回 deprecated 的老做法。用 nudge 把团队的注意力引到专项目标的下一步上。记住，注意力是稀缺资源！如果你用一封 nudge 邮件或 ping 浪费了人家时间，下一次人家就不看了。
定期跟 sponsor 回顾专项状态。 专项想推的是组织优先级，天然跟各团队自己的目标不对齐。很多团队很难跳出局部优先级去做全局优先级。这时候必须跟 sponsor 一起回顾整体进展，把那些不接专项活的团队指给他看。有效借 sponsor 之力弥合优先级错位，是你成功的关键。

很多方面，专项就是一场没有尽头的迁移，适用于迁移的技术同样适用于专项。

如果你把上面都做对了，你就在跑一个真正 great 的专项。这听起来活很多，wow，确实多：太多专项死掉了。专项失败的三大原因是：

纯从流程视角跑，跟你想达成的现实脱节，
纯从技术视角跑，以为可以跳过倡导目标、倾听被你 motivat 的人这些必备步骤，
一个人想兼顾两种视角——别单干！

烂专项很像低效的非营利组织：目标是对的，但没几个钱真到了目标手里。不管你怎么度量技术质量，跑质量专项时最重要的一件事永远是：专项本身不是目标，创造技术质量才是。组织型专项体量巨大，惯性巨大，早就失效了还能靠惯性往前滑。让你的专项保持 lean 到随时可砍，并保持足够的自我批判，一旦不创造质量就砍掉它。

从小处开始，慢慢加码

当你发现实际技术质量已经大幅落后于目标，第一反应往往是恐慌，然后铺天盖地地上一堆技术和方案。把所有料一股脑倒进锅里，结果必然不好，更糟的是，你连哪部分该留都不知道。

如果你发现自己在技术质量上挣扎——我们都经常挣扎——那就从小处开始，迭代到它 work。再加一种技术，同样迭代到 work。慢慢攒出一个真正 work 的东西，哪怕要顶着“不够快”的指责。在复杂系统和相互依赖面前，求快只是 optics。methodical 的推进才能成事。

与授权保持一致

我的角色里，我们经常几周都见不上一面，但我行事还得像他的直接代理。所以我进一个房间就会想：Matthew 在这里会怎么做？他会想问什么问题？这个问题他给过什么指导？因为我不可能每次都跑回去问他要 clarification，所以对他的世界观有深入理解并持续维护，是必不可少的。这是我保住那份极深信任的根本，让我能作为他的代表，有效执行他的战略和愿景。大家要确信：如果 Matthew 在场，他的答案会和我的一样。——Rick Boone

认为 authority 让人 powerful 是常见误解。很多想往 senior 走的人以为终于能按自己的方式做事了，以为 title 天生带来弹性和自主，以为卡住自己的摩擦会爆成一群蝴蝶、四散飞进风里。

现实要微妙一些。

Title 带来一种叫组织 authority 的权力，而这种权力是更大的组织 authority 借给你的。能给就能收，保住组织 authority 的条件是跟给你 authority 的 sponsor 深度对齐，一般就是你的直属经理。要在 staff-plus 角色里持续有效，就得学会跟组织 authority 保持对齐这门艺术。

走出安全网

收起“公司是为你的成功而设计的”这类残余期待吧。现在，_你_是负责让公司、让团队、让经理成功的人之一。

大多数成熟科技公司都成功建出了一条可预测的晋升流水线，从刚入行的新人一路到 Senior Engineer。拿到 Staff title 的过程一般比之前都复杂，但通常还有工程经理扶着你走完。这条流水线上，你可能已经习惯了经理带你成长、给你兜底。到了 Staff 之后，安全网就没了，顶多剩一张短到你一跳就能越过去、直接掉进后面深渊的网。越往 Senior Staff、Distinguished Engineer 走，越是如此。

Staff-plus 是领导角色，到了领导角色，送你上来的支持系统会褪去，常常是 abrupt 地褪去。现在轮到你把周围的零件对齐，为你自己的成功创造条件。

Serve at the pleasure of the President（凭总统意愿效力）

Rick Boone 在描述自己作为 Uber 基建 VP 的战略顾问这个角色时，把它比作《Game of Thrones》里的 Hand of the King，以及《The West Wing》里 Leo McGarry 常说的那句“I serve at the pleasure of the President”。两个例子都是一样的权力模型：权力来自跟更大的 authority 的紧密绑定。这是对 Staff-plus 角色很好的心智模型。从之前的角色转过来会有些难，因为以前你的 authority 主要靠自己长期的行动和影响一点点攒出来。

如果你和经理已经共事多年，那你们已经在潜移默化中做了一种 subterranean 的对齐。也有另一种情况：新来一位高管，懂怎么支持这类角色，会带来一张 deliberate 的协同地图。但这两种都 largely 不在你控制内，所以值得你自己练出一套向上对齐经理的方法。

跟经理对齐，可以抓这几块：

永远别让经理意外。 没有什么比 surprise 更快摧毁信任。 steering 一个大组织常常要在脑子里同时 juggle 好几个项目、好几个问题，意外会打乱 juggler 的节奏。大而频繁的意外也会让人怀疑 leader 是不是真在为组织负责。一般来说，把每次让经理意外都当一次 incident 来复盘，想办法别再犯。
也别让 sponsor 让你意外。 大多数人对经理的期待极高，比如默认经理永远记得转交跟你手头工作相关的信息。经理们会努力这么做，有的很擅长，有的很不擅长。如果你的经理不擅长，你当然可以给反馈，但也要主动修信息流。可能是每周邮件同步，或在团队频道里用 Slack thread 分享这周的 focus。1:1 里多挖反馈！问问还有哪些地方该使劲，问问当前优先级跟经理的优先级对得上吗。如果你们还在互相 surprise，那就定几条一起用的 controls。
喂给经理上下文。 如果第一步是不用自己的行动 surprise 经理，下一步就是帮经理不被大组织 surprise。如果团队对新政策一肚子怨气，或内部工具撑不住需求了，主动喂给经理。说清楚你_不是_甩个问题让他解，而是传一份你觉得有用的信息。有观点很好，有数据更好。

有时你会听到有人挤兑同事，说他擅长“向上管理”。向上管理确实有 destructive 的玩法，比如控制信息隐瞒问题、歪曲情况，但向上管理的内核是增加你和经理之间的带宽、减少摩擦。刻意经营跟经理的伙伴关系，比在经理没达到你期待时练习失望有用得多。

不带太多摩擦地影响

成长为 leader 的一部分，是长出自己对世界应该如何运转的看法，没这个到不了 Staff-plus。对事情应该长什么样有清晰判断，你的判断才会锋利，才能 proactive 行动。到了领导力的下一站，你越来越要把自己的愿景和更 senior 组织 leader 的愿景合到一起。

你的第一反应可能是拿别人的愿景替换自己的，这对有些人管用，但对很多人来说，这等于亲手扔掉那个带自己成功的、有判断力的 proactive leader 视角。我建议的做法是： sharpen 你对价值差异的觉察——哪些是你坚持的，哪些是组织在用的——找到一种不被踢出房间的倡导方式。

人只能这么快地变，组织又是由人组成的。你方法得当，假以时日，你对组织 leader 的影响会 immense，但前提是你学会在每一步都保持 tight 对齐，只有这样你才换得到这个时间。

要领导，先跟随

把全局思考用到局部。就是把团队的（技术）initiative/roadmap 对齐到全工程的技术战略上；偏离主路去服务团队眼前 stakeholder 时，是故意的。就是跟团队的经理们一起，从别的团队捡好用的招聘、onboarding、生产运维实践；也把自己团队的好实践分享出去。就是拿公司级的业务/产品战略上下文，翻译成对团队手头项目的影响。——Ras Kasa Williams

多年前，我在的公司招了一位新的工程总监，CTO 聊起为什么这是个 amazing hire。新总监的 clinching 成就是：对领导力和管理的区别给出过史上最佳解释。后来证明这不是什么有效的招人标准，但确实是个有意思的话题。

领导力和管理已经被讨论到烂了，很难再添什么新东西，不过大致上，管理是一个具体职业，领导力是一种任何职业里都能展现的 approach。

我对领导力的理解这几年变了一点，收敛到两个具体属性上。第一，leader 对事情应该如何运转有足够清晰的看法，能靠“现实如何”与“应该如何”之间的 distiction，找出 proactive、congruent 的行动去缩小差距。第二，他足够在乎这个差距，真去动手缩小它。

只看到差距不动手，你可能是 visionary，但你是 inert 的。没有清晰目标就动手，很多人会觉得你是 leader，但你的影响会是随机、任意、低效的。两者兼备再加一点运气，职业路大概差不了，而这正是我合作过的、顺利转进 staff 或高级管理的同学们的共性。

但这种领导力只能带你走这么远。就我个人，花了 好几年 瞎撞才明白：为什么我这套领导方法刚加入一家公司时战无不胜，久了反而慢慢侵蚀大家对我贡献的认可。我慢慢学到的教训是：学不会跟随，就做不了长期的有效 leader。

这是我过去几年学到的最重要一课：最有效的 leader 花在跟随上的时间比领导更多。这个想法也出现在“第一个 follower 造就 leader”里，但有效 leader 不把世界切成 leader 和 follower 两半，而是跟周围的人时而领导、时而跟随，进出自如。

落地的方法有很多。

对自己真正的优先级诚实，别被找上门的事稀释。如果你只是轻微不同意，就让别人 lead 着把它搞定。这里有个好问题：“六个月后，这里的事还 matter 吗？”如果不，那就趁机跟随。
给做改进的其他 leader 快一点的支持。即使你不同意他一开始的做法，可信的人 lead 的项目 almost al- ways 会到好结果。如果 lead 的人可信，你还是不放心让他往前走，想想为什么你对影响他这么没信心，是不是你不擅长给反馈。
把反馈明确标成 non-blocking。可以是 code review 里标“optional nit”，也可以是写一份详细的反馈，但交给对方时说清楚只是分享视角，不一定非要他改。

如果你在这事上挣扎过，我懂，我也挣扎过。当你的世界观强到能领导时，你身边会聚起一群依赖你维持这个世界物理规则的人，容忍任何偏离你的愿景，都像在辜负他们。但这正是典型的带你到一层、拦你在下一层的东西：继续成长要求你把自己的世界观融进周围人的世界观，加速整体的进展，哪怕意味着容忍一段绕路。

一个人能做成的，远比不上一群 leader 能做成的。想做 great leader，先花时间学跟随。

学会永远不错

我会拿出我认为对我们最有利的方案，大家可以不同意。说实话，他们也经常不同意。我更多是在引导和影响，而不是说：“我有权直接告诉你该怎么做。”我从没见过那种风格能真正奏效。——Keavy McMinn

大多数人都和自认为永远不错的人共事过。每次讨论中，他们都会身体前倾、端起架子，强行把自己变成拍板的人。他们会一直争论下去，直到自己的观点获胜，或者时间耗尽。他们常常是对的，但那种正确会把房间里的空气吸干。随着他们在公司的资历越来越深，他们可能觉得自己变得很有说服力，但那往往是一种靠同伴放弃抵抗换来的“说服”。

我合作过的技术领导者中，有几位找到了不压制全场、却永远不错的方法：在给别人留出空间的同时保持正确。在我心中一直践行这一点的是 Franklin Hu，我见过他很多次，靠着“为所有人找到最好结果”的信念、愿意放弃自己的初始立场，以及默认“一定还有一条没看到的额外信息，能把看似冲突的观点统一起来”，可靠地化解充满争议的讨论。

要成为资深技术领导者，你必须对技术和架构建立深刻的见解。而要真正胜任这样的领导角色，你还必须培养同样深刻的务实和对技术信仰的不可知论，对自己始终保持怀疑。这听起来像个悖论，但这正是你每天都要走的钢丝。

倾听、澄清和读懂房间

很多时候，你会看到工程师带着“我的观点是对的”的自信走进讨论，目标是让房间里的其他人同意自己的方案。这种心态把每次会议都变成了零和辩论。即使在“最好”的情况下——方案通过了，他们也没有从房间里的其他人身上学到任何东西，剩下的人也不太可能带着干劲离开。

最高效的工程师走进每次会议，目标是先就手头的问题达成一致，理解房间里每个人的需求和视角，并弄清楚要对齐方案还需要做什么。他们把每次会议都看作项目大局和人际关系中的一轮互动。如果房间已经准备好达成一致、往前走，他们就帮团队落定方案；如果还没准备好，他们不会强行推动。

要练好这一点，你需要掌握三种方法：用提问来倾听、明确目标、读懂房间。

用提问来倾听是一种主动倾听，目的是理解房间里其他人的视角。带着善意问出好问题，本身就能打开对话，为别人提出自己的问题创造空间和安全感。好问题出于求知的欲望，而且足够具体。它们能让讨论更锋利，能让回答者从“为自己辩护”的义务中解脱出来。在一场可能有争议的会议里，先问三个好问题再表达自己的观点，你会看到整个房间的气氛都变了。

好的会议从清晰的目标和议程开始，但很多会议并不符合好会议的定义，特别是临时起意的讨论。如果你发现自己身处一场目标不清的对话中，那就明确目标。花一点时间确认一下你对“大家希望达成什么”的理解是否正确。最有效的方式是把陈述包在一个澄清式问题里，比如：“确认一下，我们这次的目标是决定项目发布是否推迟两周，对吗？”

注意，明确目标如果用得太频繁，反而会起反作用。它不再是澄清对话，而是制造对话内耗。一般来说，如果已经有人尝试过，就尽量不要再用。出现多次 reframing 都失败的会议，几乎总是以“再约一次会”收场。

最后，在每场会议里，你都要读懂房间。很多人对讨论感到 frustrated，就会试图强行达成一致，这会给讨论施加巨大压力，反而不太可能好好收场。如果房间里的人分歧太大，就找一个愿意花更多时间深挖的子集单独讨论，或者在会外找到合适的升级对象。如果抽屉里东西实在太多，就别硬往里塞了。

如何练习

如果这些行为对你来说并不自然，没关系，练习的机会无处不在。每一条文档评论都是机会，每一场会议都是机会，每一个 pull request 都是机会。

每周开始时，挑一项你想刻意使用的技能，带进你要参加的会议里。如果有一场特别难的会议，提前花点时间在脑子里演练一下，或者找个同事模拟练习：用这些方法，如何在困难中推动进展。

难缠的人

上面的方法大多数时候都管用，但不是每次都管用，一个明显的例外就是遇到难缠的人。这里说的难缠，是指不愿服从集体、拒绝妥协、不听人说话的人。这种人还没明白：职业生涯更多取决于“让人愿意和你合作”，而不是“技术上正确”。

对付难缠的人，最有效的两招是：

把一个他不敢难缠的人拉进会议（比如他的经理或 CTO）
会前花大力气先和他对齐，让他觉得自己被听见了，开会时也就不太会掀桌子

这两招都会让你觉得花时间很荒谬，但它们往往最管用，特别是对那些你不常打交道的人。如果这个人属于你负责的领域，或者是你经常合作的人，你的义务就不太一样。这时要尽量温和但诚实地给他反馈。给一次，再给第二次。两次都记下来，如果还是没有改进，就带着具体记录，当面或视频找他的经理沟通。

还有一点很有用：你的 title 带来的权威给你挡掉了很多这类人，所以你感受到的难缠程度，已经是打折后的版本。对你来说还只是 borderline 的行为，对别人可能已经严重得多。

这样做有什么帮助

这个方法之所以有力，是因为复杂项目更多是被人与人之间的冲突拖垮的，而不是被技术复杂度拖垮的，而这是一套可以重复使用的、把紧张变成合作的方法。它感觉上很慢，因为启动可能更花时间，但最终其实更快，因为工作更可能不受干扰地做完。

另外，资深领导者的长寿，和维护关系有同样大的关系，而不只靠高光时刻。你会看到很多人红极一时，后来却因为失去支持而寸步难行。如果你不想落到那个下场，就学会永远不错，并且永远不要停止练习。

为他人创造空间

到这个阶段，我花在鼓吹具体技术或项目上的时间越来越少，更多时间花在赋能别人，让他们去为自己认为重要的技术和项目发声。我也努力成为一个知识和支持的来源，大家在遇到跨领域的产品决策、或者要向整个组织呈现想法时，可以来找我聊聊要反馈。——Michelle Bu

衡量你作为 Staff 及以上工程师长期是否成功，最好的标准之一是：你周围的组织越来越受益于你的贡献，但不再依赖你的贡献。因为很多人是靠做组织的“go-to 人物”第一次升到 Staff 及以上的，从不可或缺转到退居旁边，会是一个艰难的转变。

这个转变要求你有意识地为身边的团队创造空间：主动把他们拉进讨论和决策，最终用举荐他人来替代重复当年让你升到 Staff 的成功路径。

讨论

当你只关注最大化个人影响时，好的讨论就是：快速结束，得出一个合理的答案，参与者达成一致，大家心情也不错。当你开始想为别人创造空间时，好会议的定义就宽得多！

在这个更宽的定义里，好会议取决于有没有让更多人参与进来，能不能在几乎不需要你亲自贡献的情况下得出好的决策。在这个新世界里，好会议就是：原来没有你参加也行。当你做出关键贡献时，为此高兴一下没问题，然后想一想，下次要发生什么，才能让别人做出这个贡献。

除了心态转变，下面几个技巧对我在讨论中创造空间很有帮助：

把你的贡献转向提问。问对问题既能避免走错路，也能让更多人更容易参与进来
如果看到会议里有人没参与，把他拉进讨论。最好一次只拉恰好一个人。一下子面向所有人开放，或者一次拉两三个人，都会让人混乱
主动做会议记录。这能帮你把记笔记从“低 status”的刻板印象里摘出来，也能把原本要记笔记的人解放出来，让他更多参与讨论。还能让你有事可做，而不是只顾着发言！
如果发现本该参加讨论的人缺席了，主动把他拉进下一次会议。和会议组织者聊聊，告诉他为什么拉这个人进来很有价值

当你越来越忠实地做到这些，你在会议中的存在感会变小，你对组织的影响会变大。

决策

在职业生涯的大部分时间里，成功就是做出正确的决策，要花很长时间你才会意识到，到了一定阶段，做决策本身不再是工作。Ritu Vincent 很好地描述了这个转变，

也是在那个项目上，我的经理让我明白，我作为 tech lead 的第一反应是不可扩展的。一开始我想的是：“我把它拆成二十块，分出去十八块，把最难的两块留给自己，”而我的经理 push 我把难的部分也分给团队，去拉伸和培养他们，

和发展他们。

另一方面，把你的判断力转移给别人很难，特别是复杂的决策。好在你可以用渐进的方式，把越来越复杂、越来越重要的决策交到更大的团队手里。

写下来。 有个关于天才的经典模型，Feynman 算法：“1）写下问题。2）使劲想。3）写下答案。”这种对天才的神秘化看法既遥不可及又让人气馁。它也不真实，但如果你不把思考过程写下来，别人就很难知道它不真实。把找到答案的过程和答案背后的理由都写下来，周围的人才能从你的决策中学习，而不只是被你的决策指挥
尽早分享， 在你还没有下定决心之前就分享。大多数人都很难收回已经形成的观点，早点收集反馈，更容易吸收反馈，也更容易让大家参与决策过程，让他们看到你的思考轨迹，而不只是最终输出
把风格和实质分开， 别再对别人的决策给风格上的反馈。如果一条反馈不会实质影响项目成败，那就考虑不说。如果有用但不关键，可以私下建议，而不是把会议拉进你的轨道
不要为了刷存在感。有些资深的人觉得什么都要插一句，才能证明自己的资历。还有些人要求每个决策都必须和自己当年做过的某个决策一模一样。这两种都是把 insecurity 放在影响力前面，会阻止别人成长为领导者
改变主意。 对同事最大的尊重之一，就是听进去他们的话，然后改变主意。如果资深领导者从不改变主意，很快所有人都会把嗓门大和成功划等号

把大家拉进你做的决策、分享你的决策方法，是培养身边团队的重要一环，但如果把决策本身变成他们的呢？

举荐他人

把大家拉进你的讨论和决策，是让他们参与你的工作。这是成长、凝聚和向周围人学习的好方法，但在某个时刻，你必须再往前走一步。

不再是让他们参与你的工作，而是把工作变成他们的。

最后一步，就是把当年让你升到 Staff 及以上的那类工作，举荐给别人去做。当关键工作找到你时，你的第一个问题应该变成：“谁既能做好这件事，又能借此成长？”争取让他来 lead 这项工作，然后和他一起把项目搭好脚手架，帮他成功。你的做法会是什么？有哪些一开始就要想清楚的风险？应该早点和哪些 stakeholder 聊这个问题？

当你发现新的关键工作，比如发现工具或流程上的缺口，想想还有谁能提出这项工作，然后坐下来，让他写出你本来打算写的那份 proposal。再像支持你自己的 proposal 一样，去为他的 proposal 争取支持。

重要的是，工作交出去之后，就让它真正属于他。给建议、给上下文、做参谋，但最终举荐就包括允许他用你不会用的方法去做。可能最后搞砸了，他会从中学习——就像你职业生涯里从错误中学到的一样。也可能最后做得非常好，那反而是你学到了东西。

举荐应该成为你面对问题的默认方式，但不应该是你唯一的工具。大多数 Staff 及以上工程师都觉得，直接参与一些项目、保留对软件、工具和组织实际运转的体感，仍然很重要。如果需要一个经验法则，记一个举荐日志，确保每个月至少举荐别人几次——如果发现自己举荐得比这还少，就深挖一下是什么卡住了你。反过来，如果回头看，发现过去几个月自己完全没有亲手做过任何事，那也值得纠正一下。

如果不这样做会怎样？

如果你是靠成为某个关键公司领导者的“go-to 人物”、铺好最后一块 Staff 及以上之路的，那你已经知道：替组织领导者解决 urgent 问题，是获得认可最稳的路之一。如果你是靠成为技术 visionary、想法渗透公司架构路线图走上来的，那你已经知道：把守公司技术未来之门，是多么有力量的感觉。

这些都很难放下。

但是，这种模式的最好结果，也不过是一家在某个人离开之前暂时繁荣的公司。而更常见的坏结果是，一家公司被你个人的局限卡住，而唯一能容忍被你卡住的公司，就是不再生长的公司。

要长期做一家真正成功的公司的领导者，唯一的办法就是不断为别人创造空间，把让你坐到今天这个位置的认可、回报和工作让出去。这会出乎意料地让人不舒服，但别担心：属于你的新工作永远都会有。

建立同行人脉

在我和越来越多 Staff 及以上工程师聊职业建议时，最一致的推荐就是建立一个做类似工作的个人同行网络。不是每个人都强调这一点，但超过一半的人提到了，对提到的人来说，这往往是他们第一条、也是最强烈的建议。

Ritu Vincent 说，

对我影响最大的，是有很多我当作 mentor 的人，通常是朋友、前经理和合作过的人。我有不少每月固定的午餐、咖啡和晚餐，和过去和我共事过、了解我、我也信任的人一起。正是这些关于职业挑战和成长的对话，把我带到了今天的位置。

Keavy McMinn 把她的人脉看作获得诚实反馈的重要方式，

我首先想到的是找到你的同行或支持网络。和管理一样，越往上走越孤独，找到还会 challenge 你、还能一起 brainstorm 的同行很重要。他们甚至不一定和你在同一个领域，甚至不在同一家公司都没关系。

Nelson Elhage 也同样分享道，

对我来说，培养一个好的资深工程师个人网络非常有价值。我会非正式地和他们聊聊各自在做什么、在想什么。有了私人连接，你就能看到大家遇到的最真实的问题，和他们正在考虑的解法。

知道应该建人脉很有帮助，但有些人不知道具体怎么做。在各种建人脉的方法里，最常见的两种是：让别人容易找到你，和在内部 networking。

让自己被看见

Staff 及以上工程师对社区的需求一直被压抑着，所以建人脉最简单的方法就是让自己作为 Staff 及以上工程师容易被找到。一个有效的方法是参与 Staff 及以上工程这个话题本身的讨论，比如 Joy Ebert 的 What a Senior Staff Software Engineer Actually Does，或者 Keavy McMinn 的 Thriving on the Technical Leadership Path。虽然已经有不少人写过自己眼中的 Staff 及以上角色，但每篇都会带来新的、有价值的视角。你的观点也有位置。

如果写作不适合你，你的声音也有位置，在技术会议上演讲是另一种在更大社区里被看见的有效方式。Keavy McMinn 这样描述她做会议演讲的动机，

主要是，我喜欢在会议上遇到的人。后来演讲者网络还给我带来了工作机会。

如果这两件事都觉得门槛太高，哪怕开个 Twitter 账号，或者加几个相关的 Slack（比如 Rands Leadership Slack 里的 #staff-principal-engineering），都是不错的开始。

内部人脉也要建

Katie Sylor-Miller 的 networking 建议不是对外演讲写作，而是建好你现在公司内部的人脉，

Networking，networking，networking，networking……你必须非常清楚自己在和谁聊，确保在多个团队、多个组织里都有连接，能用上这些网络。

虽然 networking 听起来像是只发生在外部的事，但在你已经在的公司里做往往更容易，在日常工作中半自然、半刻意地发生。这个方法还有个直接好处：直接改善你的日常工作。长期看，这些人以后会离开、散布到整个行业，反过来成为你更大人脉的起点。在一家足够大或足够有名的公司里，这招特别好用，公司越小或越不知名，效果就打点折扣。

环境式人脉

在没提建立个人人脉的人里，大多数提到了建立环境式学习网络：跟进行业书籍，在社交网络、特别是 Twitter 上关注行业领导者。

Diana Pojar 的说法是

我重度用 Twitter，但我基本是个消费者，关注了很多技术圈的人。我一般关注在会议上讲过、或者合作过、内容对我 relevant 的人。比如这几个，不分先后：Camille Fournier、Lara Hogan、Josh Wills、Vicki Boykis、David Gasca、Julia Grace、Holden Karau、John Allspaw、Charity Majors、Theo Schlossnagle、Jessica Joy Kerr、Sarah Catanzaro、Orange Book。

Damian Schenkelman 提到，

我会在 Twitter 上关注我觉得在做有意思事情、能让我学到东西的人。有太多人在做有意思的事，有太多可学的东西！我能想到的名字有：[包括 Aphyr、Tanya Reilly 和 David Fowler]。

如果建人脉这件事让你觉得不自在，建环境式人脉可以是朝正确方向迈出的第一步。不过你会发现个人人脉更有影响力，找到一种真诚的建人脉方式，是在职业生涯长弧线上站稳资深角色、持续有影响力的重要一步。

重质不重量

有个同事 once 给我讲过一个故事：有人立志在 Business Development 出名，会带着一份想见的人名单从 SF 飞到 NYC。看 tweets 和 Foursquare 签到猜这些人晚上可能在哪，过去买杯酒，假装偶遇。一晚上顺利的话，能这样“认识”六个以上新 connections。

不用说，你不该这么做——这完全踩过了边界。更何况这么做根本没意义：建同行人脉，数量不重要。相反，要慢慢和你真正信任、尊重、受其启发的人建连接。这才是真正强大的网络，能帮你解决最难的问题和最棘手的情况。

最后，如果你读到这一段，真的很想建人脉但不知道从哪开始，我分享一下自己作为内向者、 struggled 过后找到的真诚方法。找一个你尊重的人，发一封简短的一两段邮件或 DM，问一个具体的求建议的问题。如果他回了，谢谢他，六到十二个月后再问下一个问题。如果后来他找你帮忙或问问题，尽力帮。如果他没回，也别放心上，直接 move on 就好，不用多说什么。这招出奇地管用，最坏的结果也完全可以接受：他只是不回而已。

向高管汇报

你有没有给公司高管讲过关键工程项目，兴奋地走进房间，垂头丧气地出来？可能你才讲到第二页，就被不相关的问题带跑了。可能你讲完了整个 presentation，大家说了句“Great job”就走了，没有任何有用的讨论。事后你不太说得清发生了什么，但你知道结果不好。

职业生涯早期，你可能不常和公司高管打交道。当然，公司够小的话也可能，但那不是常态。越往后走，你的影响力就越被“有效影响高管”的能力卡住。保持和 authority 对齐是影响高管的前提，但除此之外，还有一些新的沟通技能要练。

为什么这很难

每个人职业生涯里都遇到过糟糕的高管，但大多数高管并不糟糕。几乎每个高管都在某件事上 extremely 出色，只不过那件事经常不是你要和他沟通的话题。加上他们在这件事上时间有限，沟通自然是个挑战。

但那些还只是普通的沟通挑战，和高管沟通之所以出乎意料地难，还有个不太明显的原因：高管已经习惯了以特定方式被预处理过的现实。

每个高管几乎都在某一种信息消费方式上 uncannily 擅长。他们用那种方式消费数据最舒服，围绕他们的整个沟通系统也被优化成只用那种方式和他沟通。我把这叫作预处理现实，用错了预处理方式，经常会造成双方都说不清的误解。

比如，有些高管极擅长 pattern matching。他们在任何汇报里的第一反应，都是连珠炮似地问一串细节的、看似随机的问题，直到能 match 上自己过去的经验。如果你给这种高管做结构化的学院派汇报，他会 bored，你大部分时间都在讲他根本不会消费的信息。还有些高管，你说的任何话如果不连到具体数据或数据集上，他都会无视。你自信满满地讲着，知道数据都在附录里，他却越来越觉得你的 proposal 没有依据。

在大多数其他场景，误解带来的是延迟而不是错误。但和高管沟通时，相关决策做出之前，你往往没有第二次讨论的机会。事前多投入，才能避免事后 lament。

如何有效沟通

和高管有效沟通的基础，是先搞清楚你为什么要和他沟通。你可能习惯了为了说服对方或同步项目去沟通，但这里大概率不是。当你和高管沟通时，几乎总是三件事之一：做规划、汇报状态、解决 misalignment。

虽然这是三件不同的事，但你的目标永远是尽可能从高管那里挖出视角。如果你抱着改变他想法的心态进去，很容易显得 inflexible。抱着理解如何和他的优先级对齐的心态进去，你会显得 strategic，也很可能带着足够的信息离开，能把现有计划调整到他刚说清的重点或约束里。

挖出他视角的最好方式，是写一份结构化文档。写作逼你全面思考自己的信念和数据。结构确保读者聚焦在重要的事上。Barbara Minto 的 The Pyramid Principle 是最有影响力的有效商务沟通著作，她也是结构的 big fan：

控制你呈现想法的顺序，是清晰写作最重要的动作。最清晰的顺序永远是先给总结性的想法，再给被总结的各个想法。这一点我再怎么强调都不为过。

能用的结构很多，但我特别推荐每份文档的开头段都用 SCQA 格式：

Situation：相关背景是什么？举例：我们已经连续两年在产品功能交付上落后于竞争对手。去年我们把工程团队翻了一倍，交付的功能反而比前一年更少。
Complication： 为什么当前情况有问题？举例：我们今年还打算再把工程团队翻一倍，但根据去年的经验，我们觉得这会进一步降低 velocity，同时大幅推高组织预算。
Question： 要解决的核心问题是什么？举例： 今年还要继续按计划把工程团队翻倍吗？
Answer： 你对这个问题的最好答案是什么？举例：我们应该暂停招聘六个月，先把现有团队磨合好。根据到时的进展，再刷新今年剩下的招聘计划。

在很多讨论里，一个结构良好的开头段就足以引出重要对话。虽然那种情况下你可能聊不到文档后面，但写文档的过程仍然是打磨思考的重要一步。

用正式结构写完整篇文档的人相对较少，但至少有一个流行的格式有些人觉得有用：前面那本书里的 Minto Pyramid Principle。先把你的 proposal brainstorm 成一系列支撑答案的论点。都写下来之后，把相关的论点分组。把这些组塑造成三个顶层论点，每个顶层论点最多带三个子论点。递归地用这个方法，确保每个论点都是对其最多三个子论点的总结。组内论点按重要性降序排列。到这一步，就算完成。

我个人觉得 SCQA 上手就有用，但我承认第一次按 Pyramid Principle 写时，感觉像盯着 Brutalist 建筑。练多了慢慢顺眼了，但我还是建议大多数人先把 SCQA 作为核心习惯，只有在收到“汇报不好跟”的反馈后，再去用完整的 Pyramid Principle。

写完结构化文档，先找同行和 stakeholder 要反馈。汇报前先和 stakeholder 对齐，有时叫 nemawashi，对减少意外 extremely 有效。有些同行应该有给高管汇报的经验，能给出有用的改进意见。

汇报本身，要有清晰的议程，但别死守议程。和高管开出好会，标准是有投入的讨论，而不是走完议程上的每一项。有人会觉得这是争议观点，更愿意用 action items 衡量每场会议，但这忽略了这类会议里往往更有价值的部分：关系的建立和发展。

要避免的错误

即使准备得很好，给高管的汇报有时还是会翻车。你没法避开所有坏路径，但可以避开那些 routine 翻车的反模式。

永远不要对抗反馈。高管经常手里有关键的一条反馈，只是当下还没找到合适的 framing 说出来。你要让他说出来，而不是憋回去、回头就忘了。如果你表现得抗拒反馈，他就会开始吞评论，你在这场会议里也得不到什么。先聚焦收集反馈，同不同意等下来有时间再说。如果有个必须拍的决策你不同意，可以抛出一两条可能改变他想法的相关数据，然后就放下。会后反思反馈、再去改变他的想法，比在会上硬顶有效得多。

不要逃避责任或问题。 很多人想对领导藏问题，这永远没好下场。厉害的人把告知高管看作 absolution：一旦摆到台面上，就可以从藏转向解。特别是高管在会上嗅出问题的时候，更要迎上去，别躲。用他的视角认下来，会后再补更多数据，会给你加 credibility；和他争，会损害你的 credibility。

不要只抛问题不给答案。 给新领导的常见建议是“永远不要只带问题不带解法找你经理”。这话一般来说不算好建议，但如果你给高管抛问题却不给建议答案，他心里会嘀咕是不是要招个更资深的领导来补你或换你。没有 proposal 让大家对齐，房间里就形不成对齐。

避免学院派汇报。 学校里教你的那种汇报方式，多多少少就是给高管汇报的错误方式。Minto Pyramid Principle 照着做，能把你带回正路。

不要执念于你想要的结果。 很多人对自己想要的结果太执着，花尽力气抗拒那些明摆着“不会如愿”的信号。看到“错误”的决策做出来，很容易 frustrated，但记住你缺了很多 context 会有帮助：没有永久的决策，几乎每个决策在未来两年里都会被重新审视好几次。

给高管汇报会让人紧张，这些建议可能多到让人焦虑。如果浓缩成一条简洁的建议：提前发一版草稿给参会的高管，问他要改什么。听进去、改到位，其他部分你慢慢就会了。

Keyboard shortcuts

Staff Engineer（中文版）