技术负责人（Tech Lead）

多年前我成了技术负责人（tech lead）。当时我刚被提升为高级工程师（senior engineer），在一个由几位高级工程师组成的小团队里工作。我之所以有点意外地被提升为技术负责人，是因为无论从职级还是经验年限来看，我都不是团队里资历最深的人。回过头看，我有几个优势。其一，我不只是一个好工程师。我还是一个好的沟通者。我能写出清晰的文档，能从容不迫地做演示，还能与不同团队、不同角色的人交谈，解释正在发生的事情。我同样擅长排定优先级（prioritizing）。我渴望推动工作前进，决定下一步该做什么。最后，我愿意接手烂摊子，做任何需要做的事来推动进展。我认为，最终起决定作用的正是这种务实的紧迫感。毕竟，技术负责人这个角色是一个领导职位，即使它不是管理职位。

我也见过技术负责人举步维艰。一个特别令人难忘的例子是，有个人是出色的工程师，代码写得很好，但讨厌与人交谈，还常常被技术细节带偏。我看着他钻进一个又一个兔子洞，与此同时，产品经理（product manager）利用他的缺席，强行让团队其余成员承诺交付一批设计糟糕又过于激进的特性。项目一团糟，而这位技术负责人做了什么？他去追逐下一个重构了，因为他确信问题完全出在代码结构上。你大概也认得出这个故事，因为它到处都在发生。认为技术负责人这个角色理应交给最有经验的工程师——那个能处理最复杂特性、写出最好代码的人——是一种常见的误解，就连经验丰富的管理者也会犯。技术负责人不是为那些想要自由地深度专注于自己代码细节的人准备的。一个这么做的技术负责人没有在履行自己的职责。但技术负责人的职责到底是什么？我们对这个人有什么期待？

与软件工程中的许多头衔一样，“技术负责人"缺乏一个通用的定义。我能做的最好的事，就是从自己和别人的经验中总结。我作为技术负责人的工作是继续写代码，但还承担了额外的责任：向管理层代表团队、审核特性交付计划、处理项目管理（project management）过程中的许多细节。我之所以能当技术负责人，尽管不是资历最深的人，是因为我愿意也有能力承担这个角色的职责，而团队里其他人更想保持纯粹，只专注于自己写的软件。当我们在 Rent the Runway 创建工程职业阶梯（engineering career ladder）时，我们有意识地决定把技术负责人的角色定义为一组工程师可以在阶梯上许多位置承担的特征，而不是一个特定的级别。我们采取这种做法，是因为我们想承认：随着团队的变化和演变，技术负责人这个角色可能由不同阶段的工程师担任，也可能从一个工程师传给另一个工程师，而两人的职能职级都不一定需要变化。技术负责人这个角色在不同公司之间可能不完全相同，甚至在同一家公司内的不同团队之间也不尽相同，但从这个头衔我们可以知道，它既是一个技术岗位，也是一个领导角色，而且它往往是一组临时的职责，而不是一个永久的头衔。那么，说了这么多：技术负责人到底是什么？以下是我们（Rent the Runway）创建的定义：

技术负责人角色不是阶梯上的一个点，而是任何工程师在达到高级级别后都可以承担的一组职责。这个角色可能包含也可能不包含人员管理；如果包含，技术负责人需要按照 RTR 技术部门的高管理标准来管理这些团队成员。这些标准包括：

定期（每周）一对一沟通（1-1 touchbase）
定期反馈职业成长、目标进展、需要改进的领域，并在适当时候给予表扬
与下属一起确定需要学习的领域，并通过项目工作、外部学习或额外指导帮助他们成长

如果技术负责人不直接管理下属，他们仍然需要为团队其他成员提供指导（mentorship）和建议。

技术负责人正在学习如何成为一名强势的技术项目经理（technical project manager），因此他们通过有效委派工作来放大自己，而不进行微观管理（micromanaging）。他们关注整个团队的生产力，努力提升团队工作成果的影响力。他们有权为团队做出独立决策，并正在学习如何处理困难的管理和领导情境。他们也在学习如何与产品、数据分析（analytics）以及业务的其他领域有效合作。

工程师并非必须担任过技术负责人才能晋升，但这是工程师从高级工程师 1 成长为高级工程师 2 最常见的途径，也是从高级工程师 2 成长为工程主管（engineering lead）的必要条件。实际上，如果没有担任过技术负责人，很难在高级工程师 2 之上继续成长——即使走个人贡献者（individual contributor）路线也是如此，因为在高级别上，领导力和责任感非常重要。

也许一个更好的概括是 Patrick Kua 在他的书《与技术负责人对话（Talking with Tech Leads）》中使用的描述：

一个领导者，负责一个（软件）开发团队，至少花 30% 的时间与团队一起写代码。

技术负责人有能力充当强有力的技术项目领导者，并在更大规模上运用他们的专长，让整个团队变得更好。他们可以做出独立决策，并在与团队可能拥有的非工程合作方协调方面发挥重要作用。你会注意到，这里完全没有提到具体的技术工作。这是一个高级工程角色，但把技术负责人的概念等同于团队里最好或最有经验的工程师，是一个错误。不与他人打交道就无法领导，而我们要求新晋技术负责人锻炼的，正是人际技能（people skills），而远不止纯粹的技术专长。不过，技术负责人将在一项重要的新技术技能上下功夫：项目管理。拆解项目的工作与设计系统的工作有很多相似之处，即使是对管理他人不感兴趣的工程师，学习这项技能也很有价值。

如果你发现自己身处技术负责人的位置，恭喜你！有人认为你具备成为团队关键人物（point person）的潜质。现在是时候学习一些新技能了！

成为技术负责人（Being a Tech Lead）

成为技术负责人是在没有正式权力的情况下施加影响（influencing without authority）的练习。作为技术负责人，我在领导一个团队，但我们都向同一位工程经理（engineering manager）汇报。所以我不仅必须影响我的同级，还必须向上影响我的经理，以确保我们在优先处理正确的工作。在最近的一个角色中，这一点尤其具有挑战性，因为我成为技术负责人后处理的第一个项目就是停止所有特性开发，专注于技术债（technical debt）。在我看来，“技术债的罐子"被踢下路已经太久了：部署新代码很困难，运营现有服务的成本很高，值班（on-call）轮换简直是地狱。我相信我们需要慢下来，才能在将来快起来。然而，这对其他想写有趣新特性的开发人员来说并不好卖，对我的经理来说也不好卖——他那边总有源源不断的客户请求。我通过强调这对团队每个成员的不同影响来推销这个想法。对有些成员来说，这是拥有更可靠的服务；对另一些成员来说，这是迭代速度；还有的成员关心的是减轻值班负担，让他们能睡个整觉。与经理交谈时，我强调降低运营开销意味着我们团队未来可以完成更多的特性工作。

成为技术负责人要求我改变关注点。工作不再那么关于我自己、关于做最有技术挑战性的想法或最有趣的项目；相反，我的关注点更多在团队上。我如何赋能（empower）他们？我如何移除拖慢他们的障碍？做一个重写项目，或者某个能让我尽情展现技术实力的新特性，可能更有趣，但团队当时需要的是处理技术债、专注于运营。最终，这项举措取得了惊人的成功。团队把关键的分页告警（paging alert）数量减少了 50%，接下来的一个季度我们几乎把部署次数翻了一番。

Caitie McCaffrey

所有优秀技术负责人都知道的这一个诀窍

你是技术负责人，这意味着你懂一些软件知识，而且你的经理认为你足够成熟，可以承担更大的项目责任。然而，如果你搞不明白成为优秀技术负责人的最大诀窍——愿意从代码中抽身，学会如何平衡你的技术投入与整个团队需要的工作——那么再强的技术能力和成熟度也毫无意义。你必须停止完全依赖你的旧技能，开始学习一些新技能。你将学习平衡的艺术。

从现在起，无论你在职业生涯中走到哪里，平衡都很可能是你的核心挑战之一。如果你想对自己的工作拥有自主权，想自由选择在什么时间做什么工作，你就必须掌控自己的时间和使用时间的方式。更糟糕的是，你常常需要在做自己会做且喜欢做的事（比如写代码）与做自己不会做的事之间取得平衡。人类天然偏爱自己已经精通的活动，所以当你不得不减少花在现有才能上的时间、转而学习新东西时，会感觉非常不舒服。

在项目管理与监督的工作和亲自动手的技术交付之间取得平衡可能很难。有些日子你处于创造者日程（maker’s schedule），有些日子你处于管理者日程（manager’s schedule）。通过反复试错，你需要学会管理自己的时间，为自己安排大小合适的整块工作时间。最糟糕的时间安排错误是让自己被随机拖进会议。如果每隔一小时就被一场会议打断，你很难进入写代码的状态。

即使日程安排得很仔细，你也常常没有时间连续几天专注于编码问题。希望你在此之前已经学会了一些技巧，能帮你拆分自己的工作，这样你就不需要花好几天专注努力来完成技术任务。你也知道，让团队进入一个能让他们长时间专注于开发的日程很重要，因为他们需要连续几天专注于编码问题。你领导工作的一部分，就是帮助其他利益相关者（stakeholder）——比如你的老板和产品经理——尊重团队的专注时间，并安排不会压垮个人贡献者的会议日程。

技术负责人入门（Being a Tech Lead 101）

假设你正与一位产品经理和另外四位工程师组成的团队合作，共同开展一个为期数周的大型项目，推出一项新举措。在这个场景中，技术负责人有许多职责，具体取决于你处于项目生命周期的哪个阶段。当然，你需要写一些代码，做一些技术决策。但这只是你要扮演的角色之一，而且很可能不是最重要的角色。

技术负责人的主要角色

作为技术负责人，你的最高优先级是从宏观视角看待工作，让项目持续前进。你如何从独自组织和规划自己需要写的代码，转变为组织和领导整个项目？

系统架构师（systems architect）与业务分析师（business analyst）

在系统架构师和业务分析师的角色中，你识别为了交付即将到来的项目而需要变更的关键系统和需要构建的关键特性。这里的目标是为估算和安排工作顺序提供一些结构。你不需要精确识别项目的每一个要素，但花时间思考与项目相关的外部因素（externality）和问题很有价值。这个角色要求你对自己系统的整体架构有良好的感知，并扎实理解如何设计复杂软件。它可能还要求你理解业务需求并将其转化为软件。

项目规划者（project planner）

项目规划者把工作拆解成大致的可交付成果（deliverable）。戴上这顶帽子时，你在学习寻找高效拆分工作的方法，让团队能快速工作。这里的挑战之一是尽可能多地并行完成生产性工作。这可能很难，因为你大概习惯了只考虑自己的工作，而不是一群人共同的工作。找到应用既定抽象（abstraction）来支持并行工作的位置是关键。例如，如果你有一个前端消费 API 提供的 JSON 对象，那么 API 完全完成之前前端开发就应该可以开始。相反，双方约定好 JSON 格式，然后用假对象（dummy object）按该格式编码。如果幸运的话，你以前见过这种情况，只需把之前的工作模式套用过来即可。在这个阶段，你会想从团队里的专家那里收集意见，与那些深入了解软件受影响部分的人交谈，让他们帮你处理这里的细节。你还会想在这个过程中开始确定优先级。哪些部分是关键的，哪些是可选的？你如何能在项目早期就处理关键事项？

软件开发者（software developer）与团队领导者（team leader）

软件开发者和团队领导者写代码、沟通挑战、委派工作。随着项目推进，意想不到的障碍会出现。有时技术负责人会忍不住上演个人英雄主义，自己硬闯过这些障碍，加班加点把所有事做完。在你作为技术负责人的位置上，你应该继续写代码，但不要写太多。即使你很想自己从帽子里变出兔子，你也必须先沟通这个障碍。你的产品经理应该尽早知道任何可能的挑战。必要时寻求你的工程经理的帮助。在一个健康的组织里，尽早提出问题是可耻或有害的。团队常常失败，是因为他们在一个产品经理本来愿意妥协的特性上把自己累垮了。当一个大型项目接近交付日期时，功能上总会有所妥协。开始寻找委派工作的机会，尤其是当系统中有你本来打算自己构建、却一直没时间处理的部分时。

正如你从这些描述中看到的，在担任技术负责人的过程中，你必须扮演软件开发者、系统架构师、业务分析师和团队领导者——知道什么时候该亲力亲为，什么时候该把工作委派给别人。幸运的是，你不必同时做所有这些事。一开始可能不舒服，但随着时间的推移和实践，你会找到平衡。

问问 CTO：我讨厌当技术负责人！

我以为当技术负责人会很棒，但现在我的经理期望我去追查这些项目状态细节，告诉她事情什么时候能完成，我真的很讨厌这样。为什么没有人告诉我技术负责人这个职位这么糟糕？

所有这些新责任都很难，我知道。我喜欢把这个特定的问题称为"凯旋之石（Stone of Triumph）"。（《辛普森一家》（Simpsons）的粉丝会懂我的梗。）凯旋之石是一个隐喻：你获得了认可，却发现这份认可伴随着沉重的代价。虽然这在工程领导生涯的许多阶段都是如此，但技术负责人阶段无疑是其中最沉重的石头之一。技术负责人很少能获得加薪或头衔提升，而且初次担任技术负责人的人往往对新的责任有多难毫无概念。正如我在职位定义中提到的那样，许多公司认为这更像是一个临时头衔，一组你在职业生涯中可能多次承担和卸下的责任。它可能是晋升到更高级别所必需的垫脚石，但通常不是一个带来即时、有形回报的里程碑。

为什么技术负责人角色如此沉重？技术负责人的责任范围比处于个人贡献者职位的高级工程师要大得多。技术负责人被叫来帮助架构一个项目，然后经历实际规划工作的步骤。技术负责人被期望确保团队完全理解项目需求、工作已规划好、团队高效且表现良好——所有这些都不一定有任何管理职责，通常也没有任何专门培训。而且，现实地说，大多数经理会期望他们的技术负责人继续写几乎和担任领导角色之前一样多的代码。这通常纯粹是责任和工作范围的增加。如果你是初次担任技术负责人，你的手已经非常满了。

所以，恭喜你，他们给了你凯旋之石！幸运的是，扛着这份负担最终会让你变得更强，给你在职业生涯中前进所需的技能。它不会永远像现在看起来这么重。

管理项目（Managing Projects）

我对自己第一次接触复杂项目管理的经历记忆犹新。我当时是第一次当技术负责人，我的团队正在承担一项非常复杂的任务。我们有一个现有系统，已经被我们扩展到了崩溃点。在几乎把书里所有的临时方案都试了一遍之后，我们决定是时候想办法让它在多台机器上运行了。那还是分布式系统（distributed system）的早期，大多数软件开发者对创建分布式系统的最佳实践真的了解不多。但我们有一支出色的聪明人团队，我们相信自己能搞定。

我们确实搞定了，虽然缓慢但稳步前进。我们花了很长时间思考设计，以及拆分计算的不同方式，让它们在多台机器上计算时仍然有意义。然后有一天，我的老板 Mike 把我叫进他的办公室，告诉我需要做一个项目计划。

那是我最糟糕的经历之一。

我必须把这组极其复杂的任务拆开，搞清楚哪些任务依赖其他任务。我得考虑各种各样的依赖关系。我们要如何在我们依赖的复杂测试框架中让它工作？我们要如何部署它？我们什么时候需要订购硬件来测试？集成测试（integration testing）要花多长时间？问题一个接一个地冒出来。我会走进 Mike 的办公室，坐在那张大木桌对面，和他一起过任务描述、日期和拆解。他会帮我做一部分，然后把需要更多工作的部分交给我。

这不是我喜欢做的事。它作为一系列令人沮丧和乏味的步骤烙在我的记忆里，我必须克服不确定性、克服犯错和遗漏的恐惧，才能做出一个能通过 Mike 评判的计划。然后我们还有一轮乏味的工作，把它整理成可以呈现给领导团队的形式，让他们接受。它几乎要了我的命。而它是我职业生涯中最重要的学习经历之一。

敏捷软件开发（agile software development）难道不能消除对项目管理的需求吗？不能。敏捷软件开发是一种思考工作的好方式，因为它迫使你专注于把任务拆成更小的块，规划这些小块的执行，并增量地交付价值，而不是一次性交付。这绝不意味着你不需要理解如何做项目管理。你总会遇到一些项目，出于各种原因无法在一个冲刺（sprint）甚至两个小冲刺内完成。你需要为你的管理团队估算项目时长，并给出一些细节说明你为什么认为事情要花那么长时间。有些项目，通常用基础设施（infrastructure）、平台（platform）或系统（system）这样的词来描述，需要架构或大量提前规划。面对这种包含许多未知数和相对紧迫截止日期的项目时，你会发现它不太适合标准的敏捷流程。

随着职业生涯的推进，你需要理解如何拆解复杂性超出个人能力范围的工作。为长期、团队型项目做项目管理，不是大多数人认为有趣的事。我觉得它乏味，有时还有点吓人。我想做的是构建并获得价值，而不是去想如何拆解一个实现细节仍然非常模糊的项目。我害怕自己会被追究责任，害怕过程中遗漏什么重要的东西导致项目失败。但另一种选择是项目失败得更慢，而不是更快。

项目管理不是每项工作都需要详细进行的，而且它在一些组织中被过度使用了。我甚至不喜欢雇项目经理（project manager），因为他们常常充当工程师的拐杖，让工程师不去学习思考自己未来的工作、不去问关于自己在做什么以及为什么做的真问题；而且他们的存在意味着你会有更多瀑布式（waterfall）项目，而不是敏捷流程。尽管如此，项目管理必须进行，而作为技术负责人，你应该在需要的时候去做，尤其是对深度技术项目。

归根结底，规划的价值不在于你完美地执行了计划、事先抓住了每个细节，或者你预测了未来；而在于它强制你自律，在埋头扎进项目、看看会发生什么之前，先对项目进行一定深度的思考。在你能合理做出预测和计划的地方，一定程度的预想（forethought）才是目标。计划本身无论最后有多准确，都不如花时间进行规划这个行为重要。

回到我第一次做项目管理的经历。项目是否完全按计划运行了？当然没有。有磕绊、有 bug、有意想不到的延迟，还有我们遗漏的东西。然而，令人惊讶的是，我们仍然基本按时交付了项目，而且没有为此熬过一连串不眠之夜。我们设法做出了必要的改动，把这个复杂系统变成一个可部署的分布式产物（distributed deployable artifact），同时还在主代码分支上与其他 40 名各自做着并发改动的开发人员并肩作战。所有这一切之所以可能，是因为我们有一支出色的团队，而且我们有一个计划。我们想清楚了成功是什么样子，也识别出了一些可能导致失败的风险。

自从与 Mike 那令人沮丧的一系列会议之后，我自己也主持了一系列项目规划会议，在那些会议里我坐在 Mike 的位置上，坐在我对面的是 Carlo、Alicia 或 Tim。他们每个人都感受到了计划缺乏细节的挫败感，每个人都回去做了那些不舒服的工作——思考那些不是代码、无法完美预测的事情。正因为这些工作，他们每个人都成功领导了复杂项目，而且现在他们更清楚拆解一个项目到底意味着什么，因此更有能力构建更大的系统、领导更大的团队。

花时间解释（Take the Time to Explain）

博士项目的最后步骤之一是答辩（defense）。这是你——博士候选人——经过多年研究后，在你所在领域的专家评审团面前展示你的工作成果，由他们评判你的成果是否值得授予博士学位。多年前，我有幸从美国最负盛名的应用数学项目之一获得数学博士学位。我评审团里的一位评委是数值分析领域的著名数学家。在我（成功）答辩之后，他对我说的一句话在我的整个职业生涯（不是数学领域！）中一直伴随着我。他说：“你的论文是我多年来读过的最清晰、最明白的论文之一。谢谢你！“我当然很欣慰，但也对他的话非常惊讶。我本以为，作为世界级数学家，他会"全都懂”，只是"看着"我的论文会怎样。事实上，正如他解释的那样，他确实可以做到，但那只是因为我不厌其烦地解释了这个问题的基本概念和我想法背后的动机。我从未忘记这一课。从那以后，在软件和大型组织工作了多年之后，我更加珍视那些评价。

我们认为管理层"懂"我们作为技术人员做的事。“读读代码就行了，兄弟！“我们每天赖以生存的软件对任何从事技术工作的人来说都应该是显而易见的，对吧？但事实并非如此。技术管理者雇佣最好的人（希望如此），这些人解决非常困难的问题。但他们并不"全懂”。我一直很惊讶，当我能够以一种不具威胁性、不居高临下的方式，向高级技术管理者解释一些非常基础的新想法（比如，NoSQL 到底是什么东西，我为什么要关心它？）时，他们是多么感激。

最近，工作单位一位高级业务经理私下问我，为什么我们要把传统部署的胖客户端（fat-client）架构迁移到托管平台（hosted platform）很重要。他承受着很大的内部压力要为这项工作提供资金，但他完全不知道这为什么必要。他可能也觉得公开问太尴尬了。我花了非常富有成效的两个小时来解释（没有用 PowerPoint！）。如今，我毫不犹豫地抓住机会向高级或初级成员解释基础知识和动机。这教育了他们，又不会让他们觉得自己渺小；他们学会信任我的判断和建议，我们也带来了改变。花时间解释非常重要。

Michael Marçal

管理一个项目（Managing a Project）

项目管理是把一个复杂的最终目标拆解成更小的部分、把这些部分按大致最有效的顺序排列、识别哪些部分可以并行做、哪些必须串行做，并试图挖出项目中可能导致项目变慢或完全失败的未知因素的行为。你在处理不确定性，试图找出未知因素，并认识到在这个过程中你会犯错，尽管尽了最大努力，还是会漏掉一些未知因素。以下是一些指导原则：

拆解工作。 拿出一张电子表格，或一张甘特图（Gantt chart），或任何对你有用的工具，开始把你的大交付物（比如，重写你的计费系统）拆解成任务。从最大的部分开始，然后把大块拆成更小的块，再把那些拆成更小的块。你其实不必全靠自己做。如果系统有你不完全理解的部分，向懂的人求助。先把大块拆得差不多，然后把注意力转向工作的排序。什么可以立即开始？把这些任务交给那些能把它们变成工单大小（ticket-sized）工作的人。
坚持推进细节和未知。 项目管理的诀窍是，不要在你感到有点卡住或厌倦的时候停下来。它确实又累又乏味，正如我之前说的。而且它可能不是你擅长的事情。所以要继续推进，越过那些烦躁、无聊和痛苦的节点。一个好的经理会坐下来陪你，告诉你哪里还不够好，问问题启发你，甚至和你一起解决一部分。我们也不享受这个过程，但这是教学的一部分。把未知数逐个攻破，直到你真的觉得再花时间在它们身上没有更多价值为止。
运行项目，边做边调整计划。 一个好的规划过程的价值在于，它帮你大致了解项目已经走了多远，以及距离完成还有多远。当事情延期（它们总是会延期）时，让所有人都了解状态。但现在，你不用再猜测还要走多远，你可以清楚地指出已经达到的里程碑（milestone），并概述预期的剩余工作。
利用规划过程中获得的洞察来管理需求变更。 通过按最初的需求集拆解项目，你学到了很多。如果需求在中途开始变化，把这些洞察应用到变更上。如果变更给项目增加了显著风险、需要大量新的规划，或者只是需要大量额外工作，那就清楚地说明这些变更的成本。如果你在朝着一个硬性截止日期努力，大致了解所需的工作量会帮你确定优先级、削减和简化工作，以在特性、质量和交付日期之间达成最佳折中。
接近完成时重新审视细节。 项目临近结束时，乏味又回来了。是时候真正关注收尾细节了。缺什么？什么测试？什么验证？做一次事前验尸（premortem）——一种演练，你过一遍这个大型项目上线时所有可能失败的事情。确定"足够好（good enough）“的线在哪里，把它宣传出去，并承诺坚守它。砍掉低于"足够好"线的工作，让团队专注于最重要的最终细节。制定上线计划（launch plan）；制定回滚计划（rollback plan）。最后，别忘了庆祝！

问问 CTO：我不确定我想当技术负责人

我的经理一直推着我考虑当技术负责人。她想让我负责一个大项目。我知道如果我接下这个角色，我写代码的时间会少很多，因为我得参加很多会议，处理一堆协调工作。我觉得我不想要这个，但我该怎么决定？

我对把人们推入管理角色有强烈的看法，那就是你不应该这样做。如果你还没准备好承担管理类责任，就不要承担。深入技术没什么不好，尤其是如果你觉得自己在成为专家之前还有很多要学的。

好的管理者会留意有才华、可以被赋予更大领导角色的人，但有时这会导致他们在人们准备好之前就把人从编码工作中推开。这种做法会对你的职业生涯产生非常负面的影响，因为在更高级别，被认为"技术不够"的人会发现很难被提升到责任更大的管理职位。留在专注的个人贡献者角色中，在那里学你需要学的东西，比一边学那些技能一边学管理技能容易得多。

在某个时刻，要在职业生涯中前进，你很可能需要做技术负责人的工作，即使你有兴趣留在个人贡献者（非管理）的职业路线上。这不意味着你现在就需要做。如果你觉得团队里还有很多纯粹的技术学习等着你，而你宁愿作为个人在这项目上工作、让别人来负责，那就不要接下技术负责人的角色。另一方面，如果你认为个人工作不会再给你技术上的挑战，也许是时候逼自己学一些新技能了——而技术负责人的技能是很好的尝试对象。

决策点：留在技术路线还是成为管理者

是成为管理者还是留在技术路线，这个决定很难。它极其依赖具体情况，我不可能告诉你该怎么做。然而，作为一个两条路线都梦想过、也亲身经历过的人，我可以告诉你我是如何想象这些角色的，以及我最终经历和观察到的现实。所以，先说明这些只是漫画式的概括，并非定论，让我告诉你想象与现实在我身上是如何分道扬镳的。

资深个人贡献者的想象生活

你的日子在混合中度过：深度思考，解决在智力上挑战你但仍然有趣和新颖的难题，以及与其他深度思考者合作。这是软件，所以你知道会有一些"剃牦牛毛”（yak shaving，指做琐碎杂事）的时候，但你能做一些最有趣的工作，而且你有很多权力选择自己做什么。你热爱写代码、修代码、让代码跑得更快、让计算机做新的事情，而你大部分时间都在做这些。

因为你的资历，管理者们会在开发开始前征求你对开发方式的建议，所以你知道所有正在发生的事情，但你不需要真正处理构建它的人们的细节。你被邀请参加恰好合适的那几场会议——那些做出重要决定的会议——但又不会多到打扰你的心流（flow）。更年轻的开发人员敬仰你，把你的每句话都当回事，接受你的反馈，但不会太占用你的深度思考时间。

你的上升轨迹从未减慢，总有新的重大问题等着你去解决，向组织展示你的价值。你工作努力，但很少被要求加班或周末工作，因为我们都知道，一周工作太多个小时是不可能做出高质量、有思想的工作的。当你确实工作到很晚，那是因为你太投入心流了，等不及要完成手头的特性或修复你刚发现的 bug。

你可以写书、做演讲、做开源（open source）工作——只要有一点运气和坚持，你能赢得一些行业范围内的名声。没人在乎你有点笨拙或害羞，也没人期望你大幅改进你的沟通风格，因为你说的话太重要了。你所在组织的每个人都认识你，理解你的工作有多有价值，并对你的意见毕恭毕敬。

简而言之，你拥有引人入胜的工作、名声和积累的专业知识的完美平衡，这让你无可替代、受人尊敬、薪酬丰厚且有影响力。

资深个人贡献者的现实生活

当你找到合适的项目、合适的项目生命周期时，你的生活很棒。你受到挑战，能学到新东西。你对日常事务有很强的掌控力，会议肯定比管理层的同行少，但你的日子并不总是花在幸福的心流状态中。每个项目都有一段时期，你有了想法，然后向人们推销，试图说服他们这是正确的方法。或者你已经实现了系统，但现在需要让其他团队开始使用它，所以你连着几天和他们坐在一起，向他们展示来龙去脉，解释它为什么有用，试图说服他们去游说自己的经理腾出时间来采用它。

你的上升轨迹并不像你希望的那样快和容易。事实上，它相当慢。那些证明你是无价架构师的大项目很难找到。团队不需要新的编程语言、新的数据库或新的 Web 框架。你的经理不擅长把展示你才华的肥差分给你——她期望你告诉她这些机会在哪里。发现好项目似乎全靠运气。选错了项目，你会在某个东西上花几个月甚至几年，尽管你尽了最大努力，它还是可能被取消。你有点嫉妒你在管理层的朋友，他们似乎晋升得更快，同时团队还在不断壮大。

其他开发人员好坏参半。你是个好人，所以有些人钦佩你、听你的意见，但另一些人似乎嫉妒你的影响力。新开发人员要么想要你太多时间，要么因为某种原因似乎怕你。同行之间肯定存在一些竞争，争夺谁去领导大型、有趣的项目。

你的经理有点烦人。她不太支持你开源一个系统的愿望，因为你觉得它提供了行业需要的日志记录新思路，她还暗示，如果你想做演讲或写书，也许需要花一些个人时间在这些事情上。她在技术问题上征求你的反馈，但有时忘了告诉你新的举措，等你想插两句嘴时已经太晚了。你怀疑自己错过了关键信息，因为你不在那些对的会议上，但每次她邀请你去参加那些会议时，你又想起它们有多无聊、多低效，以及你失去了多少宝贵的专注时间。而且她对你想要摆脱乏味工作的愿望没什么耐心，比如回邮件、面试、及时回应代码审查。

不过，你大部分时间还是在构建东西。你能把时间花在技术问题、系统设计和工程问题上，不必处理太多人际事务或坐在无聊的会议里。你常常可以选择自己的项目，如果想要新的东西，可以轻松地在团队之间流动。而且你刚刚发现你比你的经理挣得多！所以，生活并非全是坏事。

管理者的想象生活

你有一个团队，你有控制权，你能做决定，你终于可以让别人按你的方式做事了。你的团队尊重你，乐于在所有事情上服从你的权威。你觉得他们应该写更多测试？你告诉他们：“写更多测试”，他们就照做了！你想确保每个人不分性别、种族等都得到公平对待？你确保这一点实现，并解雇任何越线、为团队其他人创造不健康环境的人。

因为你关心人，他们知道即使他们不同意你，你也总是在为他们尽力。他们会给你怀疑的好处，当你搞砸了的时候，他们会带着坦率的反馈来参加你的一对一，并渴望收到你的反馈。处理人际关系是有压力的，当然，但他们知道你关心他们，所以这也非常有回报。既然你处在这个权威的位置上，你能很快看到你的辅导产生的影响。

当你看到另一位管理者做了似乎错误的事情，你可以自由地去给他建议，就像你会和需要系统设计帮助的工程师交谈一样。其他管理者总是有兴趣听你的想法，他们能看到你让团队高效工作得多好，你多么清晰地关心组织的健康，以及你让每个人都变得更好的兴趣多么真诚。

你的经理给你大量的辅导，但很少插手告诉你该做什么。当你觉得自己准备好带更大的团队的那一刻，你的经理就愿意给你更多人、扩展你的组织。她交给你的目标很清晰，很少变动。尽管你有很多责任，你仍有一些时间写博客文章和做演讲，而且这是被鼓励的，因为它会帮助你的团队招人，提升你在科技行业的地位。

简而言之，你能做决定，你创造文化，你的效率对周围所有人都是显而易见的，这让你的晋升之路很快，让你的职业生涯激动人心且回报丰厚。

管理者的现实生活

你有一个团队。你有一些控制权，但你很快发现，让人们做某件事比告诉他们去做更难。你似乎放弃了对日常事务的所有控制。大部分时间你整天都在开会。你知道这会到来，但只有亲身经历你才真正理解这意味着什么。当你只有一个小团队时，你能平衡事情，还能写代码，但随着团队壮大，你已经与代码脱节了。它啃噬着你，觉得这是你应该做的事，但没有时间。每次你抢出几个小时写代码，你意识到把它检入（check in）并让团队维护它是不负责任的，所以充其量你在这里抓个脚本，在那里调试个问题。自己专注构建一个大东西，已经是一个遥远的记忆。

你能做决定——嗯，一些决定。现实地说，你也许能缩小将要被决定的事情的范围。你能让团队专注于某些事情，比如写更好的测试，但他们还有产品路线图（roadmap）要实现，他们对哪些技术任务应该优先有自己的想法。所以，与其说你自己做决定，不如说你是在帮助团队做决定。你的经理给你目标，但有时又彻底改变这些目标，向团队解释这些变化是你的责任。

你确实为你的团队设定了文化标准，这有好有坏。当他们继承你最好的方面时是好的，当你意识到你的团队也在映照你的缺点时是坏的。

你的团队不会自然而然地同意你、尊重你，甚至喜欢你。你意识到权威需要的不仅仅是头衔。你发现自己在艰难时期手忙脚乱地激励他们——项目进展不顺利的时候，或者你必须告诉某些人他们还不能晋升、他们不会加薪、今年没有奖金的时候。有些人心情不好时都懒得告诉你；他们只是受够了，在你注意到有任何问题之前就辞职了。当公司发展得好、你有大把钱可发、有大量激动人心的项目时，生活很棒；但当事情有压力时，你看到自己让员工开心的力量有多小。更糟糕的是，你甚至不能随便解雇人，还要走一趟疯狂的人力资源（HR）流程！尽管如此，你仍然能看到你的工作对其中一些人很重要，因为你的辅导，他们更快乐、更成功。这些小小的胜利支撑你度过艰难时期。

其他管理者对你的反馈不感兴趣。事实上，当你被认为侵入他们的地盘时，他们会觉得你多管闲事，产生竞争心。你自己的经理不认为你准备好带更大的团队，又无法真正解释为什么；他的辅导技能有待提高。也许他只是担心你会盖过他的风头？不过他肯定不想让你把所有时间都花在做演讲上——你离开办公室太频繁他会恼火，不管团队可能从中获得什么价值。弄清楚如何在不让同级或老板难堪的情况下领导的办公室政治，比你预期的更棘手。但如果你能拿到那个更大的团队，你知道你会得到晋升，所以至少你的道路是清晰的。当你发现为你工作的 Staff 工程师（staff engineer）挣得比你多时，你几乎崩溃，所以你最好赶紧想办法拿到那个更大的团队。否则，所有这些压力和破事有什么意义？

我最后的建议是记住，如果你想的话，你可以换轨道。人们常常在某个时刻尝试管理，发现自己不喜欢，然后回到技术路线。这个选择不必是永久的，但要睁大眼睛走进去。每个角色都有利弊，感受你最享受什么取决于你自己。

好经理，坏经理：流程沙皇（Process Czar）

流程沙皇相信存在一种唯一正确的流程，只要正确地实施并按设计遵循，就能解决团队所有最大的问题。流程沙皇可能痴迷于敏捷、看板（Kanban）、Scrum、精益（lean），甚至瀑布方法。他们可能对值班应该如何运作、代码审查（code review）必须如何进行、或者发布流程该如何运作有非常精确的想法。他们往往非常有条理，对细节很自在，而且擅长了解规则并精确地遵循它们。

流程沙皇常见于 QA、帮助台（helpdesk）或产品管理团队中。在咨询公司和那些对特定工作进展的衡量得到高度回报的地方也很常见。他们可能以运营为导向，尽管以我的经验，在你典型的系统运维团队里这种人相对较少。他们可以成为项目管理团队中极具价值的成员，因为他们往往确保没有任务被遗忘，一切都按应有的方式收尾。

当流程沙皇没有意识到大多数人不像他们那样擅长遵循流程时，他们就会挣扎。他们倾向于把所有问题都归咎于没有遵循最佳流程，而不是承认灵活性的必要性和意外变化的不可避免性。他们常常专注于容易衡量的东西，比如在办公室的时长，而错过了那些在专注于易衡量事物时无法捕捉的细微差别。

相信"为工作选择正确工具"的工程师有时在成为技术负责人后会变成流程沙皇，寻找正确的工具来解决规划、专注、时间管理和优先级排序的所有问题。他们试图在寻找完美流程时停止所有工作，或者不断向团队推销新工具和新流程，作为人类互动中那些更混乱问题的解决方案。

流程沙皇的反面不是完全放弃流程的经理，而是理解流程必须满足团队和工作的需求的人。讽刺的是，虽然"敏捷"常常被以僵化的方式实施，但敏捷宣言（Agile Manifesto）的原则是健康流程领导的绝佳总结：

个体和互动高于流程和工具
可工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

作为新晋技术负责人，要小心不要依赖流程来解决团队中因沟通或领导力缺口而产生的问题。有时改变流程是有帮助的，但它很少是银弹，而且没有两个伟大的团队在流程、工具或工作风格上完全相同。我的另一条建议是寻找能自我调节的流程。如果你发现自己扮演着任务监工（taskmaster）的角色——批评那些违反规则或不遵循流程的人——看看流程本身是否能被改变得更容易遵循。扮演规则警察是在浪费你的时间，自动化常常能让规则更显而易见。

作为流程沙皇的经理，帮助那个人对模糊性更自在。与许多经理的陷阱一样，对流程的痴迷可能与对失败的恐惧和想要控制事物以防意外的愿望有关。如果你诚实并明确表示失败和不完美是安全的，这通常就足以让你的流程沙皇放松一点，让一些模糊性进来。非常重要的一点是，防止流程沙皇把所有时间都花在寻找完美工具或流程上，尤其重要的是确保他们不会因为团队没有遵循流程而惩罚他们。

如何成为优秀的技术负责人

优秀的技术负责人有许多特质，但以下是最重要的。

理解架构

如果你进入技术负责人的角色，却觉得自己不完全理解你所支持的架构，那就花时间去理解它。学习它。感受它。把它可视化。理解它的连接、数据在哪里、如何在系统之间流动。理解它如何反映它所支持的产品，这些产品的核心逻辑在哪里。当你不懂你要改变的架构时，几乎不可能领导好项目。

做团队合作者（team player）

如果你把所有有趣的工作都留给自己做，停下来。看看技术需求中棘手、无聊或烦人的领域，看看你是否能疏通这些领域。处理代码库中不那么令人兴奋的部分能让你学到很多关于流程哪里出了问题的东西。对于无聊或令人沮丧的项目，如果有一个有经验的人花时间去看，往往能发现并修复一些显而易见的问题。如果你只做最无聊的工作，那也停下。你是一个在开发上很有天赋的高级工程师，承担一些更困难的任务是合理的。你想鼓励团队里的其他人学习整个系统，你想给他们伸展自己的机会，但你在选择做什么时也不必总是自我牺牲。偶尔给自己一个有趣的任务，只要你知道你有时间把它做好。

主导技术决策

你会参与团队大多数重大技术决策。然而，参与不等于所有决策都由你一个人做。如果你开始不征求团队意见就做所有技术决策，他们会怨恨你，事情出错时也会怪你。另一方面，如果你不做任何技术决策，把所有事都留给团队，本可以快速做出的决定可能会拖下去，没有结果。

确定哪些决定必须由你来做，哪些应该委托给更有专长的其他人，哪些需要整个团队来解决。在所有这些情况下，都要明确正在讨论的问题是什么，并沟通结果。

沟通

你的生产力现在不如整个团队的生产力重要。这通常意味着你要付出沟通开销（communication overhead）的代价。与其让每个团队成员都坐在会议室里，不如由你代表团队，传达他们的需求，并把会议信息带回团队。如果说有一种通用才能能把成功的领导者与其他人区分开，那就是沟通技巧。成功的领导者写得好，读得仔细，能站到一群人面前讲话。他们在会议上专注，不断测试自己和团队知识的边界。现在是练习写作和演讲技巧的好时机。写设计文档，并从更好的写作者那里获得反馈。为你的技术博客或个人博客写博客文章。在团队会议上发言，在 meetup 上发言，练习站在观众面前。

在所有这些沟通中，别忘了倾听。给别人说话的机会，听他们说。练习向人们复述他们的话，确保你理解了。学会如何听懂别人说的话，并用你自己的话重新表述。如果你不擅长做笔记，你可能需要成为一个。无论你选择深入技术，还是成为管理者——如果你不能沟通、不能倾听别人说的话，你从这一刻起的职业成长都会受损。

评估你自己的经验

你的组织有技术负责人吗？这个角色有书面的职位描述吗？如果有，它怎么说？如果没有，你会如何在你的组织中定义这个角色？技术负责人会如何定义这个角色？
如果你正在考虑成为技术负责人，你准备好逼自己了吗？你愿意把一些时间花在代码之外吗？你觉得你对你的代码库足够专业，能成功领导别人在其中工作吗？
你问过你的经理他或她对技术负责人有什么期望吗？
你共事过的最好的技术负责人是谁？那个人做了什么让他/她如此出色？
你共事过令人沮丧的技术负责人吗？他或她做了什么让你沮丧？