管理多个团队（Managing Multiple Teams）

欢迎来到多团队管理的世界！我们要在谈论管理经理人之前先谈论管理多个团队，因为虽然这两件事彼此相关，但它们未必重合。你现在很可能已经有技术负责人（tech lead）向你汇报，而在直接管理超过三四个人与了解几个团队正在发生的事情的细节之间来回周旋，可能意味着一个重要的事实：你不再写（多少、甚至任何）生产代码（production code）了。

当我在上一份工作中创建职业阶梯（career ladder）时，工程总监（director of engineering）一职通常是一个人开始管理多个大型团队的位置。让我回顾一下我的工程职业阶梯中的部分描述：

工程总监负责技术团队中一个重要的领域。工程总监通常领导跨多个产品领域或多个技术职能的工程师。技术负责人和独立贡献者（individual contributor）都向他们汇报。

工程总监通常不被期望每天写代码。然而，工程总监负责其组织的整体技术能力，通过培训和招聘，在必要时引导和提升整个团队的技术能力。他们应该有扎实的技术背景，并花一部分时间研究新技术、紧跟科技行业趋势。他们将被期望帮助调试（debug）和分诊（triage）关键系统，并且应该足够了解他们所监管的系统，以便在需要时进行代码评审（code review）和帮助研究问题。他们应该主要通过作为技术上有见地的声音参与架构和设计工作，向团队中的工程师提出产品和业务问题，确保我们编写的代码符合产品和业务需求，并能随着这些需求的增长而适当扩展。

工程总监主要关注确保复杂交付物的顺利执行。为此，他们专注于确保我们持续评估和优化我们的开发/基础设施标准和流程，以创造能为业务带来持续价值的技术。他们负责打造高性能、高速度的组织，随着我们作为一家企业的成长和演变，衡量并迭代流程。他们是组织招聘、人员编制管理和规划、职业发展和培训的领导者。必要时，总监们将管理供应商关系并参与预算流程。

工程总监的影响力应该覆盖技术组织的多个领域。他们负责在组织中培养和壮大下一代领导和管理人才，帮助这些人才学会如何平衡技术领导力与人员领导力和管理。他们痴迷于打造高效运转、投入且积极向上的组织，并被期望对组织内的留任（retention）目标负责。此外，工程总监负责战略性地平衡近期和长期的产品/业务导向工作与技术债务（technical debt）和战略性技术发展。

总监是强有力的领导者，为跨职能协作树立榜样——既包括技术与其他公司领域之间的协作，也包括技术部门内部各分支之间的协作。这种协作的目标是创建一条既战略又战术的技术路线图（tech roadmap），既能应对业务需求、效率和收入，又能推动基础性的技术创新。总监是非常强的沟通者，既能简化技术概念向非技术伙伴解释，也能以一种激励和引导团队的方式向技术团队说明业务方向。工程总监帮助为 Rent the Runway 的技术打造正面的公众形象，并且能够向潜在候选人推销公司和自己的领域。

由于他们广泛接触技术和业务驱动力，总监们负责指导其组织中所有团队的目标设定流程，帮助这些团队阐明既支持业务举措，又支持技术和组织质量的目标。

我特意确保我们明确指出工程总监不一定每天写代码，因为我相信，一个负责亲手管理多个团队的人很难写代码。到了这个阶段，你的日程大概已经从「创作者」（maker）转向了坚定的「经理人」（manager）。在一对一会议（one-on-one）、与其他工程负责人的会议、团队规划会议，以及与产品管理或其他业务职能部门的同行会面之间，你可能已经相当忙碌了。这时要对自己的日程现实一点。如果你没有整块的时间可以投入，而且你无法现实地保证每周至少几天有整块时间，那么你写的任何代码都会进展非常缓慢。

幸运的是，我们有办法保持亲力亲为（hands-on），而不必写大量生产代码。代码评审是保持实践的好方式，至少作为次要评审者。如果你在更亲力亲为的时候创建了一些系统，请继续参与这些系统，因为你会比大多数人更记得细节，你可以帮助在这些系统中工作的工程师进行代码评审和解答问题。调试和生产支持也很有价值。你如何保持亲力亲为取决于你的技能组合。如果你在进入管理层之前就不是一个很强的调试者，跳进事故处理中可能更多是添乱而不是帮忙。你做结对编程（pair programming）、修复小 bug 或小功能可能更有帮助。我们常常贬低这些小努力，认为它们不值得，但它们非常有助于让你保持对软件开发感觉的敏锐，并向你的团队展示你愿意也有能力以有价值的方式参与日常工作。

如果你在进入这个角色之前没有花足够的时间编程，让自己至少对一种编程语言达到深入、流畅的舒适程度，那么放手（hands-off）的风险会被大大放大。我强烈主张你在进入管理层之前花时间掌握编程。对我来说，这花了大约 10 年，包括我的本科和研究生学位。你可能比我做得快，但请在这方面仔细审视自己。你觉得自己对至少一种编程语言足够流利，能够在花有限的时间掌握其基础写法、使用标准开发环境、在标准框架和库中工作之后，为用该语言编写的好代码库做出有成效的贡献吗？最终，即使最深的知识也会萎缩，但在一种语言中工作的流畅度（包括对其标准工具、库和运行时的熟悉）是能伴随你很长时间的东西。

有用的流畅度还需要根深蒂固地理解在这种语言中高效工作意味着什么，最好是与其他构建生产软件的人一起在团队中工作。如果没有这种构建软件节奏的感觉，你会在这一层级工作的一个关键部分上挣扎：调试团队问题，让你的团队平稳地产出优质软件。

最后，即使你不打算写太多代码，我也强烈建议你每周至少保留一个完整的半天，完全不受会议或其他义务的打扰，并尽量把这段时间至少部分用于某种创造性追求。你可以为你的工程博客写博文、准备会议演讲，或参与一个开源（open source）项目。做点什么来满足那种创造的渴望，否则作为经理人你很难满足它。

问问 CTO：我想念写代码！

我管理着两个复杂的团队，我的管理职责迫使我从技术职责中退出来。我发现自己非常想念写代码。这是否表明我不应该当经理？

几乎每个从重度亲力亲为的技术角色进入管理层的人，都会经历一个过渡期，在此期间他们频繁质疑自己是否犯了错。此外，许多人担心自己在这个过程中失去了所有宝贵技能。问问自己，你是否已经内化了「管理不是一份工作」这种想法。科技行业充斥着鄙视管理的人，他们认为管理不如写代码重要。但管理是一份工作，是一份必要且重要的工作，尤其是，它现在就是你的工作。

写代码充满了快速胜利，尤其是对有经验的开发者而言。你让测试通过，你看到新功能上线，你让代码编译成功，你解决一个问题。管理则没有那么多明显的快速胜利，尤其是对新经理而言。怀念更简单的时光是很自然的，那时只有你和你的电脑，你不需要处理所有这些乱七八糟、复杂的人类。你刚开始全职工作时，可能也对校园时光有过类似的怀旧，因为当你离开学校时，你完全知道能从学校期待什么。怀念更简单的时光、对放弃的东西有一点恐惧，这都是可以的。但你不可能一下子做完所有事。成为一名伟大的经理需要你专注于管理的技能，而这需要你放弃一些技术专注。这是一种取舍，你必须自己决定是否准备好做出这种取舍。

管理你的时间：到底什么才重要？（Managing Your Time: What’s Important, Anyway?）

当你的管理职责多到几乎没有时间写代码时，你会开始觉得自己的白天被别人的兴致所绑架。你开始看到会议堆积如山：一对一会议、规划会议、状态更新。站会（standup）。坐会。打打打！

等等，不——作战室里不许打架！

是时候了——就是现在——你要想清楚如何管理你的时间。否则，你会发现日子一天天过去，却没什么成果可言。你仍然有作为经理的责任。你仍然有需要你做的比坐在会议室里更多的事情——比如为团队设定目标、帮助你的产品团队把细节落到产品路线图（product roadmap）上，以及确保分配下去的任务真的完成了。最后一项，跟进任务完成情况，如果你不小心，它可能成为你一天中最大的时间消耗和干扰源。

时间管理是个人的事情。有些人非常有条理，他们会制定复杂的策略来管理日历和待办清单。我为这些人鼓掌。我一般不是其中之一。不过，我发现 David Allen 的书《搞定：无压工作的艺术》（Getting Things Done）[1] 中的想法值得思考，我推荐阅读它，即使你不采用整个流程。

与此同时，我总体的时间管理理念无论你的策略是什么都会对你有用。管理时间归结为一件重要的事：理解重要性（importance）和紧急性（urgency）之间的区别。你的几乎所有任务都会落在由这两个要素构成的坐标图上。大致来说，它们属于四个象限之一（见表 6-1）。

如果一件事既重要又紧急，你就在做它。你知道我说的是什么。有一个重大故障（outage）你在帮忙修复。绩效评估（performance review）的书面材料明天截止。你想给一位优秀候选人发录用通知（offer），而他还有一个竞争性的 offer 两天后到期。如果你在这个类别的事情上掉链子，你会失去实实在在的东西。你不太可能看不到做这类事情的必要性。

时间管理挑战的一大部分出现在你开始失去重要性感知的时候。紧急性往往比重要性更容易被感受到。回复电子邮件就是一个好例子。邮件很容易把你吸进去当作一种干扰，因为红点告诉你有什么新东西，而你觉得确认它很紧急。然而邮件到底有多紧急呢？邮件可能是传达紧急、有时效性信息的最差载体。它感觉紧急，但其实并不紧急。这就是为什么那么多精准的时间管理技巧鼓励在一天中的特定时间阅读和回复邮件。我们还倾向于在判断某件事的价值时，用显而易见（obvious）来替代紧急。如果一个会议在你的日历上，那么在那个时候你应该在哪里是显而易见的，但那个会议真的紧急吗，还是你在用它来回避思考如何最好地利用你的时间？

有很多事情感觉紧急但其实并不紧急。比如整个互联网。新闻、Facebook、Twitter。聊天（chat）可能感觉紧急，但对于同地办公（collocated）的团队来说，聊天在传达真正紧急和重要的信息方面几乎和邮件一样糟糕。在现代科技工作场所，我们已经把大量沟通从邮件转移到了 Slack 和 HipChat 这样的聊天系统里。这有利有弊，但重要的是要认识到，转移沟通不等于消除沟通。话语和信息持续流动，它们只是搬到了不同的地方，而聊天中源源不断的信息细流会让你更加分心。

你很可能把大量时间花在紧急但只有一点点重要的事情上，牺牲了重要但不紧急的事情。一个重要但不紧急的任务的例子是：真正为会议做准备，以便你能以健康的方式引导会议。健康的会议需要所有各方参与，而一种偏好简短但有成效会议的文化，需要参与者做一些前期工作，带着准备来开会。作为多个团队的经理，你可以通过把高效的会议文化向下推行到你的团队来赢回大量时间。让人们对以任何合理方式做准备负责。提前索要议程事项。任何涉及一群人的标准会议，无论是规划会、回顾会（retrospective）还是事后复盘（postmortem），都应该有清晰的流程和预期的结果。

与上一层级相比，这一层级的一个主要变化是，你的老板会期望你足够成熟，能够独立管理自己和你的团队。这意味着你的经理信任你能主动处理所有那些重要但不紧急的事情，在它们变得紧急之前——尤其是变得对你的经理紧急之前。没有人会告诉你如何管理你的日历，为自己留出做这些事的时间。我见过经理在这个节点失败，因为他们就是无法以有条理的方式同时处理所有不同的任务。

会议可能落入紧急但不重要的类别，你可能决定干脆不去参加那些并非明确需要你的会议。在这个管理层级上，要非常小心不要过度使用这一策略。让你的团队顺利前进、快乐投入的责任落在你的肩上。当你不再参加他们所有的内部会议时，你就有错过那些能帮你及早发现问题线索的风险——其中一个主要线索就是存在太多无聊的会议。开会时，环顾房间里的团队，注意他们的投入程度。如果一半人在打瞌睡、发呆、看手机或笔记本电脑而忽略会议进程，或者以其他方式脱离参与，那么这个会议就是在浪费他们的时间。你参加这些会议，部分就是为了关注团队的动态和士气。快乐的团队会感觉精力充沛、投入其中。不快乐或缺乏动力的团队会感觉疲惫或无聊。

回到重要但不紧急的事情。思考未来在这份清单上名列前茅。毫无疑问，有些事情你知道自己应该做但一直拖着。也许是为你正在招聘的职位写职位描述（job description）。也许是从头制定一个招聘计划。也许是审查一个项目的当前工作，确保没有明显的问题悄悄滋生，或者是与另一个团队的管理者谈谈，因为在一个共同问题上如何推进存在冲突或意见分歧。也许是培育那份重要但你已经有一阵子没想过的事情清单，这样你就知道该专注于什么。如果你不留出一些时间专注于这些问题，它们会以消极的方式悄悄找上你。作为多个团队的经理，你负责平衡思维的广度和深度，既要了解今天团队的细节，也要着眼于未来需要走向何方、以及到达那里需要什么。

当你应对新的职责时，开始问自己：我正在做的事情有多重要？它看起来重要是因为它紧急吗？这周我在紧急的事情上花了多少时间？我有没有为自己留出足够的时间去做那些不紧急的事情？

成为经理最难、最短的一课（The Hardest, Shortest Lesson of Becoming a Manager）

作为经理，我脑子里有一份关于团队需求事项的清单。我在监测的事情、我想修复的事情、我想为团队找到的事情。我的工作就是弄清楚正在发生什么，以及整个团队需要什么才能高效运作。

也许你可以看着现状说：「我们现在有一个截止日期，我们需要的是接下来一个月再多一名工程师。那个工程师就是我。」

但更可能的是，你看着现状，意识到你的团队需要的是一个经理。因为你需要再招 X 个人。因为 Y 潜力很大但需要一些辅导（coaching）。因为产品、设计或其他某个团队没有给你需要的东西，所以你需要亲自去争取。因为流程很重要，而你现有的流程不够用，或者干脆就是错的。

如果你的团队需要经理胜过需要工程师，你就必须接受：成为那个经理，意味着你按定义就不可能是那个工程师。我知道有些人两者兼顾，但你需要决定，如果你注定要在其中一个上做得糟糕，那会是哪一个。

当我在做工程师这件事上表现糟糕时，我会难过，但在做经理这件事上表现糟糕，则是我强加给别人的选择。那不公平。

所以，在又一个结束时觉得自己没写够代码、又无法量化自己成就的日子，我告诉自己，我尽己所能做了一个好经理。今天这样就够了。

Cate Huston

决策与委派（Decisions and Delegation）

这些天你在一天结束时感觉如何？如果你像许多新的全职经理一样，你大概感觉相当精疲力竭。即使你一整天没写多少代码——甚至一行都没写！——回到家你也发现自己没有精力决定晚饭吃什么，没有精力做爱好，只想吃点慰藉食物、也许喝杯啤酒，然后呆呆地盯着电脑或电视直到该睡觉。

管理多个团队的头几个月可能感觉像一次死亡行军，即使你的工作时长并不过分。你曾经专注的注意力被各种会议切碎、分割，散落在你的一天中。我在管理多个团队的头几个月里反复失声；我完全不习惯每天说那么多话。我的一个朋友最近成了工程总监，她不得不开始让助理帮她订午餐，因为她发现自己会忘记吃饭——而且当她意识到自己需要食物时，也没有精力决定吃什么。

所以，首先是坏消息：走出这种处境的唯一办法就是挺过去。事实上，我预计大多数人都会经历这样一段时间。如果你完全没有经历过，要么算你极其幸运，要么再检查一下，确保你真的在关注所有需要你关注的事情。以我自己的经验，无论是经历这个转变，还是管理正在经历它的人，如果你一点都没有感到不知所措，你很可能是漏掉了什么。

从现在开始，描述管理感受的最好方式就是转盘子（plate spinning）。如果你不熟悉，转盘子是一种花哨的杂耍形式，杂耍者有几根杆子，每根杆子顶端有一个盘子旋转。杂耍者必须在每个盘子慢到掉下杆子之前去照料它。你的盘子就是你监管的人和项目，你的工作是想清楚每个盘子需要多少关注、在什么时间。重要的是，你要以学生的心态来对待这种旋转。你还在学习如何转盘子，你会把一些盘子掉在地上，因为你忽略它们太久了。磨练你关于何时该碰哪个盘子的直觉，就是这个游戏的名字。

现在说好消息：随着时间的推移你会越来越擅长。你的直觉会改进。你会开始识别项目进展不顺、有人准备离职、团队表现不佳的早期预警信号。我在上一节建议你认真考虑退出会议，部分原因就是，那些会议正是你了解健康和不健康动态是什么样子的地方。这也是为什么我强烈建议你保持与每个直接向你汇报的人定期、可靠的一对一会议。如果你的人太多，你可能需要缩短这些会议，或者改成双周而不是每周，但因为太忙而跳过一对一会议，是错过员工要离职的预警信号的好办法。

我把这一节叫做「决策与委派」——那么委派（delegation）在哪里体现呢？委派是你把自己从「同时有太多盘子在转」的感觉中挣脱出来的主要方式。当任务向你涌来时，问问自己：需要由我来完成这项工作吗？答案可能取决于几个因素（见表 6-2）。

任务的复杂程度和频率可以作为判断是否以及如何委派的指南。

委派简单且频繁的任务（Delegate Simple and Frequent Tasks）

如果任务简单且频繁，找一个你可以移交的人。简单且频繁的任务的例子可能包括：主持每日站会、每周撰写团队进展摘要，或进行次要的代码评审。你的技术负责人或其他资深工程师可以承担这些任务，而且可能甚至不需要培训就能做。

自己处理简单且不频繁的任务（Handle Simple and Infrequent Tasks Yourself）

如果自己做某件事比向别人解释它更快，而且它很少需要做，那就卷起袖子自己做，即使你认为这任务有失身份。这可以是任何事情，从偶尔为你的团队订一张会议门票，到运行生成季度报告的脚本。

把复杂且不频繁的任务用作培养新晋领导者的培训机会（Use Complex and Infrequent Tasks as Training Opportunities for Rising Leaders）

像写绩效评估和制定招聘计划这样的任务是你独有的。然而，这些也是你想传给冉冉升起的经理人的技能。你可以让一位技术负责人坐在你旁边，为一名实习生写绩效评估，或者让一位资深工程师就他认为明年支撑一个项目需要多少新人提供反馈。在这些任务上向上面的人寻求帮助，直到你感到得心应手，但一旦你得心应手，就开始把新晋领导者拉进来，学习这些工作是怎么做的。

委派复杂且频繁的任务来发展你的团队（Delegate Complex and Frequent Tasks to Develop Your Team）

像项目规划、系统设计，或在故障期间担任关键人物这样的任务，是你培养团队人才、同时让团队运转得更好的最大机会。强大的经理会花大量时间在这些领域培养团队成员。你的目标是让你的团队能够在没有你太多输入的情况下高水平运作，这意味着他们需要有人能接手这些复杂任务，并在没有你在场的情况下把它们跑起来。

你的团队是在学习如何独立运作，还是你让他们在对关键职能上依赖你？列出那些只有你真正知道如何为团队做的事情。其中一些可能合理，比如写绩效评估或制定招聘计划，但其中许多是重要教会团队自己完成的。项目管理（project management）。新成员入职引导（onboarding）。与产品团队合作，把产品路线图目标分解为技术交付物。生产支持。这些都是你的团队成员需要学习的技能。教他们可能需要前期时间，但从长远看会为你节省时间。不仅如此，教你的团队做这些事情是你工作的一部分。作为经理，你有责任建设组织内的人才，帮助你的人学习他们在职业生涯下一阶段需要的新技能。

委派是一个起步缓慢、但最终成为职业成长关键要素的过程。如果你的团队没有你在场就无法良好运作，你会发现很难获得晋升。培养你的人才，把决策下放到这些人才手中，这样你就能找到新的、有趣的盘子去学习如何转。

问问 CTO：预警信号（Ask the CTO: Warning Signs）

我已经有几次经历团队出乎意料地陷入困境，有人毫无征兆地辞职。有没有什么我可以留意的预警信号，以便更早发现这些问题？

管理了一段时间之后，你肯定开始注意到一些信号。以下是一些我学会识别的：

• 那个平时健谈、快乐、投入的人，突然开始早退、迟到、工作日中途离开、在会议上保持沉默、不再在聊天里出现。 这个人要么有重大的私人问题，要么正准备辞职。通常，有私人问题（比如亲属生病、感情问题或健康问题）的人会告诉别人，但也不总是如此。如果这发生在一个重大调整（比如晋升、团队重组或其他事件）之后不久，这个人可能觉得自己被忽视了。不管原因是什么，你可能想在她辞职前进行一次诚实的对话，试着找到问题的根源。
• 技术负责人声称一切顺利，但经常跳过你的 一对一会议，而且在他的状态更新中很少提供细节。 这个人可能在隐瞒什么。他经常隐瞒的是，进展比他预期的慢得多，或者他在构建项目范围之外的东西。尽早帮他制定一个清晰的项目计划，并就事情变化时如何调整该计划设定预期，这样他就更难隐瞒缺乏进展。还要帮他澄清项目的目标和范围，这对一些新的技术负责人来说可能令人生畏。你可能在管理那些力不从心的新员工时经历过类似的事。这也与那种花大量时间鼓吹新语言/平台/流程、而不是完成自己工作的人有关。
• 团队在会议上完全没有能量。事实上，会议感觉完全像苦差事，产品经理和技术负责人说所有的话，而团队其他人沉默地坐着，或者只在被点名时才发言。 会议缺乏投入往往意味着团队对工作不投入，或者觉得他们在决策过程中没有发言权。
• 团队的项目清单似乎每周都在变，取决于顾客当天的兴致。 这个团队除了取悦顾客之外没有思考过自己的目标，可能需要更好的产品或业务方向。
• 一个小团队内部在理解上似乎非常割裂；工程师们声称对不归他们做的系统一无所知，并且缺乏好奇心或开放性去了解这些系统。 这个团队更多地以他们的日常工作和他们接触的系统来认同自己，而不是以更大的团队或公司。他们可能抗拒根据更大团队或业务的需要来改变自己的系统。

棘手情境：说「不」的策略（Challenging Situations: Strategies for Saying No）

经理的工作包括创造能让工作发生的肥沃环境，让她的员工容易把事情做成。她让团队专注，这样他们就能做自己最擅长的事。她在团队中培养同志情谊和友谊，帮助人们学习新技能。在所有这一切中，她是一个赋能者（enabler）、一个教练（coach）、一个拥护者（champion）。

但要创造这种环境，她有时必须说不。她必须对团队说不。她必须对同事说不。她甚至必须对老板说不。这些「不」每一个都以自己的方式很难，而一个强大的经理必须发展出有效的说「不」策略。以下是我总结的几个。

「是的，而且」（“Yes, and”）

当你是一个经理时，对你的老板说「不」很少表现为一个简单的「不」。相反，它看起来像是即兴喜剧中的「是的，而且」（yes, and）技巧。「是的，我们可以做那个项目，而我们所需要做的就是把目前路线图上的另一个项目的启动推迟。」以积极的态度回应，同时仍然阐明现实的边界，会让你进入高级领导层的顶级行列。这种积极的「不」对大多数工程师来说是相当难掌握的技能。我们习惯于阐明项目的弊端，而要摆脱「不，那不可能」的条件反射习惯很难。开始掌握用「是的，而且」策略来说「不」，尤其是在与老板和同事互动时，看看它如何常常把激烈的争执变成关于优先级的现实谈判。

制定政策（Create Policies）

说到你的团队，你想帮助他们理解达成「是」需要什么代价。也许你在处理一位工程师想为一个项目改用一种你们团队不用的新编程语言的问题。他有一些很好的论据说明为什么这种语言是这个工作的完美工具，但你不愿意仅仅因为它完美就添加一个新工具。你可能想干脆说不、给出理由、然后了事，有时这样确实管用。但你可能发现自己一遍又一遍地说着同一个「不」，给出同样的理由。「不，我们需要有更多人懂那种语言；我们需要理解把那种语言投入生产意味着什么。」「不，我们需要有日志记录的标准；我们需要考虑测试会是什么样子。」当你开始重复自己时，你就有了制定一条合理政策的依据。那条政策包含为了说「是」必须满足的硬性要求，以及一些用于思考该决定的指导原则。制定政策能帮助你的团队提前知道达成「是」的代价。

「帮我说「是」」（“Help Me Say Yes”）

政策是有用的，但它们不能覆盖所有情况。下一个策略，「帮我说「是」」（help me say yes），类似于制定政策，但更适合那些没有明确政策的偶发情况。有时你会听到一些看起来非常欠考虑的想法。「帮我说「是」」意味着你就那些让你觉得非常可疑的要素提问、深挖。通常，这种追问会帮助人们自己意识到他们的计划不是个好主意，但有时他们会用他们的思路让你惊讶。无论哪种方式，对想法进行好奇的盘问都能帮你同时做到说不和教学。

诉诸预算（Appeal to Budget）

当涉及到你的团队和你的同事时，你可以使用的一个策略是诉诸时间和预算。用直白的话摆出当前的工作量，展示几乎没有回旋余地。有时这与「现在不行」（not right now）相结合，这是另一种有点被动攻击性的说不方式。「现在不行」暗示你可能同意这个想法，但此刻无法做，所以也许你将来会做。这通常是事实，所以很容易陷入「现在不行」模式。但正如我之前讨论的，当你给出一个隐含的承诺，即「现在不行」意味着你将来会认真做某事，你需要确保「将来」真的能发生。

团队协作（Work as a Team）

说到你的同事，会有一些时候，你和你的同事（尤其是跨职能的——即你的产品或业务同事）需要共同行动来说不。这可以适用于任何层面的「不」。有时你会用你的技术权威以一种对产品团队有益的方式说不。有时你会诉诸财务部门，请他们帮你说不，拒绝某些预算超支。唱红脸/白脸可能有点不诚实，所以要谨慎使用，但把你的权威借给一个「不」、然后在你将来需要支持自己的「不」时讨回这个人情，可能是有用的。

不要含糊拖延（Don’t Prevaricate）

当你知道你需要说不时，尽快说比拖延和拖长过程更好。如果你有说不的权力，而且你不相信某件事应该发生，帮自己一个忙，不要在过程中痛苦纠结。你有时会错，所以当你发现自己说不说得太快时，为那个错误道歉。你不会有奢侈的时间去仔细调查和分析每一个决定，所以要练习对低风险、低影响的决定坦然接受快速说不（以及快速说「是」！）。

问问 CTO：我的技术负责人没有在管理（Ask the CTO: My Tech Lead Isn’t Managing）

我有一个技术负责人，他本该在我们的一个把应用从 Objective-C 重写为 Swift 的项目上监管我们的一位初级工程师。我刚发现那位初级工程师还没有创建项目计划，也没有回应我在设计评审中给出的任何反馈。我怎样才能让技术负责人去管理这件事，而不需要我亲自介入？

委派失败时有发生。听起来你的技术负责人没有理解，你是在让她为「确保初级工程师跟进设计反馈并创建项目计划」负责。所以第一步是问技术负责人为什么这些事情还没有发生。

你得到的答案很可能是几种情况的组合。第一，技术负责人忙于自己的工作，忘记跟进初级工程师。这会发生，你必须提醒她，指导和监管这个人的工作需要与她的编码和其他职责一起安排进日程。

第二，技术负责人可能不知道当初级工程师不愿意承诺进度表时该如何推动他。问问她尝试过用什么方式从他那里获取信息，看看你是否有机会建议不同的方法。有时新的技术负责人不愿意为了项目计划去推动别人，因为他们觉得自己没有权威，而且当他们要求某件事而对方就是迟迟不交付时，他们会手足无措。

这里最好的做法是和你的技术负责人一起工作，给她技能和信心，让她去向团队其他成员索要报告。这比你自己介入去要更慢，但你会教会团队尊重她的要求，也会教会她如何独立领导团队。

超越代码的技术要素（Technical Elements Beyond Code）

这个层级的管理会变得令人困惑。我们招聘经理部分基于他们的技术技能，但我们许多人认为这份工作并不真正「技术性」。毕竟，经理大概不会写太多代码或做太多系统设计，对吧？

假设这个层级的工作基本上变得非技术性是一个错误。事实证明，运营高效的工程团队需要的不只是纯粹的管理技能，而且这个层级的管理将要求你学习一些新技能，这些技能如果你理解软件工程的实践和纪律，就最容易学会。你现在要把你的技术焦点转向观察和改进你的开发者们在其间运作的「工作系统」。尤其是，你现在需要培养对整体团队技术健康信号的眼光。但这些健康信号是什么？

广受欢迎的管理书《首先，打破一切常规》（First, Break All the Rules）[2] 讨论了几个你可以回答的问题，帮助预测团队的生产力和满意度。其中包括：

• 我知道工作中对我的期望是什么吗？
• 我有做好工作所需的材料和设备吗？
• 我有机会每天都做自己最擅长的事吗？

对大多数工程师来说，这些问题的答案可以通过他们推送代码的速度和频率来辨别。如果他们需要做的工作是清晰的，他们就知道该写什么代码。如果工具、工单（ticket）、自动化和流程都在且易于使用，他们就能把代码写出来。如果他们不被过多的会议分心，也没有淹没在支持和事故管理中，他们就有机会每天写代码。这些健康信号——代码发布频率、代码提交频率、事故的低频率——是一个团队知道该做什么、有工具去做、并且每天有时间去做的关键指标。

衡量你的开发团队的健康状况（Measuring the Health of Your Development Team）

当你专注于开发团队的健康时，戴上你的技术帽子，设计能让事情保持运转的系统和流程。创建开发者完成工作所需的工具。让他们专注，让他们能轻松弄清楚下一步需要做什么。审视每一个流程，确定它应该提供的价值，并总是问自己它能否被进一步自动化。考虑以下这些衡量团队健康状况的方法。

发布频率（Frequency of Releases）

在第 5 章中我谈到过，技术团队的一个常见功能障碍是不交付代码，而发布频率是衡量这一点最直接的指标。如果你的公司不看重频繁发布代码的价值，我很遗憾。在这个现代时代，代码变更频率是健康工程团队的主要领先指标之一。产品导向团队的优秀工程经理知道如何创造让团队快速前进的环境，而快速前进的一部分就是把工作拆成小块。即使你的公司不看重这一点，你也必须努力帮助你的团队为他们的产品实现尽可能好的发布频率。以免你认为这不适用于你，因为你正在构建一个无法频繁发布的产品（比如数据库），我确信会有一个完整的工件（artifact）被推送到测试环境（beta/开发者测试环境），它能以频率和稳定性提供同样有价值的衡量。

你为什么不能更频繁地发布？看看你的团队。如果他们不是持续发布或每日发布，发布流程是什么样的？需要多长时间？过去几个月里发布出过多少次问题？出问题的时候是什么样？你有多少次不得不因为问题而延迟或回滚（roll back）发布？那些延迟或回滚的影响是什么？你如何判断代码是否可以投入生产？这需要多长时间？主要由谁负责判断？

我敢打赌，如果你诚实地审视一个不频繁发布的团队，你会看到裂缝。执行发布的过程耗时很长。工程师不觉得对自己的代码质量有所有权，他们把所有这些工作留给质量保证（QA）团队，这造成了很多来回沟通的延迟。在糟糕的发布情况下回滚代码需要很长时间。发布过程中出错会导致生产环境事故（或开发构建损坏）。一个团队的许多弊病都源于无法频繁发布。

现在，你可能会说：「谢谢建议，但我要交付产品路线图，没时间做这个。」或者：「我们的系统不是为频繁发布而设计的。」或者：「频繁改动并没有那么重要。」

问题是这样的。你的团队是否在满负荷工作？你的工程师是否受到挑战并不断成长？你的产品团队是否为我们取得的进展感到兴奋？人们是否能把大部分时间花在编写新代码和发展系统上？如果是，那太好了。忽略我。你已经掌控了局面。如果不是，你就有问题，而你无视这个问题是在自担风险。

重要的是要记住，作为技术领导者，虽然你可能不太写代码，但你仍然对完成工作的技术方面负责。你还负责让你的团队保持快乐和高效，而解决这个问题的办法往往不是加油打气、给他们更多报酬或更多表扬，而是让他们能够更高效，挑战他们更快、做更好的工作，并帮助他们找到让工作更有趣所需的时间。你必须成为倡导者，推动能提高工程师生产力的技术流程改进，即使不是全部由你自己实施。

推动更频繁发布的美妙之处在于，它常常会揭示出一大堆有趣的挑战。提高发布频率没有唯一正确的方法，因为频率问题会因团队而异，各有不同。你几乎肯定需要解决一些自动化要素。为你的代码库启用有意义的功能开关（feature toggle）的开发者工具是另一个常见挑战。思考如何在不破坏向后兼容（backward compatibility）的情况下推进架构演进代码、系统的滚动升级（rolling upgrade）、以及实施小改动而不是巨型补丁——所有这些都可能需要处理。你负责领导这里的努力，即使你不做那些工作。争取从产品路线图中抽出时间支持提高工程生产力，并为团队设定激励他们更快前进的目标。

代码提交频率（Frequency of Code Check-ins）

很难有一个敏捷（agile）团队却不理解把工作拆成小块的价值。你可能需要把这个技能教给刚毕业的新员工，但即使是资深开发者有时也需要在这方面被推一把。我不打算鼓吹任何特定的软件开发方法论，但我发现不写测试的工程师往往更难拆解他们的工作，而学习如何做测试驱动开发（test-driven development，即使他们实际上不每天实践）能帮助他们在这项技能上变得更好。

我关注这个话题，是因为作为新经理，告诉那些写代码时间可能和你一样长甚至更长的人他们的风格需要更新，会让你非常不舒服。我们大多数人都有很深的回避冲突倾向，而那些感觉像是个人风格的问题尤其难处理。如果你的公司期望快速的产品开发，那些想消失几周独自写代码、不推送到共享版本控制（version control）的工程师会拖慢你的团队并造成问题。你管理的不是一个研究团队。（是吗？那就跳过这一节！）你完全可以期望进行中的工作（work in progress）被定期更新。

事故频率（Frequency of Incidents）

团队生产的软件有多稳定？质量是在提高、变差还是保持不变？确定你正在构建的产品所需的软件质量水平，并随时间调整这个衡量标准，是一个需要你——经理——帮助解决的技术挑战。如果你在为一家小而成长中的企业构建一个全新产品，专注于功能可能比稳定性更重要。另一方面，如果你拥有关键任务（mission-critical）系统，稳定性和事故最小化可能是你的首要任务。这里的目标是以这样一种方式平衡风险：既不让事故频率、也不让事故预防变成一份让开发者一连几天无法写代码的工作。

你可能在一家让开发者支持他们自己写的代码或系统的公司工作。这个过程有一些缺点；最重要的是，期望团队成员频繁在夜间和周末值班（on-call）是倦怠（burnout）的一个巨大促成因素。尽管有这种风险，它也有好处：把最能帮助解决问题的人放在响应问题的位置上。作为经理，你现在可能很想把自己从这个角色中摘出来。我理解，但如果你的团队被设置为做自己的事故管理，你应该把自己移入升级支持（escalation support）的角色。你不一定会那么频繁地管理事故，但你会被期望更频繁地保持可用，以防支持系统的人需要你。

围绕事故管理的分析应该包括这个问题：「我们当前的设置是否在让我的团队每天做他们最擅长的事？」事故管理，当它变成仅仅是对事故做出反应而不是努力减少事故时，会变成一项削弱你的团队做自己最擅长事情的能力的任务。工程师去值班，他们被处理大量问题弄得精疲力竭、心力交瘁，除了修复事故后果什么也没做成，然后他们把工作交给轮换（rotation）中的下一个倒霉鬼。如果这就是你的团队处理事故管理和值班的方式，你的团队就无法每天做他们最擅长的事，而且每次去值班，他们大概都会更恨自己的工作一点。在这种情况下，作为领导者，你大概想专注于提供时间真正设计更稳定的系统，或编写代码修复反复出现的事故。

过度强调事故预防也会削弱你的团队每天做他们最擅长事情的能力。过度专注于构建没有缺陷的系统，或者通过放慢开发流程来推动错误预防，往往几乎和行动太快、发布不稳定代码一样糟糕。当降低风险变成数周的繁琐人工 QA、过度且缓慢的代码评审、不频繁的发布，或一个拖沓的规划过程时，增加的审查可能让开发者无所事事、焦躁不安，而不一定降低事故风险。

好经理，坏经理：我们vs他们，团队合作者（Good Manager, Bad Manager: Us Versus Them, Team Player）

Diana 刚刚加入一家中型创业公司，负责运营长期被忽视的移动团队。她入职时被告知这个团队一团糟，所以她的第一步是迅速招进来一大批在 BigCo 为她工作过的人。他们不太符合文化，团队很快变成了一群自认为比组织里其他人都强的开发者小圈子。虽然技术改善了，但他们似乎和产品团队冲突不断，最终应用并没有快速演进。一年后，Diana 对公司感到厌烦，辞职了。她新团队的其他成员很快也纷纷离开，公司又回到了原点。

对新经理来说，创造共享的团队认同可能很难。他们中的许多人默认围绕自己职能或技术的具体细节来构建认同。他们通过强调这种认同与其他团队相比有多特别来团结团队。当他们做得过火时，这种认同被用来让团队感觉比公司其他部分优越，而团队更关心自己的优越性而不是公司的目标。以这种方式凝聚团队是一种浅层绑定（shallow binding），容易受到许多功能障碍的影响：

• 在领导者离开时脆弱。 小圈子（in-group）团队往往在失去领导者时非常脆弱。当你雇用一个建立小圈子的经理时，如果这位经理离开公司，那个小圈子很可能会解散并离开公司。这个问题让解决经理一开始建立小圈子所造成的问题变得更加困难。
• 抗拒外部想法。 小圈子往往抗拒不是来自群体内部的想法。这意味着他们错失了学习和成长的机会。团队成员缺乏成长，往往导致团队中最优秀的成员不仅离开群体，而且离开公司。因为他们相信自己身处最好的群体，却仍然感到无聊，所以他们不珍惜仅仅通过换到新团队就能获得的成长。
• 帝国建设。 偏爱我们vs他们风格的领导者往往是帝国建设者，他们寻找机会扩大自己的团队和职权范围，而不关心什么对整体组织最有利。这常常导致与其他领导者争夺人员编制和项目控制权。
• 缺乏灵活性。 这些群体往往抗拒来自群体外部的变化。重组、取消的项目、焦点的转移，都可能打破他们认同的核心部分。无论是从职能团队转向跨职能团队、推迟 iPad 应用，还是优先考虑一个新产品，变化都可能摧毁团队与公司之间脆弱的纽带。

作为经理，要小心不要只关注自己的团队而排斥更广泛的群体。即使你是被雇来修复一个团队的，也要记住，公司能走到今天，是因为一些根本性的优势。在试图把一切都改成符合你的愿景之前，花时间理解公司的优势和文化，思考你将如何创建一个与这种文化良好配合——而不是与之对抗——的团队。诀窍不是专注于坏掉了什么，而是识别现有的优势并培育它们。

Neil 也加入了一家事情一团糟的创业公司。虽然他看得出自己需要改变团队，但他谨慎地处理解雇事宜，并花时间确保新员工总是由在公司待了一段时间的人把关。他花大量时间与产品部门的同事密切合作，并提出了一条强调跨职能协作的前进道路。他专注于设定清晰的目标并传达给他的团队。开始时进展缓慢，但随着时间的推移，整个组织感觉更强大，技术和产品都得到了显著改善。

持久的团队建立在来自公司本身的共享目标之上，他们与公司的价值观保持一致（更多关于这个话题的内容见第 9 章的「应用核心价值观」）。他们对公司的使命有清晰的理解，并且能看到自己的团队如何融入这个使命。他们能看到使命需要许多不同类型的团队，但所有团队都共享一套价值观。通过在团队、团队成员和整个公司之间建立强烈而持久的对齐，这种基于目标的绑定（purpose-based binding）让团队：

• 对个人离开有韧性。 小圈子很脆弱，尤其是对领导者的离开，而目标驱动的团队往往对个人和领导层的离开非常有韧性。因为他们忠诚于更大组织的使命，即使经历损失，他们也能看到前进的道路。
• 被驱使着寻找实现目标的更好方式。 目标驱动的团队对新想法和能帮助他们更好地服务目标的价值观变化更加开放。他们不太在乎一个想法来自哪里，而在乎它在实现目标上的价值。这些团队的成员有兴趣向职能之外的人学习，并积极寻找更广泛协作的机会以创造最好的结果。
• 以第一团队为重。 作为强大团队合作者的领导者明白，向他们汇报的人不是他们的第一团队。相反，他们的第一团队是公司里他们的同事。这种第一团队导向帮助他们在决策时先考虑整个公司的需求，再专注于自己团队的需求。
• 对服务于目标的变革持开放态度。 协作型领导者明白，变革会发生以服务于更广泛的目标。团队结构会改变，人们需要转移到业务需要的地方。带着这种认知，这些领导者创建的团队更灵活，更能理解服务于更大愿景的频繁变化。

弄清楚你的团队和公司的目标可能需要时间。尤其是在创业公司，当前目标甚至有时是底层使命常常存在一些混乱。在目标模糊、使命不清的情况下，尽你最大努力理解公司文化，思考如何让你的团队在该文化中良好运作。通过跨团队、跨业务职能的协作，你的团队会逐渐理解更大的图景，并把自己团队的使命看作这幅图景的一部分。

懒惰与不耐烦的美德（The Virtues of Laziness and Impatience）

我喜欢 Larry Wall 在《Programming Perl》[3] 中阐述的观点：工程师的美德是「懒惰、不耐烦和傲慢」（laziness, impatience, and hubris）。这些美德延续到领导力中，学会如何把这些特质转化为优势，是我鼓励所有经理去做的事。

作为经理，当你一对一地与人打交道时，你当然不想不耐烦。不耐烦如果指向个人可能会很粗鲁。你也不想显得懒惰，因为没有什么比为一个看起来轻轻松松、而你拼命交付项目的经理工作更糟糕的了。但不耐烦配上懒惰，当它们指向流程和决策时就很棒。把不耐烦和懒惰应用于流程，是值得专注的关键要素。

当你更多地进入领导岗位时，人们会向你寻求行为上的指引。你想教给他们的是如何专注。为此，有两个领域我鼓励你现在就练习以身作则：弄清楚什么重要，以及回家。

我受不了看着人们浪费精力用蛮力处理问题，花时间而不是花心思。然而，任何鼓励你一直超时工作的文化，几乎肯定正是在做这件事。如果你不用自动化来让你的工作更轻松，那自动化的价值何在？我们工程师自动化，是为了能专注于有趣的事情——而有趣的事情是那些用你大部分大脑的工作，它通常不是那种你能一天又一天、一小时又一小时连续做的事情。

所以，要对找出重要的核心不耐烦。作为领导者，任何时候你看到某件事做起来感觉低效，就质疑它：为什么这让我感觉低效？我们在做的事情的价值是什么？我们能更快地交付那个价值吗？我们能不能把这个项目简化成更简单的东西，更快地完成它？

这种追问的问题在于，当经理问某件事能否做得更快时，他们明确或隐含想知道的常常是团队能否更努力地工作或工作更长时间，以用更少的天数交付。这就是为什么我鼓励你培养并展示懒惰的价值。因为「更快」不是「同样的工时但总天数更少」。「更快」是「用更少的总时间给公司带来同样的价值」。如果团队一周工作 60 小时交付了否则需要一个半星期才能交付的东西，他们并没有更快地工作，他们只是把更多自由时间送给了公司。

这就是「回家」发挥作用的地方。回家吧！不要再在深夜和周末的所有时段给人发邮件了！强迫自己抽离对你的心理健康至关重要，相信我。倦怠是当今美国劳动力中的一个真实问题，我认识的几乎所有持续超时工作的人都在某种程度上经历过它。它对个人很糟糕，对他们的家庭很糟糕，对团队也很糟糕。但这不只是关于防止你自己的倦怠——这是关于防止你的团队的倦怠。当你比所有人都工作得晚，当你在所有时段发送那些邮件，即使你并不期望你的团队回复那些邮件或按那些时间工作，他们看到你这样做，就会认为这很重要。而这种过度工作让他们效率更低，尤其是在工程师需要执行的精细知识工作上。

当你是个比较新的经理，还没想出高效完成工作的窍门时，你可能会发现自己需要工作更长时间才能把所有事做完。短时间内这样是可以的。但我鼓励你找到一种方式，在不鼓励你的团队也这样做、或不让他们觉得有义务跟着你的日程走的情况下，去工作那些时间。把周末和深夜的邮件排队到下一个工作日发送。在非工作时间把你的聊天状态设为「离开」。去度假，度假期间不回邮件。并不断问自己你问团队的同样的问题：我能更快地做这件事吗？我到底需不需要做这件事？我通过这项工作提供什么价值？

懒惰和不耐烦。我们专注，是为了能回家；我们鼓励回家，是因为它迫使我们持续专注。这就是伟大团队得以规模化的方式。

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

• 你上一次审查自己的日程、找出那些你在做但对你自己或你的团队没有提供太多价值的事情，是什么时候？回顾过去几周。展望未来几周。你完成了什么，你希望完成什么？
• 如果你还在写代码，这与你的其余日程如何协调？你是在下班后写吗？是什么驱使你继续投入这些时间？
• 你上一次委派给你其中一个团队成员的任务是什么？它是简单还是复杂？被你委派的人处理新任务的情况如何？
• 谁是你团队中新晋的领导者？你计划如何辅导他们承担更大的领导角色？你给他们什么任务来为更大的责任做准备？
• 编写、发布和支持代码的流程在你的团队中是否运转顺畅？这个流程的一部分上一次出现明显事故是什么时候？发生了什么，团队如何应对？这个流程多久会遇到一次这种异常情况？
• 你上一次推动你的团队削减项目范围是什么时候？削减范围时，你削减的是功能、技术质量，还是两者？你如何决定？
• 你上一次在晚上 8 点之后或周末发邮件是什么时候？你发邮件的那个人回复了吗？你需要他或她回复吗？

[1] David Allen，《搞定：无压工作的艺术》（Getting Things Done: The Art of Stress-Free Productivity）（纽约：企鹅出版社，2001）。

[2] Marcus Buckingham 和 Curt Coffman，《首先，打破一切常规》（First, Break All the Rules: What the World’s Greatest Managers Do Differently）（纽约：西蒙与舒斯特出版社，1999）。

[3] Tom Christiansen、brian d foy、Larry Wall 和 Jon Orwant，《Programming Perl》第 4 版（加利福尼亚州塞瓦斯托波尔：O’Reilly，2012）。