中文书名：职业经理人成长路径
作者：Camille Fournier

第三章 技术领袖

多年前我成为了一名技术领袖。此前我被提升为高级工程师，和其他几个高级工程师一起在一个小团队里工作。被提升为技术领袖有点令人惊讶，因为无论从职级还是经验来看，我都不是团队中最资深的人。如今回想起来，我那时也已具备一些优势。一方面，我不仅是一个好工程师，也是不错的沟通者。我可以写出清晰的文档，我可以在不崩溃的情况下做工作汇报，我可以和不同团队、不同角色的人交谈，解释发生了什么。我还擅长区分轻重缓急。我渴望推进工作，对之后的工作作出判断。我愿意收拾残局，做需要做的事情来取得进展。这种务实的紧迫感最终成为了决定因素。毕竟，技术领袖的角色是带领团队，即使它不是团队管理者。

我也曾见过技术领袖的挣扎。一个特别难忘的困境是，一位技术出众的工程师，他能写优秀的代码，却讨厌与人交谈，时常被技术细节所困。我眼睁睁地看着他一个接一个地陷入泥潭，与此同时，产品经理利用他的缺席迫使团队的其他成员向设计拙劣且过于激进的产品功能提交代码。

这个项目一团糟，技术领袖做了什么？他一直在追逐下一次重构，因为他确信问题完全在于代码的结构。你可能知道这个故事，因为它无处不在。即使是有经验的管理人员也常常会产生这样一种误解，那就是技术领袖的角色应该自动地交给最有经验的工程师，因为这种工程师可以处理最复杂的功能，编写最好的代码。技术领袖并不适合那些想要自由深入探究自己代码细节的人。一 个这样的技术领袖并没有做好她的工作。但是技术领袖的工作是什么呢？我们应该对这个角色有什么期待呢？

与软件工程中的许多职位名称一样，“技术领袖”一词，缺乏一个广泛认同的定义。我能做出的最好的解释，就是借鉴我自己的经验和别人的经验。作为技术领袖，我的工作是继续编写代码，但同时还要承担代表团队进行管理、审查我们的功能交付计划以及处理项目管理过程的许多细节的责任。我可以成为技术领袖，尽管我不是最资深的，因为我愿意并且能够承担这个角色的责任，而我的团队的其他成员更感兴趣的是保持纯粹专注于他们编写的软件。

当我在 Rent the Runway的团队创造出我们的工程职业阶梯时，我们有意识地选择将技术领袖的角色定义为工程师可以在职业阶梯的多个层级所具备的一组特征，而不是一个特定的职级。我们采取这一方针，是因为我们想让大家认识到，随着团队的变化和发展，技术领袖可能由许多不同阶段的工程师承担，可能从一个工程师传递到另一个工程师，而不需要改变其职能级别。技术领袖在各个公司之间，甚至在同一公司内部的团队之间，可能不会扮演完全相同的角色，但我们从这个职位名称中知道，它既是一个技术职位，也是一个领导角色，而且往往是一种临时的责任，而不是一个永久的头衔。那么，什么是技术领袖？下面是我们在 Rent the Runway创建的描述：

技术领袖的角色不是职业阶梯上的一个点，而是一系列的职责，一旦达到高级水平，任何工程师都可能承担。这个角色可能包括也可能不包括人员管理，但是如果是的话，技术负责人应该按照 RTR技术的高级管理标准来管理这些团队成员。

这些标准包括：

日常一对一汇报（每周一次）
定期向下属反馈其职业发展情况，目标进展情况，需要改进的地方，以及需要表扬的地方
使用报告方式帮助下属确定需要学习的领域，通过负责项目、外部学习或额外的指导，推动他们在这些领域成长。
即使技术领袖不直接管理，他们仍然需要为团队的其他成员提供指导和指引。

技术领袖正在学习如何成为一名强大的技术经理，因此，他们通过有效地授权工作而不是事无巨细来提升自己。他们关注整个团队的生产力，努力提高团队产品的影响力。他们被授权为团队做出独立的决定，并学习如何处理困难的管理和领导情况。他们也在学习如何有效地与产品经理、分析师和其他业务领域合作。

工程师不一定要以技术为先导才能取得进步，但这是工程师从高级工程师到资深工程师成长的最常见方式，也是从资深工程师成长为工程主管的最常见方式。实际情况是，资深工程师在没有扮演过技术领袖这个角色前，晋升是很难的。即便个人贡献巨大，但由于此类高级管理岗位责任重大，不得不如此。

也许关于技术领袖，一个更简单的描述是PatrickKua在他的书《与技术领袖交谈》中的描述：

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

技术领袖应当作为强有力的项目领导者，在更大的范围使用他们的专业知识，让整个团队变得更好。他们可以做出独立的决策，并且他们在与其他非工程伙伴的协调中扮演着重要角色。你可能会注意到，这里没有提及任何关于具体技术工作的内容。这是一个高级工程师的角色，但是将技术领袖的概念与团队中最优秀或最有经验的工程师联系起来是错误的。你不能在没有与他人建立密切关系的情况下发挥领导作用，而人际交往能力就是我们所要求的新技术领袖需要拓展的技能，远远超过纯粹的技术专长。然而，技术领袖将致力于一个主要的新技术技能：项目管理。分解项目与设计系统有很多相似之处，学习这种技能对那些不想参与管理的工程师来说也是有价值的。

如果你发现自己身处技术领袖地位，恭喜你！有人认为你具备成为团队的关键人物的条件。现在是学习一些新技能的时候了！

如何当好技术领袖
成为一个技术领袖是一项不通过职权影响他人的修炼。作为技术领袖，我带领着一个团队，但我们都向同一个经理汇报。因此，我不仅要影响我的同事，而且还要影响我的上司，以确保我们优先做正确的工作。最近的一个角色特别具有挑战，因为在成为技术领袖后，我处理的第一个项目就是停止所有的特性开发，而专注于技术债务。
我很清楚，“技术债务的皮球”已经被踢来踢去太久了，部署新的代码很困难，运行现有的服务很昂贵，而值班待命又很糟糕。我相信我们需要放慢速度才能追赶未来。然而，这并不容易让其他开发人员买账，他们想要的是编写有趣的新特性，我的经理也很难理解，来自客户的源源不断地请求使他应接不暇。我通过聚焦未来这些问题可能对团队成员的不同影响来说服大家。对于一些团队成员来说，这意味着更可靠的服务，对于另一些人来说，这事关迭代速度，对其他人，这将减少随时待命的负担，以便他们可以睡一夜。在与我的经理交谈时，我强调了减少操作开销，这意味着我们团队将可以完成更多的功能。
作为一名技术领袖，我需要改变关注焦点。现在我的工作少了许多关于自己的事，少了应对技术上最具挑战性的想法或最有趣的项目；相反，我更多地关注在我的团队上。我如何赋能他们？我如何消除阻碍他们前进的障碍？重写一些新的激动人心的功能，让我充分表达我的技术能力，可能会更有趣，但当时的团队需要的是解决技术债务，并专注于技术运营。最后，这一举措取得了令人难以置信的成功。该团队将关键分页警报的数量减少了50%，并且在接下来的季度中，我们几乎将部署数量增加了一倍。 ----凯蒂·麦卡弗里。

所有技术高手都知道这个诡计

作为技术领袖，显然你对软件有所了解，你的经理认为你已经足够成熟，可以承担更多的项目责任。然而，如果你不能找出成为一个好的技术领导者的最大诀窍，那么拥有技术优势和成熟度就没什么大不了的。秘密就是：从代码中抽身出来，想办法平衡你的技术承诺和整个团队需要的工作。你必须停止完全依赖你的旧技能，开始学习一些新技能，理解平衡的艺术。

从现在起，无论你在职业生涯中走到哪里，平衡可能是你的核心挑战之一。如果你想要对你的工作有自主权，如果你想要自由选择你什么时候工作，你必须掌握你的时间和如何使用它。更糟糕的是，你经常需要在做你知道怎么做和喜欢做的事情（比如写代码）和不知道怎么做之间取得平衡。人类喜欢他们已经掌握的活动是很自然的，所以当你花更少的时间在你现有的天赋上，去学习新的东西时，你会觉得很不舒服。

很难平衡项目管理工作与实际的技术交付。有时你在创作内容，有时需要管理团队。经过反复试验，你需要学会如何管理你的时间，将工作分配到合适长度的工作时间段。糟糕的日程安排，就是让自己被随机拉入会议。如果你每小时都被会议打断，你就很难进入良好的编写代码的节奏。

即使有精心安排的时间表，你也不会经常有一连几天时间花在编码问题上的机会。在此之前你已经学到了一些技巧来帮助你分解你自己的工作，这样你就不需要花很多天的时间集中精力来完成技术任务。你也应该知道，让团队进入一个允许他们长时间专注于开发的日程安排非常重要，因为他们需要花几天的时间来关注编码问题。你的领导力的一部分就是帮助其他利益相关者，比如你的老板和产品经理，尊重团队的注意力，制定不会让个人贡献者应接不暇的会议日程。

技术领袖入门课

假设你正在和一位产品经理以及其他四位工程师组成的团队进行为期数周的合作，发起一项新计划。技术领袖在这个场景中有许多职责，这取决于您在项目生命周期中的位置。当然，你需要编写一些代码并做出一些技术决策。但这只是你将扮演的角色之一，甚至可能不是最重要的角色。

技术领袖的主要角色

作为一名技术主管，你的首要任务就是要对工作有一个全面的认识，这样才能保证项目的顺利进行。如何从组织和计划自己的代码到组织和领导整个项目？

系统架构师和业务分析师

在系统架构师和业务分析师的角色中，您确定了需要更改的关键系统和为了交付即将到来的项目而需要构建的关键特性。这里的目标是为估计和排序工作提供一些框架。你不需要完美地识别一个项目的每一个要素，但是花时间思考与项目相关的外部因素和问题是很有价值的。这个角色要求您对系统的总体架构有很好的了解，并对如何设计复杂的软件有扎实的理解。它还可能要求您能够理解业务需求并将其转换为软件。

项目规划人员

项目规划者将工作分解成粗略的可交付成果。这个角色可以使你学到如何有效地分解工作，以便团队能够快速工作。这里的部分挑战是让尽可能多的工作并行完成。可能很困难，因为你可能习惯于只考虑自己的工作，而不是一群人的工作。找到可以应用提前商定的抽象的位置，来开展并行工作是关键。例如，如果您有一个从API获取JSON对象的前端，那么不需要完全完成 API，前端开发就可以开始。取而代之的做法是，应该提前商定JSON格式，并开始使用虚拟对象对该格式进行编码。如果你幸运的话，你以前也见过这种情况，而且只是简单地模仿你以前的工作。在这个阶段，您将希望从您的团队中的专家那里收集输入，并与对软件的受影响部分有深入了解的人进行交谈，以便他们能够帮助了解这里的细节。作为这一进程的一部分，你还需要开始确定优先事项。哪些部分是关键的，哪些是可选的？如何在项目的早期处理关键项目？

软件开发人员和团队负责人

软件开发人员和团队领导编写代码，沟通挑战，并授权。随着项目的进展，会出现意想不到的障碍。有时，科技公司的领导们会鼓足干劲，自己克服这些障碍，加班加点地完成任务。在技术领袖的位置应该继续写代码，但不要写太多。即使你想自己从帽子里拉出一只兔子，你也必须先把遇到的障碍表述出来。应该让产品经理尽早知道，团队可能遇到的任何挑战。如有需要，寻求工程经理的帮助。在一个健康的组织中，及早提出问题没有什么害处。项目经常败于过度设计。而很多情况下，产品经理愿意妥协。随着大型项目交付日期的临近，功能会进行妥协。开始寻找委派工作的机会，特别是当你希望自己完成系统的一部分，却没有时间去处理时。

正如您从这些描述中看到的，在成为技术领袖的过程中，您必须作为软件开发人员、系统架构师、业务分析人员和团队领导者，知道何时单枪匹马地完成某项工作，何时将工作委托给他人。幸运的是，你不必一次完成所有这些任务。刚开始可能会不舒服，但是你会在时间和练习中找到平衡。

项目管理

我清楚地记得我第一次参与复杂项目管理的经历。是第一次担任技术主管，我的团队承担着一项非常复杂的任务。我们有一个现有的系统，我们已经扩展到极限。对它进行了几乎所有的改进之后，我们决定是时候弄清楚如何在几台机器上运行它了。是分布式系统的早期时代，大多数软件开发人员并不真正了解创建分布式系统的最佳实践。但我们有一支由聪明人组成的伟大团队，我们有信心能够解决这个问题。

我们确实找到了答案，虽然缓慢，但确实可靠。我们花了很长时间来考虑设计和不同的方法来分解我们的计算，所以当跨多台机器计算时，它们是有意义的。然后，有一天，我的老板迈克把我带到他的办公室，告诉我需要制定一个项目计划。这是最糟糕的经历之一。

我必须接受这一组令人难以置信的复杂任务，并试图找出哪些任务依赖于其他任务。期间，我不得不考虑各种各样的依赖。我们如何让它在我们依赖的复杂测试框架中工作？我们如何部署它？什么时候需要订购硬件来测试？集成测试需要多长时间？问题接踵而至。会走进迈克的办公室，坐在他对面的那张大木桌前，我们会仔细检查任务描述、日期和故障。他会帮我做一些事情，然后把需要更多工作的部分交给我。

这不是我喜欢做的事。这是我记忆中一系列令人沮丧和乏味的步骤，我不得不克服不确定性，克服犯错误的恐惧，克服缺失的恐惧，以制定一个能通过迈克审核的计划。然后，我们又进行了一项烦琐的工作，将其转化为一种可以向领导团队展示的格式，以便他们接受。这几乎要了我的命。这是我职业生涯中最重要的学习经历之一。

敏捷软件开发不能摆脱项目管理吗？敏捷软件开发是思考工作的一种很好的方式，因为它迫使你专注于将任务分解成更小的块，计划那些更小的块，并一次性递增地交付价值。这并不意味着你不需要了解如何进行项目管理。无论什么原因，你的项目都不能在一个或者两个小迭代周期中完成。你需要为你的管理团队估算项目的长度，并详细说明为什么你认为事情会花那么长时间。有些项目，通常用基础设施、平台或系统之类的词来描述，需要架构或重要的高级规划。当面对这类项目时，你会发现它并不适合标准的敏捷过程。

当你在职业生涯中前进时，你需要了解如何分解那些超出你个人能力范围的复杂工作。对一个长期运行的、基于团队的项目进行项目管理并不是大多数人认为的有趣之处。我觉得这很乏味，有时有点吓人。我想建立并获得价值，而不是试图思考如何分解一个仍然具有非常模糊的实现细节的项目。我担心我会被追究责任，我可能会在过程中错过一些重要的事情，从而导致项目失败。但另一种选择是项目失败的速度较慢，而不是更快。

项目管理不是每一项工作都需要详细进行的，而且在一些组织中被过度使用。我甚至不喜欢雇佣项目经理，因为他们经常充当工程师们的拐杖，而不是学习思考他们未来的工作，询问他们正在做什么以及为什么这样做的真正问题，他们的存在意味着你有更多瀑布式的项目，而不是敏捷的流程。尽管如此，项目管理还是必不可少的，作为技术领导者，你应该在需要的时候进行，特别是对于深度技术项目。

归根结底，计划的价值不在于你能完美地执行计划，不在于你能事先抓住每一个细节，也不在于你能预测未来；而在于你能加强自律，在深入研究项目之前先思考一下。目标是在你可以合理预测和计划的地方进行一定程度的深谋远虑。计划本身，无论结果如何精确，都不如花时间在计划上重要。

回溯我在第一个项目的管理经验。项目是否按照计划完美运行？当然不是。有磕磕碰碰，有 bug，有意外的延迟，还有我们错过的事情。然而，令人惊讶的是，我们仍然按时完成了项目，没有一连串的不眠之夜。我们设法进行了必要的更改，将这个复杂的系统移动到一个分布式的可部署工件中，同时还与其他40个开发人员一起进行了自己的并发更改。这一切都是可能的，因为我们有一个伟大的团队，我们有一个计划。我们已经仔细考虑了成功是什么样子，我们已经确定了一些可能导致失败的风险。

自从和 Mike那一系列令人沮丧的会议之后，我已经有了一系列的项目计划会议，我坐在 Mike的位置上，对面是 Carlo、 Alicia或 Tim。 他们每个人都感觉到计划缺乏细节所带来的挫败感，于是他们各自走开，做了一件不舒服的工作，思考那些不属于代码的、不能完美预测的事情。由于这项工作，他们每个人都领导了复杂的项目取得了成功，现在他们更有能力构建更大的系统，领导更大的团队，因为他们已经了解了项目的真正意义。

管理一个项目

项目管理是将一个复杂的最终目标分解成更小的部分，将这些部分按照它们应该完成的最有效的顺序排列，确定哪些部分可以并行完成，哪些部分必须按顺序完成，并试图梳理出可能导致项目速度减慢或完全失败的未知因素。你正在解决不确定性，试图找到未知，并认识到你会在这个过程中犯错误，错过一些未知，尽管你尽了最大的努力。以下是一些指导原则：

1、把工作分解。拿出一张电子表格，或者一张甘特图，或者任何适合你的东西，开始把你的大的可交付成果（比如，重写你的账单系统）分解成任务。从最大的部分开始，然后把大的部分分成小的部分，然后再分成更小的部分。你并不一定要亲自去做。如果系统中有你不了解的部分，向了解的人寻求帮助。把大的东西分解一些，然后把注意力转移到工作的优先级上。哪些任务可以立即开始？ 把这些任务交给那些能把它们变成票面大小的工作的人。

2、推动细节和未知。项目管理的诀窍是当你觉得有点受阻或厌倦时，不要停止。如我前面所说的那样，这是令人厌倦和乏味的。可能不知道如何做好这件事。以，继续努力，克服那些烦躁、无聊和痛苦。 一 个好的经理会和你坐在一起，告诉你哪里做得不够好，问问题来激励你，甚至和你一起完成其中的一些工作。我们也不喜欢它，但它是教学活动的一部分。不断审视未知，直到你感到花时间在这些事情上有没有更多的价值为止。

3、开始并及时调整项目计划。 一 个好的计划过程的价值在于它能帮助你知道项目已经完成了多少，离完成还有多远。随着事情的发展，让每个人都知道自己的进度。 但是现在，与其猜测您需要走多远，您可以清楚地指出已经达到的里程碑，并概述预期的剩余工作。

4、利用规划过程中获得的洞察力来管理需求变更。通过分解给定原始需求集的项目，您学到了很多。如果需求在中途开始变更，那么将这些洞察力应用到变更中。如果变更给项目增加了很大的风险，需要一系列新的计划，或者仅仅需要很多额外的工作，那么要清楚这些变更的成本。如果你正朝着一个艰难的最后期限努力，大致了解所需的努力将帮助你区分优先级、减少和简化工作，以获得功能、质量和交付日期的最佳折中。

5、当你接近完成时，重新回顾细节。项目快结束时，乏味又回来了。此时，是真正注意细节的时候了。缺少哪些功能？ 测试哪些功能？ 验证哪些功能？ 进行一次预分析，这是一次演习，你要经历所有可能在这个大项目启动时失败的事情。决定“足够好”的底线在哪里，让它社会化，并致力于它。把“足够好”的工作削减掉，让团队专注于最重要的最后细节。制定启动和回滚计划。最后，别忘了庆祝一下！

决策：留在技术轨道上或成为经理

是做经理还是留在技术轨道上是个艰难的决定。这通常与环境息息相关，我不可能告诉你该怎么做。然而，作为一个梦想和生活过这两条轨道的人，我可以告诉你我的想象和最终经历观察的对比。所以，在提醒你这些只是漫画式的描述并非一成不变的前提下，让我告诉你，我经历的想象和现实的差异。

想象中的资深个人贡献者

你的每一天都在深度思考中度过，解决那些在智力上挑战你但仍然有趣和新颖的难题，并与其他深度思想者合作。这是软件，所以你知道会有一些麻烦，但你可以做一些最有趣的工作，你有很大的权力选择你的工作。你喜欢写代码，修复代码，让代码运行得更快，让计算机做新的事情，你可以花大部分时间来做这些。

由于你的资历，经理会在开发开始之前征求你关于如何进行开发的建议，这样你就知道正在进行的一切，但你并不需要真正处理构建开发的人员的细节。你被邀请参加适当的会议，在会议上做出重要决定，但不要太多，以免打断你的交流。更多的初级开发人员仰望你，坚持你的每一句话，接受你的反馈，但不要把太多的时间强加在你的深度思考上。

你的上升轨迹永远不会减慢，总有新的大问题可以解决，以向组织展示你的价值。你工作很努力，但很少被要求熬夜或周末工作，因为我们都知道，每周要花太多时间做高质量、周到的工作是不可能的。当你工作到很晚的时候，这是因为你正沉浸在流程中，以至于你迫不及待地想要完成手头的功能或者修复你刚刚发现的bug。

你可以写书、演讲、创作开源作品，只要运气好，坚持下去，你就能赢得一点业界的声誉。没人在乎你有点尴尬或害羞，也没人期望你能改变你的沟通方式，因为你说的话太重要了。组织中的每个人都知道你是谁，知道你的工作有多有价值，并尊重你的意见。

简言之，你在工作、名声和积累的专业知识之间取得了完美的平衡，这使你变得无价、受人尊敬、高薪和有影响力。

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

当你获得了期望的项目，并合理控制了项目的生命周期，你的生活就是美好的。面临挑战，你可以学到新的东西。你获得了更多自己日程安排的控制权，比你的管理层同行更少的会议，但日子并不总是在快乐的流动状态中度过。对于每一个项目都有一段时间，你有了这个想法，然后向人们推销，试图说服他们这是正确的方法。或者你已经实现了这个系统，但现在你需要让其他团队开始使用它，所以你要和他们坐在一起几天，向他们展示它的来龙去脉，解释它为什么有用，并试图说服他们游说他们的经理，争取时间采纳它。

你的上升轨迹并不像你希望的那么快和容易。事实上，这相当缓慢。很难找到那些证明你是一位无价建筑师的大项目。团队不需要新的编程语言、新的数据库或新的web框架。你的经理不擅长给你布置漂亮的任务，向整个组织展示你的才能；她希望你告诉她这些机会在哪里。发现好的项目似乎是一件幸运的事。选择错误的项目，你会花费数月甚至数年的时间去做一些可能会被取消的事情，尽管你尽了最大的努力。你有点嫉妒你的管理层朋友，他们在不断壮大自己的团队的同时，似乎升职更快。

其他开发人员则鱼龙混杂。你是一个很好的人，所以他们中的一些人羡慕你并听取你的意见，但其他人似乎嫉妒你的影响力。新开发人员要么想占用你太多的时间，要么似乎出于任何原因害怕你。与领导大型、有趣项目的同行相比，他们显然比你有一些竞争力。

你的经理有点痛苦。她并不十分支持你开源系统的愿望，因为你认为它为行业所需的日志记录提供了一个新的转折点。她建议，如果你想演讲或写书，也许你需要花一些私人时间来做这些工作。她在技术问题上寻求你的反馈，但有时会忘记告诉你新的计划，以至于你没法发表个人意见。你怀疑自己错过了关键信息，因为你没有参加正确的会议，但每次她邀请你参加这些会议时，你都会记得这些会议是多么无聊和低效，以及你失去了多少宝贵的专注时间。而且她对你想要摆脱回复电子邮件、面试或及时回复代码审核等烦琐工作的渴望没有太多耐心。

尽管如此，大多数时候你还是可以构建东西。你可以把时间集中在技术问题、系统设计和工程问题上，不必与太多人打交道或坐在无聊的会议上。你可以经常选择你的项目，如果你想要新的东西，你可以很容易地在团队之间移动。你刚刚发现你的薪水比你的经理还高！所以，生活并不都是糟糕的。

想象中经理

你有一个团队，你有控制权，你可以做决定，你最终可以让别人按照你的方式做事。你的团队尊重你，在任何事情上都乐于服从你的权威。你认为他们应该做测试工作。 你告诉他们，“编写更多的测试”，他们就会去做！你想确保每个人都得到公平的对待，不管他们的性别、种族等等？你要确保这一切都发生了，并且解雇任何越界的人，这会给团队的其他成员造成不健康的环境。

因为关心别人，即使下属不认同你，他们也总相信你在对他们尽量负责。下属从一开始就无条件相信你，当你陷入困境时，他们会为你提供公开的反馈，并渴望收到你的反馈。和人打交道当然很有压力，但是他们知道你在乎他们，所以这也是很有回报的。一旦你处于某种权威地位，你就会看到你的教练工作会很快发挥影响。

当你看到另一个经理做了一些看似错误的事情时，你可以自由地给他建议，就像你和另一个需要系统设计帮助的工程师谈话一样。其他的经理总是对倾听你的想法感兴趣，他们可以看到你是如何有效地让你的团队工作，你是如何清楚地关心组织的健康，以及你有多么真心地希望让每个人都变得更好。

你的经理给你很多指导，但很少告诉你该怎么做。当你意识到你已经准备好面对一个更大的团队的时候，你的经理就会给你更多的人手，扩大你的组织。 她给你明确的目标，很少改变。即使你有很多的责任，你仍然有一些时间来写博客和发表演讲，这是鼓励的，因为这将帮助你的团队雇用和提高你在科技行业的地位。

简而言之，你可以做决定，你可以创造文化，你的效率是显而易见的，你周围的人，使你的晋升道路迅速，你的事业令人兴奋并且有利可图。

经理的真实生活

你有一个团队。你有一定的控制力，但是你很快就发现，让人们做某件事比仅仅告诉他们去做更难。你似乎已经放弃了对自己日常生活的控制。你大部分时间都在开会。你知道这一切即将到来，但直到你亲身经历，你才真正理解它的含义。当你只有一个小团队的时候，你仍然能够平衡事务并且写代码，但是随着你的团队的成长，你已经和代码失去了联系。它会把你当成你应该做的事情，但是没有时间。每次您抓紧时间编写代码时，都会意识到提交代码并让团队后续支持是不负责任的，因此至多在这里抓一个脚本，在那里调试一个问题。 专注于打造自己伟大的东西是一段遥远的记忆。

你可以做决定。实际上，只是有些决定可以缩小决策的范围。 您可以将您的团队的注意力集中在一些事情上，比如编写更好的测试，但是他们仍然需要实现产品路线图，并且他们对于应该优先处理哪些技术任务有自己的想法。所以，除了自己做决定，你还在帮助团队做决定。你的经理给你设定了目标，但有时会完全改变目标，由你决定如何向团队解释这些改变。

你确实为你的团队制定了文化标准，这是好的，也是坏的。当他们追求你最好的方面时是好的，当你意识到你的团队也在模仿你的缺点时是坏的。

你的团队自然不会简单地同意你，尊重你，甚至喜欢你。 你意识到权威不仅仅是一个头衔。当项目进展不顺利的时候，或者当你必须告诉个人他们还没有准备好被提升，他们还没有得到加薪，今年没有奖金的时候，你会发现自己在努力激励他们度过困难时期。 他们中的一些人不会告诉你他们什么时候不开心，他们只是在你发现有什么不对劲之前就开始厌烦并放弃。当公司做得很好，你有很多钱可以支付，有很多令人兴奋的项目时，生活是美好的；但当事情有压力时，你会发现你没有多少力量让人们快乐。更糟糕的是，你甚至不能在不经历疯狂的人事流程的情况下解雇员工！尽管如此，你仍然可以看到你的工作对他们中的一些人很重要，因为你的指导，他们更快乐，更成功。这些小小的胜利支撑着你度过了艰难时期。

其他经理对你的反馈不感兴趣。事实上，当他们认为你在侵占他们的地盘时，他们会觉得你在干涉他们，并变得很有竞争性。你自己的经理不同意你已经准备好组建一个更大的团队，也无法真正解释原因；他的教练技能还有很多不足之处。也许他只是担心你会超过他？他绝对不希望你把所有的时间都花在演讲上，尽管当你离开办公室太多的时候，无论团队从中获得什么价值，他都会很生气。如何在不损害同事或上司的情况下领导，这比你想象的要复杂。但如果你能得到更大的团队，你知道你会得到晋升，所以至少你的道路是明确的。当你发现为你工作的工程师比你赚得更多时，你几乎失去他了，所以你最好想办法让这个更大的团队更快运转。否则，所有这些压力和废话的意义是什么呢？

我最后的建议是如果你愿意，你可以切换轨道。人们在某个时候尝试管理，意识到他们不喜欢它，然后回到技术轨道，这是很常见的。没有什么选择是永久的，但要睁大眼睛。每个角色都有好处也有坏处，让你去感受你最喜欢的是什么。

好经理，坏经理：流程独裁者

流程独裁者相信，有一个真正的流程，如果正确实施并按照设计执行，将解决团队的所有最大问题。流程独裁者可能痴迷于敏捷、看板、scrum、精益甚至瀑布式方法。他们可能对随叫随到的工作方式、必须如何进行代码审查或发布过程必须如何操作有非常精确的想法。他们往往很有条理，对细节很熟悉，而且他们善于了解规则并严格遵守规则。

流程独裁者经常出现在QA、帮助台或产品管理组中。它们在咨询机构和其他对具体度量工作待遇优厚的部门也很常见。他们可能专注于运营，尽管根据我的经验，在你的经典系统运营团队中，这些人相对较少。他们可能是项目管理团队中非常有价值的成员，因为他们倾向于确保不会忘记任何任务，并确保所有事情都以应有的方式完成。

当流程独裁者没有意识到大多数人不如他们擅长遵循流程时，他们会很挣扎。他们倾向于将所有问题归咎于未能遵循最佳流程，而不是承认灵活性的必要性和意外变化的必然性。他们常常专注于容易衡量的事情，比如在办公室的时间，而忽略了他们在关注容易衡量的事物时未能捕捉到的细微差别。

相信“每个工作都存在正确工具”的工程师有时会在成为技术领袖后，变成流程独裁者，寻找正确的工具来解决计划、重点、时间管理和优先级排序等所有问题。他们试图在寻找完美流程的同时停止所有工作，或者不断在团队中推出新的工具和流程，作为解决人类交互中更混乱问题的解决方案。

与流程独裁者相反的不是完全放弃流程的管理者，而是理解流程必须满足团队和工作需要的人。具有讽刺意味的是，虽然“敏捷”通常是以一种僵化的方式实现，但《敏捷宣言》的原则是对健康流程的一个伟大总结：

人与交流优于流程和工具
软件优先于复杂文档
客户合作优先于合同谈判
响应变化优先于按计划执行

作为一名新的技术领袖，请注意不要依赖流程来解决团队中沟通或领导差异导致的问题。有时改变流程是有帮助的，但不是一个灵丹妙药，没有两个伟大的团队在过程、工具或工作风格上看起来完全相同。我的另一条建议是寻找自我约束的流程。如果你发现自己扮演了任务负责人的角色，与其批评那些违反规则或不遵守流程的人，不如看看流程本身是否可以改变为更容易遵守。检查合规是浪费你的时间，而自动化往往会让规则更明显。

作为流程独裁者的经理，尝试帮助他消除任务歧义。与许多管理者的陷阱一样，对流程管理的痴迷可能与对失败的恐惧和控制事情以防止意外发生的愿望有关。如果你是诚实的，并且清楚地表明失败和不完美是安全的，那么这通常足以让你的流程独裁者放松一点，对不确定性做一些让步。防止流程独裁者用所有时间寻找完美的工具或流程非常重要，尤其重要的是确保他们不会因为未能遵循流程而惩罚团队。

如何成为优秀的技术领袖

伟大的技术领袖有许多特点，但下面这些是最重要的。

理解架构

如果你担任技术领导，但你觉得自己没有完全理解你所支持的体系结构，那就花点时间去理解它。学习它。了解一下。将其可视化。了解它的连接、数据所在的位置以及它如何在系统之间流动。了解它如何反映它所支持的产品，以及这些产品的核心逻辑所在。当你不了解你正在改变的架构时，几乎不可能很好地领导项目。

融入团队

如果你自己在做所有有趣的工作，停下来。尝试看看那些棘手、无聊或令人讨厌的技术需求，看看你是否能解开这些难题。在不那么令人兴奋的代码工作中，你可以发现许多流程断点。对于枯燥或令人沮丧的项目，如果有经验的人花时间去看，通常会发现一些显而易见的问题并加以解决。如果你只是在做最无聊的工作，停下来。作为一名很有天赋的高级工程师，你承担一些更艰巨的任务合情合理。你想鼓励团队中的其他人学习整个系统，你想让他们有机会发挥自己，但你不必总是在自己选择的工作中牺牲自己。偶尔给自己一个有趣的任务，只要你知道自己有时间把它做好。

领导技术决策

您将参与团队的大多数重大技术决策。然而，参与与独自一人完成所有任务并不相同。如果你开始在没有征求团队意见的情况下做出所有的技术决策，他们会对你不满，并在出现问题时责备你。另一方面，如果你没有做出任何技术决定，而把一切都交给团队，那么本可以快速做出的决定可能会在没有决议的情况下拖延下去。

确定哪些决策必须由您做出，哪些决策应该委托给具有更多专业知识的其他人，哪些决策需要整个团队来解决。在决策过程中，明确讨论的问题，并传达结果。

懂得沟通

现在，你的生产力不如整个团队的生产力重要。通常，这意味着你要付出额外的沟通成本。不是让每个团队成员都参加会议，而是代表团队，沟通他们的需求，并将会议中的信息带回团队。如果说一种通用的才能将成功的领导者与其他人区分开来，那就是沟通技巧。成功的领导者写得很好，他们读得很仔细，他们可以站在一群人面前讲话。他们在会议上很专注，并不断测试自己的知识和团队的知识极限。现在是练习写作和口语技能的好时机。编写设计文档，并从更好的写作者那里获得反馈。为你的科技博客或个人博客撰写博客文章。在团队会议上发言，在聚会上发言，并练习站在观众面前。

在所有这些交流中，不要忘记倾听。给别人一个说话的机会，听听他们说什么。练习将事情重复给别人，以确保你理解他们。学习如何听到别人说的话，并用自己的话重新表述。如果你不爱记笔记，你可能需要学习。无论你是选择深入研究技术，还是成为一名管理者，如果你不能沟通和倾听别人的话，你的职业发展都会受到影响。