好书精读 · READ 919
Tanya Reilly · O'Reilly · 2022
升到 Staff 之后，你的工作不再是「写更难的代码」，而是在没有一个下属、没有任何强制权的前提下，去改变一群人做事的方式——而这本书是目前把「具体怎么做」讲得最落地的一本：怎么看清全局、怎么决定不做什么、怎么把一个跨越多个团队的大项目真正推完、怎么在不当经理的情况下把周围的人一起抬起来。
塔尼娅·赖利（Tanya Reilly）在 Google 做过十几年 SRE（site reliability engineering，站点可靠性工程），后来在 Squarespace 做 Principal Engineer。她 2019 年那场题为「Being Glue（当胶水的人）」的演讲在工程圈流传极广——「胶水工作」这个词能进入行业词汇表，很大程度上是因为她。这本书与威尔·拉尔森的《Staff Engineer》是一对：拉尔森回答「Staff 工程师是什么、怎么升上去」，赖利回答「升上去之后，每一天具体干什么」。
全书最好用的工具是三张地图的比喻。她说，工程师之所以做出局部合理、全局荒唐的决定，通常不是因为笨，而是手里只有一张放大到自己团队的地图。
这三张图为什么值得当成一套工具随身带：它把「你不够有全局观」这句空洞的批评，拆成了三个可以分别去补的具体缺口。下次你觉得一个技术争论怎么吵都吵不出结果，先别急着讲道理，问一句：我们缺的是哪张图？——是不知道自己在整体里的位置（定位图），是不知道路上有什么障碍（地形图），还是压根没有共同的终点（藏宝图）？我的经验是，绝大多数「技术分歧」其实是第三张图缺失，而人们花了三周在辩论第一张。
与三张地图配套的是一个更细的技能：altitude（高度）。赖利把工程师的注意力比作飞机的飞行高度——你可以贴地飞（钻进某个函数的实现细节），也可以上到三万英尺（看整个公司三年的技术方向）。
关键在于：没有一个「正确的高度」，只有「此刻正确的高度」，而 Staff+ 的本事是能在两者之间自如上下。一直贴地飞，你就只是个产出很高的资深工程师，视野被机身挡住；一直待在三万英尺，你会变成那种写出漂亮愿景文档、却对真实系统一无所知的人——组织里没人比这种人更快失去可信度，因为工程师能在三句话内闻出一个不碰代码的人在讲什么。她的建议很实在：定期降落一次，亲手做一点真实的工作（修个 bug、值一次班、跑一遍新人的上手流程），不是为了产出，是为了让你的高空判断有地面数据支撑。
它改变你看问题的地方在于：当你觉得一个人「说得不对」时，多半不是他错了，而是你们不在同一个高度上说话。他在讲这个季度这个接口怎么改，你在讲三年后这套架构该不该存在——两句话都成立，但对不上。先对齐高度，再讨论对错。
这是赖利最有名、也最有社会意义的一个概念。胶水工作（glue work）指的是那些让一个团队真正能运转、却不产出任何「可归功于你的交付物」的活：注意到两个团队在重复造轮子并把他们拉到一起；发现设计文档里有个没人问的关键漏洞；带新人上手；把一个吵了三周的决定写成文档定下来；在项目要散架时接住它。
她的观察分两层，两层都得讲清楚。第一层：这些工作是必需的。没有它，项目会以一种没人说得清原因的方式慢慢烂掉——大家都很忙，但事就是不往前走。第二层，也是更扎心的一层：这些工作通常不算在晋升的账本上。晋升评审要看的是「你主导了什么、交付了什么、影响力可否归因于你」，而胶水工作的本质是它的成果会显示为「别人的项目成功了」。
然后是她那个被引用最多的判断：这类工作在组织里的分配并不随机——它更容易落在女性、少数群体，以及任何一个「因为责任心强所以看见了就去做」的人头上。于是形成一个残酷的循环：越是把团队黏住的人，越容易在晋升时被评价为「贡献不够突出」。
她给的建议是双面的，而且她自己承认这不是一个完整的解法：其一，看清你在做的是什么，别糊里糊涂地做。做之前先问：这件事重要吗？如果重要，它是不是应该由一个人的业余善意来承担，还是应该变成一个有名字、有归属、被认可的正式项目？其二，如果你要做，就把它做成「可被看见」的形态——把「我帮忙协调了一下」变成「我主导了 X 系统的迁移对齐，产出了这份决策文档」。同一件事，说法不同，命运不同。这不是教你包装，而是纠正一个真实存在的记账错误。
它如何改变你看世界：以后你评价一个团队时，会开始去找那个「胶水」是谁。一个运转顺畅的组织里，总有一两个人在承担大量看不见的黏合工作。他们通常不是绩效榜上最亮的名字——而当他们离职时，你会在接下来的两个季度里，才终于知道他们一直在做什么。
她坚持把这两个词分开，因为混用它们是很多「技术规划文档」最后变成废纸的原因。
| 技术愿景 technical vision | 技术战略 technical strategy | |
| 回答什么 | 到那时候，好的样子长什么样 | 从今天的处境出发，怎么过去 |
| 对应地图 | 藏宝图上的那个「×」 | 在地形图上画出来的那条路线 |
| 失败的样子 | 一堆漂亮的形容词，谁都同意，谁都不受影响 | 一张什么都要做的清单，等于什么都不做 |
愿景说「哪儿」，战略说「怎么去」——缺前者会瞎跑，缺后者只会开会。
她在讲战略时明确引了理查德·鲁梅尔特《好战略，坏战略》里的那个「战略内核」：一份真战略必须有诊断（我们眼下真正的问题是什么，不是症状清单）、指导方针（面对这个诊断，我们选择走哪条路、放弃哪条）、一组连贯的行动（这个方针落到具体动作上是什么）。坏战略的标志正是缺了第一项：不做诊断，直接跳到一串目标。「我们要提升系统稳定性、加快交付速度、改善开发者体验」——这三句话没有任何人会反对，也没有任何人会因此改变明天的行为，因为它没有告诉任何人该放弃什么。
她还有一句很反直觉的忠告：写战略最难的不是写，是先去和所有相关的人聊一遍。一份没人参与就写出来的战略，无论多正确，都会在评审会上被礼貌地赞美然后遗忘——因为战略的价值不在文档里，在共识里；文档只是共识的存档。
Staff+ 最典型的痛苦不是不会做，而是什么都值得做、什么都在等你。她的处理办法是把「你有什么」摊开来数清楚，而其中两项是工程师最容易忽略的。
可信度（credibility）：别人相信你的技术判断的程度。它靠交付赚来——你说会成的事真的成了，说有风险的地方真的出了事。它的用处是：当你要做一件当下看不出好处、需要别人先信你半年的事时，你花的是这笔钱。一个刚到岗的人没有这笔存款，所以聪明的做法是先挑一两件周期短、能干成、别人看得见的事，把账户充上。
社会资本（social capital）：别人是否愿意跟你合作、是否乐意帮你的忙。它和可信度不是一回事——你可以技术上极受尊敬，同时没人想跟你一起做项目。它靠帮别人、靠好好合作、靠说到做到赚来；每次你请人插队、请人妥协、请人接受一个他并不喜欢的决定，都在花它。
这两个「账户」的比喻为什么重要：它把「政治」这件很多工程师本能反感的事，翻译成了一套他们熟悉的语言——资源管理。你不必喜欢它，但你至少能算账：这件事值得我花掉多少可信度？我这个季度是不是只在花、从来没在存？一个总在提反对意见、从不交付东西的人，是在赤字运行；而一个交付很多、却从不与人协作的人，账上一边余额爆表、另一边早已透支。
还有一条她说得很重的：「你可以做任何事，但不能做所有事。」Staff 工程师最常见的失败模式不是选错了项目，而是同时挂着五个项目、每一个都推进到 60%。所以她主张定期问自己一个近乎冒犯的问题：此时此刻，我能做的最重要的事是什么？我在做它吗？如果不是，要么换事做，要么诚实承认你选择了别的——但别假装自己很忙就等于在做正确的事。
带一个跨越多个团队、要做半年的项目，是 Staff 工程师最典型的活。赖利的核心判断是：这类项目失败，几乎从来不是因为技术难度，而是因为「共识」在某个地方碎掉了。她把要维护的共识拆成几层，每一层都值得单独确认：
对应的还有一个很好用的诊断问题：「我们为什么停下来了？」项目卡住时，人们的本能是加班、加人、催进度，而她的建议是先把停滞归类：是没人知道下一步是什么（缺方案）？是在等另一个团队（被依赖阻塞）？是在等一个没人敢做的决定（决策真空）？还是所有人都还在忙别的（优先级根本没排进去）？这四种停滞的解法完全不同，而其中三种加班一点用都没有。她反复强调的一点：大项目的绝大多数障碍是社会性的，不是技术性的——而工程师的默认反应是去优化那个技术的部分，因为那部分他熟。
最后一根柱子是「把人抬起来」。这里她做了一个很多人没分清的区分：
指导（mentorship）是给建议：我把我知道的告诉你，你自己去用。保荐（sponsorship）是给机会：我拿我自己的信誉做担保，把一个有风险、有曝光度的活派给你——比如让你去做那场向高层的汇报、让你当那个大项目的技术负责人。两者的差别在于谁承担风险：指导是零成本的善意，保荐是你把自己的筹码押在别人身上。她的判断相当直接：真正改变一个人职业轨迹的，绝大多数时候是保荐，不是指导。建议人人都能给，机会只有手上有筹码的人给得了——而当你成了 Staff，你手上第一次有了筹码。
另外两条也很实在。其一，你的行为会被复制，无论你愿不愿意。你在代码评审里怎么说话、你在会上会不会承认「这个我不懂」、你出了故障是找原因还是找人——组织里比你资浅的人正在从这些细节里学「在这儿要怎么当工程师」。这是 Staff+ 权力里最真实、也最少被意识到的一份：你不需要制定规范，你的日常行为就是规范。她举了一个很小但很有力的例子：当一个足够资深的人在会上说「等一下，我没听懂」，整个房间的心理安全感会往上跳一格——因为在场每个不敢问的人都刚刚被授权了。
其二，把知识从你脑子里搬出去。一个只有你能搞定的系统，看起来像你的护城河，实际上是你的天花板：你会被永远绑在那儿，而组织的能力上限就是你的时间。写文档、做分享、把复杂的东西讲简单——不是额外的好人好事，是把自己解放出来的唯一办法。
全书是一条从「看清」到「推动」到「放大」的线，每一段都在回答同一个问题的不同侧面：没有职权的人，靠什么改变一个组织？
误读一：这是一本「怎么升 Staff」的攻略。它主要写的是升上去之后怎么做这份工作。想看「怎么定位、怎么被看见、怎么走完晋升流程」，拉尔森的《Staff Engineer》更对口；两本书是互补的，不是二选一。
误读二：「让胶水工作可见」就是把这件事解决了。恰恰相反——这条建议把一个结构性问题的负担放回到了个人身上。如果一家公司的晋升机制系统性地不给协作型贡献记分，那么真正该改的是评审标准，而不是让承担者更擅长自我包装。赖利并没有回避这一点，但书的定位决定了它主要能给个人建议、给不了制度处方。诚实地说：这是本书最有力的洞察，也是它最无力的地方。
批评一：适用范围高度依赖公司类型。整本书默认你在一家有成熟 Staff+ 职级体系、有多个团队、有晋升评审文化的中大型科技公司。在一家二十人的创业公司，「三张地图」里有两张可以直接用一次午饭聊清楚；在非科技行业的 IT 部门，很多描述干脆不成立。读的时候要自己做换算，别照搬。
批评二：证据是经验，不是研究。这本书的知识来源是作者十几年的一线经验加上工程管理社群（拉尔森、卡米尔·富尼耶等人）的共同语汇，不是实证研究：书里没有数据证明「按这样做的人更可能成功」，也无法排除幸存者偏差——我们听到的都是这套打法奏效了的人的复盘。它是一份高质量的行业经验总结，当成经验读是对的，当成规律读会失望。
批评三：有读者觉得它偏长、偏软。把全书压缩，很大一部分可以归结为「多沟通、写下来、有意识地选择」——这些道理本身并不新，价值在于她把它们拆到了可操作的粒度。如果你已经在大公司做过几年跨团队项目，会有相当篇幅读起来是在确认你已知的东西；反过来，如果你刚踏进这个层级，这些「显而易见」的东西正是最值钱的部分。
批评四：一个书里没有正面回答的问题。「影响力而非职权」这套打法，前提是组织本身基本健康、讲道理、认可好论证。可如果不是呢？如果决定就是由某几个人拍脑袋做的、写多少文档都不会被读？书里给的答案更多是「那也是一种信息，说明这里可能不适合你」——这在道理上没错，但对一个正卡在这种处境里的人来说，帮助有限。
① Staff+ 不是「更资深的资深」，是换了一份工作：衡量标准从你产出了多少，变成因为你在，组织多产出了多少。
② 三根柱子——看全局、把事推成、把人抬起来；缺哪根，就长成对应的那种废人。
③ 随身带三张地图：定位图（你那个红点在整张图上很小）、地形图（沼泽与流沙都不写在流程文档里）、藏宝图（终点是什么）；大多数「技术分歧」其实是第三张图缺失。
④ 没有正确的飞行高度，只有此刻正确的高度；一直贴地飞会看不见方向，一直在三万英尺则会飞快地失去可信度。
⑤ 胶水工作是组织运转的必需品，却不进晋升的账本，而且它的分配从来不是随机的——所以要么把它变成一个有名字的正式项目，要么把它做成能被看见的形态。
⑥ 愿景说「哪儿」，战略说「怎么去」；坏战略的标志是跳过诊断、直接列一串谁都不反对的目标——因为它没告诉任何人该放弃什么。
⑦ 战略的价值在共识里，不在文档里：一份没人参与就写出来的战略，会被礼貌地赞美，然后遗忘。
⑧ 你有四个有限的账户：时间、精力、可信度（靠交付赚、用来做别人暂时看不懂的事）、社会资本（靠合作赚、用来请人让步）；「你可以做任何事，但不能做所有事。」
⑨ 大项目靠反复维护四层共识——问题、方案、分工、什么叫做完；卡住时先分清停滞的类型，因为绝大多数障碍是社会性的，而加班只治得了技术性的那一种。
⑩ 指导是给建议，保荐是拿自己的信誉去给别人一个有风险的机会——建议人人给得起，机会只有手上有筹码的人给得了；而你的日常行为就是规范：当一个足够资深的人说「等一下，我没听懂」，整个房间的心理安全感会往上跳一格。