17 管理者不用亲力亲为：关键是什么？
大部分被提拔成技术领导的工程师都拥有一定的领导力，最重要的是，他们都具备出色的业务能力；而这些技术能力强悍的工程师刚刚走上管理岗位时，最爱做的事情就是亲力亲为，看谁干活都不放心，恨不得自己把所有的事情都做了。
对此，我深有体会，因为我是一个典型的由技术骨干提拔上来的管理者。
成为技术管理者之前，我在组里是研发组长（ Tech Lead ）的角色。我不仅参与所有的设计和讨论，甚至很多的核心代码都是自己写；组里其他人的代码，我也会亲自过目。无论多忙，我都会参与所有的代码评审，尽力做到对每一个改动都心中有数。
随着业务规模的扩大，我带的项目组人数越来越多，事事亲为也变得越来越吃力。晚上和周末的时间差不多全部用来加班了，超长的工作时间变成常态。
即使这样，我也总有忙不完的事。好友池建强老师常常说，你得学着带人和授权，把事情分出轻重缓急，把有些事分出去让别人做。可那个时候的我，总觉得每件事情都很关键，什么都不愿放手，甚至我老板也常常说我，应该学会把任务授权给给别人。
我在这方面做得一直不好。一方面，我确实没有掌握到分配任务的技巧，好几次任务分出去都出了小问题，最终还要自己介入；另一方面，我那个时候的状态也不对，整个人陷到所有的细节中无法自拔，没办法做到退一步海阔天空，只能紧紧盯住眼前的事，无法看得更高更远，甚至常常在度假的时候也要处理工作上的事情。
对个人而言，我自己忙得疲惫不堪，对团队而言，一旦我这里停下来，就成了所有人的瓶颈。
这个问题在我转成管理者之后不久，变得更加突出。一方面，我多了很多管理相关的工作，这些任务会占用我很多的时间；另一方面，团队迅速成长，项目和人都变得更多了，想要事事亲力亲为再也不可能了。终于有一天，事情突破了临界点，也就是说，无论我怎么忙，都没办法延续之前的管理方式了。
当一个人熟悉的“老系统”彻底坍塌的时候，人们才会改变，去尝试构建一套新系统；但是，新系统从来不是一蹴而就的，我花费了好大的力气才从“亲力亲为”转变为授权和任务分配模式。
为什么这么困难呢？原因很多，我觉得最重要的一点可能和工程师的工作习惯有关系：一个技术方案如果自己不参与，就会担心事情不能做好。
这里面其实有两个误区：
- 事情能不能做好和完全按照你自己的方式做好，是两码事，别人有别人的工作方式，也能把事情做好。
- 介入和不介入并不是非黑即白，用什么方式介入，在哪些地方介入，才是关键。
既然出发点是把事情做好，那如果我们把任务分配出去，别人也一样能把事情做好，如果这样去思考，是不是就更容易放手了呢。
这样的话，我们就会把关注点放在如何帮助别人把事情做好上面。比如，接受任务的人需要哪些支持和帮助才能很好的完成任务呢，我们应该在什么样的时间点去提供这样的帮助。
作为一个管理者，我们在授权和分配任务的时候应该注意这些方面。
第一，让对方明确目标，知道最终想要达到的结果是什么，对这个任务完成的期望值是怎样的。比如，在什么时间内完成什么样的任务，你对这个任务成功的定义是什么样，如果有取舍，哪些是重要的，哪些是次要的，哪些是可以妥协的。如果这些标准没有说清楚，很可能会出现认知偏差，比如对方觉得做得很好，但是你认为有些很重要的东西并没有被照顾到。
当然，这里面一个重要的前提是：对方同意并承诺完成这个目标。
第二，制定一个计划，并保持跟进。跟进不是指导，不是让你去频繁介入别人的任务，告诉对方下面你该干什么了；而是需要你在对方对某个环节有疑问的时候，能够随时提供帮助。这种帮助可能是解决方案，也可能是技术方向。当对方对下一步该怎么做没有头绪的时候，你可以与其探讨，给出建议或者线索，确保没有大的障碍阻止他取得关键性进展。
第三，给出反馈，尤其是正面的反馈。当对方做得很好的时侯，你需要及时地给予肯定。对方处于平台期没有突破的时候，只要他还在努力，就应该给予适当的鼓励。反馈要尽可能的客观，不要在小细节上有太多意见。如果在方向或者优先级等问题上偏离了你的预期，要及时交流和纠正，了解对方的想法，找到问题的原因，让项目走上正轨。
那么，我们回到今天的主题：管理者不用亲力亲为，关键是什么？
我认为，关键就在于学会授权和任务分配。这个过程需要注意两个重点：第一，我们要有效地把任务分配出去，第二，我们要保证分配出去的任务能够被圆满地完成。
任务无论是自己做还是交给别人做，让事情更快更好地完成永远是第一位的。很多优秀的工程师最初都是独行侠，他们单枪匹马完成了很多丰功伟绩，也更习惯自己独立工作，但一旦他们发现团队协作可以做出更大的成就时，就会从亲力亲为转变为授权模式，帮助别人成功，团队才会获得更大的成功。
回顾一下，今天，我和你讨论了为什么工程师出身的技术领导更容易亲力亲为，如何从亲力亲为模式转变为授权和分配任务模式，以及我们在进行任务分配的时候，应该注意哪些方面。
最后给你留一个思考题。如果你在分配任务的过程中，对方不认可你设定的目标，或者不同意你对项目成功的定义，你该怎么做呢？可以在留言中告诉我，我们一起讨论。
- 小情绪 👍（15） 💬（1）
如果对方不认可设定的目标，一般有俩种方式：1.仔细聆听他的想法，认真思考看是否可以采纳，如果不行，用自己的想法结合他的意见去说服他。2.中国式安排任务：必须执行，无须异议。
2017-12-20 - 元让 👍（2） 💬（1）
如果遇到意见不一致，不要本能地上来就否定别人的意见即使是下属的意见。仔细倾听之后，再做出判断。可能是对方没有听明白你的方案，也可能确实是自己在当初指定方案的时候考虑不全。最终通过讨论让双方达成一致意见，心服口服。
2018-01-30 - buoge 👍（0） 💬（1）
安姐抛出的问题很好，各抒己见，但我想问下，安姐可不可以给出自己的答案？还是这是个开放问题安姐不会解答？只是让大家发酵？
2017-12-30 - mattlin 👍（0） 💬（2）
安姐 啥时候讲讲codereview
2017-12-21 - 刘宗尧 👍（0） 💬（1）
怎么这么少留言
2017-12-20 - 菠菜 👍（17） 💬（0）
安姐的管理课学到现在，给我最大的感触：这就像是入门管理手册，可操作性特别强，即学即用，特别适合刚踏上管理岗位的人。
2017-12-20 - 刘剑 👍（10） 💬（0）
技术骨干提拔上来我有以下缺陷： 1.不会规划团队工作 2.不会分配任务，不会授权 3.不会处理同事间关系 4.宏观和微观把控错乱 5.不会鼓励过多指责，情商较低 后续恶补了组织管理课程和案例分析就好多了，这里可以写系列文章了就不累述
2017-12-28 - AI 👍（8） 💬（0）
不用亲力亲维的关键是：思维的转变，从工程师思维到管理者思维的转变，从个人英雄到团体作战的思维转变。 关注产品、项目的成功，而不是具体功能的实现（把具体的功能做好也很重要）。 PDCA戴明环：计划、执行、检查、处理/调整。 做好计划，定好里程碑与检查点，分配好任务，信任、授权团队成员，定期沟通了解实施情况，肯定做得好的工作，对存在的问题提出改进意见。最后，对内对外做好沟通协调，排除各种干扰，让团队最高效率的工作。
2017-12-25 - 元让 👍（3） 💬（0）
如果遇到意见不一致，不要本能地上来就否定别人的意见即使是下属的意见。仔细倾听之后，再做出判断。可能是对方没有听明白你的方案，也可能确实是自己在当初指定方案的时候考虑不全。最终通过讨论让双方达成一致意见，心服口服。
2018-01-30 - 码哥字节 👍（1） 💬（0）
去沟通，了解他不认同的点的原因，知道了他的顾虑并提出可行性建议
2022-01-18 - 何慧成 👍（1） 💬（0）
思维和习惯的转变很重要，决定了授权和任务分配的指令，最终影响目标的实现情况。 个人觉得还是对于授权还是要分人看，对于成熟度不郜的人员授权后做定期必要的指导；对于高成熟度的成员，可以减少中间介入次数，主要跟进风险。 对于最后一个问题，首先确定双方对目标定义不一致的原因是什么，是目标中的时间计划、难易程度分析不一眼，还是确实对最终目标的质量或者标的物有异议。如果是第一种场景，可以考虑先沟通，其次是调配资源或者进一步细化目标，分步实施；对于第二种情况考虑转为一个平等交流的事项，非任务分配性质的工作，这样有利于双方对最终目标的一致性认可。
2020-08-23 - Geek_nyr4dj 👍（1） 💬（0）
转管理也有一段时间了，虽然心里知道要授权和工作任务下发，但是习惯还真是难改。
2018-03-17 - 怀揣梦想的学渣 👍（0） 💬（0）
如果不认可计划，依旧强制执行，这等于把自己当作工具人吧，进一步发展就变成了领导指哪我打哪，出了问题都骂领导规划差，下面人做事只需要完成即可，也不需要带脑子思考，这有点像特殊单位，不太像企业。
2022-03-20 - Ric 👍（0） 💬（0）
之所以團隊協作是那麼困難的原因，正是各成員對目標的不一致性。
2020-05-31 - 杨宗超 👍（0） 💬（0）
安姐写的太好了
2019-11-19