授权的艺术

成为一个让每个人都变得更好的人。

Kate Matsudaira

当我开始我的职业生涯，成为一名初级工程师时，我迫不及待地想成为高级工程师。我会定期查看我们的晋升指南，并根据指南评估我的进步和贡献。当然，当时我并没有真正理解成为高级工程师意味着什么。

成为一名高级工程师意味着拥有强大的技术技能、良好的沟通能力、驾驭复杂情况的能力，以及最重要的是，培养和领导他人的能力。

领导力不再仅仅是管理者的专属。

在我的职业生涯中，我曾与许多真正有才华的工程师共事。我注意到，真正伟大的工程师能够激发周围每个人的能力。团队中有他们，会让每个人都更聪明、更高效、更有动力。

工程师和高级工程师之间的区别通常在于指导和培养团队成员的能力。指导的全部意义在于教导和授权。

职称中增加“高级”意味着您拥有最丰富的经验（无论是与特定技术或方法论相关的行业经验，还是仅仅是对您正在使用的系统的历史知识）。而且因为您是高级工程师，您的部分工作就是将这些知识传授给他人。

当做得好时，这是一件很棒的事情

• 突然之间，您有时间处理新的XYZ项目，而不是被遗留的运营、支持和修复工作所累。

• 您可以看着您的同事成长和学习，承担更多的责任并提升他们的技能。

• 每个人都更高效、更努力地工作，因为他们能够从过去的错误中学习并迎接新的挑战。

• 哇！

承担教师的角色也可能非常困难

• 当您是唯一了解ABC系统的人时，您是如此重要。每个人都认可您并向您寻求帮助——被需要的感觉真好。

• 处理您是专家的东西可能很有趣——能够处理您知道如何完成的任务（蒙上眼睛或单手反绑）感觉很好。

• “如果我把这个交给别人，我担心他们会搞砸我所做的所有伟大工作。”

• 当涉及到授权时，似乎向别人解释如何做某事比您自己完成工作要花费更长的时间——谁不喜欢高效呢？

即使您知道授权是有益的，但授权也很难。您不仅必须能够信任他人完成工作，而且还必须知道给他们多少信息才能使他们取得进展。这在棘手的技术问题上可能真的很难做到。您如何授权任务并教导他人一些看起来非常不可授权的事情呢？

我见过很多次这种情况，从我所有的经验中，我总结了一些建议。

1. 改变你的心态。您听过一句老话，“授人以鱼不如授人以渔；教人钓鱼，可养其一生。” 这也适用于您的职业生涯。如果您认为花时间解释某事不值得，那么您将永远无法教导任何人。当然，这比自己完成任务花费更多时间，但这段时间对您正在教导的人来说是宝贵的。您必须关注成长和教育，而不一定是效率。

2. 从小处着手。这是成功指导和授权的关键。您要从容易做的事情开始——例如，修复一个小错误、编写测试用例或添加文档。当您从非常容易处理的事情开始时，这给对方一个机会来熟悉情况，并有机会窥探内部运作，而不会感到不知所措。当您想培训某人学习新事物时，请尝试寻找不紧急的小事——可以轻松介绍您的责任范围的迭代改进；可重复的事情。

3. 引导他们自己弄清楚。当人们向您提问时，很容易直接给出答案。下次发生这种情况时，抵制告诉他们如何解决问题的冲动。而是问他们这样的问题：

• 到目前为止你尝试了什么？

• 你考虑过尝试什么？

• 你做了什么研究？你找到什么了吗？

• 你试过查找____________吗？（空白处代表您会查找以找到答案的内容）。

您要向他们展示您会采取的步骤，并引导他们了解您的思考过程——您将如何解决问题——而不是仅仅提供解决方案。

4. 帮助他们制定计划。当您给人们更多责任时（例如，构建新功能），不要只是让他们独自行动。而是让他们起草一份计划并带回来给您。一起审查他们的方法。给他们反馈（理想情况下，通过提出好的问题而不是仅仅给出答案）。当您一起起草想法时，您会对他们的方法更有信心，他们将能够利用您的专业知识和指导。

5. 设置一些护栏。每当有人在您的团队或组织中承担新责任时，最好设置一些检查和平衡措施，以确保事情顺利进行（特别是如果您要移交软件或运营的关键部分）。弄清楚您需要什么信息，以及多久一次，以便您可以放心地了解事情进展顺利。例如，您可以设置每日状态会议来审查进度，每两周进行代码审查来审查实施情况，或每周与项目中的其他人进行一对一会议。尝试确定您需要什么信息才能对进度感到满意，然后找到获得该信息的最佳方法，而不会过于专横或微观管理细节。

6. 不要追求完美。学习新事物的人不太可能第一次就做对。而且当涉及到代码时，程序员似乎更像艺术家，每个人对任务的理解都略有不同。确保您对这些差异持开放态度，并且您接受其他人可能不会以与您相同的方式做事。如果您真的担心质量，请在分配任务时预先明确您对质量的定义。

7. 创建一个领导者团队。去年，我读了L. David Marquet的书Turn the Ship Around!: A True Story of Turning Followers into Leaders (Portfolio, 2013)，我很喜欢。我从这本书中学到的最重要的一课之一是采用领导者：领导者模式，而不是领导者：追随者模式。成为一名优秀的领导者意味着允许您周围的人成为他们各自领域的专家。Marquet书中我最喜欢的概念真正改变了我的领导方式：当我的团队中的某人问我问题时，我不会给他们答案，而是问他们，“你认为我会怎么说？”。大多数时候，他们的答案与我的想法一致，但当不一致时，我意识到他们遗漏了一些我忽略分享的重要信息或背景。这改变了我的团队；他们不再问我问题，而是开始提出建议并请求许可。您如何鼓励您的团队成员承担更多所有权并领导他们自己的领域？

学习指导和授权并不容易，但是一旦您掌握了这些技能，您将对您的团队变得更有价值。您不仅仅是专家；您将成为一个让每个人都变得更好的人——而这不正是您想要与之共事的那种人吗？

Kate Matsudaira 是一位经验丰富的技术领导者。她曾在微软和亚马逊等大公司以及三家成功的初创公司（Decide 被 eBay 收购，Moz 和 Delve Networks 被 Limelight 收购）工作，之后创立了自己的公司 Popforms (https://popforms.com/)，该公司被 Safari Books 收购。她在职业生涯早期曾担任软件工程师，技术精湛，并在分布式系统、云计算和移动领域做出了领先的工作。然而，通过管理整个产品团队、研究科学家和建立自己的盈利业务，她证明了自己不仅仅是一位技术领导者。她是一位出版作家、主题演讲嘉宾，并荣获西雅图 40 位 40 岁以下精英等奖项。她是 acmqueue 的董事会成员，并在 katemats.com 上维护个人博客。

最初发表于 Queue vol. 14, no. 1—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非密码散列函数的标准
尽管密码散列函数和非密码散列函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全需求，存在许多针对密码散列函数的标准，但在非密码方面，存在一定的民间传说，尽管散列函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受良好的开发者体验能够提高软件交付效率和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发效率
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略已证实的解决其面临的一些永恒问题的方法。用例于 1986 年首次引入，并在后来普及，是这些经过验证的解决方案之一。