管理一个团队（Managing a Team）

从管理一两个人到管理整个团队只有一步之遥，但管理团队不仅仅是做好管理单个成员的工作。到了这个阶段，你的工作已经变了。事实上，在越过这个层级之后的每一步，你都很可能会面对一套完全不同的要求和挑战。随着职业发展，最难做准备的事情，就是「你将开始做完全不同的事」这个认知。无论你多么愿意相信管理是高级工程师技能的自然延伸，它实际上是一整套全新的技能与挑战。

下面是我为「管理团队」这个角色撰写的职位描述，我称之为「工程负责人（engineering lead）」：

工程负责人（engineering lead）会花更少的时间写代码，但他们仍然会参与小型技术交付物（deliverable），例如缺陷修复（bug fix）和小型功能，同时不阻塞或拖慢团队进度。比起写代码，他们更重要的职责是识别流程中的瓶颈（bottleneck）以及团队成功路上的障碍，并清除这些障碍。

担任此角色的人被期望对[组织]整体的成功产生重大影响。特别是，担任此角色的领导者能够识别最具价值的项目，并让团队始终专注于这些项目。作为保持团队专注的一部分，工程负责人将与产品负责人（product lead）密切合作，管理项目范围（scope），确保技术交付物达成。除了聚焦团队，他们还要能够识别团队的人员编制（headcount）需求，并规划与招聘来满足这些需求。

工程负责人是独立的经理（manager）。他们能自如地管理技能领域与自己不同的团队成员。他们向所有团队成员清晰传达期望，并频繁地征求与给予个人反馈（不仅在考核期内）。除了强大的管理技能，工程负责人还充当其产品组（支柱，pillar）技术路线图（technical roadmap）的领导者。他们向支柱伙伴清晰传达时间线、范围与风险，并在明确的时间线上主导重大举措的交付。此外，他们识别战略性技术债（technical debt）的领域，为偿还这些债务做成本/收益分析，并向管理层传达解决这些债务的优先级建议时间表。

我们已经覆盖了管理个人的基础知识，现在让我们谈谈，在保持技术能力的同时，领导整个团队需要什么。

本章的主题是聚焦于人员管理之外的工作。因为新经理很容易过度关注与人相关的任务，我想把你的注意力拉回到管理团队中更技术性、更具战略性和领导力的领域。

成为人员经理（Becoming a People Manager）

我最初是在一家抵制传统经理的公司里担任非正式的团队负责人（team lead）。担任那个角色一段时间后，我该成为正式的人员经理（people manager）了。经理这个角色对公司来说是新鲜的，整个组织都带着一些惶恐来迎接这些变化。在把工程人员划分给各位经理时，我们权衡过谁会抵触新结构。不是每个人都乐于为曾经的平级同事工作，但我相当幸运。我现在管理的大多数人，与我共事已久，足以接受「我现在是他们的经理」这一事实。他们的支持帮助巨大。虽然并不完美，但我遇到的阻力并不大。

在这个新角色中，我发现自己管理着几个在技术资历上远比我资深的人。这是我第一次无法依靠「懂得最多」作为主要的领导工具。这不仅仅是简单的冒充者综合征（impostor syndrome）。我知道自己技不如人。他们也知道我技不如人！当然，我现在管理的两位最资深的工程师都意识到这很尴尬。我们聊过：每个人都有自己要做的活，而我的工作就是尽我所能帮助他们成功。

其中一位工程师一路上持续给我反馈，帮助我。我努力去了解这个人看重什么、需要什么才能成功。另一位工程师则难以适应我成为他的经理。他先是转去了另一个团队。几个月后，他带着些许懊悔回到我们团队，同意与我共事。事实证明，成为好经理不在于拥有最多的技术知识。支持他人的工作对管理的成功要重要得多。

bethanye Blount

保持技术能力（Staying Technical）

这本书是写给工程经理（engineering manager）的，它不是一本泛泛而谈的管理书。工程管理是一门技术学科，而不只是一套与人打交道的技能。随着职业生涯发展，即使你可能不再写代码，你的工作也会要求你引导技术决策。即使有设计系统的架构师（architect）或其他负责细节的高级技术人员，作为团队经理，你的职责是让他们为自己的决策负责，确保这些决策经得起技术直觉的检验（technical smell test），并且已经与团队和业务的整体背景相权衡。多年实战磨砺出的技术直觉，对引导这一过程至关重要。

此外，如果你真心想赢得工程团队的尊重，他们必须认为你在技术上可信。没有技术可信度（technical credibility），你将面临一场艰苦的战斗；即使你能在某家公司获得领导职位，你的选择也会受限。在努力成为成功的工程经理的路上，不要低估你的技术技能的价值。

当然，你必须学会如何平衡。在向管理转型的过程中，如何保持技术能力是一场挣扎。成为经理带来的新职责——更多的会议、规划、行政任务——都不利于拥有专注写代码的时间。当你被一百万个方向拉扯时，很难找到办法留在代码里。

然而，在这个层级，如果你不留在代码里，你就有在职业生涯过早地让自己技术过时的风险。你可能走在管理职业路径上，但这并不意味着你应该对技术责任撒手不管。事实上，我在工程负责人的职位描述中特别提到，我期望这个层级的经理实现小型功能并修复缺陷（bug）。

如果你做的都是小事，为什么还要费心写代码？答案是：你需要足够地留在代码里，才能看到瓶颈和流程问题在哪里。你也许可以通过观察指标看到这些，但当你自己积极参与写代码时，感受这些问题要容易得多。如果构建（build）非常慢，或部署代码耗时太长，或值班（on-call）是一场噩梦，你会从自己——一名有经验的工程师——在完成琐碎编程任务时遇到的困难中感受到这些。想象一下这对你的团队成员来说有多沮丧！当你自己啃过这些代码后，识别技术债并确定处理优先级要容易得多。

此外，作为单一团队的经理，你会被要求帮助判断在你们的系统中什么可行、什么不可行。当你们组的产品经理（product manager）冒出一个疯狂的想法时，如果你对自己评估「该功能在现有系统中实现起来有多容易」的能力有信心，管理起来会容易得多（但要当心在给出这类估算时过度自信！）。优秀的工程经理能识别穿过系统实现新功能的最短路径。正如你在担任技术负责人（tech lead）期间所学到的，复杂项目管理的一个关键部分是足够深入地理解系统各部分，从而确定最佳实现路径。你对系统中的代码理解得越深，确定这条路径就越容易。

遗憾的是，有些公司并没有真正提供「有一点时间写代码的经理」这种角色。这些公司把管理轨道和技术轨道分得过于泾渭分明，经理一上任就有大团队直接向其汇报。于是经理的工作变成了行政与人员管理岗位，这些经理最终只能（如果还有的话）在夜晚和周末挤时间搞技术。如果你的公司是这样，我的建议是：保持技术能力，直到你觉得自己真正掌握了想学的写代码和设计系统的东西，然后再决定是否要转行做管理。停止写代码后，失去的时间很难弥补；如果你在职业生涯太早的时候这样做，你可能永远无法获得足够的技术造诣来超越中层管理的角色。

如果你对我「经理应该留在代码里」的建议感到震惊，别担心！在后面的章节里，我会详细讨论「不再值得留在代码里」的那个时点，而且我确实相信那个时点是存在的。但现在，试着多留在代码里一点。我保证，这会让你的工作更轻松。

诊断功能失调的团队：基础篇（Debugging Dysfunctional Teams: The Basics）

有时你会发现自己管理着一个功能失调（dysfunctional）的团队。他们不断错过交付物。人们不开心，不断离职。产品经理很沮丧，团队也对产品经理不满。或者他们只是在工作中缺乏活力，对当前项目缺乏热情。你能感觉到有些不对劲，但不太确定是什么。几种基本的功能失调可能会悄悄潜入技术团队。我在这里简要介绍这些失调，让你知道该注意什么、如何解决。

无法交付（Not Shipping）

你可能不认为这是一种功能失调。比如，也许你的团队正处在一个新问题的深度研究模式中。然而，即使是做研究的团队，通常也有目标和交付物，哪怕只是初步发现的形式。总体而言，人类在设定小目标并定期达成时，感觉会很好。

作为团队经理，你可能担心把团队逼得太紧，于是放任他们错过截止日期而不吭声。诀窍在于学会平衡「推动团队」与「保持克制」。如果你仍在为团队写代码，这可能是一个挽起袖子、帮助团队达成交付物的好时机；或者真正深入项目下滑的部分，与负责的工程师合作，帮助理解情况。

有时，团队无法交付是因为他们一直在用的工具和流程使快速完成工作变得困难。一个常见的例子是，你的团队每周只尝试向生产环境发布一次变更，甚至更少。发布频率低会掩盖痛点（pain point），比如发布相关工具不佳、大量手工测试、功能过于庞大，或开发者不知道如何拆解工作。既然现在你管理这个团队，就开始推动清除这些瓶颈吧。

在我上一份工作中，系统有一个关键部分，有一段时间我们每周只发布一次。发布要花好几个小时，非常痛苦，而且经常有人试图塞进最后一刻的改动，破坏了测试，拖慢了所有人的节奏。我们都认为这是个问题，团队齐心协力改进代码库和自动化，让发布更快。在过程接近尾声时，我推动团队做了改进，让我们能够每天发布。这一改变对团队的影响立竿见影。事实证明，发布可能成为一个资源竞争（resource contention）点。当人们在争夺稀缺资源时，团队成员之间的冲突和不快几乎不可避免。让「发布代码」这一资源不再那么稀缺，立刻改善了团队士气。

人际纷争（People Drama）

有时我们让自己抓着那个才华横溢的混蛋不放太久。你知道的——那个人，你觉得他无可替代，因为他就是那么高效、那么聪明，但他没有团队精神，让周围每个人都不开心。（关于这类有毒员工的更多内容，参见「才华横溢的混蛋」。）这种情况的一个不那么严重的版本是：那种只会搅起纷争的人，沉湎于负面经历的人，或者花太多时间八卦、玩「我们对抗他们」游戏的人。

你必须勇敢，迅速把人际纷争扼杀在萌芽状态。向你的经理求助是可以的，尤其是你第一次处理这种事时，但要注意：你的经理在对付才华横溢的混蛋时，可能比你还难。她没有看到这对团队动态（team dynamics）的直接影响；她只看到一个能把事情搞定的人。做好准备，与员工和你的老板进行一系列对话。也许调去另一个团队就能解决这个局面。

消极的人比才华横溢的混蛋容易对付。向他明确表示行为必须改变，拿出清晰的例子，并在事情发生后迅速提供纠正性反馈。有时，消极的人只是不开心，最好的做法是帮他在友好的气氛中离开团队；你必须为这种结果做好准备。另一些时候，这个人完全不知道自己给团队带来的影响，一次简短谈话就足以制止这些事件。

要小心，别让嘴上消极的人在你的团队里长期保持那种心态。这些「能量吸血鬼」制造的有毒纷争，即使是最好的经理也难以对抗。在这种情况下，最好的防守就是进攻，迅速行动至关重要。

过度劳累导致的不满（Unhappiness Due to Overwork）

这个问题容易解决得多。通常，过度劳累导致的不满根源在于你可以着手处理的问题。例如，如果过度劳累源于生产系统的（不）稳定性，作为经理，你的职责是放慢产品路线图（product roadmap）的节奏，以便在一段时间内聚焦稳定性。为告警（alert）、停机（downtime）和事故（incident）建立明确的度量，并努力减少它们。我的建议是，在每次规划会议上，把 20% 的时间用于系统可持续性维护（sustainability）工作（用「可持续性维护」而不是更常见的「技术债」）。

如果过度劳累源于一个紧迫、时间敏感的发布，请记住两件事。第一，你应该当啦啦队长。以团队需要的任何方式支持他们，尤其是亲自帮忙干活。订晚餐。告诉他们你感激这份辛苦。明确告诉他们冲刺（push）结束后会有明确的休息时间。让当下尽可能有趣。有时，一段冲刺期（crunch period）可以成为团队的凝聚体验。但他们会记得：在压力最大的时期，经理是和他们在一起，还是跑到别处忙自己的事。

第二，尽一切可能从这次冲刺期中学习，避免下次再发生。如果可以，砍掉功能。如果日期确实不现实，就顶回去。冲刺期总会发生，但没有理由让它们频繁发生。

协作问题（Collaboration Problems）

你的团队与产品团队、设计团队或另一个技术团队配合不佳，协作的缺失拖累了所有人。这里没有速效药，但表现出改善协作的意愿会大有帮助。如果你还没有这么做，请确保与相应的平级同事定期碰头（touch-base），一起解决问题。收集来自团队的可执行反馈，并就可能的改进进行富有成效的对话。在团队面前贬低你的平级同事会让情况更糟，所以即使你对他们感到沮丧，也要尽量在公开场合保持积极，支持他们的努力。

如果你的团队内部配合不佳，考虑创造一些让他们在一起、而不全是聊工作的机会。带整个团队去吃午饭，周五下午提前下班一起参加有趣的活动，鼓励在聊天室里开一些老少皆宜（PG-rated）的玩笑，问问大家的生活过得怎么样——这些都是培养团队凝聚力的方式。作为新经理，我曾经很不情愿参与这种联络感情的活动，但即使是大多数内向的人，也想与团队有一种联结感（relatedness）。假设你没有前面列出的那些「人际纷争」问题，在这方面付出的小小努力就能让团队气氛大大回暖。

请教 CTO：管理曾经的平级同事（Ask the CTO: Managing a Former Peer）

我刚被晋升，管理自己的团队，而团队里有我的一位平级同事——一位同样想要这个职位的高级工程师。我该如何处理，才能在担起这个角色的同时不疏远他？

这种经历可能非常尴尬，所以首先要承认这一点。如果你现在管理的人曾经确实是你的平级同事，就承认这个转变的怪异之处。对这个人大方坦诚：你会尽最大努力做好这份工作，但你需要他的帮助才能做到。你需要他对你坦诚，告诉你哪些事情进展顺利、哪些不顺利。你在他面前需要稍微露出一些脆弱，因为你第一次做这件事不会完美。

接下来，记住你的工作已经发生了重大变化。作为他的经理，你现在可能有权推翻他的决定，但要非常谨慎地使用这种权力。用管理权力推翻技术决策通常是个坏主意。抵制微观管理（micromanage）他人的诱惑——尤其是那些曾经是你的平级同事的人。他们对「你被『奖赏』了」这种感觉会很敏感，即使他们自己并不想成为经理。如果你质疑他们的每一步行动，试图自己做每一个决定，你会让这种敏感变得更糟。

这里有一个推论：当你逐渐承担人员管理的额外职责时，你将不得不放下一些之前的工作。在管理链上每升一级，都意味着增加新职责、放弃一些旧职责。你可以利用这个局面，把过去由你掌控的某些技术工作公开交给曾经的平级同事，这对你有利。这也是给团队中更资浅的成员提供新挑战的机会。虽然许多工程组织希望一线经理继续写一些代码，但他们很可能期望经理写的是较小的功能、缺陷修复和增强，而不是深度的新系统。

在整个变化过程中，你的目标是向团队展示你致力于帮助他们成功。你的新角色并没有从团队其他人身上拿走任何东西；它只是给了你一些新的职责——这些职责要么之前被忽视，要么曾属于别人——并把你的部分旧职责转移给团队的其他成员。

如果你曾经的平级同事都因为受不了为你工作而辞职，你的团队不会成功。他们对任何分歧或你「抢权」的观感都会格外敏感。他们甚至可能做一些试图削弱你的事。要有所取舍地选择战斗。从长远看，以成熟的态度处理这个转变会得到回报。

盾牌（The Shield）

许多管理建议告诉新经理：如果他们做得出色，他们工作的一部分就是成为一面盾牌（或者说得不客气一点，一把「狗屁雨伞」）。他们应该帮助团队专注于需要完成的事，不被周围公司里发生的更广泛的纷争、政治和变化分心。

我对这种管理观感心情复杂。我确实认为，那些不必要地暴露在与己无关的有毒纷争中的团队，容易分心、压力山大。如果你管理的是一个工程团队，他们不需要关心客服组织里的人际纠纷。我曾怀着复杂的自豪感看着自己的团队在「世界仿佛在耳边燃烧」时依然平稳运转。让每个人都认识到：他们可以也应该专注于自己能影响和改变的事情，忽略那些改变不了的事情——这对每个人都有价值。职场中的纷争通常不过是一种满足自我、消磨精力的消耗品。

所以，是的，让团队免受干扰很重要。或者换一种说法：帮助他们理解关键的重要目标，并让他们专注于这些目标，这很重要。然而，期望你能或应该为团队挡住一切是不现实的。有时，适当地让一些压力透过来给团队是有益的。目的不是让他们压力山大，而是帮他们获得所处环境的背景信息（context）。极端的「盾牌」认为，给出清晰的目标就能最好地聚焦和激励团队。但人类通常需要某种背景信息来理解为什么设定这些目标，从而理解他们正在解决什么问题。如果某个系统在 11 月之前不能上线运行，你们就会遇到运营问题，那么你的团队应该有权理解这一后果。恰当的背景信息能帮助团队就如何、在哪里投入精力做出好的决策。作为经理，你的职责不是独自做出所有这些决策。

盾牌有时还会犯另一个错误：否认外部世界存在任何纷争。如果公司其他部门发生裁员，而团队是从别人那里听说的，那么你没有为团队挡住纷争，反而制造了一种局面：他们感觉有什么坏事正在发生，却没人愿意承认。相反，如果你以直截了当、情绪低强度（low-emotion）的方式传达这类事件的信息，就能减轻流言，迅速消除对团队的影响。

你可以是盾牌，但你不是家长。有时，把盾牌和导师（mentor）的角色结合起来，我们最终会与团队形成一种家长式的关系，把他们当作需要保护、养育和适时责备的脆弱孩子。*你不是他们的家长。*你的团队是由需要得到恰当尊重的成年人组成的。这种尊重对你的心智健康和他们的一样重要。当你把他们看作自己孩子般的延伸时，太容易把他们的错误当成针对你个人的事；或者投入过多情感，以至于把他们与你的每一次分歧都当成针对你个人。

如何推动好的决策（How to Drive Good Decisions）

你在团队的决策过程中扮演什么角色？你知道吗？你可能有一位与团队合作、拥有产品路线图（即团队承诺要做的业务功能集）的产品经理。你可能有一位技术负责人（tech lead），正如我们在第 3 章中讨论过的，他仍然深扎在技术中，但同时也在思考项目管理和需要完成的工作。那么，这把你——工程经理——置于何地？

你拥有的责任比你预想的更多。产品经理负责产品路线图，技术负责人负责技术细节，而通常由你对团队在每一个环节上的进展负责。领导力的本质在于：虽然你可能只有引导决策而非支配决策的权力，但你仍会因这些决策的结果好坏而被评判。

建立数据驱动的团队文化（Create a Data-Driven Team Culture）

当你有一位产品或业务负责人时，她应该习惯于用关于业务、客户、当前行为或市场潜力的数据来论证她的决策。开始把其他数据加入其中吧。例如，给那个人提供团队生产力数据（比如完成功能所需的时间）或质量度量数据（比如花多少时间处理故障，或在 QA 中、发布后发现多少缺陷）。这些效率和技术数据点可以用来评估产品功能和技术变更两方面的决策。

锻炼你自己的产品能力（Flex Your Own Product Muscles）

强大的领导力关心培育成功，关心拥有一支能交付成功项目的团队，这意味着打磨你对「什么对客户重要」的理解。无论你是在为外部客户写代码，为其他工程师开发工具，还是运营一个支持团队，总有一群人依赖你工作的产出。把他们当作你的客户。花时间培养客户同理心（customer empathy）很重要，因为你需要为工程师提供他们工作的背景信息。培养客户同理心还会帮助你弄清楚技术的哪些领域对客户有最大的直接影响，而这种理解将指导你把工程投入放在哪里。

展望未来（Look into the Future）

你需要从产品和技术的角度多想两步。了解产品路线图的走向，能帮助你引导技术路线图。许多技术项目之所以被支持，靠的是它们能更容易地赋能新功能——例如，重写结账系统以接入 Apple Pay 之类的支付方式，或者迁移到一种通过 WebSockets 支持流式数据变更的新 JavaScript 框架模式，以构建更具交互性的体验。开始向产品团队提出关于未来可能是什么样的问题，并花一些时间跟进技术发展——那些可能改变你对所写软件或运营方式思考的技术发展。

复盘你的决策与项目成果（Review the Outcome of Your Decisions and Projects）

讨论一下：你用来推动项目的假设是否真的被证实了。重写那个系统后，团队真的更快了吗？添加新功能后，客户行为是否像产品团队预测的那样改变了？你从 A/B 测试中学到了什么？项目完成后很容易忘记复盘假设，但如果你为自己和团队养成这个习惯，你总能从自己的决策中学到东西。

为流程与日常工作举行回顾（Run Retrospectives for the Processes and Day-to-Day）

敏捷（agile）流程通常在每个为期两周的开发冲刺（sprint）结束时举行一次回顾会议（retrospective），在会上讨论冲刺期间发生了什么，并挑选几个事件——好的、坏的或中性的——进行详细讨论。无论你采用敏捷方法论还是其他方式，定期的流程回顾对发现模式、促使人们正视决策结果都很有价值。团队对获取需求的方式感觉好吗？他们对代码质量感觉好吗？这个过程能帮助你了解：你长期做出的决策如何影响团队在日常工作中的运作方式。这种方法比收集团队健康度数据更主观，但它可以说比许多客观度量更有价值，因为它来自团队自身正在注意、正在挣扎或正在庆祝的事情。

好经理，坏经理：回避冲突者，驯服冲突者（Good Manager, Bad Manager: Conflict Avoider, Conflict Tamer）

杰森（Jason）的团队过度劳累。所有人都知道查尔斯（Charles）应该去做大型系统重写，但他已经几个月都在忙自己的「宠物项目」（pet project）。在听到查尔斯不帮助新系统的抱怨后，杰森把团队召集起来，让大家投票决定应该砍掉哪些项目来减轻工作量。大家投票砍掉查尔斯的宠物项目，这毫不意外——也就是说，除了查尔斯以外没人意外。查尔斯从未从杰森那里听到任何相关消息，他以为自己一直在做正确的事。

杰森的团队感到压力，部分原因是杰森似乎不会在别的团队面前为他们撑腰。他讨厌对新项目说不，但他也不要求增加人手来分担工作量。大家都同意杰森人很好，但要让他真正去解决冲突或做出艰难决定太难了。结果，团队过度劳累，难以确定前进的优先级，成员之间还积攒了好几桩怨气。

莉迪亚（Lydia）的团队也感到压力，她也有一个自己的「查尔斯」要对付。她曾答应查尔斯，他会有时间做这个项目，但很明显优先级已经变了，他的工作也需要随之改变。在与查尔斯的一对一谈话（1-1）中，莉迪亚解释了当前的工作量，告诉查尔斯他的团队需要他帮忙做系统重写。查尔斯不高兴，莉迪亚也不喜欢这场谈话，但她知道，作为团队经理，她有责任确保团队专注于最重要的项目。

莉迪亚知道这个项目由团队来主导很重要，所以在她争取更多人手的同时，她确保团队知道她为什么决定接下这个大项目。她与团队一起确定工作优先级，并通过一套「呈现选项、征求反馈」的结构，引导他们走过在用什么技术上的分歧。莉迪亚的团队形容她「严格但公正」；尽管分歧时有发生，团队很擅长克服挑战，协作良好。

当用这样鲜明的对比来看时，似乎很清楚：杰森没有处理好冲突，而莉迪亚在驯服冲突。虽然杰森的民主风格看起来应该造就一个被赋权（empowered）的团队，但他无法说不、不愿为任何决策承担责任，意味着没有人感到安全。在杰森的团队里很难知道接下来会发生什么，因为他不是在引导团队，而是让团队自我引导。

拥有一个不断争吵、意见不一的团队是痛苦的，而且可能非常功能失调。但还存在一种「虚假和谐」（artificial harmony）：回避冲突的经理倾向于把和谐置于有实效的工作关系之上。为分歧创造一个能自行化解的安全环境，远比假装所有分歧都不存在要好得多。

管理冲突的该做与不该做（The Dos and Don’ts of Managing Conflict）

• 不要只依赖共识或投票。 共识（consensus）看起来在道德上很有权威性，但这假设参与投票的每个人都是公正的、对各种结果有同等的利害关系、对背景有同等的了解。在团队成员专业水平不同、角色各异的团队里，这些条件很少能满足。就像团队投票否决查尔斯的工作那样，共识可能相当残酷。不要让人们去参加你明知会失败的投票，而应该承担起经理的责任，亲自传达那个坏消息。
• 要建立清晰的流程，让决策去个人化。 当你想要允许群体决策时，群体需要有一套清晰的标准来评估决策。在做决策之前，先从对目标、风险和需要回答的问题达成共同理解开始。当你把某个决策的所有权（ownership）分配给团队中的某个人时，要明确哪些团队成员应该被咨询以征求意见，谁需要被告知该决策或计划。
• 不要对酝酿中的问题视而不见。 回避冲突的另一种表现是：无法处理问题，直到问题拖了太久。作为经理，如果你在绩效评估（performance review）过程中给出负面反馈，那对你的员工来说不应该是个大意外。可能有一些细微之处是你在写评估时才想明白的，但如果某人的工作存在重大问题，那个人应该在你一注意到时就知情。如果你自己没有注意到这些问题，而是在评估过程中通过几位平级同事的反馈才得知，那可不是好兆头。这很可能表明你没有用心关注，也没有在你的 1-1 中留出空间，让团队讨论他们与同事之间的问题。
• 要处理问题，但不要制造戏剧性。 处理冲突与培育功能失调是有区别的。你要留出空间让人们表达沮丧，但要注意「发泄情绪」与「真正的人际问题」之间的区别。运用你的判断力决定什么该处理、什么该放下。要问的关键问题是：这是一个持续存在的问题吗？是你亲自注意到的吗？是团队中很多人都在挣扎的问题吗？是否有权力动态或潜在偏见在起作用？目标是找出那些导致团队协作效率下降的问题并解决它们，而不是成为团队的心理治疗师。
• 不要把气撒在其他团队身上。 讽刺的是，回避冲突的经理在涉及其他团队时，往往反而会主动寻求冲突。他们强烈认同自己的团队，会对他们眼中来自外部的威胁做出攻击性反应。当出了问题时——比如一个跨团队的事故——经理会变成恶霸，为他的团队讨公道，或者把问题归咎于另一个团队。有时，这种行为是经理对自己团队压抑情绪的出口。正如一位朋友所说：「我没有告诉我的下属那 10% 需要改进的事情，因为我害怕他们会错过那 90% 做得好的信息，于是我把那种对问责的渴望发泄在了其他团队身上。我其实只是希望每个人都完全负责，我需要弄清楚如何在内部和外部以健康的方式表达这一点。」
• 要记得善良。渴望被别人喜欢是天性，也完全符合人性。 我们中许多人相信，被喜欢的方式就是显得友善（nice）——友善本身就是目的。然而，作为经理，你的目标不应该是友善，而应该是善良（kind）。「友善」是礼貌社会的语言，在那里你试图与陌生人或泛泛之交相处。友善是说「请」和「谢谢」，是为拎着包或推着婴儿车的人扶门。友善是别人问你过得怎么样时，说「我很好」，而不是「我心情糟透了，希望你别来烦我」。友善在随意交谈中是好事。但作为经理，你会有更深层的关系，更重要的是善良。善良是告诉一个还没准备好晋升的人她还没准备好，并用她需要做的工作来支撑这个判断。不善良是吊着那个人，说「也许你能晋升」，然后看着她失败。善良是告诉某人他在会议上的行为扰乱了团队。这很尴尬、很不舒服，但作为他的经理，进行这些艰难的谈话也是你工作的一部分。
• 不要害怕。 回避冲突往往源于恐惧。我们害怕做决策的责任。我们害怕显得要求太高。我们害怕如果给出令人不舒服的反馈，人们会辞职。我们害怕人们不喜欢我们，或者我们冒这个险会失败。有些恐惧是天生的，对冲突的结果保持敏感是明智的习惯。
• 要感到好奇。 思考自己的行为是对抗冲突恐惧的最佳方式。我把这个决策推给团队，是因为他们真的是最适合做决策的人，还是我只是害怕做出一个不受欢迎但必要的决定会让大家生我的气？我回避与平级同事一起解决这个问题，是因为她真的很难共事，还是我只是希望问题自己解决，因为我不想讨论它、不想可能出错？我没有给员工这个反馈，是因为他那天确实状态不好、只是一次性的，还是因为我害怕告诉他之后他会不喜欢我这个经理？对自己的行为多思考，你就不太可能去寻求不必要的冲突。

棘手情境：团队凝聚力破坏者（Challenging Situations: Team Cohesion Destroyers）

打造功能正常的团队，关键要素之一是建立一支能愉快协作的团队。曾有人给我一个检验「快乐工程团队」的标准：「如果你晚上给他们买披萨，他们会留下来一起社交，还是会尽快冲出门去？」

我对这个标准有些保留意见。那些每天有义务必须准时离开办公室的员工，与那些愿意留下来闲聊的员工相比，投入程度并无差别。但更大的要点仍然成立。大多数磨合到位（gelled）的团队有一种同事情谊（camaraderie），让他们一起开玩笑、一起喝咖啡、共享午餐，对彼此友好。他们可能有自己尊重的义务、工作之外的爱好，但他们不会把团队看作每天急于逃离的东西。

这里真正的目标是心理安全感（psychological safety）——即一个成员愿意在彼此面前冒险和犯错的团队。这是成功团队的根基。让团队磨合到位的工作，始于创造通向心理安全感的友善氛围。你可以通过花时间去把人们当作人来了解、询问他们的业余生活和兴趣来鼓励这种氛围。让他们分享自己觉得舒服的内容。问问孩子的生日派对办得怎么样、滑雪之旅如何、马拉松训练进展如何。这不仅仅是空洞的寒暄；它培育联结感（relatedness）——把人看作个体，而不是无名齿轮的感觉。

除了你个人培育联结感，你还希望团队彼此之间有自己的联结感。当公司谈论按「文化契合度」（culture fit）招聘时，他们通常的意思是，想招一些他们能友好相处的人。虽然这可能带来一些不良后果，比如歧视，但它源自一个明智的出发点。友好的团队更快乐、磨合更快，往往产出更好的结果。我的意思是，你真的想每天和一群你讨厌的人一起上班吗？

这就是为什么那些破坏团队凝聚力（team cohesion）的人如此成问题。他们的行为几乎总是让团队其他成员难以在他们身边感到安全。我们把这类员工称为「有毒」（toxic）员工，因为他们往往让每一个与他们接触的人都变得更低效。快速处理他们是做好管理的重要部分。

才华横溢的混蛋（The Brilliant Jerk）

有毒员工的一个变种是才华横溢的混蛋（brilliant jerk）。正如我们之前讨论过的，她个人产出巨大，但自我驱动（ego-driven）到极点，让几乎身边每个人都对她又怕又厌。对付才华横溢的混蛋的难点在于：她可能因为自己的才华被奖励了很久，像抓住救生筏一样紧紧抓住它。承认世界上除了纯粹的智力或生产力之外还有价值，会挑战她在这个世界上的位置，这对她来说往往是一个可怕的命题。所以她用智力霸凌，严厉地打压异见声音，无视她认为不如自己的人，并公开流露出她对任何她认为愚蠢之事的沮丧。

如今，大多数公司声称他们不容忍才华横溢的混蛋，但我个人不相信这是真的。经理要证明「开除一个产出优秀工作的人」是合理的，极其困难，即使她对周围的每个人都是消耗——尤其是当这个人只是偶尔犯浑时。多少混蛋才算太多？你会开始围绕这个想法兜圈子，试图为留下她找理由。你给她反馈，她好了一阵子，然后变得更糟。

避免「才华横溢的混蛋综合征」的最佳方式，就是干脆别招这样的人。一旦他们被招进来，赶走才华横溢的混蛋需要一种我认为并不常见的管理自信。幸运的是，这些人常常会自我了断：即使你可能没有勇气解雇他们，你也不太可能蠢到去提拔他们。对吧？希望如此。

对付一个在职的才华横溢的混蛋，需要一位强硬的经理。做好准备，她会对你给的所有反馈都全力反抗。这对你们俩都不容易。难点在于：如果她不把自己的行为看作问题，她就不会改变。单靠你一个人不太可能说服她相信自己的行为是个问题。全世界所有的证据都无法改变一个不想改变的人。

在拥有一个才华横溢的混蛋的情况下，你能为团队做的最好的事，就是简单而公开地拒绝容忍不良行为。这可能是少数几个「公开表扬、私下批评」被颠覆的场合之一。当一个人以对团队产生明显影响的方式行为不端，且你不希望你的文化效仿这种方式时，你需要当场说点什么，把标准讲清楚。「请不要那样对人说话；那是不尊重人的。」你需要严格控制自己的反应，因为在公开场合这样做是在走钢丝。如果你显得情绪化，可能会削弱你的威信。违规者可能把你的反馈当成情绪发泄而不予理会，或者你可能显得在针对这个人。如果你要在当下、在公开场合给出反馈，请保持中立但切中要害。注意，这种方法只应用于你认为对整个群体有害的行为。如果你只是觉得这个人在针对你个人，请私下讨论。你的首要目标是保护整个团队，其次是保护团队中的每个个体，最后才是保护你自己。

不沟通者（The Noncommunicator）

另一种非常常见的麻烦成员是不沟通者（noncommunicator）——那种向你、向队友、向产品经理隐瞒信息的人。那种喜欢秘密工作、等一切都做完做完美了再揭晓一个神奇项目的人。那种不与队友沟通讨论，而是回退（revert）他们的提交（commit），或拿走他们的工单（ticket）替他们做掉的人。那种不想走代码评审（code review）流程、在大项目上不要求设计评审（design review）的人。

这种团队成员让周围每个人都恼火。作为不沟通者的经理，你必须尽快把这种隐瞒信息的习惯扼杀在萌芽状态。如有必要，要明确指出他没有达到工作期望。这往往是恐惧的迹象——这个人害怕自己被发现能力不足，或者害怕被要求做他不感兴趣的工作。有时，这也说明一个人觉得自己应该承担更多责任，并且不尊重自己的经理。无论原因是什么，这个人都会破坏团队凝聚力，因为他没有与队友协作；他觉得分享进行中的工作不安全，而他的恐惧常常给团队其他成员树立了榜样。

如果可能，解决隐瞒行为的根本原因。如果隐瞒者害怕被批评，那么你的团队是否有一种需要处理的严苛文化？你的团队总体上是否具备心理安全感？团队其他成员是否把这个人当作外人对待，也许是因为他有不同的背景或技能组合？如果团队在排斥这个人，你需要决定是尝试纠正团队，还是把这个人调到另一个团队。有时，调动这个人是最仁慈的做法；另一些时候，最好的解决方案是与整个团队一起努力，改变文化的天平，打破排斥新人的习惯。

缺乏尊重的员工（The Employee Who Lacks Respect）

第三种有毒的人，是那种根本不尊重你这个经理、或不尊重她队友的人。处理这种人会很困难，你可能需要经理的帮助，但如果你能自己搞定，那说明你品格非凡。简单地说，如果你的团队成员不尊重你或她的平级同事，她为什么还在这里工作？问问她是否想在你的团队工作。如果她说想，就清晰而平静地列出你的期望。如果她说不想，就开始把她调到另一个团队的流程，或者帮她离开公司。

就这样？就这样。你不能让一个不尊重你、或不尊重你团队的人为你工作。随着团队其他人开始怀疑「那个人不尊重你，是不是有道理」，这会侵蚀团队的凝聚力。你越快撕掉创可贴越好。

高级项目管理（Advanced Project Management）

作为工程经理，你将帮助团队制定日程。当更大的组织试图弄清楚季度或年度计划可能是什么样时，你将估算团队能否承担某些项目、这些项目的工作量有多大、是否有合适的人来完成工作。你可能会被问到：团队能否在现有承诺之外再承担旧系统的支持，或者你需要招聘多少人才能支撑一个新举措。组织会期望你既能做脱口而出的粗略估算，也能做更具体的项目规划。

我们在第 3 章关于担任技术负责人的讨论中，给出了项目管理的概要，但现在我想深入一些进阶工作。作为团队经理，虽然你可以把部分项目规划推给技术负责人，但你很可能需要自己做其中一部分工作。你可能必须决定接手哪些项目，以及什么时候拒绝接受项目。你可能会被要求给出工作何时完成的大致估算，即使是那些以敏捷方式规划和迭代的工作。

你需要对团队的节奏（rhythm）和步速（pace）有强烈的感知，才能成功管理工作量；幸运的是，有一些捷径可以提供帮助。

项目管理经验法则（Project Management Rules of Thumb）

以下是一些值得记住的经验法则（rules of thumb）。

这一切都不能取代敏捷项目管理（None of this is a replacement for agile project management）

在开始之前，我想说明白：我不是建议你进入瀑布式（waterfall）模式，从一开始就把每个项目都详细规划。然而，大多数团队既有高层级的长期目标，也有能帮助他们实现这些目标的短期目标。当谈到实际规划更小部分的细节时，团队协作分工、粗略估算工作的敏捷流程，在理顺和组织日常工作上非常有效。作为经理，你不是要打乱、甚至接管执行过程的那个部分。但你要对更大的图景负责——以月而不是周来衡量的成果——而这就是你必须开始施加更高层级规划的地方。

每名工程师每季度只有 10 个高效工程周（You have 10 productive engineering weeks per engineer per quarter）

一年有 52 周，即每季度大约 13 周。然而，现实地说，你的团队会损失大量时间。假期、会议、考核季、生产环境宕机、新员工入职（onboarding）——所有这些都会夺走专注。不要指望每名团队成员每季度能在主要项目上投入超过 10 周的专注努力。很可能第一季度（Q1，冬季假期刚结束）生产力最高，第四季度（Q4，包含冬季和年末假期的季度）生产力最低。

为通用维护性工程工作全面预留 20% 的时间（Budget 20% of time for generic sustaining engineering work across the board）

所谓「通用维护性工程工作」，我指的是测试、调试、清理遗留代码（legacy code）、迁移语言或平台版本，以及其他必须做的工作。如果你养成这个习惯，就可以每个季度处理一些中等规模的遗留代码，获得不错的改进。边做边清理系统，能让这些系统保持易于工作的状态，从而让团队继续推进新功能。在最坏的情况下，你可以用这个缓冲（slack）来平滑功能开发中意想不到的延迟；但如果你把日程 100% 填满功能开发，可以预期功能开发会很快因为这种过度排期而慢下来。

临近截止日期时，说「不」是你的职责（As you approach deadlines, it is your job to say no）

你几乎肯定会有一些截止日期，要么是你自己设定的目标日期，要么是上面压下来的目标日期。实现这些目标的唯一方法，是在项目后期削减范围（scope）。这意味着，作为工程团队负责人，你要与技术负责人和产品负责人/业务代表合作，弄清楚哪些「必备项」（must-have）其实并不是必备项。你必须对两边说不。会有这样的时刻：工程团队说，不做某些其他技术工作就无法实现某个功能，你需要判断什么时候该推动一个临时实现（hack），什么时候该坚持等待正确实现。会有一些产品功能需要相当大的工程复杂度才能实现，你需要与产品团队合作，找出真正的必备项，同时解释达到他们愿景的成本。当事情到了紧要关头，你将是那个给团队提供选项的人：哪些可以现实地实现，或者把所有东西都做完需要多少额外时间。

快速估算使用翻倍法则，但较长的任务要争取规划时间（Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks）

软件估算中流行的翻倍法则（doubling rule）是：「每当被要求给出估算时，把你的猜测翻倍。」当你被要求给出一个脱口而出的猜测时，这条法则适用且好用。然而，当你在谈论你认为需要超过几周的项目时，尽管把估算翻倍，但要说清楚：在你能确定时间尺度之前，你需要一些规划时间。有时较长的任务花费的时间远超你估算的两倍；在让你的团队承诺一个大而未知的项目之前，值得花一些时间更仔细地规划。

谨慎选择交给团队估算的内容（Be selective about what you bring to the team to estimate）

我强调你在估算和规划过程中角色的部分原因是：对工程师来说，有一个不断向他们索要随机项目估算的经理，会让人分心、压力山大。作为经理，你有责任处理不确定性，并限制你向团队暴露多少这种不确定性。不要做工程师与公司其他部门之间的传声筒，来回传话，打扰那些正忙于你已经承诺的重要任务的人。但你也不是一个黑洞。试着建立一个团队级的流程来讨论新功能和客户投诉，并限制在这个流程之外发生的估算。

请教 CTO：加入一个小团队（Ask the CTO: Joining a Small Team）

我是一位新入职的经理，负责一个五名工程师的团队。我以前在其他公司做过经理，但对这家公司、这个技术栈和这个团队都是全新的。在最初几周，我应该如何规划我的时间？

以经理身份加入一个小团队很不容易。从软件工程师晋升为经理时平衡技术工作是一回事，但带着一个新团队要管理、新代码要学习地空降进来，又是另一回事。

有几种方法可以进入代码世界而不惹恼团队。首先，找个人带你过一遍系统和架构，以及测试和发布软件的流程。如果有标准的开发者入职流程——教你如何检出（check out）代码和部署系统——就走一遍那个流程。花一些时间熟悉代码库，并开始看代码评审或拉取请求（pull request），如果它们存在的话。

计划在你入职的头 60 天里至少做几个功能。挑一个已经有规格说明（spec）的功能并实现它。与一位工程师结对（pair）做他正在做的功能，也让他和你结对，当你开始做自己的功能时。让团队中的一名成员评审你的代码。执行一次发布，如果支持（support）是团队职责的一部分，至少轮班支持系统几天。

你大概能看出来，这意味着你的管理入职可能会进行得更慢，因为你同时还要学习如何在系统中工作。这种放慢是值得的。通过了解代码、写代码的流程，以及团队日常使用的工具和系统，你将获得管理团队所需的理解力，以及让他们把你视为有能力领导者的技术可信度。

评估你自己的经验（Assessing Your Own Experience）

• 现在你是团队经理了，你的新职责是什么？为了腾出时间承担这些新职责，你停止了哪些任务，或把哪些任务移交给了别人？
• 你觉得你对团队日常「编写、部署和支持代码」的挑战了解得有多深？
• 你的团队多久把工作标记为完成一次？
• 你上一次写功能、调试问题、或与团队成员结对处理他们正在挣扎的代码，是什么时候？
• 团队中是否有一两个成员造成了大部分负面情绪？你打算如何解决这个问题，继续前进？
• 你的团队成员看起来彼此投入吗？他们在会议上微笑吗？在聊天里开玩笑吗？一起喝咖啡或吃午饭吗？你们上一次一起坐下来不谈工作是什么时候？
• 你的团队如何做决策？你有分配决策责任（decision-making responsibility）的流程吗？哪些决策你让自己负责？
• 你上一次回顾一个已完成的项目、检查它是否实现了目标，是什么时候？
• 你的团队对「为什么做正在做的项目」理解得有多深？
• 你上一次削减项目范围是什么时候？你用什么来确定该砍掉哪些部分？