管理管理者（Managing Managers）

管理管理者的工作期望与管理多个团队的期望并没有太大不同。你要对多个团队负责，监督这些团队的健康状况，并帮助他们设定目标。区别在于规模（magnitude）的大小。这些团队的覆盖范围扩大了，项目和人员的数量多到你不可能单靠自己应付。你管理的不再只是几个密切相关的团队，而可能是一大片努力成果。你可能会管理你所在部门中以前从未管理过、也没有太多专业经验的职能——例如，一位软件工程经理如今还要管理一个部门的运维团队（operations teams）。

管理多个团队已经够累人、够令人生畏的了，而管理管理者又增加了一整个全新的复杂层面，这常常出人意料。想想我曾经发给我的领导力教练（leadership coach）的这封邮件：

管理管理者，我该怎么做才能不让它占掉我所有的时间？我应该建立什么样的流程，才能从他们那里获得适当的沟通，并让自己得以规模化（scale）？你要如何帮助解决那些你并不在场、无法亲眼看到的问题，何况目击者还不可靠？我把所有时间都花在了深入两级的人员问题上，真是精疲力竭。

答案比你以前更难触手可及。现在，事情被额外的一层抽象（abstraction）所遮蔽，你很容易错过细节，因为你不再与每个团队中的每一位开发人员保持定期接触。

这是一个艰难的成长节点。你将被拉向许多方向，弄清楚究竟该如何分配你的时间、以最大化你在各个团队之间的杠杆作用（leverage），将是至关重要的。为了做好这件事，你需要练习磨练自己的直觉（instincts），而这种练习要求你跟进那些你并不确定是否真的重要、但你只是感觉不对劲的事情。

以管理一个在你技能范围之外做事的团队为例。诱人的做法是让他们自行运转，只在出现问题时才介入。然而，作为这个角色的新手，你很可能直到问题发展到无可挽回的地步才发现它们。你还没有建立起那种纪律或直觉，让自己本能地感知该在何时、何处深入介入，所以你需要更频繁地深入介入，即使在一切看似顺利的时候也是如此。

在这个层级工作，你会对自己的优势和劣势有一个全新的认识。那些善于管理单个团队、甚至几个相关团队的人，在被要求管理管理者、或管理自己技能范围之外的团队时，往往会崩溃。他们无法平衡新角色中固有的种种模糊性（ambiguities），于是退回到自己觉得容易的事情上。有时这表现为退回到花太多时间扮演独立贡献者（individual contributor）；有时则表现为一个人扮演项目经理（project manager），而不是训练他的管理者们自己去承担那份工作。

有些人凭借运气和一些技能，没费太多力气就达到了这个层级。但这是一场全新的游戏，它需要的纪律水平与直接管理一个团队完全不同。我之前谈过要让自己不舒服，但在这里，你需要找到你的不适之处，追着它跑，然后目不转睛地与它共处一段时间。在这里，你需要跟进所有的小事，直到你弄清楚哪些事是你不需要跟进的。招聘（recruiting）在进行吗？你的管理者们是否在辅导（coaching）他们的团队？每个人是否都写好了本季度的目标？你是否审阅过它们？那个本该收尾的项目进展如何？前几天发生的那起生产事故（production incident）——事后复盘（postmortem）做了吗？你读报告了吗？

人们很容易接受这个职位，并假设它只是以前工作的更多延续，但这是个错误。这个职位是一场大得多的游戏的第一级，是进入高级领导层（senior leadership）和高层管理（upper management）的门槛，它将需要大量新的技能。

在本章中，我们将讨论成功监督整个部门的一些关键，包括：

如何从你的越级下属（skip-level reports）那里获取信息
让你的管理者们负起责任（accountable）意味着什么
管理新任和资深管理者
招聘新的管理者
找出组织机能失调（organizational dysfunction）的根源
培育你团队的技术战略（technical strategy）

问问 CTO：敞开门政策的谬误（The Fallacy of the Open-Door Policy）

我告诉我的团队，我实行敞开门政策（open-door policy）。他们可以随时来找我讨论问题。我甚至尝试设立办公时间（office hours）让他们预约！然而他们却不来，我不断发现一些没有人向我反映的问题。为什么我的团队不在这方面帮我一把？

管理者必须牢记的一件事是，他们的部分工作就是主动挖掘问题。有一种观点认为，如果你让自己保持可接近（accessible），设立任何人都能约见你的办公时间，并告诉团队你随时都在，人们就会自然而然地把问题带到你的办公室来。没有必要主动去找问题，因为你的团队足够信任你，出了事会来找你。

然而，这基本上永远不会发生。敞开门政策在理论上很好，但一个工程师得有极大的勇气，才愿意冒险去找她的老板（尤其是老板的老板，等等）告诉他问题。这甚至还假设了工程师足够清楚问题到底是什么、能够解释清楚！即使在你亲手打造、拥有高度信任和尊重的团队里，有些问题也永远不会升级（escalate）到你这里。其中一些问题会导致人员离职、项目延期、故障爆发。你一转身，下一个瞬间，一个看似好好的团队就崩塌了。

你离一个团队越远，依赖敞开门政策的风险就越大。这种风险的顶峰，就是那种最经典、最迟钝的高管做派：依赖办公时间，而不是与团队一对一（one-on-one）地直接开会，然后纳闷为什么优秀的经理团队没能留住优秀人才、也没能办成事。有些人非常擅长向上管理（managing up），擅长把组织中的问题藏起来，如果你从不花时间去看，你永远不会发现这些问题。

当你管理管理者时，你最终会根据他们团队的表现来评估他们。如果团队表现不佳，那怎么办？预判问题是你工作的一部分，所以被一个分崩离析、人员大量流失（attrition）、或未能按时交付重大项目（ship a major project）的团队打个措手不及，反映出你作为更高层管理者的失职。这些问题拖得越久，修复的代价就越高，而且它们不会自己送上门来。

所以，这部分工作就是确保你的一对一会议（1-1s）为真正的对话留出空间，而不是一套脚本或一串待办事项，正如我之前提到的。但除此之外，你必须腾出时间，主动与向你直接下属汇报的人举行越级会议（skip-level meetings）。

越级会议（Skip-Level Meetings）

越级会议是在隔层管理（managing at levels of remove）中取得成功的关键之一。然而许多人跳过或低估了它们。我知道，我也经历过。没有人愿意往自己的日历上再添加更多会议，尤其是那种常常没有议程的会议。尽管如此，如果你想打造一支强大的管理团队，了解那些向你的管理者们汇报的人，并与他们保持关系，是难以回避的。

什么是越级会议？简言之，就是与那些向你下属汇报的人开的会。人们举行这类会议的方式有几种，但它们的目的是帮助你了解团队的健康状况和聚焦点。无论你选择如何举行，都要牢记这个目的。

越级会议的一种形式是简短的一对一会议，也许每季度一次，由组织负责人与该组织中的每个人进行。这种策略能达成几件事。它在你与你组织中的每个人之间建立起至少是表面上的个人关系，使你不会把他们视为「资源」而不是人（这是管理大型组织时的一种风险）。它也给这些人一个机会，向你提出那些他们觉得不值得自己专门约一次会来问的问题。当你为潜在的话题提供提示（prompts），并提醒对方这次会议主要是为了他或她的利益时，这类会议最为成功。每个人都应该带着他或她有兴趣与你交谈的内容前来做好准备。

一些建议的提示，供你提供给举行越级一对一会议的对象：

关于你正在做的项目，你最喜欢/最不喜欢什么？
你团队里最近谁表现特别好？
你对你的管理者有什么反馈——哪些做得好，哪些不好？
你认为我们可以对产品做出哪些改变？
你认为我们可能错过了哪些机会？
你觉得整个组织整体上表现如何？有什么我们可以做得更好/更多/更少的？
业务战略（business strategy）中有没有你不理解的领域？
现在是什么在阻碍你做出最好的工作？
你在公司工作有多开心（或不开心）？
我们可以做些什么，让在公司工作变得更有趣？

一对一会议不能永远扩展。如果一个季度有，比如说，60 个工作日，而你的组织有 60 个人，那么每季度与每个人开一次会，就意味着你每天要开一次，也就是 12 周里每周五次。你组织里的人越多，情况就越糟，到了某个程度它就不再合理了——如果有 1,000 个人，假设你每周工作 40 小时，你就什么也别干，光开这些一对一会议了。不过，如果你的组织较小，每个季度为每个人留出时间确实有一些好处。

如果你的组织较大，或者你对往日程里加更多无结构的一对一会议这个想法感到不耐烦，还有其他获得越级时间的方式。我曾经与整个团队举行越级午餐（skip-level lunches），我请全组人吃午饭，然后我们聊任何正在进行的事情。我尽量每季度为每个团队安排几次。就让你与团队成员彼此更熟悉而言，这有许多一对一会议的好处。它无法让你专注于给个人做职业辅导（career coaching），但它确实帮助你感知群体动态（group dynamics），并直接从团队获得反馈。

当然，人们在群体情境中的表现会不一样，当你是大老板（Big Boss）时，他们可能不好意思当着别人的面抱怨他们与管理者的那些问题，即使这个人不在场。我的许多午餐不过就是关于各种技术问题的闲聊，但我能感知到团队认为他们的聚焦点应该放在哪里，而且我能回答一些关于公司战略重点、其他领域正在做的工作、或他们有兴趣了解细节的即将到来的项目的具体问题。

在群体环境中，这些问题可以用来引出信息：

我，你管理者的管理者，能为你或你的团队提供什么？有什么我应该帮忙的吗？
从你的角度看，这个团队是否与其他团队合作不佳？
关于更大的组织，有什么我可以回答的问题吗？

对我来说，越级午餐提供了熟悉感，这反过来又让人们更愿意来参加我的办公时间，并在那里谈论更敏感的一对一话题，无论是他们主动要求的，还是偶尔我提出的。

这个越级流程的目的，除了维持信任和参与度之外，是帮助你发现那些你被「向上管理」得很好、却以该管理者手下的团队受损为代价的地方。你的组织里有擅长向上管理的人，总是一个很难察觉和应对的情况。这些人最先找到你，所以你最先听到他们的视角，你注定会认为他们是对的，并支持他们的决定。越级会议是一个听到故事另一面的机会，是从一线人员那里获得现实检验（reality check）的机会。

在这个层级，你不断地在各种昂贵的参与方式之间做取舍：像一对一会议这样能提供深层价值、但消耗你时间和精力的方式，或者那些在你时间上更高效、但提供的信息不那么详细的方式。你不可能每次都做得完美。仍然会有一些时候，你太晚才听说一个项目在受苦、一个管理者辜负了他的团队、或一个团队成员在给别人制造麻烦。投入一些时间学习如何维持这些间接关系（indirect relationships）。

不要低估这个过程，即使在你很了解那些越级下属的情况下。仅仅因为你过去直接管理过某个团队，并不能保证你会与他们保持紧密联系。管理者们常在这里犯错：他们已经有人际关系，有大量一起工作的历史，所以他们觉得不需要额外努力去直接与那些团队保持联系。我也经历过，犯过这个错误。这种想法有时在短期内管用。但随着团队慢慢变化，关系也会变化。而且即使团队成员没有变，他们也不总会带着与管理者的矛盾来找你。原因请参见上文《问问 CTO：敞开门政策的谬误》。

管理者的问责（Manager Accountability）

无论向你汇报的是资深管理者还是新手管理者，这些关系都有一个共同的目标：他们应该让你的生活更轻松。你的管理者们应该让你把更多时间花在大局上，更少时间花在任何单个团队的细节上。这就是他们存在的意义。他们不仅仅是替你分担一些一对一会议的人；他们负责带领一群人，并帮助这个团队取得成功。当他们反复做不到这一点时，他们就是没有尽到自己的职责。

嗯，听起来不错，除了一件小事：有时管理者们通过隐藏问题、只告诉你你想听的话来让你的生活更轻松，直到几个月后你看到事情分崩离析，才纳闷自己哪里做错了。所以你不能只指望他们会神奇地把事情变好——你必须让他们负起责任。这一小项专长——学会如何让管理者们负起责任——将是你在这个层级工作最大的学习机会之一。

让你的管理者们负起责任很难，因为在复杂的团队中，责任（accountability）常常是混杂不清的。你的管理者们可能管理着一些团队，这些团队里有负责技术方向和质量的的技术负责人（tech leads）。他们也可能与设定功能路线图（feature roadmap）的产品经理（product managers）或业务经理合作。当然，一个团队真正成为孤岛是罕见的，所以其他团队也会影响那个组织。当所有这些责任被分散到不同的角色中时，你什么时候才能让一个管理者负起责任呢？

以下是我经历过的一些棘手但常见的情景：

不稳定的产品路线图（Unstable product roadmap）

团队感觉效率不高，系统不稳定，还有一些人员流失，但产品组织不断改变团队的目标，而且每件事都是紧急命令。管理者需要负责吗？

跑偏的技术负责人（Errant tech lead）

技术负责人一直钻牛角尖，试图重新设计其中一个核心系统。设计文档（design doc）几乎还没开始写，工作却在堆积，但技术负责人坚持说这是一个大问题，急不得。管理者需要负责吗？

全天候救火模式（Full-time firefighting mode）

管理者接手了一个遗留系统（legacy systems）一堆、故障不断的团队，团队似乎把所有时间都花在救火上。他们还支持其他使用这些系统的团队，而其他团队不断求助，用各种请求分散团队的注意力。有一个迁出这些系统的路线图，但你没有听到任何关于这个路线图进展的报告，而且你知道团队为了保持稳定和处理支持请求已经拼了命。管理者需要负责吗？

*所有这些问题的答案都是：是的。*是的，尽管每种情况都有情有可原之处，管理者最终都需要承担起把团队拉出这些困境、让他们向前推进的责任，因为管理者对团队的健康和生产力负责。

当产品组织不断改变目标时，管理者应该识别出这些改变正在给团队造成问题，并与产品部门合作，解释问题并重新聚焦于重要的事情。如果这行不通，她应该来找你帮忙解决。

当技术负责人钻牛角尖时，管理者必须把那个人拉出来，与他一起想办法让设计过程更加透明，必要时引入其他团队的高级人员作为导师或协作者，帮助他拆解问题并取得进展。

当路线图因为其他问题而停滞时，管理者有责任来找你。如果团队除了救火什么也做不了，管理者应该制定一个解决火源的计划，必要时提出招聘更多人、或给团队加人的请求，以便控制局面。当团队要处理过多传入的支持请求时，管理者有责任对支持负担进行分类（triaging），并弄清楚是拒绝其中一些请求，还是团队需要更多人来管理工作量。

在许多这类情况下，你需要帮助你的管理者们。有时他们没有足够的筹码去顶住产品部门，需要你的支持。他们可能需要你帮忙找到其他高级人员与他们的技术负责人搭档。你可能不得不批准任何增加人手去救火的请求，或者支持他们把支持负担转移到其他团队。他们已经完成了找出拖慢团队的问题的艰难工作，但接下来你需要帮忙寻找解决方案，或支持前进的道路。这才是「让你的工作更轻松」的样子——不是隐藏信息，而是在问题变成熊熊大火之前，把清晰的问题带给你。

管理者和独立贡献者一样需要辅导和指导。别忘了花时间与你的管理者们相处，把他们当作人来了解，并关注他们的优势和需要发展的领域。你的一对一会议里有大量与日程和规划相关的话题可聊，但要为反馈和辅导留出时间。这些人对你整个组织的成败影响最大，反过来，他们的表现好坏会让你看起来好或坏，所以要积极参与他们的管理表现。

好管理者，坏管理者：讨好型管理者（Good Manager, Bad Manager: The People Pleaser）

马库斯（Marcus）是每个人的好朋友。他有一支忠诚的员工团队，他们认为他是世界上最好的管理者。他一天中的大部分时间都在与从直接下属到最新初级员工的所有人开一对一会议。所有人都同意，他为任何需要他的人留出了大量时间，并且只要你需要，他就会一直听你说。带任何问题给他，他都承诺会解决。自从他接管这个组织以来，你觉得你的担忧真正被听到了。然而，他似乎从来都腾不出手来解决那些问题。你抱怨过的那个同事还是升职了。产品团队还是在碾压你们。目标还是毫无意义。但马库斯太忙了，你不能怪他；毕竟，他要处理的问题实在太多了。

玛丽亚（Maria）就没那么受人爱戴。如果你提出要求，她会为你腾出时间，但除非你直接向她汇报，否则她倾向于保持距离。她有时很生硬，似乎对办公室八卦或浪费时间没什么耐心。但自从她接管这个部门以来，事情发生了变化。路线图上的目标更少了，而且每个目标都说得通。你那位难搞的同事似乎得到了一些反馈，开始听你的想法了。会议进行得更好了，团队多年以来第一次如此专注。问题仍然存在，但既然你真的在办成事，它们就显得不那么重要了。最令人惊叹的是，她似乎每天晚上都能在合理的时间回家！

马库斯是个讨好型管理者（people pleaser）。他深深厌恶直接让他关心的人不开心。所以，如果你在他关心的群体里，向他提出要求，他总会说好，即使事情太多、他根本不可能全部处理。通过试图让每个人都开心，讨好型管理者们常常把自己累垮。

你手上可能有一个讨好型管理者的迹象：

她的团队爱她这个人，但越来越对她作为管理者感到沮丧，因为她向他们隐藏问题，并试图把他们与外部世界隔绝开来。
他更感兴趣的是让团队平稳运行、避免犯错，而不是让团队推动自己真正变得卓越。
当她心情不好时，全都写在脸上，让整个团队失去信心。
他从不推掉工作，但常常有大量未完成的任务，以及一堆为什么这些任务还没完成的借口。
她过度承诺、交付不足，而且似乎永远无法从这次经历中吸取教训，下次少承诺一些。
他对所有人说好，并向他的团队和外部伙伴发出关于能完成什么的相互矛盾的信息，导致广泛的混乱。
她似乎知道公司里正在发生的所有问题，但没有直接解决其中任何一个。

这些年来我见过许多版本的讨好型管理者。有一种是团队讨好者（team pleaser），就像马库斯。人们往往爱他，因为他花那么多时间与他们相处。他想要与你的情绪互动，确保你开心，听你说任何困扰你的事，以便他设法解决。他不偏袒任何人，但那些愿意向他掏心掏肺的人最终会得到他的大部分时间。这种「治疗师式」的讨好型管理者能在他团队中激发巨大的忠诚，因为他愿意听你烦恼什么，而且真诚关心你的情绪健康。不幸的是，这可能意味着他放大戏剧性和负面情绪，并通过做出他根本不可能兑现的承诺来让团队失望。

在另一面，还有外部讨好者（external pleaser）。她非常想让她的老板和外部伙伴开心，并且害怕暴露她团队的问题。结果，她花费大量精力向上和向外管理，尤其是倾向于严重地让她的团队超负荷承诺。尽管想讨好别人，她却常常不怎么在内部给予团队表扬或反馈。这看起来可能令人惊讶，但这个讨好型管理者很难在内部进行艰难的对话，所以她回避谈论团队内部的严重问题，这实际上可能导致她拒绝承认好的工作，同样也拒绝承认问题。她永远不会主动与她的管理者分享问题，并且乐意同意任何进来的项目请求。

在这两种情况下，讨好型管理者都难以说不，并向团队和外部各方发出相互矛盾的信息。一个管理者可能坚持要扑向摆在团队面前的每一个问题，做所有繁琐的工作，比如说，解决由产品中的 bug 引起的数据问题。因为管理者实际上并没有专注于这项任务的精力，问题解决得很慢。此外，团队对客户面临的问题缺乏透明度（transparency），所以他们难以确定修复问题的优先级。通过试图让团队免于做不愉快的工作，管理者让那项工作拖得更久，并降低了团队一劳永逸地解决问题的能力。

专注于外部的讨好型管理者可能是他们的管理者一个巨大的盲点（blind spot）：因为他们如此专注于只谈好事、对所有找上门的事情都说好，他们的管理者们往往直到为时已晚才知道团队里或项目中的问题。这些人非常擅长让你分心、不再担心。他们有一堆借口。他们承诺下次会做得更好。当你给出纠正性反馈时，他们甚至可能真诚地后悔，但对他们来说，做那些明显让别人不开心的事情非常难。而且你很可能非常喜欢你的讨好型管理者这个人。他们人很好！

你可能认为讨好型管理者会创造出让人感到安全、可以示弱和失败的团队，但事实上恰恰相反。这类管理者让团队难以健康地失败，因为管理者自己对失败和可能被拒绝的恐惧。一个专注外部的讨好型管理者通过回避、必要时通过情绪操纵（emotional manipulation）来压制诚实的对话，这种操纵依托于他作为那个人人喜爱之人的地位。团队讨好者则通过承诺不现实的事情来让她的团队注定失败，结果往往是团队因为无法兑现这些被抬高的期望，而对管理者或公司感到极度怨恨。

如果你发现自己管理着处于这种情况的人，该怎么办？帮助这个人对说不感到更安全，并把更多决策外化（externalizing），这样他就不会把失败归咎于自己。为他提供强有力的伙伴，承担确定工作路线图的任务，是一个不错的选择。有时讨好型管理者在敏捷框架（agile frameworks）下工作得很好，因为团队自己掌握工作规划的所有权。为安排工作建立更好的流程，不要完全依赖管理者的自由裁量。当涉及到向团队本身承诺事情时，有一个明确规定晋升（promotions）或其他机会获取要求的结构也可以在这里适用。例如，当晋升不仅仅取决于管理者的自由裁量时，讨好型管理者就可以正当地指出流程是她无法控制的东西。

当你管理一个讨好型管理者时，你能做的最好的事情之一，就是让这个人看到他正在表现出这种行为，并指出其弊端。有时只需要让他意识到，他说好的习惯对团队是个问题。要认识到这通常源于无私、关心他人的个人价值观，即使你试图纠正那些不健康的行为，也要尊重这些价值观。毕竟，讨好型管理者只是想让你开心。

管理新任管理者（Managing New Managers）

我们谈论过管理对工程师来说是一次职业转变，所以新任管理者需要大量辅导也就不足为奇了。你可能还记得自己第一次管理团队的经历：你不知道自己不知道什么。你大概会模仿过去那些优秀管理者对你做过的事——如果你有一个好管理者可以效仿的话。也许你接受过一点培训，或者读过一本像这样的书，但更可能的是你一路摸索着走过来。当然，除非你自己有一个好的管理者帮你学习门道。

与你的新任管理者们共度优质时间很重要，你应该预期这是一笔前期成本（up-front cost），会为你的组织带来长期的回报。你可能认为，因为一个新任管理者有人际交往能力（people skills），她自然会擅长这份工作。新任管理者自己可能也这么认为！但你知道，成为一名优秀管理者需要一系列技能，即使人际交往能力扎实的人也需要一些训练才能做到。

当你雇用或提拔了一个新任管理者时，你常常急于把她完全放手到她的团队上。终于，那个团队不再是你的直接关注点了！不幸的是，你的新任管理者可能连最基本的事情都惊人地摸不着头脑。比如，主持一对一会议，第一次做是件令人生畏的事。聊什么？怎么给反馈？怎么记录要点（takeaways）？没有任何书或培训能取代你花时间问问你的新任管理者她的一对一会议进行得如何，看看她可能需要帮助解决什么问题或挑战。有时，你只需要提醒她首先要把会议开起来！

面对一份崭新而令人生畏的工作，有些人就是不做。当你的新任管理者不管理、在太多管理细节上掉链子时，她的团队就开始受苦，这意味着你开始受苦。当人们因为管理者没有给他们职业发展路径（career path）或没有激励他们而开始离职时，这最终是你的责任。利用越级会议来帮助你发现需要全力支持你的新任管理者的领域，并让她知道，在你最有效地引导她的过程中，你会频繁举行越级会议。

一个挣扎中的新任管理者常见的迹象是过度工作（overwork）。一个一直在工作的新任管理者，很可能没有把她以前的责任移交给团队里的其他人，所以她是在试图同时做两份工作。她稍微忙一点是一回事，尤其是在她逐渐掌握新职责的时候，但看到她早来晚走、整个周末都在写邮件，就是另一回事了。令我惊讶的是，有多少人从来没有真正学会放手任务，于是只是不断地工作越来越长的时间。明确表示你期望新任管理者移交她以前的一些工作，并帮她找到这样做机会。

过度工作也常常是另一个新任管理者危险的信号：那种认为自己现在大权在握、是团队的任务监工（taskmaster）、负责做所有决定的人。忽视工作的管理者很糟糕，但那些因为相信这份工作是实现权威的关键而干劲十足地投入的管理者，有时甚至更糟。一个权力上瘾（on a power trip）的管理者控制（domineers）她的团队，与团队中资历较深的成员进行越级会议会揭示他们的沮丧：他们自己没有任何做决定的能力。这与微观管理者（micromanager）略有不同但又相关，微观管理者期望团队每个成员随时提供详细的报告。微观管理者要求不必要的细节程度，把团队烦得要死。控制狂（control freak）则剥夺团队做任何决定的能力，把自己的工作视为给人们分配具体任务去完成。控制狂通常与产品管理和其他技术团队的同行关系不佳，因为他们常常独自争夺决策权，而不是协作。更糟的是，控制狂常常想向自己的管理者隐藏他们在做什么，唯恐那种控制权被夺走。如果你的新任管理者跳过你的一对一会议，或回避关于团队在做什么的问题，你手上可能就有一个控制狂。

你正在培养的新任管理者，最终应该让你的工作更轻松，而不只是替你把一堆一对一会议的责任从肩上卸下来。她还必须掌握团队的表现和交付，引导他们专注于目标并交付成果。有时新任管理者没有意识到，她们现在要负责这种交付，并认为自己在面对有挑战性的目标或产品路线图时无能为力。唠叨新任管理者、提醒她承诺过要做什么、或每次需要做团队规划时手把手教她基础，都不是你的工作，但你一开始需要辅导她完成这个过程。明确地预先设定期望：你会让她对团队负责，并帮助她建立实现这一目标的技能。

新任管理者很棘手，因为如果他们真的没有学习的意愿和成为扎实管理者的禀赋，他们就是一个大问题。让错误的人当管理者是一个错误，但一旦你意识到她不适合，却还把她留在那个位置上，就是一个严重的错误。我非常赞成让想进入管理层的工程师迈出小步，先做导师、管理很小的团队，但这并不总是可行，也不总能暴露出规模化（scale）带来的问题。例如，控制狂管理者在较小的管理情境中往往不会那么清楚地显现出来，而是压抑那种冲动，直到他们觉得自己拥有了头衔赋予的真正权威。留意你的新任管理者们。你可能不仅需要提供辅导，还需要在头六个月内给出强力的纠正性反馈。

除了你需要给新任管理者们提供的辅导之外，我建议寻找额外的外部培训。如果你的 HR（人力资源）团队有一个新任管理者课程，确保你的管理者们有时间参加，并鼓励他们去。你也可以在公司之外寻找额外的培训机会，比如专注于技术领导力的会议，或者由现任和前任工程经理开设的、专门针对技术领导力话题的项目。新任管理者通常渴望学习管理的窍门，专业项目可以帮助他们快速上手。

管理资深管理者（Managing Experienced Managers）

现在让我们来看看资深管理者。这是一组非常不同的挑战。资深管理者可以非常出色。合适的资深管理者知道需要做什么，并且不需要你帮忙就能做到。他对基础驾轻就熟，甚至还有自己的一些独门技巧。都很好，对吧？

当然，也可能有重大的弊端。管理往往是一项在公司中非常受文化影响的（culture-specific）任务。我可以整天给你讲最佳实践，但如果你自己当管理者，或者为一家与你不契合文化的公司雇用管理者，你就会有麻烦。许多年轻公司想用从早期就在那里、理解公司 DNA 的人来充实他们的管理团队，这是有原因的。他们理解文化，深刻理解什么重要，并且已经建立了把事情办成的内部人脉网络（networks）。

所以，第一个挑战是确保这个人适合你团队的文化。我们在所有招聘中都大谈文化契合度（culture fit），但管理者会创造亚文化（subcultures），如果你希望你的团队们好好协作，一个创造不相容亚文化的管理者可能是个问题。假设你招聘一个管理者，是因为他在构建某种产品上有专长，而你的公司缺乏这方面的专长。这种招聘可以很好地带来知识和视角。然而，我们常常高估产品领域的专长，让它蒙蔽我们，看不清与我们公司和团队的文化与流程契合度。一个在构建企业级仓储软件方面有深厚专长的人，在纸面上看起来非常适合管理你物流初创公司的仓储技术。但如果他习惯于每六个月发布一次软件，并且只与不参与产品构思（product ideation）过程的远程开发团队合作，他就不一定能与一个敏捷的、驻场的团队合得来。

如果你正在打造一个充满活力、以产品为中心的（product-centric）工程团队，你需要那些懂得如何与频繁发布软件的团队合作、对现代开发流程最佳实践驾轻就熟、并能激励富有创造力的以产品为中心的工程师的管理者。这些技能比行业特定知识重要得多。获取行业信息比重新训练一个不懂你的文化如何运作的人更容易。不要在对文化契合度上妥协，尤其是在招聘管理者的时候。

资深管理者对管理会有与你不同的想法，你必须解决这些分歧。然而，解决分歧不同于放任管理者做他认为最好的事。即使（或者也许尤其是）他做这行的时间比你长，也要愿意向他学习，但不要害怕提供你自己的反馈。在有分歧的领域协作，允许他教你东西，并在过程中扮演积极的角色。

再说一次，这是文化的问题。你负责培育你组织的文化，尤其是当你在公司待了更长时间的时候，你应该确保你所有的管理者都尊重并培育你认为对团队最好的那种文化。如果你想要以透明运作的团队，确保管理者分享信息。如果你想要鼓励探索的团队，确保管理者为他的团队安排探索想法的时间和空间。想想你的文化看重什么，帮助你的管理者们体现这些价值观，同时仍然尊重每个团队都会有一点不同，每个管理者都会有某些你需要考虑的强项和弱项。

你如何激励资深管理者？资深管理者和新任管理者的区别在于，资深的人应该有能力独立管理。这意味着你提供的很多辅导，将不再是关于管理的细枝末节（nuts and bolts），而更多的是关于他如何能对他的领域的战略和方向设定产生更大的影响。别忘了考虑你可以委派（delegate）给他的任务，而且在设定组织方向时，他应该是一个重要的顾问。虽然他们可能不像新任管理者那样需要那么多培训，但资深管理者常常需要帮助来扩展他们在公司内部和外部的网络，所以寻找能帮助他们结识新同行的项目。

招聘管理者（Hiring Managers）

你的组织在挣扎。你招进了 10 名工程师，每人经验都不到 3 年。尽管你努力了，现有工程师中没有一个可能有资格的人想承担管理角色。而且他们谁也没有多少管理经验，所以你必须做大量培训才能让他们上手。所以，被这么多人淹没的你，决定是时候从外面招一个新的管理者来接管部分团队了。但你该怎么做呢？

很多人非常不愿意从外部招聘管理者，而且有充分的理由。我们几乎都无法确定一个工程师是否有能力在团队环境中写出好代码而不把其他团队成员逼疯。而编码至少是一项我们可以要求人们向我们演示的技能。管理是……嗯，它到底是什么？我们怎么面试它？在管理招聘过程中，我们需要注意什么？

招聘管理者是一项多部分的练习，而这些部分实际上与一个良好的工程面试流程非常相似。首先，确保这个人拥有你需要的技能。其次，确保她是你的组织的文化匹配者。

管理面试和工程面试最大的区别是，管理者在理论上更容易糊弄你。管理者的技能，正如我们详细讨论过的，几乎完全围绕沟通展开。一个在管理面试中沟通得很好、说得天花乱坠的人，入职后可能什么都做不成。但面试中代码写得好的工程师，加入团队后有时也交不出任何东西。把你对雇用管理者之后会发生什么的恐惧，与你在面试她时试图评估的东西分开。你可以评估她，并从管理面试中获得有价值的信息。那你怎么做呢？看看你对一个管理者期望的技能，然后问她这些。

让我们从一对一会议开始。正如我们讨论过的，一对一会议是管理者判断团队健康状况、收集和传递宝贵信息的基本工具。你雇用的任何管理者都应该在面试过程中进行几次一对一的角色扮演（role-play）。做到这一点的最好方法之一，是让那些将向新管理者汇报的人来面试她，请她帮助他们解决他们现在或最近遇到的问题。类似于请一位高级工程师描述他会如何处理你刚刚解决的一个调试问题，一个好的管理者——即使不完全了解相关的人员或项目——也应该有良好的直觉知道该问什么问题、建议哪些可能改善局面的下一步行动。你可以更进一步，实际角色扮演其他类型的困难情境，比如处理一个表现不佳（underperforming）的员工，或给出一个负面的绩效评估（performance review）。

重要的是，管理者还必须能够调试团队（debug teams）。请管理者描述一次她运行一个落后于进度的项目的经历，以及她在那种情况下做了什么。或者让她与一个正在考虑辞职的员工角色扮演。请管理者描述她如何辅导过苦苦挣扎的员工，并帮助优秀员工成长到新的水平。

问问她的管理理念（management philosophy）。如果她完全没有理念，那可能是一个危险信号（red flag）。虽然新任管理者可能无法很好地回答这个问题，但一个没有清晰理念的资深管理者值得担忧。她认为管理者的工作是什么？她如何保持亲力亲为（hands-on），又如何委派？

根据资历的不同，你可能会让候选人进来，向一群人做一次演示。这不是专门为了评判演示的内容，而是看她如何掌控一个房间、回答一个群体提出的问题、组织她的思路、并站到观众面前。这些是一位高级管理者应该具备的技能，如果她缺乏这些技能，在决定是否雇用她时要考虑进去。不过，我要告诫你不要高估这一步。作为一个相当出色的演讲者，我认为演讲技能对某些类型的领导力有用，但不是全部，而且你能从一个如何在人群面前展现自己的人身上学到的东西是有限的。许多在其他方面非常出色的管理者，都不习惯在陌生的观众面前演讲。

技术技能呢？你要确保对候选人的技术技能有足够的了解，以便她能够向她将要管理的团队建立可信度（credibility）。对于需要写一些代码的人，给她一个你标准技术面试的简化版。对于不写代码的管理者，问一些你认为凭她的经验她应该能回答的技术问题。基于她构建或管理过的系统类型来出设计和架构问题是一个好办法。确保她能讨论所做出的权衡（tradeoffs）以及为什么。你也可以让她调解工程师之间对问题解决方案意见不一的技术争论。一个好的技术管理者会知道该问什么样的问题来引出核心问题，并引导群体达成坚实的共识（consensus）。

所以，这些是寻找技能的一些想法。第二个方面是文化契合度。正如我们已经讲过的，这在整个团队中都很重要，但到目前为止，最能造成痛苦的地方是在管理招聘中。你有没有与一个不理解公司或环境文化的管理者共事过？比如说，一个来自大公司的人到了初创公司，似乎并不拥抱初创公司的速度和随意？或者一个来自初创公司的人在大公司工作，不知道怎么达成共识？我不是说大公司员工不能成为出色的初创公司管理者（看看我，比如），或者说初创公司员工不能在一个更大的环境中成功，但你要理解你周围公司的文化，并评估管理者融入那种文化的能力。

你怎么筛选文化契合度？我在第 9 章会更详细地讨论这个问题，但总结一下，首先你需要理解你周围公司的价值观。你的结构是非正式的、不太依赖层级（hierarchy），还是层级被非常认真地对待？这两种文化中的任何一种都会给习惯了另一种文化的人带来问题。我见过来自大公司的管理者，他们对待同级很好，但对待下属和其他较低层级的员工就像他们不是人一样，这在初创公司的环境里引起了巨大的摩擦。我也见过来自初创公司的管理者，他们习惯了想做什么就做什么，在需要更多各方签字确认（sign-off）的环境中挣扎。这是最明显的文化要素。如果你看重仆人式领导（servant-leadership），却雇了一个想向团队下达精确行军命令的管理者，那就会有糟糕的匹配。同样，如果你看重协作，却雇了一个认为任何对话中声音最大的人应该赢的管理者，你也会有问题。

文化契合度对管理者如此重要，因为他们会把团队塑造成他们的文化，并根据他们的文化理念招聘新人。如果你雇了一个与她要管理的团队文化不合的管理者，很可能发生两件事之一：管理者失败，你不得不解雇她；或者团队大部分人辞职，然后你可能仍然不得不解雇她。有时改变一个领域的文化是不可避免的，招进一个新管理者会加速这种改变。你可以这样利用管理变动为自己谋利。事实上，你在成长的初创公司中经常看到这一点：他们招进更有经验的管理者和高管，来补足团队其他人经验的不足。有时这效果惊人地好，有时这是彻底的失败。无论如何，你通常会在这些新且不同的文化的承载者入职前后看到人员流失，所以要谨慎行事。

在他的书《格鲁夫给经理人的第一课》（High Output Management）[1] 中，安迪·格鲁夫（Andy Grove）谈到文化价值观是人们在高复杂、不确定或模糊的情境中做决定的方式之一——在这些情境中，人们重视群体利益胜过自己的利益。我觉得这个见解非常有力。他的观察是，大多数新员工在认识同事之前都是按自身利益行事的，然后他们转向群体利益。所以，如果你让他们从一份高复杂或不确定的工作开始，除非他们迅速融入文化规范、用文化价值观来校准他们的决策，否则他们往往会失败。如果你能筛选出那些自然而然倾向于你的公司已经拥有的文化价值观的管理者，他们比个人信念非常不同的管理者更有可能迅速完成这种转变。

最后，如果我不指出招聘新管理者时的一个关键要素，那就是失职了：背景调查（reference check）。对你计划引入的任何人都要做彻底的人事背景调查，即使你以前和那个人共事过。请推荐人描述那个人成功的方式，以及她失败的方式。问他们是否愿意再次与这个人共事，或为这个人工作。问他们喜欢这个人什么，什么让他们抓狂。如果你在招聘管理层时不做人选背景调查，你就是在严重亏待你的团队。背景调查，即使是候选人精心挑选的，也常常能揭示很多关于雇用她时你能期待什么的信息。不要漏掉这个关键步骤。

问问 CTO：管理你技能范围之外的领域（Managing Outside Your Skill Set）

我现在不仅要负责管理我部门的软件开发团队，还要负责运维（operations）和 QA 团队。我以前从未管理过这类团队，所以你对做好这件事有什么建议吗？

小心！很容易把这看作是从管理其他软件开发者的一个小跨越，但根据我的经验，在这些领域你需要追踪一些与你习惯的不同重要细节，如果你以前从未管理过这类团队，很难知道该关注哪些细节。不幸的是，在陌生的领域，你很容易直到为时已晚才发现问题。

这种情况处理不好时会发生什么？根据我个人的经验，这可能是一个大问题。当你为一个做你不深入理解的事情的团队雇了一个管理者时，那个管理者很容易走上错误的方向很长时间，而你还不知道发生了什么。当涉及到任何时间线很长（long timelines）的项目时，这尤其困难，因为缺乏进展很容易被掩盖。

对抗这个问题的一个有趣的方法，是使用我们在谈论导师制（mentorship）时我建议的同样的心态——也就是说，保持非常好奇。记住，没有人期望你因为是管理者就什么都懂。利用这一点为你服务。请那个人教你她做的工作。和她坐下来，把她当作你的导师，那个教你这份工作门道的人。无论是 QA、设计、产品管理还是技术运维，都要问很多问题，但要以开放的方式。向那个人明确表示，你的目标是理解她做什么，以便你能够更好地欣赏它。

这里还有一条建议：虽然你可能倾向于把更多时间花在你最熟悉的领域，但要做好准备，把大量时间投入到对你来说陌生的领域，尤其是在一开始。想信任和授权（delegate）的管理者很容易简单地假设人们会做正确的事然后放手，但这很容易导致你在这些领域错过问题太久。更糟的是，如果你把这些领域视为无趣或不值得你花时间，你可能会发现自己即使人们明显在引起你对这些团队问题的注意，也不愿意去处理。你会因为一开始就忽视了这些领域而感到内疚，你天生的回避心理可能会让你比原本允许的时间长得多地逃避面对问题。咬紧牙关，腾出时间让自己对每个领域感到舒服；花时间去了解团队里的管理者和员工，练习询问关于这个领域的细节，这样你就可以开始学习，并对那个团队的人实际在做什么形成感觉。

诊断机能失调的组织（Debugging Dysfunctional Organizations）

我相信最好的工程管理者往往也是出色的调试者（debuggers）。为什么会这样？这两项任务之间有什么共同之处，产生了如此重叠的技能组合？

一个出色的调试者在追寻 bug 的「为什么」时是锲而不舍的。当我们在寻找应用程序逻辑中的错误时，这很简单，但我们都知道 bug 可以深入到很多层，尤其是在涉及许多独立部分、在时延网络上运行（operating over time-delayed networks）的复杂系统中。糟糕调试者的标志是：当他在一段并发代码中添加一条日志语句（log statement）试图找出错误，看到错误无法复现时，就假设他已经修复了问题。这是个懒惰的习惯，但很常见。有时有些问题似乎根本无法确定，许多人没有耐心去挖掘层层代码（他们自己的和别人的）、日志文件、系统设置，以及任何其他需要的东西，去查明一件只发生过一次的事情的根源。我不能怪他们。对一次性问题着魔式的调试并不总是对你时间的好利用，但它确实显示了一种不会满足于未知的头脑，尤其是当那个未知可能让你在凌晨两点被传呼（paged）的时候。

这与管理有什么关系？管理团队是一系列复杂的黑箱（black boxes）与其他复杂的黑箱互动。这些黑箱有可以观察到的输入和输出，但当输出不符合预期时，弄清楚原因需要尝试打开它们，看看里面发生了什么。而且，就像有时你没有源代码，或者源代码是一种你不理解的语言，或者日志文件不可读一样，团队的黑箱也可以抗拒交出它们的内部运作。

让我们用一个例子来走一遍。你有一个感觉很慢的团队。你听到他们的业务伙伴和产品经理抱怨他们慢，你同意这个团队似乎就是缺少你其他团队那样的能量。你怎么弄清楚这个问题？

提出一个假设（Have a Hypothesis）

要正确地调试一个系统，你需要一个合理的假设（hypothesis），解释系统是如何进入失败状态的，最好是一个你可以复现的假设，这样你就可以修复这个 bug。要调试一个团队，你也要寻找一个关于团队为什么有问题的假设。要以尽可能少侵入（minimally invasive）的方式来做这件事，以防止你的干预掩盖问题。还有一个额外的挑战：团队问题通常不是单一的故障，而更像是性能问题（performance issues）。系统在运行，但它似乎时不时地变慢；机器还好，只是偶尔崩溃；人们似乎很开心，但人员流失太高了。

检查数据（Check the Data）

调试一个团队，应该与调试一个严重的系统问题时运用同样的严谨。当我调试系统问题时，我首先看的是日志文件和事件发生时系统状态的任何其他记录。当你看一个没有足够快地产出工作的团队时，看记录。看团队聊天和电子邮件，看工单（tickets），看仓库中的代码评审（code reviews）和签入（check-ins）。你看到了什么？是否发生了占用大量时间的生产事故？是不是一堆人生病了？他们是在代码评审意见中争论编码风格吗？写的工单是模糊、太大、太小吗？团队在沟通风格上看起来是乐观向上的，在聊天中分享有趣的事情以及重要的工作，还是纯粹公事公办？看他们的日历。团队是不是每周花很多小时在会议上？他们的管理者是不是不做一对一会议？这些事情都不一定是确凿证据（smoking guns），但它们可能指向一个需要处理的领域。

观察团队（Observe the Team）

也许所有这些指标看起来都正常，但团队仍然没有达到你认为他们应该达到的表现。你知道人才是有的，团队很开心，他们没有背负过多的生产支持负担。那到底发生了什么？现在是时候开始做一些潜在的破坏性调查了。坐在他们的会议上。你觉得无聊吗？团队觉得无聊吗？大部分时间是谁在说话？有没有定期举行的全员会议，绝大多数时间都在听管理者或产品负责人讲话？

无聊的会议是一个信号。它们可能是组织者规划效率低下的信号。相对于所涵盖的信息量，会议可能太多了。它们可能表明团队成员觉得他们实际上无法帮助设定团队的方向，或选择将要进行的工作。它们常常标志着团队缺乏健康的冲突（conflict）。好的会议有大量的讨论元素，从团队中引出观点和想法。如果会议过度脚本化（overscripted），以至于无法进行真正的对话，那就会扼杀那种创造性讨论。如果人们因为害怕处理冲突而不敢提出异议或提出问题，或者如果管理者总是压制冲突、不让分歧表达出来，这就是不健康团队文化的标志。

不过要注意，虽然团队可以是黑箱，但它们共享另一个著名盒子的特征——那个装着薛定谔的猫（Schrödinger’s cat）的盒子。薛定谔实验的意义在于表明观察这个行为会改变结果，或者更确切地说，会导致一个结果发生。同样，你不可能进入一个团队而不通过在场、坐在他们的会议里、观看他们的站会（standups）来改变那个团队的行为。你的存在改变了团队的行为，可能掩盖了你试图发现的问题，就像一条日志语句可以神奇地抹掉并发问题一样，至少在一段时间内。

提出问题（Ask Questions）

问团队他们的目标是什么。他们能告诉你吗？他们理解为什么那些是目标吗？如果他们不理解他们工作的目标，他们的领导者（管理者、技术负责人、产品经理）就没有做好让团队参与工作目的的工作。在几乎每一种激励（motivation）模型中，人们都需要感受到对他们工作目的的理解和联系。他们为谁构建这些系统；对客户、业务、团队的潜在影响是什么？他们在决定这些目标以及实现这些目标的项目上有任何参与吗？如果没有，为什么没有？当你看到一个团队把所有时间花在工程主导的项目上，而忽视产品/业务项目时，很可能这个团队不欣赏或不理解他们本该做的产品/业务项目的价值，因此他们缺乏攻克它们的动力。

检查团队动态（Check the Team Dynamics）

最后，你还可以看看实际的团队动态（team dynamics）。人们互相喜欢吗？他们友好吗？他们在项目上协作，还是每个人都独立做点什么？聊天室、电子邮件里有打趣（banter）吗？他们与相邻部门、与他们的产品经理有良好的工作关系吗？这些都是小事，但即使非常专业的群体，成员之间也往往有一定程度的个人联系。一群从不互相交谈、总是在做独立项目的人，并不是真正作为一个团队在工作。如果团队表现良好，那也没什么错，但既然他们没有，这可能就是造成你问题的原因之一。

介入并提供帮助（Jump In to Help）

有时管理者的管理者选择把这类问题当作只需要团队管理者去修复的事情。你毕竟是以他团队的产出来衡量他的，如果事情进展不顺利，修复是他的责任。这是真的，但就像我有时会介入帮助调试复杂的系统宕机（outages）一样，尽管我很少写代码，看到团队问题时介入帮助调试也是可以的，尤其是当相关的管理者在挣扎的时候。这可以是一个教导管理者、帮助他成长的机会。它也可以揭示组织中更根本的问题，比如缺乏高级业务领导力（senior business leadership），即使是最好的管理者也无法独自识别或解决。

保持好奇（Be Curious）

当涉及到组织问题时，对为什么的追寻给了你可供匹配的模式，和可以引领的经验教训。我们通过经常调试而变得更擅长调试，并了解到哪些领域往往最先出问题，哪些指标对理解问题最有价值。我们通过推动自己和我们的管理团队真正深入到组织问题的根源，寻找为什么，以便我们将来能更快地解决这类问题，从而成为更好的领导者。没有理解为什么的动力，我们就靠魅力和运气来撑过我们的管理生涯，并做出我们的招聘和解雇决定。结果，在真正从我们的错误中学习这方面，我们有一个巨大的盲点。

设定预期并按时交付（Setting Expectations and Delivering on Schedule）

工程管理者们最常被问到的令人沮丧的问题之一，就是为什么某件事要花这么长时间。我们都曾被问过这个问题。作为亲力亲为的工程师、作为技术负责人、作为小团队的管理者，我们都曾被问过，但当你管理的是团队管理者时，这个问题达到了一个全新的强度，因为当你不深入嵌入细节时，回答它要困难得多。

首先：希望你被问这个问题，是因为某件事大大超出了计划。那是最有理由问的时候，也是你应该尽最大努力理解情况并回答的时候。

可悲的是，我们常常在事情并没有比估计花更长时间的时候被问这个问题。我们常常被问这个问题，是因为我们的领导层，无论出于什么原因，要么不喜欢最初的估计，要么根本没有要求过估计，而现在他们不高兴了，尽管没有任何出问题。

因此，你必须总是积极地分享估计和对估计的更新，即使人们没有问，尤其是当你认为项目很关键或可能花费超过几周时间的时候。这意味着你必须积极地获取估计，而且众所周知，软件估算（software estimation）是一个非常困难的过程。协商你的团队用来估算的流程、在什么时间尺度上、为哪些项目估算，可能是你这个层级的工作的一部分。

工程师们常常根本不想估算，或者不想估算超过一个敏捷迭代（agile sprint）（通常是两周）的边界。如果你认为估计必须相当准确、需求未知或会频繁变化、而且大部分工作应该限定在大多适合一到两个迭代的功能（features）之内，这种理念是完全合理的。话虽如此，这些事情很少全部为真。估计即使不完全准确也常常有用，因为它们有助于向团队其他成员升级（escalate）复杂性。不是每个项目的需求都会频繁变化，而且有可能做前期工作来大幅减少那些使软件估算困难的未知因素。你可能会争辩说，前期工作有时会让整个流程比仅仅一个迭代一个迭代地看项目花更长时间，你可能是对的，但再说一次，我们这里不仅仅是在谈论工程团队。我们在谈论想要规划、想要了解工作成本概念的业务。在某种意义上，我们也在谈论目标设定，以及学习如何更好地理解我们软件和系统的复杂性。我们无法完美地预测未来，但教会我们的团队如何磨练他们对复杂性和机会的直觉，是一个有价值的目标。

所以，接受你需要做一定程度的估算这个事实。尝试不同的方法，看看什么对你的公司有效，但要让它在你的团队之间成为一种习惯。

敏捷软件开发（agile software development）的另一个核心要素是强调从过去中学习。当估计错误时，我们学到了关于未知复杂性的什么？我们学到了关于什么值得估算、什么时候值得的什么？我们学到了关于我们如何传达这些估计、谁对这次的偏差（miss）感到失望的什么？

你的工作就是尽可能清楚地说明「长」（“long”）到底是什么意思，提供你对项目时间尺度的最佳视角，并在它变化时主动更新那个视角，尤其是当它变慢很多的时候。

即使你尽了最大努力，有时你也会被问到这个问题——当你已经清楚地说明了「长」是什么，当你实际上并没有花那么长时间，或者当完全在你控制之外的事情出现并造成了延误，而这些延误已经被充分沟通了。这种情况发生时很糟糕，它通常发生是因为有人感到压力很大，或者被推着要交付得比你声称能交付的更快。这种情况没有简单的答案。有时耐心地提醒对方事情正在以最快的速度进行，一切都在按计划进行，是唯一的解决办法。但指责通常不是一种完全理性的行为，也不是在压力下可以完全避免的行为。对施加压力的人表现出一些同理心，并愿意以其他方式帮忙，可以大大有助于把焦点从指责转移到行动上。

最后，不要害怕与你的管理者们、技术负责人和业务方合作，在项目接近尾声时削减范围（cut scope），以便赶上重要的最后期限（deadlines）。作为高级管理者，你可能需要扮演最终裁决者（tiebreaker），决定哪些功能值得砍掉，哪些功能对项目的成功至关重要。帮助团队留意这些功能，如果为了完成更大的项目必须砍掉某个人的心爱想法，愿意为此承担责任。对你愿意在什么上让步要明智。如果你只在技术质量问题上让步，你只会让团队在项目上线后变慢，所以一定要同时考虑产品功能和技术上的锦上添花。

棘手情境：路线图的不确定性（Challenging Situations: Roadmap Uncertainty）

所有层级的管理者都面临的一个非常常见的问题，是产品和业务路线图（roadmaps）不断变化的挑战。尤其是在较小的公司里，很难让人们提前一年承诺下一年要做的工作。即使在大公司，市场的变化也会导致看似突然的战略转变，使项目被放弃、计划好的工作被取消。

这对工程管理者来说真的很难处理。战略变化正是身处「中层管理」（middle management）感觉最不愉快的地方。你可能几乎没有能力顶回来自上层的战略变化，即使你已经向你的团队承诺某些项目会发生，有时你也不得不收回那个承诺，因为意想不到的变化。这使团队不高兴，他们向你抱怨。因为你对此几乎无能为力，你会觉得这暴露了你的无能为力，而你的团队可能会觉得他们没有像人一样被对待，而是像公司机器中的齿轮（cogs）。

这里还有一个次要的挑战：当似乎没有一个清晰的流程来优先安排那类工作时，你如何为你的团队腾出时间来处理技术债（technical debt）和其他工程主导的项目？毕竟，如果你不花任何时间处理技术问题本身，你的团队做产品功能的能力就会变慢。然而产品团队永远不会把技术债放在他们的路线图上，所以规划过程常常意味着这类工作没有分配时间。

应对路线图不确定性的策略（Strategies for Handling Roadmap Uncertainty）

关于制定路线图，我学到了一些策略：

**根据你所处公司的规模和阶段，对计划改变的可能性保持现实态度。**如果你的初创公司有每年夏天根据上半年的业务结果改变年度计划的传统，那就准备好迎接夏天的变化，尽量不要向你的团队承诺需要超越那个时间点的连续性的事情。
考虑如何把大项目分解成一系列更小的可交付成果（deliverables），这样即使你不一定完成宏大的愿景，也能取得一些成果。分解技术工作需要你与产品经理或业务经理密切合作，弄清楚细节应该如何被优先排序。你们所有人都应该已经明白，事情会快速变化，所以一切都必须反复重新审视，着眼于当下最有价值的东西。
**不要过度承诺一个技术项目的未来。**不要向你的团队承诺「以后」会有的激动人心的技术项目，因为「以后」的产品路线图还没有写出来。这种想法会吊起希望，然后让人失望。如果项目很重要，现在就把它排上日程——或者尽可能接近现在。如果项目不是紧迫重要的，你可以把它放在待办清单（backlog）上，但你应该现实一点：一旦「以后」到来，会有来自业务其他部分的一长串竞争优先级。如果你没有花时间阐明这项工作的价值，它就会被推到一边，让位给那些价值更清晰的项目。
把团队日程的 20% 专门用于「维持性工程」（sustaining engineering）。这意味着留出时间做重构（refactoring）、修复未解决的 bug、改进工程流程、做小的清理，并提供持续的支持。在每一次规划会议中都要考虑到这一点。不幸的是，20% 不足以做大项目，所以需要额外的规划来进行重大的技术重写或其他大的技术改进。但没有这 20% 的时间，就会有错过交付目标和计划外的、令人不快的清理工作的负面后果。
**理解各种工程项目到底有多重要。**产品和业务项目通常有某种价值主张（value proposition）来证明它们的合理性。然而，同样的严谨并不总是适用于技术项目。当一个工程师带着一个她想做的工程项目来找你时，考虑通过回答这些问题来为这个项目定位：
- 那个项目有多大？
- 它有多重要？
- 你能向任何问起的人阐明那个项目的价值吗？
- 项目的成功完成对团队意味着什么？

这些问题的价值在于，你开始像对待产品计划（product initiatives）一样对待大型技术项目。这些项目有倡导者（advocates）和目标，它们有日程，它们像其他大型计划一样被管理。这是一个令人害怕的过程，因为有时你「知道」某件事很重要，但你不知道如何用一种业务会重视的方式来阐述它。尤其是考虑到技术项目的复杂性，以及衡量工程效率（engineering efficiency）之类东西的挑战，你有时会卡在试图向一个非技术的合作伙伴解释技术细节上，而对方可能不完全理解你要去哪里或为什么。我的建议是尽最大努力收集数据来支持自己，并谈论当工作完成时什么是可能的。如果你看一个技术项目，意识到你在为一个很少被修改、不会为你的技术或业务带来核心改进的系统提议一堆工作，那它可能不值得这份努力。不幸的是，永远没有足够的时间去做你的团队想做的所有探索性工程、遗留代码清理和技术质量改进，这个过程会帮助你挑选要打的仗（pick your battles）。

所以，回到我们不确定的路线图。项目会变。团队甚至可能被解散，或以你不理解、不同意的方式被调动。作为管理者，你能做的最好的事情，是帮助人们感到有能力收尾（tying up loose ends）、稳定当前进行中的（in-flight）项目，并以可控的方式过渡到他们的新工作中。这是一个你可以也应该顶回去的领域。确保你的团队有足够的时间完成当前的工作。此外，推动工程部门参与新工作的早期规划，这样人们可以对他们即将转到的项目感到兴奋。你自己花时间理解变动的原因，即使你不完全同意，也要尽你的一份力，帮助把这些原因向你的团队讲清楚，帮助他们理解新目标。你在这些变化面前越冷静，你越能表现出（或假装出）对新方向的热情，你的整个团队的过渡就越容易。

当你面对一波又一波的海浪时，你可以让它们把你卷入水底，也可以学着去冲浪。挂好十个脚趾，站稳了冲（Hang 10，冲浪术语，指双脚十趾都钩在冲浪板板头上）。

保持技术敏锐度（Staying Technically Relevant）

我从管理者那里听到很多的一个问题是：「我如何保持技术敏锐度（technically relevant）？」我们知道，如果不在我们的技术技能上投资，我们就有变得与领域脱节、过早过时的风险。但技术敏锐度到底能为你做什么？为了回答这个问题，让我们先明确你的技术责任（technical responsibility）。

监督技术投入（Oversee Technical Investment）

要向前发展，系统需要持续的技术工作：新的语言、框架（frameworks）、基础设施（infrastructure）和功能。可以用来改进这些系统的开发时间和精力是有限的，而你有责任确保团队把它的技术赌注（technical bets）押在正确的地方。你通过把提议的技术项目和改进与产品或客户需求的未来相匹配来监督这些投入。从项目组合（portfolio）的整体来看，你可以看到最大的需求或机会所在，并相应地聚焦团队的努力。

提出有依据的问题（Ask Informed Questions）

你不是识别所有技术项目的人。对团队技术投入负责，并不意味着你亲自做研究去找潜在的投入。相反，你通过提问来引导这些投入。当前的项目是什么，它们揭示了什么意外或瓶颈？团队如何看待这些系统的未来？哪些团队在要求更多工程师，他们认为自己为什么需要更多人？哪些团队很慢但不想通过加人来提高吞吐量（throughput）？为什么他们现在倡导这个具体的项目？你需要对工作了解得足够多，才能嗅出被误导的努力，并评估提议的投入。

分析与解释工程与商业的权衡（Analyze and Explain Engineering and Business Tradeoffs）

通过了解你的团队对什么感到兴奋、他们看重什么，你可以让他们围绕产品计划（product initiatives）团结起来。你了解得足够多，可以在一个功能想法技术上困难时、在一个技术想法有未预见的商业影响时提出担忧。你确保工程师们在理解商业视角和产品路线图未来的情况下做决定。当技术工作需要不确定的研发时，你有能力向你的非技术同行解释为什么存在那种不确定性。理解业务和客户目标，你就能够就哪些技术项目可以在合理的时间框架内实现这些目标提供指导。

提出具体要求（Make Specific Requests）

作为总监级（director-level）管理者，你仍然需要对组织中的技术有足够的理解，以便提出具体要求，而不用问问题去打扰高级工程师。通过充分了解你的团队的进展、项目和瓶颈，你可以过滤掉技术上不可行的想法，并把新计划（initiatives）映射到进行中的项目上。这些具体要求应该用来保持团队的生产力，并平衡技术风险与组织目标。这里有一个例子说明这是如何运作的：

你的副总裁（VP）告诉你，她想改善搜索体验，以便在下个季度增长活跃用户，她可以给你更多工程师来更快地完成工作。你知道团队无法通过增加工程师来有效修改搜索，因为它正在被重写的过程中。相反，你指导他们优先处理工作，更早地暴露新的 API，这样产品团队终于可以运行一些他们一直要求做的测试。你向副总裁解释什么是可能的，并确保团队专注于完成那些能让这些更高层目标得以实现的工作。

那些保持技术不够深入的管理者，有时会陷入一个坏习惯：充当高级管理层和他们的团队之间的传话筒（go-between）。他们不是过滤请求，而是把请求转达给团队，然后把团队的回应转达回管理层。这不是一个增值的角色。

用你的经验作为直觉校验（Use Your Experience as a Gut Check）

这是一项高度技术性的工作，一个不理解、不欣赏软件工程和技术的挑战与权衡的人做不了。如果你的团队把时间投入得很差，那会反映在你身上，因为你是他们的领导者，没有帮助他们做出更好的决定。依靠你的直觉来引导你把时间和注意力花在哪里，不要因为忙于人员和组织的挑战而忽视你的技术直觉。

鉴于你的技术责任水平，你应该如何投入你的时间以保持技术敏锐度？

**读代码。**偶尔花时间读一读你系统中的一些代码，可以帮助你想起它长什么样。有时，它还会向你展示一些地方变得丑陋、需要注意。浏览代码评审和拉取请求（pull requests）可以让你洞察正在发生的变化。
**挑一个未知的领域，请一个工程师给你解释。**花几个小时与一个正在做你不理解的事情的工程师在一起，请他教你那个领域。去白板前或分享屏幕，让他和你结对（pair）做一个小改动。
参加事后复盘（postmortems）。当宕机（outages）发生时，把参加宕机后的复盘会议作为优先事项。这些会议常常充满关于编写和部署软件过程的细节，而当你不是每天写代码时你会错过这些。你以为理所当然的标准被忽视或忽略了。团队之间的沟通很缺乏，工具（tooling）帮的忙比添的乱还多。在失败的时刻，你能最清楚地看到问题在哪里堆积起来，并了解到你的注意力需要放在哪里。
**跟上软件开发流程的行业趋势。**管理者的一大弱点是失去与真正开发、测试、部署和监控代码的工具和流程的联系。正是在这些地方，新想法可以让你的团队显著更有效。不是每个趋势都值得追求，但一定要留出时间了解其他团队如何交付软件，这样你就能让你的团队不断进化。
在公司之外培养一个技术人脉网络（network）。最好的故事来自你信任的人。保持一个工程和工程管理同行的网络，让你有人可以询问对新趋势的看法。利用这个网络获取博客文章、演讲和新技术推销背后的真实经验。
**永远不要停止学习。**找关于技术的文章和博客来读。看演讲。挑一件你真正好奇的事情，稍微深入挖掘一下，即使它与你团队或公司无关。不要害怕向你的团队提问，并寻找向他们学习的机会。学习是一项你可以练习来保持思维敏锐的技能。

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

你多久与你的越级下属谈一次话？你与他们一对一见面，还是以小组形式？你如何主动接触你的团队？你花多少时间主动寻找信息，而不是被动处理送到你面前的信息？你上一次坐在团队会议里是什么时候？
不看现有的文档，写下你对向你汇报的工程管理者的职位描述（job description）的看法。
- 他们负责什么？
- 你如何评估他们？
- 在你看来，哪些领域对成功最重要？
现在，看看你公司使用的职位描述。你写的与那个描述有差异，还是匹配得很好？鉴于那个描述，你在评估他们时可能忽略了什么？
最后，快速在脑中回顾一下他们当前的表现。哪些领域需要辅导和发展？在你的下一次一对一会议中留出时间讨论这个。
如果你管理着一个你技术舒适区之外的领域，你多久检查一次那个领域以确保一切顺利？你有没有花时间向那个领域的管理者学一点在那个角色中成功需要什么？在过去三个月里，你学到了什么新东西，帮助你更好地理解那个团队？
如果你有一个团队明显比其他团队运作得更顺畅，你注意到他们的流程有什么不同？他们的互动呢？他们的管理者是不是做了与其他管理者不同的事情？团队如何与该管理者互动，该管理者如何与你互动？
你的管理者面试流程是什么？你会花时间谈论他们的个人价值观和管理理念吗？你让团队面试他们潜在的管理者，还是把他们排除在流程之外？你会花时间获取候选人的推荐（references）吗？
你的组织这个季度的目标是什么？今年呢？你如何把产品目标（如果有的话）与技术目标合并？你的组织是否有团队们都很好理解的使命（mandate）？

[1] 安德鲁·S. 格罗夫（Andrew S. Grove），《格鲁夫给经理人的第一课》（High Output Management）（纽约：Vintage Books，1983 年）。