这一章我们来谈谈授权。

授权任务有很多种方法，但管理3.0中讲了一种新方法。管理3.0中的授权方法非常新潮，可以在很多不同的情况下使用。

当我担任某大型研发部门的管理者时，有多名团队主管向我汇报。这些团队的主管负责人员管理任务，像批假、做评估（年中和年终的总结）、对绩效不高的同事提供帮助和教练、雇佣新员工等等。然而，有些主管对自己的角色还比较陌生，还有些团队主管同时也是研发经理。他们在经验等级和技能方面都不尽相同。例如，拿处理低绩效员工来说，某些比较新的团队主管还从未经历过这样的情况，而最有经验的团队主管已经处理过各种各样的低绩效员工了。

有一次，人力资源部让我对研发团队的主管角色提供一份合适的工作描述。那么，我如何才能把拥有不同级别经验和技能的团队主管放在一份工作描述中，或者为他们的职责做一份概览呢？我当时真是感觉要晕倒。

我不希望让初级团队主管在没有我介入的情况下处理低绩效员工这种棘手的问题。此外，我也不想让最有经验的团队主管觉得需要和我讨论每个细节。当然，我当时完全可以编写一个庞大的工作描述，里面放上所有的职责，我也可以在其中加上大量脚注。或者我还可以告诉某些团队主管，他们是典型工作描述的例外，可以以不同的方式来行动。另一种方法是，什么都不描述，含含糊糊，顺其自然……好吧，如果你了解我的话，就会知道那可不是我的风格。

我不喜欢上述的任何一种方式，但人资坚持要这些工作描述，所以我不得不写点儿东西……接下来要怎么做呢？

授权板矩阵

在《管理幸福课》一书中，Jurgen Appelo讲了授权板的概念。这些板子可以是物理的也可以是电子的。简而言之，你可以认为它是一个表格，竖向列举你想要授权给其他人的决策领域，而横向设置为团队主管可以拥有的独立性。

关键决策领域可能包括：批假、批准培训、评估、雇佣等等——全都由你来决定。那么，在横轴上，表格会显示七种授权等级。授权等级决定了团队主管在特定的决策领域所具有的自主性程度。所以，其中的想法是，对于每个关键的决策领域，授权板都会在七个授权等级栏里面包含一条记录，从而清晰地和所有人沟通，总结在授权板的那个领域可以有多高的授权等级。例如，有人会在某种程度参与到决策过程中吗（等级3：咨询）？特定的话题需要他们的同意吗（等级4：商定）？他们期望把决定告诉管理者吗（等级6：征询）？注意，授权等级是固定的，但是你可以增加任意多的关键决策领域。想要了解更多信息，你可以阅读这个页面（https://management30.com/product/workouts/delegation-employee-engagement/），获得你自己的一份书籍（https://management30.com/product/managing-for-happiness/）副本（当然，我没有股份，只是喜欢那本书，并且觉得它很实用且有启发）。

然而，不同于书中的叫法，我更愿意把它叫做授权矩阵。我发现当你说它是个矩阵的时候，对授权板并不熟悉的人会更容易理解这个概念。对我来说，使用授权矩阵的好处在于，我可以为每个团队主管创建一个矩阵。我可以把每个团队主管的个人技能和经验考虑在内。

准备工作

我首先会为特定的研发团队中的团队主管确定几个关键的决策领域。其中包括：

批准休假：为团队成员的假期或者其他特定的休假批准；

处理病假：监控病情报告，在必要的时候采取措施；

决定薪资：决定新的薪资等级，并对这些改变做沟通；

管理表现不佳的员工：处理表现不佳或者长期病假的员工，辅助人资部门提供信息以创建改进计划，在需要的地方，帮助和教练团队成员，达到必要的目标，从而使其再次成为组织结构中优良表现的员工。

记住

当我和一组团队主管说明我想要开始使用授权板的时候，我发现对于某些人来说很难理解授权等级的概念。这主要是因为，他们会混合了三种不同的视角：团队成员、团队主管和研发经理。授权矩阵是在团队主管和研发经理之间的某种契约，但某些团队主管禁不住会认为它是团队成员和主管之间的契约，这就混淆了概念。

授权等级

为了解决这个问题，我明确声明这个授权矩阵非常关注团队主管和研发经理之间的一致意见，并且为每个授权等级写了如下的描述：

第一等级，告知：研发经理自己做决定或者自己执行。团队主管不参与决策过程，只会被告知经理做了什么样的决定。或者，关注的任务由经理自己完成，如果需要的话，团队主管会被知会结果。

第二等级，推销：研发经理会让团队主管相信决定的正确。团队主管不参与决策。然而，经理会通过向他推销自己的想法，从而获得认可。或者，经理执行任务，并通过推销将对团队主管使用的方法来获得认可。

第三等级，咨询：研发经理会在做决定之前从团队主管那里获得信息输入。团队主管会被请求为经理将要做出的决定或者经理要执行的任务提供信息。然而，团队主管应该意识到，要做出决定或者执行任务的是经理。

第四等级，商定：研发经理和团队主管一起做决定。团队主管会和经理一起讨论决定或任务，团队主管和经理一起试着达成一致意见。团队主管的意见和经理同等重要。

第五等级，建议：研发经理会影响团队主管做出的决定。团队主管会从经理那里请求建议，从而对他自己要做的决定或者要执行的任务有所帮助。然而，经理会把决定权交给团队主管。

第六等级，征询：团队主管做出决定之后，会向研发经理请求反馈。团队主管在行动之前不需要先和经理讨论这个决定或者任务。团队主管会独立地做决定或者执行任务。然后，团队主管会在之后告诉经理任务或者决定的输出。

第七等级，委托：研发经理不对团队主管产生影响，让他自行处理。团队主管完全对决定或者任务负责。经理把决定或者任务完全授权给团队主管。

授权的最高和最低等级

在和每位团队主管讨论他们在每个决策领域可以获得哪个级别的授权等级之前，我会先大概说一下最低和最高等级。团队主管永远不要超出自己的范围。是的，我想让我的经理生活变得更简单，但有时候我就是想要让事情在掌控之中。还有些时候，公司策略就是不允许我把一些工作授权出去。

例如，公司策略要求我需要自己来批准所有费用，这样就不允许任何授权。

对于批准休假这个关键决策领域，我选择完全授权。我甚至不想知道五十多位雇员的休假计划，而且我肯定不想决定他们是否要休假。团队主管完全可以自行决定，而且我们能够很好地了解到谁在什么时候休假。

正常的病假也是一样。员工在生病的时候需要给团队主管打电话。不要用文字或者聊天工具，只要给团队主管打电话就好。在这个领域么有什么需要决定的……我或者团队主管都无法决定某人是否生病……在有人报告生病的时候，我确实想得到通知，那只是要了解什么时候会有流行感冒，或者压力巨大的团队开始报告有人生病了。我把这个领域添加进来，就是要明确，团队主管要负责处理生病的员工。

薪资是非常重要的关键决策领域——决定新的薪资并与其沟通。最终，这总会是我的决定：我要百分百负责。我想要从更有经验的团队主管那里得到输入，但只是为了确保把他们的意见和反馈考虑在内。

最有趣的关键决策领域之一就是处理组织结构中低绩效员工，或者长期请病假的人。正如你可能猜到的，和无法达到预期绩效的团队成员一起工作非常挑战和复杂（也会有回报）。依我所见，这肯定需要一些管理经验。当没有任何管理经验的初级团队主管需要处理这种情况，而没有任何我们通常处理这类事情方式的支持或指导的话，就很可能会陷入麻烦之中。一位团队主管甚至明确表示，在接下来的几年间，他不想对这个领域负任何责任。我发现，有些时候，我会完全自己来管理这种情况，而还有些时候，我最有经验的团队主管会处理这种情况并向我随时更新情况。

最终的结果是，对每位团队主管都有唯一的授权矩阵。你可以查看下面两份不同的快照，并看一下接下来两个部分的快照。

最后一个步骤是要让人资满意，针对所有团队主管提供工作描述。我只是基于授权矩阵上的工作描述做出来。首先我会为最低授权选项的团队主管进行描述。记下来为最高授权选项的团队主管描述。在其中你会发现我之前已经提到过的各种领域的描述。你可以看到，我描述了同样的关键决策领域，但根据团队主管的级别不同，描述的方式也有区别。

初级团队主管的工作描述

“你批准所有休假，包括假期和特殊的休假。你负责考虑团队成员的最小可用性，并确保团队有足够的能力来交付期望交付的工作。

你所有团队成员都会和你请病假。你会告诉研发经理，确保遵守了人资部门的请病假流程。

你会向研发经理提供一些基本的输入，他会有效决定新的薪资标准。研发经理会向团队成员发放薪资信件。作为团队主管，你不会参与这个过程。

当某位团队成员在组织中绩效很低或者长期生病的时候，研发经理会介入并负责。他会和绩效不高的团队成员来讨论情况，并采取必要的行动来提升绩效。”

高级团队主管的工作描述

“你批准所有休假，包括假期和特殊的休假。你负责考虑团队成员的最小可用性，并确保团队有足够的能力来交付期望交付的工作。

你所有团队成员都会和你请病假。你会告诉研发经理，确保遵守了人资部门的请病假流程。

研发经理会向你咨询，以有效地决定团队成员的新的薪资标准。研发经理会决定薪资。你或者研发经理会向团队成员发放薪资信件。

当某位团队成员在组织中绩效很低或者长期生病的时候，团队主管会负起责任。你会和绩效不高的团队成员来讨论情况，并采取必要的行动来提升绩效。研发经理会定期被告知进展情况。”

那么我的收获是什么？

我为每位团队主管都写了一份工作描述，从初级或者高级描述那里复制，然后做些调整，使得描述符合选定的关键决策领域。人资对工作描述非常高兴和满意。

我和团队主管一起，每年都会对授权矩阵做几次回顾，必要的话就做些调整。在年终的时候，我会为人资部门创建新的工作描述。

对我来说，最大的收获就是，授权矩阵让我可以为团队主管定义清晰的成长路线。他们变得技能越来越强，经验越来越丰富，在移动的授权等级中找到自己的卡片。我可以很容易地基于示例来讨论授权等级，并且，当团队主管已经证明他为下一等级做好准备的时候，慢慢地把卡片向右移动，或者我可以为明年设置期望。最后，我发现自己会把它作为自己担任经理的目标，总是要让团队主管随着时间的推移，把尽可能多的卡片向右移动。那会让我的经理工作变得越来越简单，也让团队主管自身不断进步。

我上个月和那个组的一位团队主管进行了谈话，他告诉我，在这种方法中，他真正欣赏的一件事是，他总会对自己的职责有非常清晰的描述。他确切知道我对他的期望，从那里可以引领自己前行。他真的喜欢这个工具，并且始终和他的团队成员一起使用它。

对我来说，最大的好处是，我可以完成人资部门的要求，同事因为团队主管的经验等级不同，有很大的灵活性。作为管理者，我面临的一项个人挑战就是有时候要信任人，并更频繁地把事情授权出去。是的，我也不是完美的。授权矩阵帮助了我；我不需要马上把所有事情都授权出去。和团队主管一起，我可以决定在哪个领域授权什么事情到何种程度。此外，通过每年几次对矩阵进行回顾，它会继续成为非常灵活的方式，给了团队主管提升自身技能的 机会，并在一年之中不断把更多的责任授权给他们。

小结

授权板是一种非常强大的方式，可以在团队或者和个人设定授权。首先，描述关键决策领域，然后，对于每个关键决策领域，决定你会如何设定授权。一共有七种授权等级，从告知到委托。这是一种灵活的方式，在其中团队或者团队成员也可以把某些领域授权给做经理的你。此外，你可以非常容易地可视化授权。在授权的情境下，使用授权板唯一的限制可能就是你的创造力。

如果你想要阅读更多关于授权板的信息，可以访问这里：https://management30.com/practice/delegation-board/。你可以在这里订购自己的授权卡片：https://management30.com/product/delegation-poker/。

这两样东西你认为哪种更有价值：世界的另一端对你作为经理的称赞，还是坐在你旁边每天都能够看到你做什么的同事？大多数人都更喜欢后者。在下一章，你会读到分布式环境中关于夸奖卡片的内容。