管理员工（Managing People）

新的工程经理往往把这份工作看作一次晋升，让他们在工程任务和工程问题上拥有了资历。这种心态是确保他们永远停留在初级经理、并且成为不成功的领导者的绝佳方式。很难接受「新经理」是一份没有任何方面资历可言的入门级工作，但这才是开始领导工作的最佳心态。

马克·赫德伦德（Marc Hedlund）

恭喜你！你已经进步到了人们信任你去管理其他人的级别。也许你的人力资源部门（HR）已经就一些管理基础知识给你做过培训。也许你过去遇到过一些很棒的管理者，你想要效仿他们。但现在到了动真格的时候，是时候把所有这些想法和观念付诸行动了。

首先，让我们专注于管理个体。关于这个话题，市面上已经有一堆书能给你提供更多的想法和观念；我在这里的目标是给你我所理解的管理的基本要素。一旦你坐上了管理的「热座」，你应该如何思考执行管理员工的基本任务呢？

在适应管理这个转变的过程中，你的关注点之一是要摸索出你自己的管理风格。你们中的许多人将在学习如何管理个体的同时，还要负责带领一个团队。在下一章里，我们会更多地谈论把团队作为一个整体来处理的挑战，以及你角色中的技术侧可能发生的变化，但从个体入手思考是很重要的。毕竟，你的团队的健康程度取决于它的每个个体，而作为个体经理，你对每个人都会产生巨大的影响。

我们将讨论管理员工所需的主要任务：

接收新的直接下属（direct reports）
定期举行一对一会议（1-1s）
就职业成长、目标进展、待改进之处给出反馈，并在适当的时候给予表扬
与下属一起确定需要学习的领域，并通过项目工作、外部学习或额外的指导（mentoring）帮助他们在这些领域成长

为新的汇报关系开个好头

你开始管理时发生的第一件事，就是有人成为你的直接下属。这些人可能是你已经共事了一段时间的人，也可能对你来说完全陌生。随着管理生涯的推进，你会反复经历有新人开始向你汇报的情况。你如何快速了解这个人，以便更好地管理他呢？

建立信任与融洽关系

一个策略是问一系列问题，这些问题旨在帮助你了解这个人的各个方面，而这些方面会影响你管理好他的能力。这些问题可能包括：

你喜欢被怎样表扬，公开的还是私下的？ 有些人真的很讨厌被当众表扬。你需要知道这一点。
对于严肃的反馈，你偏好的沟通方式是什么？你更希望收到书面反馈，这样你有时间消化，还是你接受不那么正式的口头反馈？
你为什么决定来这里工作？你对什么感到兴奋？
我怎么知道你心情不好或者恼火了？有没有什么总能让你心情不好的事情是我应该知道的？ 也许某个直接下属因为宗教原因斋戒，这有时会让他脾气暴躁。也许他在值班（on-call）时总是压力很大。也许他讨厌评估季。
有没有你明确讨厌的管理者行为？ 如果你问我这个问题，我的回答是：跳过或重新安排 1-1、忽视给我反馈，以及回避艰难的对话。
你有没有我应该知道的、明确的职业目标，以便我帮你实现它们？
你入职以来有没有什么意外，好的或坏的，是我应该知道的？ 比如：我的股票期权（stock options）在哪里？你承诺过给我搬家奖金，但我还没拿到。为什么我们用的是 SVN 而不是 Git？我没料到我已经能这么高产了！

想了解更多想法，请看 Lara Hogan 的关于这个主题的精彩博文。

制定 30/60/90 天计划

许多有经验的经理使用的另一种方法是帮助新下属制定 30/60/90 天计划（30/60/90-day plan）。这可以包括基本目标，比如熟悉代码、提交一个 bug 修复、或完成一次发布（release），对新员工和从公司其他部门转岗过来的人尤其有价值。入职者级别越高，他就越应该参与制定这个计划。你要让他有一些清晰的目标，以表明他在熟悉工作节奏时学到的东西是否正确。这些目标也需要你和团队付出一些努力，因为很少有什么东西对新人来说是显而易见的、有良好文档记录的、完全一目了然的。

不幸的是，有时你会招错人。为你的新员工设定一套你认为在头 90 天内可以达成的明确预期目标，会帮助你迅速发现错误的招聘，并让你和他们都知道你需要纠正这种情况。根据你以往的招聘、当前技术和项目的状况，以及新进人员的级别，创建一套切实可行的里程碑。

鼓励新人更新入职文档

对于处于职业生涯早期到中期的员工，入职流程（onboarding）的一个方面可能包括为团队的入职文档做贡献。许多工程团队的一个最佳实践是创建一套入职文档，让每一位新员工在熟悉工作节奏时都对它进行编辑。他编辑文档以反映自上一次招聘以来发生变化的流程或工具，或者他发现令人困惑的地方。作为经理，你不一定需要亲自带新人走这个流程——这可能是同事、导师（mentor）或技术负责人（tech lead）的工作——但你可以是把这个流程建立起来的人，而且你需要为每一位加入团队的人强化这个流程。

沟通你的风格与期望

你的新员工需要理解你的期望和风格，正如你需要理解他的一样。你们双方都需要各自调整一点来适应对方，但如果新员工不知道你对他有什么期望，他就无法交付他需要交付的东西。你这一方的期望设定应该包括具体细节，比如你想多久和他见一次面，你们俩如何共享信息，以及你会在什么时候、以什么频率审查他的工作。如果你希望他每周通过电子邮件给你发一份进展摘要，就告诉他。帮他理解他应该独自花多长时间去尝试解决一个问题，以及在什么节点应该寻求帮助。对有些团队来说这可能是一个小时，对另一些团队来说可能是一周。

从新员工那里获取反馈

最后一条建议：在头 90 天里，尽可能多地获取新员工对团队视角的反馈。这是一个难得的时间段，新人带着新鲜的目光进来，往往能看到老团队成员很难看到的东西。另一方面，请记住，处于头 90 天的人缺乏整个团队所拥有的背景信息，所以对他们的观察要带着必要的保留态度去对待，而且绝对不要鼓励这个阶段的人以让现有团队感觉受到攻击的方式去批评既有的流程或系统。

与团队沟通

定期的 1-1 就像换机油；如果你跳过它们，就要做好在最糟糕的时刻被困在高速公路边的准备。

马克·赫德伦德（Marc Hedlund）

保持定期的 1-1

我曾经和一个朋友有过一次有趣的对话，他是另一位首席技术官（CTO），拥有丰富的管理经验。他有些不好意思地向我承认，他不喜欢做定期的 1-1，因为他自己一直很反感被迫与他觉得并不需要的经理做 1-1。「定期的 1-1 就像你本来好好的，却被拉去看心理医生，结果发现自己得了抑郁症。」我尊重他的经验。确实，每个人和每个团队都是不同的：他们需要不同的东西，有不同的沟通风格，关注不同的事情。话虽如此，如果你不是一位拥有多年管理经验的首席技术官，你可能应该先假设自己需要做定期的 1-1。

安排 1-1

1-1 的默认频率是每周一次。我鼓励你从每周一次开始，只有当你们双方都同意这个频率超出了你们的需要时再调整。每周一次意味着你们的交谈频率足以让会议保持简短和聚焦，也给了你错过偶尔一周的余地。当你们见面不那么频繁时，任何错过的 1-1 必须重新安排，这通常对你们双方来说都是个负担。

尽量把 1-1 安排在你们双方都可能在办公室的时间。周一和周五不适合做 1-1，因为人们有时会延长周末并错过这些天。我更愿意在上午、事情变得繁忙之前做 1-1，以避免日程滑掉或因为其他事情冒出来而被迫改期。然而，上午的 1-1 只对那些同样早到的人、以及那些不需要围绕晨会（standup meeting）腾挪时间的人有效。尊重下属的「创造者日程」（maker schedule），尽量给他们安排不太可能正好落在他们高效工作时间段中间的 1-1 时间。

调整 1-1

和生活中的大多数事情一样，1-1 不只是「设好就忘」。有许多因素需要考虑：

这一周里你和这个人有多频繁地非正式互动？

如果你和她互动频繁，你可能不需要每周留出一段专门的时间来聊天。

这个人需要多少辅导（coaching）？

刚加入团队的初级员工，可能比一个正处于顺境的资深员工更需要时间。另一方面，一个正在攻坚困难新项目的资深员工，可能更需要你腾出专门的时间来帮助她处理那项工作的一些细节。

这个人向你上传信息的程度如何？

一个不擅长向上传递信息的人，可能需要更多的面对面时间来这样做。

你和这个人的关系有多好？

这里要小心。有些人认为好的关系几乎不需要关照，于是把所有时间都花在了不好的关系上。但有很多人，包括我自己，即使在好的关系里也强烈需要定期的 1-1 时间。仅仅因为你认为你和这个人相处顺利，并不意味着她也这么认为。不要犯把所有时间都花在你的问题员工身上而忽略你的明星员工的致命错误。

团队或公司里的事情有多稳定或不稳定？

你的 1-1 中要讨论的话题之一将是公司新闻。尤其是在快速变化或不确定的时期，确保你花时间回答人们可能有的任何问题。在不确定时期保持 1-1 的规律性将有助于稳定你的团队，减缓谣言工厂的运转。

不同的 1-1 风格

既然你已经安排了这些 1-1 会议，你实际上应该用它们来做什么？我见过几种截然不同的 1-1 风格，最有效的 1-1 类型既取决于管理者，也取决于被管理者。

待办清单式会议

一方或双方带着一份要覆盖的目标清单进来，双方按重要程度依次覆盖这些目标。给出更新，做出或讨论决定，进行规划。这种风格遵循「不要用无意义的会议浪费时间」的原则，并确保事情会发生。当然，缺点是有时你会想为什么你需要以同步的方式做这件事。通常这份清单有些刻意，由一些本可以通过聊天或电子邮件处理的事情组成。如果你决定采用这种风格，确保你带来的清单以及你鼓励下属带来的清单，对 1-1 讨论来说是有意义的。确保其中有一些值得在 1-1 环境中用语言交流的细微之处。

总的来说，这种风格非常专业和高效，尽管有时有点冷淡。它迫使你的下属事先思考会议以及他们可能想讨论什么。我认识的一位经理使用一个共享的 Google 电子表格来维护一份不断更新的讨论话题清单，他和他的下属都可以访问，这样每个人随时想到什么都可以往里加，他们会在 1-1 中回顾这份清单。这也给了双方一个机会，在 1-1 发生之前看到对方在想什么，以便他们可以做准备。

闲聊式

我不是一个很有条理的人，对 1-1 待办清单有严格要求的风格与我不合拍。如果我的下属想要这些要求，我很乐意采纳，但我更喜欢更流动的风格。我在 1-1 中的目标首先是倾听我的直接下属想要讨论的任何事情。我希望会议由他们驱动，我想给他们空间提出他们认为重要的任何事。我把 1-1 看作既是规划会议，也是创造性讨论。漫无边际的 1-1 的缺点是，如果不加控制，它会变成一场抱怨会或心理治疗。有同理心的领导者有时会允许自己陷入与直接下属不健康的亲密关系中。如果你开始把大量精力花在倾听下属的抱怨并与他们共情上，你很可能会让问题变得更糟。你不必有一份待办清单，但工作场所的问题要么被处理，要么在双方同意下被搁置。反复聚焦于戏剧化的事情几乎没有价值。

反馈式会议

有时你的 1-1 会专门用于非正式的反馈和辅导。最好定期举行这类会议，尤其是对职业生涯早期的员工。每季度一次就足以让这个话题得到关注，而不会让人觉得你们谈论的全是职业发展。许多公司强迫每个人遵守特定的个人目标设定流程，所以你可以利用这段时间来回顾目标的进展，无论这些目标是正式的还是个人化的。

如果你有一个表现有问题的员工，反馈会议应该更频繁地举行，如果你正在考虑解雇某人，我建议你把这些反馈会议记录下来。那份记录将包括你们讨论过的问题，以及你与这个人设定的期望，以书面形式发送给这个人（通常通过电子邮件）。

当有人做了需要立即纠正性反馈的事情（侮辱同事、错过关键会议、使用不当语言）时，尽可能不要等到 1-1 再提供那个反馈。如果你看到或听说某个直接下属做了你想纠正的事情，尽量在事后不久接近那个人。你等得越久，你就越难开口，反馈的效果也越差。表扬也是如此！当事情进展顺利时，不要积攒你的表扬——在当下慷慨地给予它。

进度汇报式

当你到了管理经理的阶段，你的很多 1-1 会议将深入探讨他们正在监督的项目的细节，而这些细节你没有时间亲自深挖。当你只管理少数几个人的时候，你唯一应该用 1-1 来做进度汇报的情况是，有一个人在做某个你没有亲自监督的旁支项目（side project）。从你已经紧密共事的人那里获取进度报告是浪费时间，因为你听到的只是自上次站会或项目评审以来工作的增量。如果你的 1-1 经常是状态更新，试着打破这个习惯，让下属准备一些与当前项目状态无关的问题的答案，或者让他们带着问题来让你回答——关于团队、公司或其他任何事情。而对于那些真的除了进度没什么可谈的少数人，你可以把这当作一个信号，减少见面频率。

了解彼此

无论你做哪种类型的 1-1，都要留出空间去了解向你汇报的这个人，把他当作一个有血有肉的人。我不是建议你打探下属的私人生活，而是向他们表明你把他们当作个体来关心。让他们谈谈他们的家人、朋友、爱好、宠物。了解他们迄今为止的职业生涯，问他们长期职业目标。不必只关注下一个技能或晋升。表明你投入于在现在和未来帮助他们。

换换形式

为了多样化，你可以把 1-1 做成散步会议（walking meeting），或者喝杯咖啡、吃个午饭，走出办公室。只要记住，当你不做笔记时，你可能会忘记一些重要的事情，所以尽量不要依赖这些形式进行关键对话。我们许多人都有塞得满满的办公空间，私密会议室少之又少，但尽可能把 1-1 放在私密场合进行，这样你就可以自由地讨论敏感话题，而不必担心被听到。

最后一条建议：尽量把笔记记在共享文档里，由你这位经理担任记录员。为你管理的每个人，维护一份不断更新的共享文档，记录你 1-1 中的笔记、要点和待办事项。这有助于你保持关于已经发生的事情的上下文，也有助于记住反馈是在何时、以何种方式给出的。当你写评估或传达反馈时，它也是必不可少的参考历史记录。如果你在会议期间因为面前开着电脑而分心，那就留出时间在结束时补记笔记。

好经理，坏经理：微观管理者与授权者

Jane 把一个大项目交给了她的技术负责人 Sanjay 去管理。项目需要在月底前完成，这本来应该没问题，但 Jane 担心截止日期会滑掉。于是她开始参加所有她平时不参加的站会，并直接向团队询问他们的阻塞问题（blocker）。她翻看项目工单（ticket），做了一堆评论，甚至把其中一些重新分配给其他团队成员。当她发现 Sanjay 和产品经理（product manager）决定降低某个功能（feature）的优先级时，Jane 认为该由她来接管这个项目了，她告诉 Sanjay，从现在起将由她来管理日常事务。

毫不奇怪，尽管项目最终成功交付，Sanjay 还是告诉 Jane，他觉得自己不再想当技术负责人了。事实上，他似乎没什么精力，他平时的投入和勤奋被早退和在会议上沉默寡言所取代。她最好的团队成员似乎一夜之间变成了低绩效者。发生了什么？

微观管理（micromanagement）会悄悄爬上你的身。一个不容滑期的、高压的项目看起来有风险，于是你介入去纠正。你委派了一些事情，但随后发现你不喜欢团队为实施它而做的技术选择，于是你让他们重写。你强迫每个人在做决定之前先来找你，因为他们就是不能被信任去做正确的事，或者错误太多，而总是由你来买单。

现在，让我们看看 Jane 的同事 Sharell。Sharell 给了 Beth 她主持的第一个大项目。Sharell 知道这个项目需要按时交付，但她没有列席每一次会议、追踪每一个细节，而是与 Beth 一起确定她应该参加哪些会议，并帮助 Beth 理解哪些细节需要上报给 Sharell。有了这种支持，Beth 对主持项目充满信心，同时也知道 Sharell 是她的后盾，当事情在最后阶段变得紧张时，Beth 借助 Sharell 的帮助削减范围，让项目按时交付。Beth 带着更足的信心离开这段经历，准备好承担更大的项目，为 Sharell 更努力地工作。

Jane 和 Sharell 的决定凸显了微观管理者和有效授权者（delegator）之间的细微差别。Jane 和 Sharell 都在试图委派一个高优先级项目的管理，以培养团队中的新领导者。然而，Jane 最终从未放弃控制权并削弱了 Sanjay，而 Sharell 则向 Beth 明确了目标是什么、她的责任是什么，并提供支持和指导来帮助 Beth 成功。

微观管理最难的地方在于，有些时候你确实需要这样做。初级工程师常常在细致入微的监督下茁壮成长，因为他们想要那种具体的指导。有些项目会脱轨，你偶尔需要推翻下属做出的、可能产生巨大负面影响的决定。然而，如果微观管理是你的习惯，是你领导团队的默认方式，你最终会像可怜的 Jane 一样，无意中削弱那些你本应培养和奖励的人。

信任和控制是围绕微观管理的主要问题。如果你在微观管理某个人，你之所以这样做，很可能是因为你不信任任务会被正确地完成，或者你想非常紧密地控制结果，使它符合你的精确标准。当有才华的工程师成为经理时，这种情况经常发生，尤其是当他们以自己的技术能力为傲时。如果你对团队的价值已经从你擅长的东西（写代码）转变为你还不知道如何做好的东西（管理他人），你很容易把下属当成「迷你版的自己」（mini-me）来对待。当一个截止日期滑掉时（这是不可避免的），你把这看作是你未能足够精确地控制局面的失败，于是加大关注力度。你抓到某件事没有按你预期的方式进行，这似乎强化了你的信念：微观管理团队是对你时间的合理利用。

自主权（autonomy），即对自己的部分工作拥有控制权的能力，是激励（motivation）的一个重要要素。这就是为什么微观管理者很难留住优秀团队。当你剥夺了有创造力和才华的人的自主权时，他们会很快失去动力。没有什么比感觉自己做不了任何一个决定，或者感觉你做的每一份工作都必须被你的经理双重、三重检查更糟糕的了。

另一方面，授权（delegation）不等于甩手不管（abdication）。当你委派责任时，你仍然被期望在必要的时候参与进来，帮助项目成功。Sharell 并没有抛弃 Beth——她帮助 Beth 理解了新角色中的责任，并在需要时在场支持项目。

有效授权的实用建议

重要的是要记住，成为一个好的领导者意味着善于授权。

用团队目标来判断该深挖哪些细节

当你想微观管理时，问团队他们如何衡量自己的成功，并要求他们持续向你展示这一点。然后，如果有必要，管住你的手，但等上一两周，看看他们会给你什么。如果他们没有什么可分享的，这说明你可能需要纠正方向，而这很可能意味着要深挖更多细节。

你如何决定什么时候开始要求这些信息？我的理念很简单：如果团队在朝着目标取得进展，系统是稳定的，产品经理是满意的，我很少深挖细节，最多做一个粗略的概览。然而，这需要目标配有一个计划，让人们能够朝着它取得进展，还需要一个能给你另一个视角的产品经理。当你管理一个没有清晰计划的团队时，用你想要监控的细节来帮助他们制定一个。这个月、这个季度或今年，你让他们对什么负责？如果你回答不了这个问题，第一步就是帮助团队创建这些目标。

先向系统要信息，再去找人

作为工程师，我们有一个优势，因为系统可以把有价值的信息推上来，而团队几乎不需要做什么。如果你想知道工作的状态，看版本控制系统（version control system）和工单系统（ticketing system）。如果你想知道系统有多稳定，订阅告警信息，看指标（metrics），跟踪值班中发生了什么。最糟糕的微观管理者是那些不断索取他们自己很容易就能得到的信息的人。要求状态摘要是可以的，利用你的团队来从所有这些来源中浮现出最重要的信息也是可以的，但要轻触轻放。团队不会因为把一半时间花在为你收集你很容易就能自己找到的信息上而变得高效或快乐。记住，这些信息只是上下文的一部分，不是全貌，而且如果没有刚才讨论的目标，它们毫无意义。

根据项目阶段调整关注点

如果你直接管理一个或两个团队，你应该把项目状态的所有细节都作为你常规团队流程（如晨间站会）的一部分来了解。不同的细节在不同的项目阶段很重要。在项目的开始和设计阶段，你可能想更多地参与，以便促成一套好的项目目标或一个好的系统设计。当接近交付日期时，进度细节变得更加重要，因为要做出的决定更多，那些具体信息传达了更多可操作的信息。但在正常的工作流程中，知道什么在推进、什么比预期花费了更长时间，通常就足够了，尤其是如果你能利用这些信息重新调配工作或帮助一个苦苦挣扎的团队成员。

为代码和系统建立标准

我是那种技术底蕴很深的经理，对系统应该如何构建和运营有自己的看法。放手对我来说一直很难，所以我制定了一些指导方针，帮助我对这些问题周围的结构感到更自在。作为一个团队制定基本标准，有助于每个人在代码评审（code review）和设计评审中进行沟通，也使提供技术反馈的过程非个人化。对我来说，基本标准意味着诸如此类的事情：每次变更期望有多少单元测试（unit testing）（一般来说，某些测试总是必需的），以及技术决定应该在什么时候接受更大群体的评审（比如有人想给技术栈添加一门新语言或新框架时）。和设定目标一样，在这里建立标准有助于人们知道他们在创建技术时哪些细节是值得思考的。

以中立乃至积极的态度对待信息的公开分享，无论好坏

考虑这个场景：Jack 在一个项目上遇到困难，但一直没有为他的问题寻求帮助。你终于听说了他的挣扎。这时，合适的做法是告诉 Jack，他需要更主动地分享他的进展，即使这意味着承认他在挣扎。你可以让 Jack 每天给你更新，作为一种帮助，但我只会在短时间内使用如此多的结构。这里的目标不是用微观管理来惩罚他未能沟通状态，因为你只是在惩罚你自己，并妨碍他为自己工作负责。相反，你的目标是教 Jack 他需要沟通什么、何时沟通、如何沟通。不过，有一句告诫：如果你把一个苦苦挣扎的工程师或项目当作个人或管理者的大失败，她会感受到那种指责和批评，而在未来，她不会给你更多信息，反而会继续向你隐瞒，以此避免指责，直到为时已晚。故意隐瞒重要信息是一种失败，而卡在一个问题上或犯了一个错误，往往只是一个学习的机会。

从长远来看，如果你不学会放手细节、授权并信任你的团队，你很可能会个人受苦。即使你的团队没有辞职，随着责任的增加，你最终也会工作越来越长时间。如果你已经处于这种境地，试着限制你允许自己在一周内工作的小时数。如果这周你只被允许工作 45 小时，你会用这 45 小时做什么？你真的会花其中 5 个小时去挑剔一个初级开发者的代码吗？你会仔细检查某个进展顺利的项目的细节，寻找任何微小的错误吗？还是会把注意力转向更大的问题？你会拿出一些时间专注于未来，而不是当下时刻的细节吗？你的时间太宝贵了，不能浪费，你的团队值得一个愿意信任他们独立做事的管理者。

营造持续反馈的文化

当我说绩效评估（performance review）时，你脑子里闪过什么？你会畏缩吗？你会为浪费时间翻白眼，或者一想到要做所有那些工作就呻吟吗？你会因为听到令人惊讶的新缺点而涌起一阵恐惧吗？还是你会有一点紧张的小兴奋，想听听别人怎么看你？

如果绩效评估让你发抖，你并不孤单。不幸的是，评估流程并不是每个经理都会认真对待或以成熟的方式处理的。既然你现在管理着人，你在塑造直接下属的评估体验方面有很大的力量。那种体验在评估写出来之前很久就开始了。它始于持续反馈（continuous feedback）。

持续反馈，最重要的是，一种定期分享正面和纠正性反馈的承诺。与其把这些评论留到评估周期，经理和同事被鼓励在事情进展顺利时指出，并在问题发生时提出。一些公司已经开始采用软件，让团队能够轻松提供持续反馈并随时间跟踪这些反馈，但最重要的是团队已经采纳了频繁提供反馈的文化。对你来说，作为新经理，养成持续反馈的习惯是在训练你关注个体，这反过来让你更容易发现和培养人才。你也在练习与个体就他们的表现进行小而偶尔棘手的对话的艺术。很少有人对提供一对一的表扬或纠正感到自在，这能帮助你克服尴尬的感觉。

有一些步骤可以让你擅长提供持续反馈：

了解你的人。 成功提供持续反馈的第一个必需部分是对团队中个体的基本了解。他们有什么目标（如果有的话）？他们的优势和劣势是什么？他们目前在什么级别运作，要升到下一个级别他们需要在哪里改进？你可以通过阅读他们以前的绩效评估（如果你有的话）获得其中一些了解，但你还需要和团队中的每个人坐下来，询问他们对所有这些问题的看法。这种了解给了你一个基线，你可以用它来构建你的反馈，并帮助你找到一些你可能想关注的东西。
观察你的人。 如果你不注意，你就无法提供反馈。如果非要说的话，我认为尝试持续反馈循环的最佳结果不一定是实际产生的反馈，而是这种努力迫使你开始关注团队中的个体。在你的管理生涯早期，当你可能还只管理着几个人时就开始这个习惯，有助于你锻炼那些观察的肌肉。练习首先在团队中寻找才能和成就。好的经理有一种发现才能、帮助人们更多发挥自己优势的诀窍。是的，你也会想寻找弱点和需要改进的地方，但如果你把大部分时间花在试图让人们纠正弱点上，你最终会得到一种感觉更像持续批评的风格。有时候有一个目标是有帮助的，所以给自己布置任务，定期识别值得表扬的人。采纳积极认可的习惯迫使你留意值得表扬的事情，这反过来让你关注个体正在给各个项目带来什么。你不必公开做这件事，但每周至少应该有一件你可以认可团队中某个人的事情。更好的是，为你汇报给你的每个人都寻找每周可认可的事。
提供轻量、定期的反馈。从正面反馈开始。给正面反馈比给纠正性反馈更容易也更有趣。作为新经理，你不必一上来就跳进辅导的深水区。许多人对表扬的反应比对纠正性反馈更好，你可以通过强调他们做得好的事情，用赞誉（kudos）引导他们走向更好的行为。正面反馈也会让你的下属更有可能在需要给他们批评性反馈时听你的。当他们相信他们的经理看到了他们做的好事时，他们会更愿意听那些他们可能改进的地方。在明显的失误的情况下，最好快速给出批评性反馈，但持续反馈不仅仅是当下的纠正。利用持续反馈的习惯，在你开始注意到事情不对劲时就谈论它们，而不是等到评估周期才进行那些不舒服的对话。加分项：提供辅导。归根结底，当你作为经理把反馈与辅导（coaching）结合起来时，持续反馈效果最好。随着情况的出现，用辅导来问人们他们本可以做得有什么不同。当事情进展顺利时，表扬他们，但也提出建议，说明未来什么可以做得更好。基于辅导的持续反馈意味着超越一句简单的「干得好」，真正深入细节，与你的直接下属结成伙伴关系，你们俩一起努力帮助她成长。为什么我把辅导列为加分项？它并不总是把工作做好的核心需求，而且很多时候你既没有资质也没有能力为团队中的每个人提供他们需要的辅导。辅导对你职业生涯早期的团队成员，或者那些有晋升潜力或渴望的人最重要。许多人会满足于做他们知道如何做好的工作，只要他们做得足够好，试图辅导他们就不是对你时间的好利用。把你宝贵的辅导时间留给那些乐于接受的人。

绩效评估

持续反馈，即使只是对好工作的定期认可，也是实操型经理工具包中的一个重要工具。然而，它不能取代更正式的、基于 360 度的绩效评估流程。

360 度模型（360 model）是一种绩效评估，除了一个人的经理之外，还包括他的队友、任何向他汇报的人、他经常互动的同事的反馈，以及自我评估（self-review）。例如，一个没有直接下属的工程师可能会征求她团队中另外两名工程师、她指导过的新员工、以及她合作的产品经理的评估。绩效评估要花很长时间，因为你需要从许多不同的人那里给予和接收反馈。作为经理，你随后必须收集所有反馈，并为被评估的人总结。

绩效评估通过提供一个宝贵的机会来综合关于一个人的大量信息，回报了所花的时间。除此之外，360 度评估至少让你对其他人对你的直接下属的看法有一个高层次的了解。自我评估让你了解你的人对自己、他们的优势和劣势、以及一年来的成就的看法。撰写总结评估给了你一个机会，让你能专注在个体上超过几分钟，并在一个更长的时间段内看大局。所有这些都应该帮助你看到一些你在日常持续反馈的过程中可能忽略的模式和趋势。

绩效评估会出问题，因为人们没有被给予时间优先处理它们，而且许多人觉得它们难写。它们会出问题，因为我们倾向于记住并过度强调最近发生的事情，而忘记六个月或一年前发生的事情。它们会出问题，因为我们都会遭受各种我们可能意识到或意识不到的偏见（bias），我们倾向于通过那些偏见的镜头来评估人，批评某些人的一些行为，而我们在别人身上甚至注意不到。所有这些都是真的，你可能会看到它们全部上演。尽管如此，这个流程还是非常有价值的，作为经理，你有机会根据你如何处理它来让它变得更有价值或更没价值。

撰写并传达绩效评估

以下是一些成功撰写和传达绩效评估的指导方针。

给自己留足时间，尽早开始

这个流程不是你能在一小时内搞定并做好的。你手头有一百万件事，但要计划花整块、不间断的时间来写评估。如果需要，在家工作。你欠你的团队足够的时间来阅读收集到的反馈、消化它、并很好地总结它。我的建议是从阅读收集到的评估并做一些笔记开始，在尝试写完整总结之前先处理一下信息。给自己足够的时间来写作，并在提交评估之前至少回来一次看你写的东西。

大多数公司期望经理阅读反馈，并在写总结时将其匿名化，但有些公司有开放的流程，原始的同事反馈对被评估的人可见且可识别。即使在开放的流程中，作为经理，你仍然应该阅读那份反馈，并将其作为你撰写评估的一部分，因为经理评估仍然经常被认为是所有评估反馈中最重要的总结。

尽量覆盖全年，而不仅仅是过去几个月

如果你保留每个人全年发生的事情的笔记，这会更容易。一个策略是保留你的 1-1 的持续总结，包括任何已传达的反馈。如果你没有这样做，我鼓励你翻看你的电子邮件，记住哪些项目上线了，逐月回顾发生了什么活动，把自己放回到那个时间段的视角中。看全年的目标是不仅识别早期的成就，还要识别自那以后你看到的成长和变化。

使用具体例子和同事评估的摘录

如果需要，将同事评估匿名化。如果你不能用具体例子来支持一个观点，问问自己这个观点是不是你该在评估中传达的东西。强迫自己具体化会让你远离基于潜在偏见的评估写作。

在成就和优点上多花时间

你想庆祝成就，谈论什么进展顺利，并为好工作给予大量表扬。这不仅适用于写作过程，也适用于——尤其是——传达过程。不要让人们跳过好的部分去纠结于改进的方向，尽管许多人都会想这样做。那些优点是你用来决定人们什么时候应该被晋升的，把它们写下来并反思是很重要的。

谈及改进方向时，保持聚焦

写改进方向往往是反馈中棘手的一部分。在最好的情况下，同事反馈中会有几个清晰的主题，你也观察到了这些主题，可以加以评论。以下是我见过的一些主题的例子。有些人：

难以对干扰说「不」，最终去帮助其他项目而不是完成自己的项目
工作做得很好，但很难与他人共事，在会议、代码评审或其他协作活动中往往过于挑剔或粗鲁
难以把工作分解成中间交付物（intermediate deliverable），不能在规划、设计与把事情做完之间取得平衡
和其他工程师合作得很好，但与其他部门或团队合作得不好
难以遵循团队公认的最佳实践，走捷径，或以其他方式做马虎的工作

更常见的是，你会得到大量零散的反馈，最多只是适度有用。有些人似乎在努力找话说，另一些人会有一种特别苛刻的印象，而似乎没有其他人认同。尤其是在零散反馈的情况下，确保你在传达之前看到的反馈是有意义的。例如，如果只有一个评审人提到工作马虎，问题是工作确实马虎，还是评审人的标准比团队其他成员更高？在这种情况下用你的判断力。如果反馈似乎对这个人有价值去听，就分享它，但不要盲目地报告所有的积怨。

如果你几乎没有什么有意义的改进反馈，那该怎么办？这表明这个人已经准备好被晋升或被给予更有挑战性的工作。如果这个人在她自己的级别上做得很好，但还没有准备好晋升，反馈应该指出她需要扩展的一两项技能才能有资格晋升。有些人可能永远不需要从当前级别晋升，但科技行业的性质决定了技能需要不断刷新才能保持最新，所以你也可以关注新的技术学习机会。

避免大的意外

在评估传达之前恰当地设定期望。如果有人全面表现不佳，评估不应该是他第一次得到那个反馈。同样，如果有人最近刚被晋升，你可能想让她做好准备：她将被以更高的标准来评估。

安排充足的时间讨论评估

我通常在评估预定日期的前一天晚上，在人们离开时给他们一份评估打印件。这种做法让他们有机会在家里读它，然后带着准备好的状态来开会讨论它的内容。即使他们已经拿到评估并读过它，我仍然会花时间逐节过一遍，从优点和成就开始。再说一次，不要让他们跳过这部分，直接跳进改进方向。许多人对被长时间表扬感到不自在，但跳过那一节会削弱它在强化和鼓励他们才能方面的价值。

一些评估用分级评分（scaled ranking）来总结，比如 1 到 5 的数字或等价的文字（「未达预期」「达到预期」「超出预期」）。如果你必须这样做，要预期到：对任何没有得到最高评级的人来说，这是评估中最难讨论的部分。根据我的经验，人们不习惯被告知他们只是达到了预期，尤其是那些职业生涯早期的人。准备好深入讨论这个分数的原因，包括这个人如何能达到更高分数的例子。

问问 CTO：识别潜力

有没有识别潜力的好方法？所有的潜力看起来都一样吗？一个人有潜力到底意味着什么？

人们在理解潜力时经常犯一个关键错误。他们把它看作一套天生的特质，或者某种可以纯粹从资历中确定的东西。「他上过好学校，所以他潜力很大！」「她很能说会道，所以她潜力很大！」或者，最直白的，「他又帅又高又是男的，所以他潜力很大！」偏见让我们假定潜力，而且，让我们在人们已经表明他们的「潜力」是一种幻觉很久之后，仍然给他们怀疑的好处。

我要给你们所有人一个建议。一个从未表现出合理绩效的人，并且已经在公司待了足够长的时间让你观察到他的绩效，很可能实际上没有潜力，至少在那家公司内是这样。无论他的学校有多好，她有多能说会道，他有多高……如果员工在公司待了一段时间却没什么可展示的，你想象的所有那些潜力就是那样——你想象（或你的偏见）的产物。

真正的潜力会很快显露出来。它表现为努力工作、多走一英里，对问题提出有见地的建议，以及在以前被忽视的领域帮助团队。有潜力但尚未表现出同等绩效的人，正在以一种其他人没有的方式为团队挺身而出，即使她的工作进展缓慢。很少见到一个人在公司的真正潜力与糟糕的绩效并存，尽管你可能会看到略低于中等水平的绩效。通常解决这个问题的办法是把这个人挪到一个他的潜力可以发挥的地方。一个有着强烈视觉设计感但在完成编码工单的日常工作中挣扎的人，可能在 UI/UX 岗位上做得更好。一个讨厌规划的出色救火队员，可能更适合以运维为导向的团队。

不要混淆小学老师可能描述的「潜力」和你在乎的那种潜力。你不是在塑造幼小的心灵；你在让员工做工作并帮助你发展公司。因此，潜力必须与行动和产生的价值挂钩，即使那不是你预期看到产生的价值。你越早克服「高潜力的人没有成功」的失望，你就能越早识别你团队中真正的高潜力明星，并充分培养他们。

培养职业生涯

我最关键的一次晋升发生在我做金融的时候。金融界有一种奇怪的授予头衔的方式。追溯到公司建立在合伙制模式上的年代，往往只有少数几个「公开」头衔：助理（Associate）、副总裁（Vice President）、董事总经理（Managing Director）和合伙人（Partner）。副总裁头衔是一个关键的飞跃。获得它（或曾经）是一个人已经证明自己值得在公司建立长期职业生涯的标志。因此，你花多少时间获得副总裁头衔是你未来成功的强烈信号，而获得晋升是一个复杂的过程，每年只做一次，由高级经理们运作。

我的经理向我解释过两次。第一次，当我获得自己的副总裁晋升时，他带我过了一遍我们将要收集的、用来支持我的案子的所有材料。交付的项目，是的，但也有领导力的迹象，以及把我推到我直接团队之外的工作。我第二次经历这个过程，是在我为一位向我汇报的人准备材料包时。我们收集了各种各样的证据，包括候选人收到的一封称赞他是楼层消防队长（floor fire warden）的信。这两次晋升都成功了，但我毫不怀疑我们的成功至少部分是因为我的老板/导师（boss/mentor）确切地知道如何玩这个游戏。

如果你是经理，你将在让你的团队成员获得晋升方面扮演关键角色。有时决定谁获得晋升完全取决于你，但更常见的是，晋升会由你的上级管理层或一个委员会审查。所以你不仅需要对谁值得晋升有很好的判断，还需要为他们的晋升提出理由。

这个流程通常是什么样子的？一般来说，你一年看几次你团队里的人，考虑他们的职级，问自己，这些人中有谁接近下一个级别吗？就职业生涯早期的员工而言，答案很可能是肯定的。如今，刚大学毕业的人往往在入职的头几年里至少晋升一次，因为他们通常是以「要么晋升要么走人」（up or out）的级别被招进来的。

为了说明，以著名的大公司（Famous BigCo）为例。著名的大公司以 E2 级别（E1 级别留给实习生）从大学招聘工程师。著名的大公司有一条政策：一个工程师在该级别待了两年后没有任何超越 E2 级别的迹象，就没有在这家公司的前途。它对 E2-E4 级别有这条政策，但在 E5，你可以永远留下来。

所以，如果你有一个由 E2 和 E3 组成的团队，你需要每两年左右就让他们准备好可以被晋升。幸运的是，这通常是直截了当的。只要你不阻止他们晋升，他们就会被这个流程推着前进。你对这群人的工作是确保他们学会估算自己的工作，大致在估算范围内完成它，并从错误中学习。晋升的证据往往采取以下形式：他们独立完成的项目或功能，参与值班轮换或其他支持工作，以及参与团队会议和团队规划。

既然你进入了管理岗位，你需要开始做的重要事情是了解你公司的游戏怎么玩。每家公司都有自己的晋升流程变体，你可能是以幸存者的身份进入这个角色的。如果你不知道它是怎么做的，向你的经理请教。这些决定是怎么做出的？你需要多早开始准备材料包？任何一年里可以发生的晋升数量有限制吗？在你学习怎么玩这个游戏时，我鼓励你对团队保持相当透明。当成员表达晋升愿望但他们没有强有力的晋升理由时，告诉他们这个流程包含什么，会帮助他们理解他们可能需要改变什么。

你还应该准备好开始识别值得晋升的项目，并尝试把这些项目交给接近晋升的人。作为经理，你处于一个很好的位置来识别团队接下来会有什么。根据工作分配的方式，你可以直接把这些项目分配给人们，或者鼓励人们自愿参加那些对他们来说是延展目标（stretch goal）的项目。留意让你的团队成员延展自己、成长的机会。

随着你的团队变得越资深，这项工作确实开始变化。许多人不会继续超过某个级别晋升，至少在同一个公司或团队内不会。随着人们变得更资深，他们展示晋升所需的领导力或影响力广度（breadth of impact）的机会更少。有时你对此无能为力，也许只能把他们推荐给公司不同部门的其他领导者，寻求指导或引导。失去他们可能让你很痛，但他们可能在另一个团队，甚至另一家有着新挑战的公司里过得更好。

许多公司期望你在晋升到下一个级别之前，就以那个级别行事。这种做法是为了防止「彼得原理」（Peter Principle），即人们被晋升到他们无法胜任的级别。它也表明团队里还有空间容纳另一个在那个级别行事的人。在思考团队成员的职业时记住这一点。如果你的团队没有成长潜力，因为没有空间让人在更高级别工作，这可能是一个信号：你需要重新思考工作的完成方式，以便让个体承担更大的责任。

挑战性情境：解雇表现不佳者

任何经理都必须做的最难的事情之一，就是因表现不佳而解雇某人。

这件事很难写，因为解雇员工的许多行为如今都受人力资源部门支配，即使在小公司也是如此。这有好有坏，但可以说最好的部分是，作为经理，你将有一个流程和程序可以遵循。当听说有人表现不佳时，许多公司会让你给这个人写一份叫做绩效改进计划（performance improvement plan）的文件。这是一套明确定义的目标，这个人必须在固定期限内实现。如果她设法实现了它们，那么她就被移出计划，一切顺利；否则，她就被解雇。取决于公司，这样的计划实际上可能是扭转员工的努力，但通常计划被写成一种这个人不可能在指定时间内实现目标的方式，它只是给某人在被解雇之前时间找另一份工作的慷慨方式。

无论你公司的程序是什么，引导某人离开（coaching someone out）的过程应该在任何绩效改进文件提交给人力资源部门之前很久就开始，也远在实际解雇行为之前。管理的基本规则之一是「没有意外」规则，尤其是负面意外。你需要理解一个人应该给你什么，如果这没有发生，要尽早、经常地向她明确她没有达到期望。

理想情况是你确切知道她的工作应该是什么，如果她没有做，你可以说：「你没有做 X、Y 和 Z。多做那些事情。」当然，像所有完美的情况一样，现实很少如此简单。

一个常见的、直截了当的场景更接近下面这样。你的员工 Jane 已经跟了你几个月。她在入职流程中看起来有点慢，但你给了她怀疑的好处；代码库不是完美的状态，而且新员工头几个月有很多业务行话要学。然而，已经六个月了，当你回顾那段时间，你看到 Jane 这边几乎没什么成就。事实上，她做过的少数几件事也不顺利——它们非常晚，非常多 bug，或者两者兼有。

这种情况在纸面上听起来直截了当。告诉 Jane 她没有达到期望，她的工作太慢或做得不好，给她一个严格的可交付物。但 Jane 当然有借口，其中一些是可信的。入职流程不好。她的第一个月被公司派对打断了，然后你出去度假一周，她一直没有人可以问问题。事实上，听起来问题有点像你和团队，根本不是她。

这种情况就是为什么你要尽早、经常地开始给反馈，并保留你一直在传达的反馈的记录。反馈，无论正面还是负面，都应该是一场对话。如果你避免处理负面反馈，直到它积累到沸点，你会被一堆借口迎接，然后你怎么办？一些经理会冒险无视借口，然后一个接一个地失去员工，因为他们加入了一个不欢迎他们的团队，这个团队没能做好入职、辅导，也没能给员工清晰的目标。另一方面，一些经理会接受任何借口，直到问题再也无法掩盖，团队对管理层在那个落后的员工问题上的不作为感到愤怒。

在任何人力资源部门活跃、并且需要标准绩效改进计划的环境中，要解雇某人，你总是需要有负面反馈的记录。如果你没有人力资源部门，我建议你仍然以书面形式给人清晰的改进反馈，附上改进的时间表，并让他们也以书面形式确认（电子邮件也可以）。这不仅在法律上保护你，也帮助你公平对待你的员工。

最后一条警告：不要把任何你并不乐意失去的人放进计划里。大多数聪明的员工会把这种正式警告当作组织不适合他们的信号，并尽快离开。我曾经听说过一个故事，一位出色的工程师被他的经理放上了一个突然的绩效改进计划，因为组织里有人抱怨他退出了一个项目。这位经理没有关注过情况，并且已经批准了这位工程师专注于其他方面，却屈服于压力制定了一个计划，除了毒化这位工程师可能对经理和公司抱有的任何善意之外，毫无作用。毫不奇怪，这位工程师很快就辞职了，尽管他轻松实现了改进计划的目标。

问问 CTO：引导员工离开公司

我有一个似乎卡住了的员工。他在公司待了几年，工作做得还行，但我不认为他有潜力在我们的团队进一步晋升。每次他问他要做什么才能达到下一个级别，我都告诉他，但他随后又回到他的舒适区，无论怎么推动似乎都不会带来任何改变。我该怎么办？

这是经理们必须处理的相当常见的情况。你有一个在组织中已经到顶、似乎正在失去能量的员工。他在自己的级别达到了期望，但尽管你付出了努力，他还是想不出如何成长到足以达到下一个级别。也许是时候引导他离开了（coach him out）。

许多组织对职业生涯早期的员工有一条「要么晋升要么走人」的规则。大多数工程职业阶梯的入门级别期望那些级别的人在特定时间内进步，如果没有，他们就没有达到期望，将被解雇。一般来说，你要确保长期员工能够独立完成他们的日常工作，而不需要大量监督或帮助。然而，一旦人们过了这些要么晋升要么走人的职业节点，当他们卡住时你该怎么办？

有些人会很乐意在整个职业生涯中作为某个级别的资深工程师或经理巡航，如果你们双方都对工作满意，那没什么不对。其他人，比如你的员工，想要进步，但出于某种原因似乎无法在你的团队里做到。你有责任对你的员工清楚地说明情况就是如此。这就是「引导离开」（coaching out）的意思。把情况向他说明白。你已经反复告诉他下一个级别是什么样子，他一直未能表现出他能在这个级别工作，所以你不认为你的团队是他发展职业生涯的正确地方。你不是在解雇他，但你在告诉他，如果他想进步，他就需要往前走。

给员工一个在组织的其他部分或另一家公司找到工作的机会。当他找到时，让他开心地离开，并尽你所能保留善意。那些因为看不到共同未来而分手的前情侣可以继续做朋友，前员工也一样，他们只是需要一个不同的团队或公司来发光。

评估你自己的经历

你和你的直接下属建立定期的 1-1 了吗？
你最后一次和你的下属谈论他们的职业发展是什么时候？如果超过三个月了，你能确保把它放进你接下来的 1-1 里吗？
你在过去一周里给下属反馈了吗？你最后一次在团队面前发放赞誉是什么时候？
上一次有人做出需要纠正的行为是什么时候？你花了多长时间给出纠正性反馈？你是在私下给的反馈，还是公开做的？
你曾经收到过一份让你觉得浪费时间的绩效评估吗？它缺少了什么本可以让它更有价值的东西？
你收到过的最有用的绩效反馈是什么？它是如何传达给你的？
你知道你们公司的晋升流程是如何运作的吗？如果不知道，你能请人带你过一遍吗？