选择管理路径

几个月前，我的一位朋友联系了我，因为他正在考虑从个人贡献者(IC)角色转变为工作中的工程管理(EM)角色。考虑到我曾来回跳槽几次，他想向我请教一下我认为的权衡是什么，以及我最终重返管理层的原因。

他不是唯一一个就这个话题联系我的人(事实上，一周后，另一个朋友联系了我)，所以我想在整理我的想法后写一个博客会很有用。我会把这篇文章分成两个部分：一些重大的，也许是不直观的变化，与考虑从IC转到EM的人有关，以及我的个人动机。

我曾经听到一些关于跳槽到管理层的半开玩笑的建议：“如果不再编码的想法让你的生活化为灰烬，那就不要跳槽到管理层去。”事实证明这是真的。

“经理们还应该编码吗？”问题可能是关于角色转换争论最激烈的问题，我站在一边：不。也许在转换之后不会马上进行，因为您的团队可能足够小，需要您的技术贡献，或者您可能仍然是主题专家，但是随着您在管理阶梯上的攀登，您将进一步远离任何实现工作。事实上，我会争辩说，执着于编码工作的经理们阻碍了他们团队的产出。

一种流行的假设是，这是你的技术技能变得陈旧的流出。不是这样的。我并不是说这是不可能的，特别是在一个涉及行业实践核心结构转变的非常长的时间表上，但我认为这样的转变(以及假设有强大的技术基础，你无法加快步伐-参见“慈善专业的工程师/经理钟摆”)是罕见的。良好的软件工程实践的原则是永恒的，但是任何一条轨道都需要关注。这并不是说你不能编程，而是你不应该这么做--你的日程安排根本不允许这样做。

作为一名经理，您的日程安排将不可避免地变得如此不确定，以至于您的团队其他成员不能依赖您以预期的节奏发布代码更改。您将无法响应涉及您以前编写的代码的问题或请求。当需求更改时，您将没有带宽来更改该代码的日期。从总体上看，这是一个问题，因为团队协同分发和发布工作是成功软件开发的支柱。

一般来说，作为IC，影响的衡量标准是您个人的技术贡献：工作范围、成功部署到生产中的代码、RFC建议和审查等。虽然这通常涉及到与他人合作，但在一天结束时，您在很大程度上控制了决定您产出的因素。你可以坐在办公桌前多工作几个小时。您可以编写更多/更好的代码。您可以添加更多测试。你的技术努力的成败更多地与你的努力有关，而不是其他任何人的努力。

我关于管理的一个信念直接借鉴了安迪·格罗夫(Andy Grove)的“高产出管理”(High Output Management)：衡量一个管理者的标准是他们下面组织的产出。不幸的是，构成团队产出的因素比构成IC产出的因素要模糊得多。而且，这并不像将IC的所有离散技术输出相加那么简单，因为团队输出是通过随着时间的推移交付协调一致的高质量项目来衡量的。

一支才华横溢的IC团队提供高质量的工作。但他们在团队或更大的组织内感觉不到任何认同或同志情谊，整个团队在一年内就会扭亏为盈。不断的招聘和入职使得很难依赖这个团队来完成时间敏感的任务或对部分代码库的可靠所有权。

一组团队花更长的时间在一个项目上工作，而这个项目在启动前就被扼杀了。事实证明，这不是建造的正确之处。那支团队中的IC完成了高质量的工作，但结果是徒劳的。

一支才华横溢的IC团队提供高质量的工作，但他们有一两个非常资深的才华横溢的混蛋。其他团队不喜欢与这些聪明的混蛋打交道，所以他们避免与团队互动。因此，这个团队的高质量工作不会对组织产生影响。

这些场景之间有一个共同的主线，那就是IC正在提供高质量的工作。另一条线索是，高质量的工作最终不会给组织带来好处。留住问题、做错了事、有毒的文化--这些都是管理失败的例子。

没有建立无毒文化的清单，也没有IC想要留在的团队的清单。工程团队是幸运的，如果他们每个季度都被告知要建造什么，以满足公司日益增长的技术和业务需求，但我从来没有发现这是真的。对这些想法的模糊定义使管理变得困难。这给管理者带来了负担，要保持他们自己的警觉水平，确保所有这些事情--个性、优先事项、文化等--都保持在正轨上。

作为一个小的但说明性的例子，作为一名IC不同于经理的东西：早上的单口相声。当我还是一名工程师的时候，在早上的单口相声中，有好几次我都没有注意到，除非我给出了我自己的最新消息。坦率地说，这似乎无关紧要，特别是如果其他更新涉及的工作流与我目前关注的工作流不同的话。

作为一名经理，我不能不关注站立期间的每一次更新，因为我最终要对每一项工作流程的交付负责。我不仅要找出全队的拦网队员，还要知道什么时候初级队友听起来像是在转轮胎，或者什么时候高级队友听起来筋疲力尽了。在我每周1：1的时间里，我会在脑海中记录我需要跟进的要点，哪些项目感觉他们偏离了原来的时间表，或者我的队友在整个组织中遇到了沟通问题。队友会不会不知所措？是不是有队友在拖后腿？如果我听到报告说有队友在会议中中毒怎么办？这些都是我脑海中不断浮现的担忧。

从第一点开始，这就是非确定性计划的根源。说我闻到了这些事情中的一件--一个队友非常不投入和不快乐？一个项目出轨了吗？一个队友突然给了他们两周的通知？这些现在是我的火了。

通过可能的工作小时数除以票务估计值来计算确定带宽的几周时间已经一去不复返了。而这种不可预测性意味着我解锁另一位队友的过时请求几天或几周都没有合并。

是否每隔一段时间就有空间让EM在非阻塞公关上工作，只是为了满足他们的编码之痒？可能吧。你花在公关上的工作时间用在管理责任上会更好吗？可能吧。

更关心每一件事的副作用意味着管理会让你在情感上付出更多代价。当一个队友的生活遭遇困难或悲剧，影响到他们的工作能力时，我通常是第一个知道的。根据问题的敏感性，有时我是唯一知道的人。我不仅要为他们的缺席带来的实际后果负责，而且如果我不真正关心队友的福祉，我的工作也不会成功。根据我的经验，知道你关心的人正在受苦是不免费的。

作为一名经理，你有权以他们不能为你做的方式直接决定你下属的续聘和薪酬，这意味着你在工作中对他们的权力比他们对你的权力更大。这不是对错的陈述，这是事实的陈述。

你现在代表的是你势力范围内的公司。虽然我认为进入管理层并不意味着你失去了独立思考的能力，但一个组织的健康通常取决于其领导者是否有能力持不同意见并做出承诺。

在危机时刻，这一点尤其重要，因为你团队中的人会把你视为稳定的力量和信息的来源。由于你的头衔，你可能知道尚未公开的信息，并被期望在适当的计划到位之前将这些信息保密，这一切都是为了公司的利益。有时，这个消息将是毁灭性的，你会因为不让信任你的人知道而承受压力。这是工作的一部分。

友谊的基础是平等、诚实和透明，这些原则并不总是与管理关系相适应。管理是更强大的等级制度(！平等)，有时你不得不不同意并承诺或遵守党的路线(！诚实/！透明)。

另一种选择是特殊对待你的朋友，这是一种管理上的失败，因为裙带关系破坏了你作为领导者的信誉。在最坏的情况下，你不得不终止朋友的工作，这也是工作的一部分，这是不令人羡慕的境地。

作为一名没有像经理那样落地的IC，你可以开一个糟糕的玩笑：“喂，你搞砸了生产。收拾好你的东西，你就被解雇了。“。

管理层的权力动态严重，生计岌岌可危。不要用笑话来贬低他们。

管理者的衡量标准是他们下面组织的产出。虽然有很多责任和任务可以归结为“产出”，但工程经理的主要职责之一是责任。您需要有足够的技术知识来让您的团队对强大的工程成果负责。

作为一个普遍的生活原则，我认为你不能让人们对你不能证明自己的事情负责。在IC层面上，如果我在某项技术上不比他们更有经验，就很难在该技术上指导和成长某人。在管理层面上，如果我从未展示过团队执行力，也不能解释团队执行力的原则，就很难确保团队的执行力。

我并不是说你被期望成为一名技术主题专家，事实上，在大多数大型科技公司，平行的IC轨道和EM轨道使得这一点不是最优的。但你必须对技术项目是如何交付的有真正的嗅觉和意见，而不知道它们的实现细节。而且你必须有足够的技术知识，知道什么时候一个项目感觉不会交付，并进行适当的干预，迫使它回到正轨。

你如何介入是根植于技术经验的战略思维。您是否可以在不牺牲关键功能的情况下削减范围？您是否可以选择一个用户不太友好的解决方案，但可以用更多的文档来加强它？增加更多的工程资源会有帮助吗？当您探索替代方案时，对其他工程或业务团队有何下行影响？

Grove书中我经常想到的另一句话是“委派不是退位”。作为经理，您负责团队项目7的技术交付，尽管您没有执行任何实现。委托工作作为一种从结果中推卸责任的手段，是一种管理失败模式。

在列出这样一份清单之后，你可能会问，为什么会有人想要追求管理这条道路。事实上，在我分享了与上面类似的观点后，不止一个联系过我的人决定留在IC赛道上。

对我来说容易完成的两项任务是写作和公开演讲。我要保证，这不是追求管理的动机，而是内在技能和日常管理责任的一种非常方便的结合，它使管理工作变得更容易。

关于写作：我真的不知道怎么换个说法，但我就是不费劲把我的想法写下来。实际上，这意味着我可以快速制作出高质量的文字制品。因为书写的工件是许多管理任务的共同输出，这对我的时间管理有很大帮助。假设我事先已经收集了相关信息，我发现我不必花很长时间来写路线图或评论之类的东西，而且任何与作者块打交道的时间都是相对短暂的。

关于公共演讲：与其说这是一种“固有”技能，不如说是我通过大量练习培养出来的一种技能，但在我职业生涯的这个阶段，我是一个非常舒服的公共演讲者。我在很多会议上都做过演讲，我在乔布斯做过无数次内部演讲，既有全公司的，也有为小团体做的。我对公开演讲感到很自在，所以向一大群人发表演讲的机会真的让我充满了更多的兴奋而不是恐惧(这与我职业生涯早期的情况完全相反)。

这是相关的，因为我认为公开演讲是领导者不可避免的责任，特别是当你在公司阶梯上攀登的时候。你将不可避免地召开大型会议或向高管发表演讲。领导者的一项关键职责是激励和激励，所以当你有机会在整个组织内进行广泛沟通时，表现出色是至关重要的。

我的长期职业目标之一是经营一家工程公司。在我看来，管理一个工程组织是一项能把你拉向100个不同方向的工作：招聘、升级、建筑、运输、留住、薪酬等等。作为领导者，这个组织要么蓬勃发展，要么在你的领导下取得成功。

当那一天到来的时候，我认为我是该公司最强大的经理之一是至关重要的。我不认为有一本方便的书或灵丹妙药来发展这项技能。提高管理水平的唯一途径就是积极管理--发展和管理团队，交付生产，建立和维护与我不断磨练的管理哲学相一致的文化。

他说：我不想哀叹工程领导层缺乏种族多元化的代表性，而我自己却没有做些什么。

我是东亚男性。我会第一个承认，声称东亚人在技术角色中的代表性不足是荒谬的。事实上，我做过的每一份工作都有相当数量的东亚工程师。

然而，我从来没有在一家公司工作过，在工程领导层中，东亚代表的人数与较低工程级别的人数几乎相当。在管理会议上的特色演讲者中，我也没有看到太多东亚代表。

刻板印象的存在损害了东亚后裔作为领导者的看法。无论是在我的一生中，还是通过亲眼目睹一位才华横溢但不具对抗性的非美国出生的同事在以前的工作中获得惊人的薪酬过低，我都以各种形式生活在这些刻板印象中。

我追求管理的一个原因是，我相信工程领导中的种族多样性很重要，可以创造更好的结果。我认为实现这一改变的最好方式就是自己去实现这一目标，方法是随着时间的推移，不断展示自己在管理角色中的卓越表现，并倡导我自己的知名度。

你有没有在一个团队里当过IC，在那里工作完全是一件令人愉快的事情？在哪里，你积极期待来工作，与你热爱的人一起面对棘手的技术问题，并定期发运体现卓越工程的有意义、影响商业的项目？我有过。

你有没有和你真正尊敬的经理共事过？谁尊重你的技能和兴趣，在你的错误中公平对待你，庆祝你的胜利，在你的级别给予你安全的自主权，在内部和外部赞助你，并确保在薪酬/晋升时间的知名度和认可度？我有过。

当我回首往事时，这些都是同一支队伍。我所在的最好的球队都有最好的教练，那是我作为IC成长最快的时候。

在一支运行良好的团队中找到一位出色而有能力的经理可能会让人感觉很愚蠢，但事实并非如此。这是故意的。它正在建立和执行行为、期望、心理安全和产出的规范。它提供了程序上的界限，让工程师们能够完成他们最好的工作，并因此认可他们。

管理层处于为他人提供这种环境的特权地位。当团队在工作时-团队是健康的和协作的，IC通过延伸项目成长，你在团队成员的自主性/掌握/目标的发展中发挥作用-世界上没有比这更好的感觉了。

作为一名员工工程师，我习惯于研究和执行影响广泛的技术问题。我仍然喜欢参加那些会议。但是，在范围划分会议的上游有一层抽象，我认为对组织来说更关键的是：“考虑到我们当前的业务/人员/优先事项的上下文，我们是否应该构建这个东西？如果答案是否定的，并且它最终仍然需要构建，我们如何实现这个目标？”我现在更感兴趣的是那个讨论，而不是范围划分讨论。

我认为上游的讨论是决定公司成败的关键。我不会贬低资深IC的技术领导能力--这一点很关键--但我经常发现，与纯粹的技术能力相比，一致性、优先权和方向更像是公司成功的拦路虎。