书名：工程师进阶之路 : 个人贡献者成长与改变指南
ISBN：978-7-115-67826-3
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [爱尔兰] 塔尼娅·赖利 (Tanya Reilly)
译 何万青
责任编辑 卜一凡
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright©2022 Tanya Reilly. All rights reserved.
Simplified Chinese Edition, jointly published by O’Reilly Media, Inc. and Posts & Telecom Press, 2025.
Authorized translation of the English edition of The Staff Engineer’s Path ©2022 O’Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
本书简体中文版由O’Reilly Media, Inc.授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
多数公司意识到了他们对主管工程师的迫切需求，却因技术路线混乱、缺乏明确指引，导致工程师和管理者面临职业发展困惑。本书围绕工程师如何成长为优秀主管工程师展开，分为大局观、执行力和提升力三篇。第一篇探讨如何以广阔、战略性视野思考工作，提出与主管工程师角色相关的大问题，如在场景中审视工作、揭示目标，并创建全局图。第二篇聚焦领导项目和解决问题的实际情况，分享选择工作、管理精力的技巧，讨论领导跨团队和跨组织项目的方法，以及克服障碍、复盘项目的要点。第三篇关注组织水平，介绍如何通过学习模范工程师的行为来提高团队水平，探讨提高同事技能的模式，以及提升个人水平、规划职业生涯的方法。
本书适合正考虑或已走上主管工程师道路的工程师，以及与主管工程师共事或管理主管工程师、想了解这一新兴角色的人阅读。
本书直击技术人最核心的困惑：当拥有五年经验的工程师站在“管理岗”与“技术专家”的职业分岔路口时，该如何选择真正适合自己的道路？本书的作者长期关注技术团队效能与工程师职业成长，系统揭示了顶级科技公司所推崇的主管工程师（Staff Engineer）成长体系，为那些不愿放弃技术深度的从业者指明了一条清晰路径——通过对“大局观 × 执行力 × 提升力”三大支柱的刻意修炼，实现从代码贡献者到技术领袖的蜕变！
——吴甘沙，驭势科技（北京）有限公司董事长、CEO
很多工程师发展到一定阶段后，容易陷入一种“既不是管理者，也不再纯粹执行编码任务”的中间状态——进退两难，方向模糊。我自己也经历过这个阶段。这本书所讲述的，正是如何从一名个人贡献者，逐步成长为能够推动组织系统性变革的技术骨干。它不空谈励志，而是提供路径。对每一位希望在技术道路上走得更远的工程师来说，这都是一本值得反复阅读的书。
——陶建辉（Jeff），涛思数据创始人兼CEO
尽管很多企业都为员工提供了技术与管理双通道的职业发展路径，但许多工程师仍然对未来的职业可能性，以及如何在技术路径上持续成长感到迷茫。无论是初入职场的新人，还是经验丰富的资深工程师，都能从本书的建议和案例中获益。
本书提炼出工程师进阶的三大核心能力：大局观、执行力和提升力。它们揭示出，走向技术领导者的道路不仅需要技术热情与专业深度，还离不开沟通、协调、组织与管理等软技能，更要学会从团队和公司的整体视角分析问题、提出方案。重要的是，每一位工程师在实现自我进阶的同时，也应当积极投入时间培养与辅导年轻工程师，助力他们共同成长。
——黄波，华东师范大学特聘教授《以终为始：数字化时代人才终身成长之道》作者
技术岗位工程师根据其职责范围与影响力层级，可划分为三个发展阶段：块级、产品级和产业级（涵盖跨部门大型项目）。本书的核心受众是处于产品级和产业级的工程师，本书旨在为这一群体的职业发展提供系统化的方法论和实战指导。
当工程师晋升至产品级及以上层级时，其工作范畴将发生质的变化——从单纯的技术实现转向端到端的全链路闭环管理，主要包括以下方面。
• 战略层面：技术洞察、竞争力分析、业务价值论证与长期规划。
• 执行层面：架构设计、技术选型、资源协调与跨团队协作。
• 领导力层面：立项推动、风险攻关、组织复盘与团队赋能。
此时，工程师不再仅仅是解决方案的执行者，更是以技术驱动的业务负责人，需要以最终结果为导向，主动填补流程缺口。
• 当团队方向模糊时，你是战略落地的规划者。
• 当系统出现瓶颈时，你是技术攻坚的定海神针。
• 当跨部门协作受阻时，你是破除壁垒的协调者。
这一过程中所需的非技术能力（如向上管理、横向沟通、商业思维）往往比技术能力更重要。针对这些无人明说却至关重要的软技能，本书提供了切实可行的实战框架。
——吴峰光，华为鲲鹏计算操作系统首席专家
当前，新一轮科技革命与产业变革席卷全球，软件与信息技术正成为重塑世界竞争格局的核心变量。在这一变局中，能够驾驭复杂系统、引领技术方向、贯通战略与落地的高阶工程师，日益成为国家实现科技自立与产业升级所急需的稀缺资源。
然而，从资深专家向主管工程师（Staff Engineer）的跃迁之路，往往面临角色定位模糊、成长路径不明、能力模型缺失等现实痛点，这不仅制约了个体的职业发展，也限制了组织对技术红利的充分释放。
面对这些问题，本书应运而生。作者基于二十余年一线主管工程师的深厚积淀，系统剖析了这一关键角色的内涵与外延；何万青博士以精准流畅的译笔，将国际最佳实践原汁原味地呈现给中文读者。全书构建起“三大支柱”能力框架。
• 大局观：以战略视野统揽技术方向、业务目标与组织生态。
• 执行力：在资源受限、依赖复杂的真实环境中切实交付成果。
• 提升力：将个人卓越转化为团队与组织的乘数效应。
作者摒弃了“晋升秘籍”式的功利说教，转而借助丰富案例与实用工具，引导读者进行自我定位、厘清职责边界、修炼“人性化技能”（如沟通、决策与影响力等），从而找到契合自身特质的发展路径。
本书既可作为工程师职业成长的“导航图”，也可为技术管理者选育人才提供参考坐标系。在迈向科技强国的征程上，我们迫切需要一支“精于编码、善于洞察、能带队攻坚”的高水平工程师队伍。愿每一位读者都能借此书突破职业瓶颈，在中国式现代化的火热实践中不断攀登技术新高峰。
郑纬民
中国工程院院士，清华大学计算机科学与技术系教授
这是我在成为首席工程师时，希望能拥有的一本书。如果你想知道“主管+”（Staff+）意味着什么，以及如何在你的组织中胜任这一角色，那么，本书将为你指明路径，并提供大量实用而富有洞见的建议。这本书将提供你所需的工具，帮助你在技术进阶之路上茁壮成长并发挥影响力。
——Sarah Wells，独立顾问兼技术作家，曾任《金融时报》首席工程师
这本书像是我整个职业生涯中缺失的操作手册。看到主管工程师这个模糊角色被清晰定义，并附有关于时间管理、共识建立等的具体指导，我感到无比安心。我将会经常参考这本书。
——Titus Winters，谷歌首席工程师，Software Engineering at Google合著者
塔尼娅·赖利是撰写本书的不二人选。她深厚的直接经验体现在每个章节中，让我受益匪浅。
——Will Larson，Calm公司CTO，Staff Engineer作者
作为个人贡献者的高阶领导岗位长期以来定义模糊，而这本书为这个相对新兴的行业角色提供了急需的成功指南。本书作者出色地融合了大公司视角与规模化企业挑战，全面阐述了如何成为优秀的主管工程师。
——Silvia Botros，首席工程师，High Performance MySQL, 4th edition合著者
当你接近个人贡献者职级的顶峰时，就像被给予了指南针和目的地，如何抵达是你的课题，如何引领众人抵达则是所有人的课题。本书作者提供了一个坚实的框架和导航方法，把你从“此处”引领至“彼处”。这本书既为初入高阶个人贡献者领域的人提供稳固支点，也为经验丰富者带来全新视角。主管工程师，当有清晰的认知。
——Izar Tarandach，首席安全架构师，Threat Modeling合著者
本书作者以惊人的准确度捕捉到了我初次成为“总得有人做点什么”中的那个“人”时心中的那份沉重与无力。这本书深入探讨了这对身处主管工程师层级的从业者意味着什么。
——Niall Richard Murphy，创始人兼CEO
Reliable Machine Learning and Site Reliability Engineering合著者
本书为“如何在没有直接下属的情况下成为资深技术领导者”这个模糊且常被误解的问题，带来了急需的清晰阐释。书中每一页都满载着如何驾驭自身角色和所在团队并规划职业发展的宝贵洞见和可行建议——全部以塔尼娅·赖利标志性的睿智、深刻又接地气的风格呈现。这是一部杰作。
——Katie Sylor-Miller，Etsy高级前端架构师
如果你是一名资深工程师，正在思考下一步该成为主管工程师还是工程经理，这本书正是为你而写的。它涵盖了关于主管工程师这个角色没人会告诉你的诸多要义——即便有优秀导师指导，这些认知往往也需要漫长岁月才能自行领悟。本书以凝练的方式，提供了有关主管工程师角色的观察、思维模型和一手经验。
——Gergely Orosz，The Pragmatic Engineer作者
2016年撰写《技术为径：带领公司走向卓越的工程师》（The Manager’s Path：A Guide for Tech Leaders Navigating Growth and Change）时，我有不少目标。我想分享自己成为经理人[1]的经验和教训，向那些有志成为经理人的朋友展示这项工作的全貌。我想向整个行业阐明我们应该对经理人有更多的期望。而我们当下所提拔的经理人，常常无法正确地在人力、流程、产品和技术能力之间平衡地聚焦，从而干好工作。简而言之，我想纠正技术领域的文化缺失：既要认真对待管理这个关键角色，又要防止有抱负的工程师将成为经理人作为他们职业发展的唯一道路。
[1] 在本书中，经理人指管理者，包括工程经理、产品经理、技术项目经理等。——译者注
我得说自己取得了一定的成绩。每次有人告诉我，读了我的书，他们决定放弃经理人这条路，我听了都恨不能原地起舞。从这个角度看，起码有人读了我的书，意识到经理人这条路并不适合他们。遗憾的是，对个人贡献者而言，另一条职业发展道路，即成为主管工程师，却鲜有类似的指南。这种书的缺失导致很多人明知自己不愿意承担越来越大的团队的管理责任，却仍选择了管理道路，因为他们无法看到其他出路。这成为工程师和管理者共同的困惑：大多数经理人希望自己的组织内有能干的主管工程师，却又不知如何培养他们；很多工程师想走技术道路，但除进入管理层之外，他们没有其他的现实选择。
成为主管工程师的核心挑战之一在于，人们总是不约而同地期望那些有资格走上这条路的工程师可以无师自通，知晓如何在这条道路上前行。如果你注定会成为主管工程师，那么坊间智慧就会认为你自己能够想到如何达到目标。无须赘言，这是一条让人困惑且存在诸多歧路的职业发展之路。越来越多的公司意识到了他们对主管工程师的迫切需求，整个行业无法再忍受笼罩在主管工程师前进道路上的神秘主义，而无视那些成功的技术领导者的基本能力。心存此念，你可以想象，当塔尼娅·赖利（Tanya Reilly）提出她将撰写一本有关主管工程师职业发展的书时，我有多激动。它填补了我的《技术为径：带领公司走向卓越的工程师》一书中另一半未涉及的职业阶梯。我认识塔尼娅，源于她关于技术领导力的文章和演讲。显然，塔尼娅希望解决当前过度关注编码和技术贡献的问题，同时澄清那些使优秀工程师无须管理他人即可成为成功的“放大器”所需的关键技能。
在这本书中，塔尼娅阐述了那些对成功的主管工程师来说至关重要的基本技能。她提供了一个框架，展示了如何运用大局观、执行力和提升力三大支柱，来搭建超越个人贡献的影响力。
塔尼娅意识到成为主管工程师的路径有多面性，所以她并没有试图规定高级工程师以上每个级别所需技能的精确组合。相反，她明智地把重点放在如何基于当下建立这些基石。从制定技术战略到成功领导大型项目，从担任导师到成为组织催化剂，这本书将带你了解这些关键的支柱，并展示如何在代码之外放大你对公司取得成功的影响。
在你的职业生涯中，只有一个人说了算，那就是你自己。弄清自己的职业道路，是你生命中最大的机会和挑战之一，你越早规划出自己的职业道路（外加一大堆运气），你就越能在工作中游刃有余。这本书揭示了成为主管工程师所需的技能，是每个工程师书架上不可或缺的一本书。
卡米尔·弗涅尔（Camille Fournier）
《技术为径：带领公司走向卓越的工程师》作者
《项目经理应该知道的97件事》（97 Things Every Engineering Manager Should Know）主编
摩根大通董事总经理
ACM Queue编委会委员
于纽约，2022年9月
你怎么看5年后的自己？这道经典的面试题有点儿像“长大后你想做什么”，它有一些被社会普遍接受的答案，并且时间跨度足够长，你无须立即做出承诺。[1]但若你是一名希望在自己职业道路上持续成长的高级软件工程师[2]，这个问题就变得非常现实了。你想朝哪个方向前进呢？
[1] 面试时，最好避免给出“既想当动物园管理员，又想成为宇航员”这类答案，因为成年人的生活确实有很多限制。
[2] 为了叙述简洁，本书将统一使用“软件工程师”这一称谓。但如果你是系统工程师、数据科学家或其他技术岗位的从业者，相信本书内容对你同样具有参考价值。欢迎各位技术同人！
你可能会发现自己处在一个岔路口（见图0-1），摆在你面前的是两条不同的职业发展道路。一条是成为一名经理人，直接管理下属；另一条是成为一个没有直接下属的技术领导者，这种角色通常称为主管工程师。如果你能预见这两条职业道路未来5年的发展，你会发现它们有很多共同点：它们通向许多相同的目的地，而且走得越远越需要许多相同的技能。但是，刚开始的时候，它们看起来截然不同。
图0-1 多歧路，今安在
经理人的道路是清晰的，有很多人走过。那些能够清晰沟通、在危机中保持冷静，并帮助同事更好地完成工作的人，成为经理人是一条很常见甚至被默认的职业道路。你很可能认识那些选择这条道路的人。你也可能以前有过自己的经理，对他们做得好或不好的地方有自己的看法。管理是一门被研究得很透彻的学科。“晋升”和“领导”两个词通常是指“成为某人的上级”，机场的书店里也充满了关于如何做好这项工作的建议。因此，倘若你踏上管理这条路，尽管不会轻松，但至少能对自己的职业旅程有个大概的预期。
主管工程师的道路则不那么清晰。虽然现在许多公司允许工程师在不带人的情况下不断提升职级，但这种“技术路线”仍然很混乱，没有明确的指引。考虑走这条路的工程师可能从来没有和主管工程师一起工作过，或者只见过少数几种类型的主管工程师，以至于这一岗位看起来像是难以企及的神秘领域（其实不然，这些都是可以学习的）。不同公司对这一岗位的期望不同，即使在一家公司内部，雇用或提拔主管工程师的标准也可能是模糊的，并且缺乏可操作性。
“不识庐山真面目，只缘身在此山中” ——即便躬身入局，通常工作也并不会变得更清楚。过去的几年，我曾与许多公司的主管工程师交谈，他们并不太清楚公司对他们的期望是什么，而工程经理也不知道如何与他们的主管工程师下属及同僚合作[3]。如果你的工作没有明确定义，你怎么能知道自己是做得好，还是根本没做好？
[3] 这一现状正在改变。Will Larson、LeadDev等先行者已在这条道路上做出了非凡贡献。
即使期望明确，实现这些期望的道路也未必清晰。作为一名新的主管工程师，你可能被期望成为一名技术领导者，做出高明的商业决策，具备很大的影响力，但如何做到呢？又从哪里开始呢？
我理解这种感觉。在这个行业工作的20年里，我一直走的是主管工程师的道路，现在我是一名高级主管工程师，在职级上与总监平级。虽然我曾多次考虑过经理人的道路，但我始终认为，“技术路线”的工作给我带来了活力，我每天早上都想来上班。我希望有时间去钻研新技术，深入了解架构，并探究新的技术领域。花时间在什么地方，就在什么地方进步，而我一直想在技术方面不断进步[4]。
[4] 我保留在未来改变自己观点的权利。
不过，在我职业生涯的早期，我一直在努力理解这条道路。当我还是一名中级工程师时，我不理解为何还有高于“高级工程师”的职级——那些人整天在忙什么？那时我当然看不到通往这些角色的道路。后来，我成长为一名主管工程师，我发现了很多未被言说的期待和不知如何描述的缺失技能，更不知道该如何采取行动。多年来，我从许多项目和经验中学到了很多，既有成功的，也有失败的，我也从其他公司杰出的同行那里学到了很多。现在，我对这项工作的了解已经足够多了，但如果我从刚开始就知道我今天所知道的东西就好了。
如果你已经走上了主管工程师的道路，或者正考虑这样做，欢迎你！本书正是为你准备的。如果你和主管工程师共事，或者管理主管工程师，并且想了解这个新兴的角色，那么本书也有很多内容适合你。在本书中，我将分享我所学到的有关如何成为一名优秀主管工程师的内容。但我想要提醒你，我不会对每个主题都开出处方，也不会回答每个问题：这个角色本身就面临大量模糊性，而答案往往“取决于场景”。但我会告诉你如何驾驭这种模糊性，让你理解什么是重要的，并与你工作上的其他上级保持一致。
我将从我命名的三大支柱——大局观、执行力，以及提升与你共事的工程师的水平（简称提升力），来解读主管工程师角色。
大局观意味着能够退一步，以更广阔的视野来看待问题。它意味着超越眼前的细节理解你工作的环境，还意味着超越眼前的思考。而无论这意味着启动一个为期长达一年的项目，构建易于撤销的软件，还是预测公司[5]三年后的需求。
[5] 在本书中，我将会用“公司”这个词来指代雇主，但这当然只是举例，可能实际上你是在非营利组织、政府机构、学术机构或其他类型的组织中工作。请根据你自身的情况，将适合你的组织类型替换进来。
在主管工程师层面，你承担的项目将变得更加混乱和模糊。它们会涉及更多的人，需要更多的资本、更大的影响力或文化变革来取得成功。
资历的提升伴随着担负更多的责任，包括提高你所领导的工程师的水准和技能，而无论他们是你的直属团队、组织中的同事，还是整个公司或行业里的工程师。这种责任包括通过教育和指导产生有形影响，以及作为榜样产生无形影响。
主管工程师角色的三大支柱如图0-2所示。
图0-2 主管工程师角色的三大支柱
你会注意到，这三大支柱建立在技术知识与经验的坚实基础之上。这个基础十分关键。大局观需要你理解什么是可能的，并有良好的判断力。在执行项目时，你的解决方案需要能够真正解决别人想要解决的问题。作为榜样，你的审查意见应该使代码和设计变得更好，而且你的意见需要经过深思熟虑——它们必须正确！技术能力是每个主管工程师都必须具备的，你需要不断地磨炼它们。但仅有技术知识是不够的。你在这个层次上的成长和成功，意味着你要做的事情的难度远超单凭技术能力就能做到的。要想成为掌控大局的人，执行更大的项目，并提高周围人的水平，你需要具备一些更加“人性化”的技能，比如：
• 沟通力和领导力；
• 驾驭复杂性；
• 放眼全局去看待工作；
• 教导、支持和授权；
• 提出问题，并让其他人关心你所提的问题；
• 无论你是否觉得自己是领导，都要像领导那样行事。
把这些领导技能想象成你在哥特式大教堂看到的飞扶壁（见图0-3）——飞扶壁不能取代墙壁，但能让建筑师建造出更高、更宏伟、更令人敬畏的建筑——它们不能取代你的技术判断。
这三大支柱中的每一个都有一套必要的技能，而我们在每一个技能领域的天赋也会有所不同。我们中的一些人可能擅长领导和支持大项目，但很怕在两个战略方向间做出选择；另一些人可能在理解公司和行业发展方向上直觉很强，但在事件管理中却很容易失去控制；还有一些人可能会提高与他们合作的每个人的技能，但却很难围绕一个技术决定促成共识。好消息是，所有这些技能都可以学习，你不必因此而退缩。
图0-3 领导技能就像飞扶壁，旨在保持巨大建筑物的稳定
本书分为三篇。
在第1篇中，我们将探讨如何在思考工作时拥有广阔的、战略性的视野。第1章从提出围绕主管工程师角色的大问题开始：业界对主管工程师的期望是什么？主管工程师做什么工作？在第2章中，我们将进一步拉远视角，帮助你获得更全面的认知。我们将在场景中审视你的工作，引导你的组织，并揭示你的目标是什么。在第3章中，我们将通过创建全局图来为全局添砖加瓦。
第2篇是战术性的，涉及领导项目和解决问题的实际情况。在第4章中，我们将讨论如何选择要做的工作。我将分享决定在哪些方面花时间的技巧，管理个人精力的技巧，以及如何在不损害个人信誉和社会资本的情况下“使用”这些技巧。在第5章中，我们将讨论如何领导跨团队和跨组织的项目：成功组织好人员，做出正确的决定，并保持信息畅通。在第6章中，我们将讨论如何克服前进道路上的障碍，以及对取消并干净利落地关闭的项目进行复盘。
第3篇聚焦于提升组织水平。在第7章中，我们将通过学习模范工程师的行为来提高每个人的水平，诠释如何公开学习，以及如何建立心理安全的文化。我们将研究如何在事件处理或技术分歧中，成为理性决策者。在第8章中，我们将介绍关于提高同事技能的更具目的性的模式，如教导和辅导、设计审查、代码评审和文化变革。在第9章中，我们将探讨如何提高个人水平，包括如何保持成长，以及如何考虑自己的职业生涯。
在进一步讨论之前，需要提醒你的是，这是一本关于如何在技术道路上发展的书，而不是一本技术书。你需要具备坚实的技术基础，才能成为一名主管工程师。本书并不能帮助你获得这些技术基础。本书默认你已经拥有（或正着手学习）你所需的专业技能。无论这些“技能”是编程、架构设计、用户体验设计、数据建模、生产运维、漏洞分析，还是其他什么，每个领域都有大量的图书、网站和课程可以帮助你。
如果你是一个认为技术能力是唯一重要技能的人，那么你不太可能在本书中找到你要找的东西。但神奇的是，你也可能是从本书中收获最多的人。无论你掌握的技术知识有多深奥，你都会发现，当你能说服他人采纳你的想法、提升你周围工程师的水平、轻轻松松地打破让每个人都停滞不前的组织僵局时，工作就不那么令人厌烦了。这些技能并不容易学习，但我保证它们都是可以学到的，我将在本书中尽我所能为你指明方向。
你想成为一名主管工程师吗？不追求更高级的工程师角色也没关系，转到经理岗位或留在高级岗位上做你喜欢的工作，也是可以的。但如果你想帮助你的组织实现目标，并继续增强自己的技术能力，同时使身边的工程师在专业上做得更好，那么请继续阅读本书。
40多年来，O’Reilly Media一直致力于提供技术和商业培训、知识和卓越的见解，以帮助用户取得成功。
我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。O’Reilly的在线学习平台允许读者按需访问直播培训课程、深入的学习路径、交互式编程环境，以及O’Reilly和其他200多家出版商提供的大量文本和视频资源。更多相关信息请访问O’Reilly官网。
美国：
O’Reilly Media，Inc.
1005 Gravenstein Highway North
Sebastopol，CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
欢迎读者对本书中文版提出勘误，请发送电子邮件至errata@oreilly. com.cn。
若要获取有关我们的图书、课程、会议和新闻的更多信息，请访问O’Reilly官网。
感谢为本书成功出版做出贡献的所有人。
感谢Sarah Grey，她是我能想到的最好的执行编辑。感谢 O’Reilly的杰出编辑们，包括策划编辑Melissa Duffield、责任编辑Liz Faerm、文字编辑Josh Olejarz、创作了令人印象深刻的封面的美术编辑Susan Thompson，以及将我的涂鸦变为华丽插图的插画师Kate Dullea。这是我第一次写书，是你们让我摆脱了胆怯。
感谢Will Larson的鼓励和支持，是他帮助主管工程师们第一次找到彼此。也感谢Lara Hogan，我发私信问她“我真的可以写书吗？”，她给予了我热情的介绍。感谢你们让我认识到支持者的重要性。
我很幸运，在这个旅程中，有两位聪明且深具洞察力的工程师相伴，他们是Cian Synnott和Katrina Sostek。正因为你们过去一年的辛苦审校和反馈，本书才更加完善。特别感激你们对那些不够完善的部分提出的周到建议。提出建设性的批评总是更难，感谢你们付出的时间和精力。还有许多人拿出宝贵的时间来讨论他们对本书的想法，给予我反馈或教给我一些知识。
我要特别感谢Franklin Angulo、Jackie Benowitz、Kristina Bennett、Silvia Botros、Mohit Cheppudira、John Colton、Trish Craine、Juniper Cross、Stepan Davidovic、Tiarnán de Burca、Ross Donaldson、Tess Donnelly、Tom Drapeau、Dale Embry、Liz Fong-Jones、Camille Fournier、Stacey Gammon、Carla Geisser、Polina Giralt、Tali Gutman、Liz Hetherston、Mojtaba Hosseini、Cate Huston、Jody Knower、Robert Konigsberg、Randal Koutnik、Lerh Low、Kevin Lynch、Jennifer Mace、Glen Mailer、Keavy McMinn、Daniel Micol、Zach Millman、Sarah Milstein、Isaac Perez Moncho、Dan Na、Katrina Owen、Eva Parish、Yvette Pasqua、Steve Primerano、Sean Rees、John Reese、Max Schubert、Christina Schulman、Patrick Shields、Joan Smith、Beata Strack、Carl Sutherland、Katie Sylor-Miller、Izar Tarandach、Fabianna Tassini、Elizabeth Votaw、Amanda Walker和Sarah Wells。此外，我还要感谢通过私信、电子邮件、走廊谈话或Slack频道与我交流的其他人。是你们提升了本书的品质，感谢你们！
感谢和我一起喝下午茶的诸位，你们每天都在展示社区的力量。感谢Rands Leadership Slack平台staff-principal-engineering频道的每个人，感谢你们的大力支持，同时感谢你们慷慨地分享经验。衷心感谢我在Squarespace的同事，以及Google SRE团队的成员，我从你们那里学到了很多。还要感谢Ruth Yarnit、Rob Smith、Mariana Valette，以及整个Lead Dev团队，感谢你们与世界分享如此精彩的技术领导力内容。感谢你们所做的一切。
感谢我的山居好友们，包括那只狗。我很幸运，也很荣幸能与你们成为朋友。谢谢你们让我在房车里写作（当我感染新冠病毒时，我还在那里隔离！）。我期待着与你们一直保持朋友关系，看着你们的小橡树长高。
最后，感谢我的父母Danny和Kathleen，以及整个大家庭，感谢你们去年在我从人间蒸发时的耐心。当然，还有Joel和9号女士[6]。我期待在周六再次见到你们。对于Joel（他提出了人性化技能是“飞扶壁”的想法），感谢你关于工程组织和开发好软件的精彩建议，也感谢你提供的所有三明治。感谢9号女士（当我写本书的第一稿时，她还是6号女士！）：感谢你的优秀想法、插图和拥抱。感谢你们所有人！
[6] 美国智商测试专家Don Richard Riso和Russ Hudson共同提出了九型人格理论。根据该理论，人的性格分为9种类型，分别是1号型~9号型。9号性格的女士（文中称“9号女士”）通常很温和、友善和包容，她们善于协调和处理人际关系中的冲突，拥有自己独特的价值和贡献，在社会和团队中扮演着重要的角色；而6号性格的女士（文中称“6号女士”）通常非常依赖他人，会不断地征求别人的意见和建议，以便能够更好地应对生活中的各种挑战。——译者注
对很多公司来说，主管工程师路线或者说“技术路线”还是新鲜事物。对于资深的工程师该具备怎样的特质，以及这些工程师应该承担什么工作，不同的组织看法不同。尽管大多数人认同，正如Silvia Botros所说，技术路线的顶端不只是“更资深的前辈”，但我们对其确切内涵的理解尚未达成一致。因此，我们将从一个本质性的问题开始本章的讨论：为什么一个组织希望非常资深的工程师长期留任？理解这一点之后，我们再来深入解读主管工程师这个角色，包括其技术要求、领导力要求，以及自主工作的意义。
主管工程师有很多类型，并且他们也有许多有效的方式去完成工作。然而，有些类型的主管工程师更适合工作在特定情形下，并非所有组织都需要所有类型的主管工程师。因此，我们将探讨如何描述和定义主管工程师这一角色，包括其职责范围、专业深度、汇报链、主要关注点等。通过这些描述，读者可以更明确自己想要如何工作，希望发展成什么类型的主管工程师，或者需要雇用什么样的人才等等。最后，由于不同的公司对主管工程师的职责见解各异，我们将努力使你的理解与组织中其他关键人物的理解保持一致。
让我们从这项工作的本质说起。
如果唯一的职业道路是成为一名管理者（见图1-1中左侧的公司结构），那么许多工程师都会面临一个严峻而困难的选择：是留在工程岗位上，在技艺上不断进步；还是转向管理层，在事业上不断成长。
因此，现在许多公司提供“技术”或“独立贡献者”的路线，允许一条与管理角色平行的职业发展道路，这是件好事。图1-1中右侧的职业阶梯就是一个例子。
不同公司的职业阶梯各不相同，以至于催生出一个网站（levels.fyi），专门对不同公司的职业阶梯进行比较。[1]这些职业阶梯的层级数量不同，每个职业阶梯的名称也不同，你甚至可以看到相同的名称以不同的顺序排列[2]，但很多时候会出现“高级”这个词。Marco Rogers，一位在两家公司创建了职业阶梯体系的工程总监，将高级职称描述为职业阶梯的“锚定”级。如其所说，“下层的级别，体现了人们逐渐增强的自主能力；上层的级别，则主要为了加强影响和责任。”
[1] 网站progression.fyi值得推荐，上面有各种科技公司公布的大量职业阶梯。
[2] 我听说有一家按工程师资历使用“高级”“主管”“首席”三个级别的公司，被另一家使用“高级”“首席”“主管”三个级别的公司收购了。结果一片混乱。后者将所有“主管”改为“首席”，将所有“首席”改为“主管”，但没有工程师为此感到高兴。主管工程师和首席工程师都认为这种改变是一种降级。头衔很重要。
图1-1 两个职业阶梯示例
高级工程师有时被看作“终身职称”，因为有的工程师并不一定想要更上一级。[3]但如果你愿意，你可以将其归入“技术领导力”象限，高级以上的第一级通常称为“主管工程师”。
[3] 我的朋友Tiarnánde Burca这样定义高级工程师：一名工程师到了该级别可以选择停止升迁，在余下的职业生涯中保持其目前的生产力、能力和产出水平。但如果其离开，则仍然是公司“令人遗憾的损失”。
根据图1-1中右侧所示的双轨制职业阶梯，高级工程师可以选择培养自己晋升为经理或主管工程师所需的技能。一旦晋升，从主管工程师转为经理，或者反过来，都会被视为平级转岗，而不是进一步晋升。高级主管工程师的职级与高级经理相同，首席工程师相当于总监，以此类推。在职业阶梯中，这些级别可能会继续提升（为了表示所有职级高于高级工程师的角色，可以使用“主管+”这种表达方式，这是Will Larson在其著作Staff Engineer中创造的表达方式）。
| 关于头衔的说明 我偶尔听到有人坚持认为头衔和职级不应该（或本来不）那么重要。提出这种主张的人往往说得很有道理，说他们公司是一家平等、任人唯贤的公司，对职级制度带来的危险保持警惕。他们会说：“我们的企业文化是自下而上的，所有的想法都将得到尊重。”这个目标值得钦佩：即便你是职场里的菜鸟，你的想法也不会被忽视。 但是头衔确实很重要。Medium工程团队写了一篇博文，阐述了头衔非常重要的三个原因——“帮助人们了解他们在进步，将权力赋予那些不会自动获得权威的人，以及向外界传达期望的能力和水平。” 第一个原因是内在的，也许并非每个人的出发点，而另外两个原因则描述了头衔对其他人的影响。无论一家公司是否宣称自身是扁平、平等的，总会有一些人对不同职级的人看碟下菜，我们大多数人多少会有一点职级意识。正如美国科罗拉多州立大学创业学实践指导教授Kipp Krukowski博士在其2017年的论文《头衔对客户尊重的影响》（“The Effects of Employee Job Titles on Respect Granted by Customers”）中所说，“头衔是一种象征符号，公司通过这种象征符号向公司内外传递员工的能力资质与社会价值”。 我们无时无刻不在对人做出潜在的判断和假设。除非投入大量时间和精力来认识我们内心隐性的偏见，否则这些假设很可能受到刻板印象的影响。例如，2015年的一项调查发现，在接受调查的557名从事科学、技术、工程或数学行业的黑人和拉丁裔女性中，约有一半人曾被误以为是保安或保洁。 当一名工程师走进一个充满陌生人的会场时，类似的隐性偏见便开始显现。白人和亚裔男性工程师通常被认为更资深、更有“技术”、更擅长写代码，而不管他们是昨天才毕业还是已经干了几十年。女性，尤其是有色人种女性，则被认为资历较浅，她们必须在会议上更努力，才被认为有能力。 正如Medium的那篇工程文章所说，头衔赋予了那些可能不会自动得到它的人以权威，并传达了他们预期的能力水平。通过锚定期望，头衔节省了他们的时间和精力，否则他们将不得不一次又一次地证明自己。 你现有的头衔也影响着你下一步的工作。就像业界的许多人一样，我每天都会收到来自LinkedIn上猎头的邮件。在我的印象中，我只收到过三封邮件邀请我去面试一个更高级的职位，所有其他邮件都推荐我去尝试一个级别相同的职位，甚至一个级别更低的职位。 |
所以，这就是猎头在职业阶梯上看待工作的样子。下面让我们来看看为什么会有“技术领导”职级存在。前言中阐述了主管工程师角色的三大支柱：大局观、执行力和提升力。为什么主管工程师需要具备这些技能？公司又到底为什么需要主管工程师？
任何工程组织都要不断地做决定：技术选择、决定构建什么、投资或及时废止某系统。其中一些决定有明确的负责人和可以预测的结果；另一些则是基础性的架构选择，它们会影响到其他所有系统，没有人可以说清楚它们的走向。
好的决定必须考虑场景。有经验的工程师知道，大多数技术选择的答案是“得看具体情况”。只知道某项技术的优缺点还不够，还需要了解局部细节。你想做什么？你有多少时间、金钱和耐心？你能承受多大风险？公司需要什么？这就是做决定的背景。
收集背景信息需要付出时间和努力。你的团队往往容易陷入局部最优困境，团队里的工程师高度专注于实现团队的目标。而那些看似属于团队的决定，产生的后果却远远超出团队的职责范围。局部最优只是团队的最佳决策，当从更大的视野考查时，却可能和组织的最佳决策相去甚远。
图1-2给出了这样一个例子：一个团队要在A和B两款软件中做出选择。这两款软件都具备必要的功能，但软件A明显更容易设置，它马上就能工作，软件B则更难一些，它需要进行完善才能奏效，没有人愿意等那么久。
图1-2 局部最优与最佳决策
从团队的角度看，软件A明显胜出。他们为什么要选择别的呢？其他团队更希望他们选择软件B。事实证明，软件A会给组织的法务和安全部门带来持续的负担，软件A的认证需求意味着组织的IT和平台团队将不得不一直将其视为特例处理。选择软件A仅获得局部最优，团队不知不觉中选择了一个对整个组织来说时间投入更大的解决方案。软件B对团队稍差一点，但总体上要好得多。只有当团队里有人能用更全面的视角进行审视时，多出的两轮冲刺在一个季度内就能收回成本这一优势才会显现出来。
为了避免陷入局部最优困境，团队需要决策者（或至少影响决策的人）从局外人的角度出发，选择一条对整个组织或企业最有利的道路。第2章将介绍如何拉远视角，看清大局。
与看清大局同样重要的是，你还需要能够预测你的决定未来会如何发展。一年后，你会后悔什么？三年后，你会希望自己现在就开始做什么？为了朝同一个方向前进，整个团队需要在技术战略上达成一致：投资哪些技术，对哪些平台标准化，等等。这些重要决定最终可能结局微妙，往往还会有争议，所以做出决定的关键是要能够分享背景，并帮助其他人理解它。第3章将讨论如何为团体选择一个方向。
因此，要制定战略性全局决策，就必须启用具备大局观的决策者。但是，这个人为什么不能是管理者呢？为什么首席技术官（Chief Technical Officer，CTO）不能了解所有业务，将其转化为技术成果并传递重要的信息呢？
在有的团队中，CTO的确可以做到。对小团队来说，经理往往作为最有经验的技术专家，负责重大决策和技术指导。在小公司里，CTO会深入参与每个决定的细节。这些公司可能不需要主管工程师，但是管理权威可能会掩盖技术判断：即使有更好的方案，下属也不愿意和经理或CTO在技术决定上产生分歧。而人员管理本身就是一项全职工作。一个致力于成为优秀职业经理人的人，不会有太多时间去了解技术发展的新情况，而任何深陷“枝蔓缠绕”杂务的管理者，也不太可能满足其下属的需求。短期内，这可能行得通：一些团队不需要大量关注，继续走成功的道路就好了。但是，当团队需求和技术战略需求之间出现矛盾时，管理者就必须选择关注的重点。否则，要么团队成员被忽视，要么技术方向被忽视。
这也是许多组织为技术领导和人事管理分别创建职业路径的原因。假设公司雇用了很多工程师，如果每个决定都要汇报给CTO或高级经理，效率就会很低，更不用说降低自主权了。如果经验丰富的工程师有时间深入研究，构建场景和可信度，并确定正确的技术方向，组织就能得到更好的结果和设计。
但这并不意味着工程师可以单独设定技术方向。经理作为负责为技术项目分配人手的人，需要参与重大的技术决策。本章后面将探讨如何保持工程师和管理者之间的一致性，第3章在谈到战略时会再次提到。
| “架构师”的角色定位 在一些公司，“架构师”是职业阶梯中技术晋升体系里的一个职级。而在另一些公司，“架构师”是抽象的系统设计师，他们有自己的职业发展道路，与专注于系统实现的工程师不同。在本书中，我打算将软件设计和架构视为主管工程师职责的一部分，但请注意，这在业界并不普遍。 |
理想状态下，组织中的团队应该像拼图一样交错相扣，涵盖正在进行的项目的方方面面。与此同时，所有人都在这个全新的项目中工作，不受遗留系统的束缚，所有团队都致力于完成这个项目。团队的职责范围明确，没有争议。事实上，我们正在实践Thoughtworks技术顾问所说的“逆向康威策略”：团队与所需架构的组件完全对应。这个假想的乌托邦项目之所以困难重重，是因为其包含深入、引人入胜的研究和发明，而它的负责人渴望解决这些技术挑战并因此获得职业荣耀。
我想加入这个项目，你不想吗？很遗憾，现实是另一个样子。几乎可以肯定的是，参与任何跨团队项目的团队在项目酝酿之前就已经存在了，并且正在做其他事情，他们认为那些事情更重要。他们会在项目中途发现未注意到的依赖关系。他们的团队职责范围有过度的重叠和空白，这会渗透到架构中。而项目中混沌和困难的部分并不是迷人的算法研究问题，而是涉及对遗留代码的琢磨，与那些不想改变任何东西的忙碌团队的谈判，以及猜测多年前离职工程师的工作意图[4]，甚至理解哪些地方需要改变。刚开始你并不能了解全部工作。如果你仔细看一下设计文档，就会发现那些最需要调整的关键决定要么被推迟，要么被视而不见。
[4] 他们当时是怎么想的？这真的是他们想要做的吗？或许，未来的团队也会这样问我们。
这才是更现实的项目描述。无论你如何小心翼翼地将团队摊派到一个大型项目中，一些职责始终没有任何团队认领，而另一些职责却被两个团队声明负责。信息不能有效流动，或者在传达过程中被曲解，导致冲突。团队做出局部最优决定，项目陷入困境。
保证项目进度的一个方法是，让一个人对整个项目负责，而不是仅负责项目的某一部分。甚至在项目启动前，这个人就能确定工作范围并给出提案。一旦项目开始，他很可能就是高层系统设计的作者或共同作者，也是项目的主要联络人。他需要保持较高的工程标准，利用经验来预测风险并指出难题。他还需要花时间非正式地指挥或辅导下属，或者只是为项目的各个领导树立榜样。当项目陷入困境时，他有足够的视角来追踪原因并疏通解决问题（第6章将详细探讨）。在项目之外，他讲述正在发生的事情和原因，向公司其他部门阐述项目愿景，以及项目将如何影响每个人。
为什么技术项目经理（technical program manager，TPM）不能做这种建立共识和沟通的工作呢？主管工程师和技术项目经理在职责上肯定有一些重叠。不过，总的来说，技术项目经理负责的是交付而不是设计，更不是工程质量。技术项目经理负责确保项目按时完成，而主管工程师负责确保项目以较高的工程标准完成。主管工程师还负责确保所开发的系统足够强大，并与公司的技术环境相适应。他们对技术妥协持谨慎态度，并对任何可能成为系统未来维护陷阱的东西保持警惕。技术项目经理需要写技术设计文档，并为测试或代码评审制定项目标准，没有人期望他们对一个遗留系统进行深入研究，以决定哪些团队需要整合。当主管工程师和技术项目经理在项目中合作愉快时，他们甚至可以组成“梦之队”。
软件至关重要，关乎人们的福祉、生计甚至生命安全。维基百科上的软件缺陷列表虽令人警醒，却也真实地反映了现实。从飞机失事、救护车调度系统瘫痪到医疗设备故障，无数案例表明软件缺陷足以夺人性命。若天真地认为未来不会出现更严重的软件灾难，则无疑是掩耳盗铃。[5]我们必须以敬畏之心对待软件开发。
[5] Hillel Wayne 在文章“We Are Not Special”中指出，许多过去需要精心调试物理设备的工程解决方案，如今都被“软件补丁”所取代。坦白说，我对此一直感到惊讶：迄今为止，由软件引发的重大致命事故竟然如此之少。我可不敢指望永远能靠运气。
即便风险系数较低，软件开发的本质也仍具有明确目的。除少数具有研发属性的特例外，工程组织的存在绝非单纯为了创造更多技术产物。他们需要解决实际的业务问题，或打造用户真正需要的产品。在此过程中，他们希望以某种可接受的质量水平、对资源的有效利用和最少的系统混乱来实现这一目标。
当然，质量、效率与秩序远非唾手可得，尤其在面临交付期限时更是如此。当“正确行事”意味着放缓进度时，急功近利的团队可能跳过测试环节、偷工减料，甚至对代码评审敷衍了事。打造优质软件绝非易事，也非仅凭直觉即可达成。团队急需经验丰富的资深人员——他们具备千锤百炼的技术能力，深谙成败之道，并敢于为软件的可靠性扛起全责。
每个项目都是学习契机，但个体经验储备终究有限。这意味着必须建立经验共享机制——既要汲取他人的失败教训，也要借鉴成功经验。经验不足的团队成员可能从未见证过优质软件的诞生过程，甚至将代码产出等同于工程能力的全部。资深工程师则可通过多维赋能发挥作用：主导代码评审与架构评审、传播架构最佳实践、打造工具链体系以提升全体成员的交付效率与系统安全性。
主管工程师是团队的行为标杆。管理人员通过建设团队文化，推行良好的行为，来确保工程规范落地。但是，工程规范是由项目中最受尊敬的工程师设定的。不管工程规范是什么，如果最资深的工程师不写测试用例，就永远无法说服他人去写。这种影响力早已超越技术范畴，还同样关乎团队文化。当资深工程师大声赞扬别人的工作，保持相互尊重，并提出要澄清的问题时，其他人也会更容易有样学样。当初级工程师把某资深工程师当作其想要成为的那种工程师来尊重时，这种心理认同将成为驱动其行为改变的强大动力（第7章将探讨资深工程师如何通过成为榜样来实现组织能力升级）。
或许此刻你已认同主管工程师应当肩负宏观战略规划、重大项目把控与文化影响力塑造等职责，但现实困境在于，这些工作无法叠加在主管工程师的日常编码任务之上。每当投入时间撰写技术战略文档、评审项目设计方案或制定工程规范时，就意味着牺牲编码、架构设计或代码贡献等传统考核指标。如果最资深的工程师终日埋头编写代码，尽管代码库可以直接受益于其技术能力，但公司将错失唯有他们才能创造的价值。这种技术领导力必须成为主管工程师岗位职责的有机组成部分，而非他们本职工作的干扰因素。
主管工程师角色的具体职责因企业而异，但其核心特征具有普遍一致性。本节将系统阐述这些共性，并作为全书论述的基石展开。
首先也是最重要的，主管工程师本质上是领导者。主管工程师通常具有与产品经理相同的职级。首席工程师则与总监同级。主管工程师需要展现出与同级管理者同等的成熟度，甚至需要成为团队中“定海神针”般的存在。你甚至可能发现自己的资历与经验超越了部分中层管理者。每当出现“该有人站出来推动此事”的时刻，这个人大概率就是你。
是否必须成为领导者？中级工程师有时会问我他们是否真的需要处理好“那些软绵绵的人际关系”才能走得更远。难道拥有技术能力还不够吗？如果你是那种因为想做技术工作才进入软件工程领域的人，不喜欢与他人交谈，则这种职业瓶颈确实令人沮丧。但是，如果你希望持续地成长，那么仅凭技术终将触及职业天花板。完成更大的事情意味着要与更多的人一起工作，而这需要你具备更广泛的技能。
随着薪酬的增长，你的时间变得越来越昂贵，你所做的工作被期望具有更大的价值，产生更大的影响力。你需要技术判断力，融合业务现实，评估特定的项目是否值得做。随着资历的增加，你将承担更大的项目，这些大项目如果仅凭个人技能而没有合作、沟通和协调，是不可能成功的。如果你不能说服团队中的其他人相信你的方案，那么你的方案只会让你感到沮丧。但无论你是否愿意，你都会成为标杆，其他工程师会从拥有高职位头衔的人身上了解如何做事。所以，逃避领导职责既不现实也不明智。
不过，主管工程师的领导方式与经理不同。通常情况下，主管工程师不直接管理团队成员。虽然他们积极参与并致力于提升周围工程师的技能，但他们不负责绩效考核、休假审批和费用核准，更无权决定人员去留或晋升——尽管经理很重视他们对其他团队成员技能和产出的意见。他们的领导力是通过其他方式体现的。
他们的领导力体现在设计“康庄大道”来帮助团队成员规避常见错误，通过代码评审提升其他工程师的技能，或指出设计方案与业务需求之间的偏差。教导是领导力，默默提升团队水平是领导力，设定技术方向是领导力，甚至凭借卓越技术让他人因信任而认可你的方案也是领导力。若符合上述描述，那么恭喜你，你已是领导者。
| 你可以内向，但不能让人讨厌 对许多人来说，“成为领导者”的想法可能有点吓人。不要担心，并不是所有的主管工程师和首席工程师都需要成为“合群的人”。内向的人完全能够胜任技术领导岗位——即使是最好静的工程师，也可以通过他们的决断和良好的影响力来设定一个强有力的技术方向。卓越的领导力无需以社交热情为前提。不过，你必须成为典范，而且你必须善待他人。 我们中的许多人都能说出几个因性格乖张而被边缘化的工程师的故事。20世纪80年代和90年代的科技文化，以Usenet用户组中的讨论为例，充斥着难以对付的、让人不愉快的“混蛋操作员”的流行形象，他们的同事不仅容忍他们的行为，而且做出奇怪的技术决定，只是为了避免与他们打交道。在如今的职场上，这样的工程师已成为团队毒瘤。无论他们的技术产出如何，都不难想象，当他们不愿跨团队协作时，其他工程师必然效能下降，导致跨团队项目失败。 把这样的人当作榜样，可能会毁掉整个组织。如果你怀疑自己处于这种困境，建议阅读Kind Engineering，Squarespace的SRE经理Evan Smith在其中给出了关于如何成为积极友善同事的具体建议。你会惊奇地发现，你可以很快扭转局面，改善协作口碑。 |
主管工程师既是领导岗位，也是高度专业化的技术职位。这要求你具备技术背景，以及通过工程经验积累的各种技能和直觉。要发挥影响力，你需要对优秀的工程设计有很高的标准，并在实践中示范。你的代码评审必须对你的同事有指导意义，并且能使代码库或架构变得更好。当你做出技术决定时，你需要理解其中的利弊得失，并帮助其他人理解它们。你还需要能够在必要时深入细节，提出正确的问题，并理解答案。当你因为某一特定行动方案或技术文化的某一特定变化而争论时，你要明白自己在说什么。因此，专业素养是你的立身之本。
但这并不一定意味着你要写大量的代码。你的目标是有效地解决问题，而编程往往不是对你时间的最佳利用。对你来说，承担只有你能做的设计或领导工作，将编程任务委托给他人，可能更有意义。主管工程师经常接手一些模糊的、混乱的、困难的问题，要对这些问题做足工作，使其可以由其他人继续处理。一旦问题得到解决，它就会成为经验不足的工程师成长的机会（有时需要主管工程师的支持）。
对一些主管工程师来说，代码库仍是解决许多问题的最有效工具。而对其他人来说，撰写文档，或成为数据分析高手，或进行数量多得吓人的一对一会议，也能获得很不错的结果。重要的是问题得到解决，而不是如何解决。[6]
[6] 这正是我不太赞成让资深主管工程师参与编程面试的原因。毕竟，到了这个级别，他们要么本身代码实力就很强，要么已经懂得如何借助其他技能来应对技术难题。因此，面试评价的重心，更应放在最终的结果上，这才是最关键的。
当你初入职场，成为一名初级工程师时，你的经理可能会告诉你要做什么工作以及如何去做。等你成了高级工程师，你的经理会告诉你哪些问题是需要解决的，然后让你自己去想办法解决。在你晋升为主管工程师后，你的经理会为你提供信息并分享背景，但你应该告诉他们哪些是重要的。正如Intercom的主管工程师Sabrina Leandro所问：“我知道应该把重心放在那些有影响和有价值的工作上，但是从哪里找到这个神奇的、能带来巨大影响的工作待办事项列表呢？”答案是：“主动创造它们！”
作为组织中的技术决策层成员，你很可能遭受多方诉求的拉扯。这取决于你如何安排自己的时间。一周的工作时间是很有限的（见第4章）。你可以选择如何利用好这有限的时间。如果有人要求你做某件事情，你最好带着经验去做决定。你需要权衡轻重缓急、时间承诺和收益，包括你想与请求你帮助的人保持的关系，然后做出自己的决定。如果CTO或其他权威人士告诉你他们也需要你做一些事情，你必须给予重视。但是，拥有自主权意味着承担责任。如果他们要求你做的事情被证明是有害的，你有责任说出来，不要默默地让灾难发生。（当然，如果你希望自己的意见被倾听，你必须先建立起自己值得信赖且判断可靠的声誉。）
作为技术领导者，主管工程师的部分职责是确保组织有良好的技术方向。组织提供产品或服务的基础是一系列的技术决定：系统架构设计、存储方案选型、工具和框架的选择等。无论这些技术决定是在团队层面做出的还是跨团队或整个组织做出的，你要做的部分工作就是确保它们被很好地实现，并被写下来。你不需要指出技术方向的所有方面（甚至不一定是任何方面！），但要确保有一个商定的、被充分理解的方案能解决组织所要解决的问题。
你的资历越深，你就越依赖强大的沟通技巧。你所做的一切都涉及将信息从你的大脑传递到他人的大脑。你越被人理解，你的工作就越容易。
上述原则应该能帮助你初步定位主管工程师角色，但你会注意到，它们遗漏了很多实施细节！事实是，一个主管工程师的日常工作可能与另一个主管工程师的日常工作有很大不同。主管工程师角色的实际情况取决于公司或组织的规模和业务需求，同时受个人工作风格和偏好的影响。这意味着你很难将自己的工作与周围或其他公司的主管工程师的工作做比较。在本节中，我们将解读主管工程师角色的更多特征。让我们从汇报链切入。
对于主管工程师如何向组织的其他部门汇报，业界还没有形成统一的模式。一些公司安排主管工程师向首席架构师或CTO汇报；另一些公司则把主管工程师分给各事业部总监管理，或采用混合型管理模式。尽管没有唯一正确的答案，但根据组织目标的不同，却存在很多错误答案。
汇报链（见图1-3）将影响你获得的支持程度、信息获取权限，以及许多情况下跨部门同事对你的认知定位。
图1-3 处于组织结构不同层级的主管工程师的汇报链。即使这些主管工程师的资历都是一样的，主管工程师A也会发现自己比主管工程师D更容易了解组织背景，也更容易进行总监级别的对话
向组织结构中的“高层级”汇报，比如向总监或副总裁汇报，能给你带来更广阔的视野。你接触的信息将是高层次且有影响力的，需要你解决的问题也将如此。看他们做决定、主持会议或处理危机，将是你独特且宝贵的学习机会。
不过，你能获得“高层级”关注的时间可能会远少于“低层级”的情况。你的经理对你的工作了解有限，可能导致其难以有效为你争取资源或提供职业发展支持。例如，某主管工程师与单一团队紧密合作却向总监汇报，可能产生两种风险——要么与团队其他成员产生疏离感，要么可能会将本应在团队层面解决的局部分歧上升到更高层面来处理。
如果你发现你的经理没有时间了解你所做的工作，无法理解你的工作价值，或者将宝贵时间耗费在低技术含量的决策上，考虑一下，你可能更乐于与一个工作重点与你更一致的经理合作。
向组织结构中的“低层级”汇报，比如向经理汇报，你有可能从你的经理那里得到更多的关注，这对你的职业发展有利。如果你希望深耕特定技术领域，则你有可能从与熟悉该领域的经理的合作中受益。
但隶属于单一团队的主管工程师可能难以影响整个组织。不管你是否愿意承认，人们都会关注地位和等级。如果你向一个经理汇报，你的影响力可能会小得多，你得到的信息也很容易被过滤，且不得不以团队的问题为中心。如果你的经理接触不到某些信息，那几乎可以肯定你也接触不到。
向经理汇报可能还意味着你要接受比你经验少的人的指导。这本身不是什么问题，但是你从你的经理那里学到的东西可能很少，而且对你的职业发展没有帮助：你的经理有可能不知道如何帮助你。如果你的一些管理需求在其他地方得到了满足，这些情况尚可接受[7]。特别地，当你向组织结构中的“低层级”汇报时，要确保与你的上级建立跨级沟通机制[8]，并确保始终与组织的战略目标保持同步。
[7] 推荐阅读Lara Hogan撰写的“Manager Voltron”一文。
[8] 如果你的公司尚未建立跨级沟通机制，则需要明确表明寻求跨级对话并非质疑经理的权威，而是为了更好地理解组织战略并有效协作。理想情况下，公司的管理者应充分认识到跨级沟通的价值并协助建立相应机制。
如果你的经理对你如何有效地完成工作存在异议，则可能引发矛盾。你可能陷入前面提到的局部最优困境，即你的经理希望你把团队的利益放在首位。但是，当组织正面临需要你参与解决的挑战时，这种错位将产生负面影响。当一方掌握另一方的绩效评估与薪酬决策权时，技术层面或优先级层面的平等讨论将变得尤为困难。若此类冲突频繁发生，建议重新评估向“高层级”汇报的可行性。
你的汇报链很可能会影响你的职责范围——你需要密切关注且负有一定责任的领域、团队或小组，即使你在这个领域、团队或小组没有担任任何正式的领导角色。
在你的职责范围内，你应该对短期目标和长期目标有一定的影响力。你应该了解正在做出的重大决定。你还应该对变化有自己的看法，并代表那些没有影响力的人去阻止影响他们的不良技术决策的制定。你需要考虑如何培养和发展下一代的高级工程师和主管工程师，主动发现并提议有助于他们成长的项目与机遇。
在某些情况下，你的经理可能希望你把大部分技能和精力用于解决属于其职责领域的问题。在其他情况下，团队可能只是你的“大本营”，你会将一部分时间用于处理组织的紧急事务。如果你向总监汇报， 则存在两种情况：要么你站在战略高度统筹全局，要么明确自己想要加入总监领导的部分团队或技术领域。你需要弄明白自己属于哪种情况。
你要准备好在危机出现时突破自己的职责范围。例如，系统宕机期间不存在“这不归我管”的说法。你还应该对跳出日常经验有一定的适应性，必要时领导团队，学习你所需的技能，并具体解决问题。主管工程师的部分价值体现就在于突破固有职责范围。
尽管如此，我仍建议你清晰界定自己的职责范围，即使它是临时且可以改变的。
如果你的职责范围太宽泛（或未定义），则有几种可能的失败模式。
如果任何事情都可以归到你的职责范围，那么出现的所有问题都会归咎于你，特别是当你所在组织的高级工程师人数不足的时候。组织中总会存在各种支线任务。事实上，很容易形成一种完全由支线任务[9]构成的角色定位，缺乏核心目标。你必须警惕精力过度分散带来的风险：最终可能导致你的工作成果不连贯，使你和雇用你的组织难以感知实质性成就。
[9] 支线任务是电子游戏中与主线任务无关的部分，但你可以选择完成它们来获取金币、经验值，或者仅仅是为了乐趣。想象一下这样的场景：“我本来正准备杀入重兵把守的堡垒，去击败那个一直在这片土地上肆虐的恶魔，不过嘛，先帮你找猫也行。”
当某资深人士被认为能处理所有事务时，组织惯例可能演变为要求其参与每个决策的制定。这种依赖反而会拖累组织整体的效率，因为组织已无法在没有其参与的情况下做出有效决策。
如果你摆脱了试图做所有事情的困境，则需要持续承担决策成本——不断决定该处理哪些事务。我会在第4章中讨论如何选择你的工作。
如果你需要与多个团队保持广泛的协作，则可能难以建立足够的日常联系来培养有助于推进工作的友好关系（同时也会降低工作乐趣）。其他工程师也会遭受损失：他们无法获得“本地”资深工程师参与其工作所带来的指导与支持。
在职场上，如果职责范围过于宽泛，则往往难以有效开展工作。更可取的做法是聚焦特定领域，建立影响力，并积累成功案例。你应该将时间和精力聚焦于彻底解决某些问题，待时机成熟后再拓展至新领域。
不要把自己的职责范围定得太窄。一个典型的例子是，某主管工程师隶属单一团队并向经理汇报。这种模式可能深受管理者青睐——他们获得了一个能承担大部分设计工作、技术规划任务，甚至可担任项目技术负责人或团队领导者的技术专家。一些工程师也会对此感到满意，这意味着可以深入研究团队的技术难题，洞悉所有细节。但你需要特别注意这种过窄的职责范围可能引发的潜在风险。
你可能需要将全部时间投入那些不需要主管工程师专业技能的工作。如果你选择深入钻研某一技术，则必须确保其属于公司核心业务、关键任务团队或对公司具有战略价值。
主管工程师往往高度稀缺。如果你被分配至单一团队，则你可能无法优先获得参与跨团队解决问题的机会，你的经理肯定不愿让你参与其他团队的工作。
过窄的职责范围可能意味着没有足够的工作让你忙碌，同时你可能限制了经验不足的人的学习机会。如果你总是有空解答所有疑问并处理所有棘手的问题，其他人就无法获得解决问题的经验。
当主管工程师的工作量不饱和时，他们就容易掉进“自我创造工作”的陷阱。那些看似过度设计的解决方案的背后，往往可能是主管工程师未被分配更有难度的工作。
有些技术领域和项目的深度足以支撑主管工程师投入整个职业生涯而不缺乏发展机遇。
只要人们普遍认为你所做的工作具有影响力，你在开展工作方面就会有很大的灵活性，包括在一定程度上自主界定你的工作是什么。以下是一些值得你自我叩问的问题。
你是否喜欢专注于一个问题或技术领域？或者你是否更倾向于在多个团队或技术领域进行广泛的研究，且重点关注在没有你参与的情况下无法解决的单一问题？是深度优先还是广度优先在很大程度上与你的个性和工作风格有关。
没有标准答案，但如果你的职业偏好与职责范围相契合，你的工作将更为轻松和愉快。例如，如果你想影响组织或业务的技术方向，你就会主动寻求能让你拥有宏观视角的机会——参与关键决策，解决影响许多团队的复杂问题。如果你试图做到这一点，却被限定在单一的深层架构难题中，则只会陷入多方掣肘的困境。相反，如果你的目标是成为特定技术领域的专家，则需要高度聚焦，把大部分时间和精力用在这个领域。
Twitter[10]的杰出工程师Yonatan Zunger提出了从事世界上任何工作都不可或缺的“四大技能”。
[10] Twitter现已更名为X。——译者注
编程、法律诉讼、内容创作、烹饪等——相应岗位从业者的典型工作内容。
明确需要完成的工作及其意义，并维护相关叙事逻辑。
实现目标的具体路径，消除混乱、追踪任务、识别瓶颈，并确保问题得到解决。
把团队成员凝聚成高效团队，培养他们的技能，为他们的职业发展指明道路，处理成员协作问题。
Zunger指出，你的职位越高，你的这些技能的组合与职位头衔的关联性就越弱：“职位越高，这种现象就越明显。人们越来越期望你能轻松、流畅地在这些技能之间切换，从而让它们在任何场合下都能发挥作用。”
每个团队和项目都需要这些技能。作为一名主管工程师，你会用到所有这些技能，但不需要样样精通。我们各有不同的偏好。有些工作让你充满热情，有些工作则让你避之不及。如果你不确定自己的偏好，Zunger建议你与朋友讨论以上每种技能，并让他们观察你的情绪反应和精力状态。如果某类工作让你极度抗拒，务必与擅长此类工作的伙伴协作。无论你选择广度优先还是深度优先，你都会发现，仅掌握核心技术很难持续成长。
| 超级专家的职业道路 在极少数情况下，某些在关键业务领域非常出色的高级工程师可以在不提前规划或不影响周围人的情况下取得成功。Zunger称他们是“超级专家”，但他指出，“随着时间的推移，超级专家的影响力会减弱。实际上，高级职位中纯粹的超级专家非常少，市场需求也不大。”Pat Kua称这条道路是“真正的个人贡献者之道”，并强调仍然需要出色的沟通能力和协作能力。根据企业的不同，“超级专家”可看成主管工程师或完全独立的个人贡献者。 |
你可以将此处的“编程”随意替换成自己职业生涯中迄今为止所掌握的任何核心技术技能。核心技术技能推动你走到今天，当你发现对自己的核心技术技能生疏时，你可能会因此不安。一些主管工程师发现自己止于阅读或评审大量代码，而不再写代码。还有一些主管工程师则成了项目的核心贡献者，每天都在写代码。剩下的主管工程师则找各种理由写代码，找那些有趣、能学到新东西但不会造成延期的非关键项目做。
如果你一天不写代码就焦躁不安，你需要确保自己不会负责一个广泛的架构或担任有影响力的角色，否则你不会有时间写代码。或者你至少要有一个规划，让你能够时不时编码来“练练手”，这样你就能抵制编码的冲动，而避免把更大、更重要的问题抛在一边。
编程有让人安心的快速反馈周期：每一次成功的编译或测试运行都会告诉你事情进展如何。这就像每天都有一次小型的绩效评估！如果没有任何内置反馈机制来告诉你做的对不对，这样的工作会令人沮丧。
在长期项目、跨组织协作或战略/企业文化转型中，可能需要几个月甚至更长的时间，你才能得到你所做的事情是否有效的验证信号。如果你在一个反馈周期较长的项目中感到焦虑，请你的经理定期告诉你事情的进展。如果你需要这样的反馈却没有，就只能考虑那些在较短时间内有反馈的项目。
虽然大多数主管工程师没有直接下属，但有些主管工程师有直接下属。技术领导经理（tech lead manager，TLM）有时也称团队负责人，兼具技术领导者与团队管理者职责。这是众所周知的高难度复合型角色：既要对团队成员负责，又要交付技术成果，很容易顾此失彼。同时，培养这两方面的技能也需要大量的时间，我曾听闻担任此类角色的人感叹职业发展受限。
一些人会在管理岗位上工作数年后转任主管工程师，通过定期轮岗保持技术与管理技能的敏锐度。第9章将深入探讨这种“钟摆式轮岗”及技术领导经理的具体实践。
在“主管工程师原型”（Staff Archetypes）一文中，Will Larson描述了他所看到的主管工程师角色的4种不同原型。你可以使用这些原型来定义你所拥有或希望拥有的角色类型。
与管理人员协作指导一个或多个团队的工作。
对某个关键领域的技术方向和质量负责。
聚焦单点复杂难题的突破性解决。
为组织提供领导力支持。
如果你没有从中找到适合自己的原型，或者你的角色跨越了一个以上的原型，没关系！这些原型并不是绝对的，它们只是给我们提供了一些思考框架，用于帮助我们找到理想的工作模式。
前面我们讨论了主管工程师的职责范围和汇报链：你在组织中可掌控的范围，以及你在组织结构中的位置。此外，我们还分析了你的天赋：你喜欢怎样工作，以及你喜欢什么样的技能。但是，即使你了解所有这些，并已清楚自己的角色定位，也仍有一个核心问题待解决：你需要聚焦在哪些工作上？
随着你的影响力的提升，会有越来越多的人希望你关注一些事情：有人正在为组织如何进行代码评审编写一份最佳实践文档，他们想听听你的意见；你的团队正在招聘人员，需要你帮助决定面试的内容；如果你能设法取得组织高层的支持，项目就能够有更大的进展。而这还只是周一早上，你要处理的事情就已经这么多了。
在某些情况下，你的经理及其上司会对你的工作重点有明确的要求，他们甚至会专门雇用你来解决特定问题。但在大多数情况下，你仍拥有决定什么最重要的自主权。每当你选择工作内容时，你也在主动放弃一些要做的事情。因此，对待承接的任务须保持清醒的判断并审慎取舍。
在职业生涯的早期，有些工作你做得很好，即便这些工作后来证明并非必要，你也算得上成功。不过，晋升到主管工程师级别后，你做的一切都有很高的机会成本，所以你做的工作必须是重要的。
“你做的工作必须是重要的”并不意味着你只能投身于最前沿、最光鲜的技术或高管亲自推动的项目。真正重要的工作往往是隐形的基石：可能是为团队梳理尚不清晰的认知框架，或者挖掘不存在的数据以支撑决策，抑或深入10年未动的代码库和文档以清理bug。有意义的工作会有多种形式。
你要知道为什么你正在处理的问题具备重要的战略意义。如果它不重要，就去做其他工作。
当主管工程师投身于任何中高级工程师都可以完成的编程项目时，虽然也能交付成功，但更应关注那些需要主管工程师技能才能解决的问题——这类问题往往超出中高级工程师的能力范畴。不要把有限的宝贵资源浪费在不值得的事情上。
选择项目时，谨慎避开已有大量资深成员参与的项目。评估其他参与者的能力，判断他们能否成功解决问题。某些项目甚至可能因额外领导的介入而延缓进度[11]。注意，如果项目中“理性建议者”的数量远超实际执行者（如编程人员或核心贡献者）的数量，切勿强行介入。选择真正需要你独特价值的项目。第4章将提供决策工具，帮助你判断项目的适配性。
[11] 人们常引用布鲁克斯法则：“为进度滞后的软件项目增加人力，只会让它延期得更久。”尽管布鲁克斯本人称之为“一种过分简化的说法”，但这其中确实蕴含着一定的道理。可参考The Mythical Man-Month。
至此，你应对自身角色的职责范围、所属类型及当前工作内容有了清晰的认知。你还需要确认自己的理解是否与上级和同事的期望一致，尤其在刚加入一家公司时，主管工程师的角色定位、职责范围、决策权限等关键问题可能存在显著认知差异，建议你尽早弄清楚。
我从我的朋友Cian Synnott那里学到的一个技巧是，写出自己对工作的理解并与经理分享。尽管回答“你的工作职责是什么”这个问题会让你感到不安：如果别人认为我做的没用，或者认为我做得不好怎么办？但把它写出来就可以消除分歧，而且可以尽早发现自己对这个角色的心智模型是否和其他人一样。与其等到绩效评估时才发现分歧，不如现在就主动消除分歧。
以下是Ali的角色描述，他是一名广度优先型主管工程师，正在协助（而不是领导）一个大型的跨团队项目。
| Ali是做什么的 概述这份文件是我未来一年的工作计划。我的首要目标是确保零售工程小组的成功。我希望花50%的时间为该小组提供技术指导，30%的时间贡献给“新零售”项目，剩余的时间用于跨部门的活动（API工作组、架构评审等）和团队建设（面试、指导高级工程师等）。作为应急指挥轮岗项目的一部分，我被要求每10周有1周待命。 目标 1．通过指导技术方向，促进组织目标的设定，以及预测风险，推动零售工程小组完成目标。 2．担任“新零售”项目的顾问，起到力量倍增作用，识别威胁到项目目标的风险或工程实践中的差距。 3．领导零售工程小组的架构评审。 4．通过参与其他销售小组的架构评审，提升跨部门协作与规划一致性。 5．在需要时，比如当发生突发事件或冲突时，承担部分领导责任。 行动 • 提出解决零售业风险与机遇的OKR（Objectives and Key Results，目标和关键成果）。 • 商定“新零售”项目的目标和可交付成果，并确保团队保持一致。 • 为跨整个组织的团队提供架构方面的咨询，推荐架构方法并负责撰写RFC（Request For Comments）文件的部分内容，但不成为任何RFC文件的主要作者。 • 指导/辅导高级工程师。 • 面试高级工程师和主管工程师候选人。 成功如何定义 • 为零售业务建立起未来5年可用的系统。 • “新零售”项目进展良好，所有团队对项目目标达成一致。 |
不必苛求完美，确保足够正确即可。明确目标并不是限制你探索其他领域，而是作为行动指南，帮助你提醒自己是否真正落实了所宣称的工作职责。
如果发现需要提前调整工作的重点（世事无常，如外部环境发生变化），请及时更新角色描述。清晰的自我预期能确保团队上下认知一致。
你的职责是助力组织成功。无论是技术专家、开发者还是特定团队成员，最终目标都应服务于组织战略。资深从业者的工作范畴通常超越既定职责，必要时甚至会突破职位描述的职责范围。若某项任务对项目成功至关重要，即使超出常规分工，你也应主动承担。
我在Squarespace的同事讲了这样一个故事：2012年的一天，他们的数据中心停电了，他们背着桶装柴油爬了17层楼，硬生生地用发电机发电来保障数据中心的正常运行。这项“柴油搬运工”的苦差事并未出现在任何岗位职责描述中，但在那种情况下，为了保持数据中心正常运行，必须那样做。几年前，我所在公司的ISP（Internet Service Provider）机房被水淹没，千钧一发之际，为了降低水位，所有人变身“人肉抽水机”——用垃圾桶串联成“排水链”，一桶接一桶手动排水。那一刻，保住服务器比什么都重要。再来看2005年Google某项目赶工期的名场面：硬件人手严重不足，我被临时征调到圣何塞的数据中心工作几天，化身“服务器装配工人”。为了推动项目取得进展，你会做需要你做的几乎所有事情。
当然，这种职责外的工作通常不那么戏剧化。它可能意味着要进行无数次沟通协调，或者当观察到新人迷失方向时，和他们沟通使其重回正轨。再强调一次：你的价值取决于组织当下的真实需求。在第2章中，我们将讨论如何敏锐感知组织需求。
• 主管工程师角色的定义是模糊的。你需要主动探索自己的角色是什么并弄清楚职责范围。
• 主管工程师虽然没有经理头衔，却承担领导职责。
• 主管工程师需要兼具技术判断力和扎实的技术经验。
• 主管工程师需要明确职责范围，还需要划定自己的责任和影响力。
• 主管工程师的时间有限。你需要慎重选择一个重要的聚焦领域，以免浪费自己的技能。
• 主管工程师需要与管理层保持一致。明确你自己的工作是什么，明确你的管理者认为你的工作是什么，了解什么对组织是有价值的，什么是真正有用的，明确设定预期。并非所有公司都需要全能型的主管工程师。
• 主管工程师的工作不拘一格，这很正常。
