引言

软件工程师在其职业生涯中迟早会遇到转入管理职位的阶段。这可能是技术领导职位、团队领导者、开发经理、（高级）架构师、员工+（staff+）工程师，或者是其他负责管理技术人员的职位。这些资深的技术人员都会问自己一个问题：我应该进入管理角色，还是继续留在技术岗位呢？

进入管理岗位似乎就像是离开了技术领域，你不得不停止做自己擅长并乐意做的事情。转到管理岗位可能会令人不适应。这会影响你与同事的关系，这包括了其他的工程师和公司经理的关系。这可能会让你思考一个问题：作为一个工程师，我是该这样做，还是应该继续留在技术岗位上？

在本次虚拟座谈会中，我们将会讨论是什么因素促使人们成为领导者以及他们是如何做到这一点的。我们还会探讨成为领导者是否意味着必须永远离开技术领域，以及是否有办法重回工程领域。

参与讨论会的成员：

Shawna Martell：Carta的高级员工工程师（Senior Staff Engineer）Peter Gillard-Moss：DeepL的高级工程经理Brittany Woods：乐高集团的高级工程经理

InfoQ：什么因素促使你成为一个技术领导者？当你还是一名工程师的时候，是否有什么事情让你立志成为一名领导者，或者什么事情让你觉得自己已经做好了准备？

Shawna Martell：在大约20年前，当我刚开始从事技术工作时，我只知道一种类型的领导角色，那就是管理人员。直到工作十年多之后，我才听说“个人贡献者（individual contributor，IC）职业轨道”，那时候我已经担任过两次管理人员了。如果那时候我知道还有其他选择，我可能会选择另一条道路。 管理是一种重要且有价值的领导方式。我不会假装自己已经为管理或领导工作“做好了准备”。我要是这样做，就是在你面前说大话而已。当我接到第一个管理职位时，我是非常犹豫的。最终说服我的是来自经理的鼓励。这进一步说明优秀的管理者对任何组织来讲都是至关重要的。 但是，管理和领导并不是一回事儿。作为高级员工工程师，我现在是一位领导者，而不是管理者。我现在依然感觉自己没有准备好担任高级员工工程师的领导角色，但同样幸运的是，我身边有很多人鼓励和支持着我。 我之所以承担领导职务，是因为我信任的人鼓励我这么做。我一直担任领导职务，这是因为我真正热爱这种工作。 领导者是组织者、啦啦队长和具有远见的人。他们利用自己的影响力让周围的人变得更好。 Peter Gillard-Moss：在这方面没有明确的原因。早期，我认为这是职业发展的需要，而且我感觉自己能够把这项工作做得很好（可以说是自负吧）。第三次我并不情愿，但是有人看出了我的潜力，鼓励我去做。 我前两次转为领导者并不成功。第三次我正准备放弃时，我遇到了一位好教练，他让我得以扭转了被动的局面。 Brittany Woods：对我来说，担任首席工程师最有成就感的一点就在于培养身边的人，不是从技术角度思考问题，而是从如何融入更大的愿景来思考问题。在这个阶段，我们已经开始制定路线图并向高级领导层介绍和协调项目，所以至少在这方面，我已经为下一步做好了准备。

InfoQ：作为工程师，你所具备的哪些技能或素质有助于你成为一名管理者或技术领导者呢？或者，在这个过程中，你发展了哪些缺失的技能呢？

Shawna Martell：我的第一个角色是所谓的“混合角色”，担任领导只是我工作职责的一部分，也就是很多地方所说的技术主管经理。我仍然负责工程任务，但是我也有一些直属的下属。我知道这种类型的角色可能会引起争议，我也理解其中的原因。对我来说，我可以轻松地花费很多的时间做技术相关工作，直到我的头衔发生变化。我对日常工作中的工单（ticket）和拉取请求非常熟悉，这是在人员管理工作中所不具备的。 在此之前，我唯一的管理经验就是……每个员工只能被一个人管理。我想我的经历也是很多人进入管理职位的原因：我是一名出色的工程师，现在恰好有一个管理职位的空缺。在日常工作中，我已经在领导团队并分配任务，所以顺理成章地添加了人员管理的职责。 我所欠缺的是如何应对领导岗位上的人际挑战。该如何帮助解决人际关系问题，而不仅仅是技术问题？我从我的经理身上寻求了很多的支持，而且读了很多的书。对于新的管理者或有志于此的人，我现在推荐阅读“Creating Magic: 10 Common Sense Leadership Strategies from a Life at Disney”和“The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change”"。 在我第二次担任管理者几年后，我成为了一位期待大展宏图的总监，我知道在总监的岗位上会涉及一些商业和金融方面的概念，而我的计算机科学硕士学位并不能帮助我理解这些概念。因此，我决定重返校园，读取了MBA。我并不认为每个领导者都需要去读商学院，但我很高兴我这么做了。即便现在我重新回到了个人贡献者的角色中，但是在读MBA时学到的市场营销、品牌塑造和金融方面的概念依然非常有价值。 Peter Gillard-Moss：伟大的工程师和领导者有三个共同点，即善于沟通、知道如何进行设计才能使事情简单化，以及善于诊断问题。这其实就是工程师每天在代码中都在做的事情。我怎样才能使代码的意图清晰明了？如何确保某个方法带来的价值与另一个方法带来的价值保持独立？如何从系统层面的错误行为快速排查出何处引发了该问题？ 当成为一名管理者时，这些都会成为你的长处，从而带来真正的优势。你只需要通过不同的视角运用它们即可。我们是否像处理代码那样明确传达了我们的意图？我们是否消除了歧义？团队有明确的目标吗？这种交付是一次性的，还是某种模式的一部分？ 通常来讲，我们缺少的是如何将这些技能与人类的行为结合起来。只要有了好的答案，我们不需要说服计算机，只需下达命令即可。但是，对于人类，情况却并非如此。 Brittany Woods：我一直非常擅长沟通，能够在企业内部构建良好的关系。作为领导者，这对我的日常工作是非常有帮助的，因为我每天都要与其他团队或利益相关者构建良好的关系。 正如我之前提到的，我非常喜欢培养他人。当我还是一名工程师的时候，我发现自己经常教导别人如何做事，或者在与其他工程师的关系中担任导师的角色。这也是进入领导角色后需要具备的一项重要技能，在我看来，这不再是你自己的事情，而是要学习如何帮助周围的人和团队成长。 

InfoQ：作为技术领导者，你面临过哪些挑战，又是如何应对的呢？

Shawna Martell：冒名顶替者综合症（imposter syndrome，这是一种心理状况，特征是持续怀疑自己的能力或成就，并伴随着担心被揭穿为骗子的恐惧，即便有事实证据证明自己一直在取得成功——译者注）是我职业生涯中最大的障碍。它让我对自己产生怀疑，而缺乏自信是难以掩饰的。我通过对他人坦诚一切来解决这个问题，而令人惊讶的是，我经常遇到有同样困扰的人。 我非常敬佩的一些人居然也有冒名顶替者综合症！知道自己并不孤单是一个巨大的资源，当你需要支持的时候，通过这个群体能够让一切都好起来。 Peter Gillard-Moss：作为技术领导者，你需要与其他学科的人协作，并将技术问题纳入到工程之外的决策中。在很多组织的流程图中，都将技术放在流程最后的一个名为“交付”的方框中。再加上与工程师打交道是你的舒适区…… 但是，作为技术领导者，你必须对质量、变更速度和可扩展性等问题负责，但是你却无法直接控制这些问题，因为它们在很大程度上受其他领域同事（如市场、产品、财务、设计等）决策的影响。我们可能会陷入这样一个误区：盲目地认为我们必须在这些限制下工作，并且仅在工程方面做出妥协。 解决这种问题的唯一办法是将可见性引入到工程中，这样其他人就可以和你合作，做出更好的决策。这并不意味着讨论技术债、整洁代码、重构等等。这代表着，要了解什么才是对他们重要的事情，并帮助他们了解实现目标所需的权衡。这意味着从你认为的正确事情开始，然后双方协商该做出的妥协。 Alfred P Sloan给年轻时的Peter Drucker的建议在这里非常适合：“我对你的唯一指示就是，把你认为正确的东西记下来。不要担心我们的反应。不要担心我们会喜欢这个还是不喜欢那个。最重要的是，不要担心为了使你的结论得到接受可能需要做出的妥协。在这家公司中，每个主管都知道在没有你的帮助下如何做出可以想到的妥协。但是，你必须先告诉他们什么是正确的，否则他们无法做出正确的妥协。” Brittany Woods：作为科技领域的女性，尤其是科技领域的女性领导者，总会遇到各种挑战。我认为，在我的职业生涯中，我经常遇到的挑战之一就是如何确保自己的声音能够被听到。 我绝对无意为技术领域的所有女性代言，因为每个人都有自己的经历。但对我而言，我注意到有些人有打断对话或主导交流的倾向，尤其是当有女性试图推动解决方案或想法的时候。 对此，我的补救措施是不断提醒自己，我不仅可以在必要的时候坚持自己的观点，像其他人那样占据谈话空间，而且还注意为其他人保留空间。如果我的团队中有人难以发出自己的声音，或者我知道他们想发表意见却保持了相对安静，我会直接了当地询问他们，并为他们留出回答的空间，而不是让其他人越俎代庖。 我希望有人也能够为我采取这样的小举动，尤其是在我职业生涯的早期，现在我一定要为我的团队成员做到这一点。因此，作为领导者，我一定会做到这一点，并且鼓励其他的领导者在谈话中注意倾听他人的意见。

InfoQ：你是如何领导高绩效技术团队的？具体来说，你学到了哪些在团队中有效和无效的东西呢?

Shawna Martell： 从管理的角度来思考这个问题，高绩效团队需要管理者为团队成员提供两样东西：保护他们的时间，确保他们能够解决正确的问题；让其他人不要碍事，以便他们能够解决问题。 高绩效团队有一个最大的优点，那就是他们通常能够让任何情况都会变得越来越好。这也是高绩效团队最难做的事情之一，因为你不可能让他们做所有的事情。 高绩效团队的成员也是乐于助人的。他们希望让周围的人和环境都变得更好！这是非常好的事情，不过也可能成为一个挑战，因为每个人都乐于助人，他们可能会被卷入很多的事情，他们有能力提供帮助，但是这并不意味着他们有义务这样做。如何确定哪些事情值得他们花费时间和注意力呢？ 这个问题的解决是一门艺术，而不是科学。作为管理者，你不能每小时都盯着你的团队，确保他们的每分钟都“正确”地度过。你也不能假定他们知道哪些请求可以被忽略，或者其他团队能够正确地珍惜他们的时间。 我发现最有效的方式是，采用对团队中每个人最有效的方式来记录他们的时间。无论是在每周的1:1会议上列出他们关注的事项或更新，还是维护一个显示他们当前正在进行和即将开始的工单面板，只要有效都是可以的。团队中难免会出现一些应该由其他人解决的问题，帮助他们尽快将这些事情从清单列表中移除。 如果你是高绩效团队的IC领导者，那么在这方面不会有太大的差异。你可能比管理者更了解团队的日常工作，保护团队的时间依然是最高优先级的事情。 高绩效团队也会出现职业倦怠。如果他们的时间没有得到很好的保护，那么他们可能会为了应付太多的事情而疲于奔命。 如果能对高绩效团队进行有效调配，并保护好他们的时间，他们就能取得成功。 Peter Gillard-Moss：最重要的是建立信任。只要团队相信你的意图，相信你的判断，相信你以他们的利益为重，那么你就可以建立一支高绩效团队。 如果没有信任，你发号施令，就会认为自己能够看到结果。于是，你更加卖力地下达命令，期待取得更好的结果。但是，六个月后，你发现每次下达命令，团队都会说：“嘿，拉倒吧，我们已经受够了”。因为你是他们的领导，他们不想惹你生气，也不太信任你，所以他们会采取“向上管理”的方式。这基本上意味着，他们会开始说你想听的话，以让你离开他们。因为你给他们带来了痛苦，他们担心如果告诉你真相，你可能会采取其他的行为让事情变得更糟。一旦发生这种情况，就积重难返了。 Brittany Woods：在领导高绩效的技术团队时，我认为有两件事是“最重要的”，那就是信任和透明。 我始终确保我的团队成员都知道这一点，那就是我相信他们的专业技能，相信他们对业务的了解，相信他们会帮助我们为公司找到正确的解决方案。我们聘用工程师是因为我们相信他们的技能。如果硬性规定他们应遵循的解决方案步骤，或者更糟糕的是，给他们一个已解决问题的列表，让他们在方框中打勾，这是对他们知识和经验的侮辱。 在透明度方面，我确保与团队成员分享我所能分享的一切。这无疑会建立起他们对我的信任，也能确保他们掌握所有必要的细节，从而做出最佳决策。站在我的立场上，我知道有些东西是不能分享的，但如果它不敏感，而且与团队的工作密切相关，我就会与他们分享。

InfoQ： 有些工程师渴望获得“员工+”职位，这样他们既能保持技术方面优势，又能承担领导责任。你对“员工+”职位有什么看法和经验？

Shawna Martell：我担任“员工+”工程师已经快三年了。当有IC工程师来找我谈话，说他们正在考虑担任“员工+”角色时，我都会很兴奋。根据我的经验，“员工+”角色是职业生涯中的一个范式转变，不同于从“IC轨道”到“管理轨道”的转变。 我的高级员工角色通常被认为是“人员管理”职责和“工程”职责的混合体。我参与规划、战略和产品愿景，这些都是我在担任管理者时做过的事情，同时，我还参与架构、设计和实现（尽管与IC角色相比，我不会再做那么多的实现相关的工作）。 我仍然会经常指导工程师和管理者，帮助他们成长，但我不写绩效考核，不做人数预算，也没有直接下属。 “员工+”职位并不适合所有人。很难找到这种整天写大量代码的职位。这种职位尽管存在，但根据我的经验，它是比较少见的。对我来说，作为一名高级员工工程师，我所从事的领导工作是我梦寐以求的。我仍然要参与深层次的技术事项和问题的解决，但我也要努力推动愿景和战略的实现。 我建议所有想知道自己是否适合担任“员工+”角色的人都去看一下Will Larson的“Staff Engineer”或staffeng.com"。在我开始担任员工工程师的那一周，我就阅读了他的书，这本书让我的转变更加顺利。 Peter Gillard-Moss： 每个领导者都会有所不同。人们的职业生涯也不是一成不变的。我们不是在工厂生产线上生产带有指定特性的小部件。因此，必须慎重对待那些将人们推向僵化角色的流程。 同样，团队也是如此。绩效的单位是团队，而不是个人。这就需要构建合适的团队和人才组合，让人们能够发挥各自的特长。某个团队可能需要技术性更强的领导者。其他团队可能需要更擅长管理利益相关者的人。另一个团队则可能需要更敏锐的产品洞察力。 就个人而言，当有人具有真正的潜力时（无论是作为领导者还是IC），我们的目标是为他们找到合适的机会，以提高他们的影响力并加快他们的学习速度。如果这意味着，对他们现在的职业生涯而言，保持更多的技术性是很重要的，那么你该如何找到达成目标的方法？如何与他们现有的团队合作，或者在其他地方寻找新的机会？ Brittany Woods： 我个人认为，为工程师建立健全的职业发展框架，与为那些有志成为员工领导者的人建立职业发展框架是一样重要的。事实上，当较为高级的工程师表达对职业发展感兴趣时，我总是建议他们审视一下自己的角色能给他们带来哪些成就感。 正如之前提到的，我发现在人际交往方面，为他人提供帮助是一种成就感，而在技术方面，在更大的层面发挥价值则是另一种成就感。因此，我想问希望成长的工程师们一个问题：你是在培养他人中能够找到成就感，还是在解决问题和亲自动手写代码中能够找到成就感？ 在很多情况下，你越偏向于领导者的发展方向，就越远离在日常工作中亲手编写代码和实际解决问题。对于那些能够在这方面找到成就感的人，我总是建议他们走工程发展的道路。

InfoQ：你有没有特别想重返技术岗位的时候，如果有的话，你是如何处理的呢？

Shawna Martell：在我的职业生涯中，我曾两次从人员管理岗位转回个人贡献者岗位，最近一次是离开总监岗位，到Carta担任员工工程师的角色。  我曾经认为，我必须在技术角色和领导者角色之间做出选择，但事实证明并非如此。直到我来到Carta工作，我才完全理解了这一点。我非常幸运能在这样一家公司工作，它给了我自主权，让我在设计新系统的同时，还能参与一些宏观的事情，比如改革我们的面试流程或建立工程导师计划。我知道这不是每个人都能享有的特权，我对此非常感激。 我们每个人在工作中找到的快乐和成就感都是不一样的，重要的是了解这些东西对你来说是什么。你可能会尝试一些不太适合自己的工作，就像我一样。我在每一次职业转型中都学到了很多东西，每一次转型都有助于我成为今天的自己，让我能够做着真正热爱的工作。 Peter Gillard-Moss：是的，经常遇到这种情况。不过，我另辟蹊径。例如，我非常相信Genba实践（现场巡视——译者注），所以我会花时间与工程师们在一起，观察他们的实际工作。这能培养我的同理心和理解力，还能让我体验到亲手实践技术的快感。 Brittany Woods： 对我来说，我知道我走在正确的道路上，我还没有感觉到“躁动（itch）”，也就是回到更加技术性的角色中。我认为在现阶段，我已经能够在保持技术性需求和个人项目之间取得平衡，在做自己喜欢的事情的同时保持技术技能的敏感度。 我明白有人想重新回到技术岗位上，我认识很多人，他们从领导者变成了个人贡献者，然后又回到了领导者的位置。我认为，关键是要在对你重要的事情和能给你带来快乐的事情之间取得平衡。随着时间的推移，这些能给你带来快乐的事情会发生变化或转变，这都是可以接受的。

结论

通常情况下，软件工程师走上管理岗位，都是得到上级要求或鼓励的，或者在职业生涯中出现了这样的机会并感觉已经为这一步做好了准备。他们会利用自己已有的技能，如良好的沟通能力、建立人际关系的经验、掌握如何进行设计以及能够解决问题的能力。

人们在管理岗位上遇到的挑战各不相同，比如冒名顶替综合症、如何学会承担责任、技术领域的女性声音如何让别人听到等等。

领导者可以通过给予团队足够的时间和空间来开展工作，信任他们，并通过与他们分享自己所掌握的信息来提高透明度，从而培养高绩效的团队。

在“员工+”职位上，你可以保持技术优势，并承担领导责任。“员工+”可能会成为高级软件工程师职业生涯的下一步，也可能是在管理岗位上工作之后想重返技术岗位时可考虑的一个职位。

原文链接：

Leading tech people or staying a software engineer: What to choose? Panel Discussion"