大部分被提拔成技术领导的工程师都拥有一定的领导力，最重要的是，他们都具备出色的业务能力；而这些技术能力强悍的工程师刚刚走上管理岗位时，最爱做的事情就是亲力亲为，看谁干活都不放心，恨不得自己把所有的事情都做了。
对此，我深有体会，因为我是一个典型的由技术骨干提拔上来的管理者。
成为技术管理者之前，我在组里是研发组长（ Tech Lead ）的角色。我不仅参与所有的设计和讨论，甚至很多的核心代码都是自己写；组里其他人的代码，我也会亲自过目。无论多忙，我都会参与所有的代码评审，尽力做到对每一个改动都心中有数。
随着业务规模的扩大，我带的项目组人数越来越多，事事亲为也变得越来越吃力。晚上和周末的时间差不多全部用来加班了，超长的工作时间变成常态。
即使这样，我也总有忙不完的事。好友池建强老师常常说，你得学着带人和授权，把事情分出轻重缓急，把有些事分出去让别人做。可那个时候的我，总觉得每件事情都很关键，什么都不愿放手，甚至我老板也常常说我，应该学会把任务授权给给别人。
我在这方面做得一直不好。一方面，我确实没有掌握到分配任务的技巧，好几次任务分出去都出了小问题，最终还要自己介入；另一方面，我那个时候的状态也不对，整个人陷到所有的细节中无法自拔，没办法做到退一步海阔天空，只能紧紧盯住眼前的事，无法看得更高更远，甚至常常在度假的时候也要处理工作上的事情。
对个人而言，我自己忙得疲惫不堪，对团队而言，一旦我这里停下来，就成了所有人的瓶颈。
这个问题在我转成管理者之后不久，变得更加突出。一方面，我多了很多管理相关的工作，这些任务会占用我很多的时间；另一方面，团队迅速成长，项目和人都变得更多了，想要事事亲力亲为再也不可能了。终于有一天，事情突破了临界点，也就是说，无论我怎么忙，都没办法延续之前的管理方式了。
当一个人熟悉的“老系统”彻底坍塌的时候，人们才会改变，去尝试构建一套新系统；但是，新系统从来不是一蹴而就的，我花费了好大的力气才从“亲力亲为”转变为授权和任务分配模式。
为什么这么困难呢？原因很多，我觉得最重要的一点可能和工程师的工作习惯有关系：一个技术方案如果自己不参与，就会担心事情不能做好。
这里面其实有两个误区：
既然出发点是把事情做好，那如果我们把任务分配出去，别人也一样能把事情做好，如果这样去思考，是不是就更容易放手了呢。
这样的话，我们就会把关注点放在如何帮助别人把事情做好上面。比如，接受任务的人需要哪些支持和帮助才能很好的完成任务呢，我们应该在什么样的时间点去提供这样的帮助。
作为一个管理者，我们在授权和分配任务的时候应该注意这些方面。
第一，让对方明确目标，知道最终想要达到的结果是什么，对这个任务完成的期望值是怎样的。比如，在什么时间内完成什么样的任务，你对这个任务成功的定义是什么样，如果有取舍，哪些是重要的，哪些是次要的，哪些是可以妥协的。如果这些标准没有说清楚，很可能会出现认知偏差，比如对方觉得做得很好，但是你认为有些很重要的东西并没有被照顾到。
当然，这里面一个重要的前提是：对方同意并承诺完成这个目标。
第二，制定一个计划，并保持跟进。跟进不是指导，不是让你去频繁介入别人的任务，告诉对方下面你该干什么了；而是需要你在对方对某个环节有疑问的时候，能够随时提供帮助。这种帮助可能是解决方案，也可能是技术方向。当对方对下一步该怎么做没有头绪的时候，你可以与其探讨，给出建议或者线索，确保没有大的障碍阻止他取得关键性进展。
第三，给出反馈，尤其是正面的反馈。当对方做得很好的时侯，你需要及时地给予肯定。对方处于平台期没有突破的时候，只要他还在努力，就应该给予适当的鼓励。反馈要尽可能的客观，不要在小细节上有太多意见。如果在方向或者优先级等问题上偏离了你的预期，要及时交流和纠正，了解对方的想法，找到问题的原因，让项目走上正轨。
那么，我们回到今天的主题：管理者不用亲力亲为，关键是什么？
我认为，关键就在于学会授权和任务分配。这个过程需要注意两个重点：第一，我们要有效地把任务分配出去，第二，我们要保证分配出去的任务能够被圆满地完成。
任务无论是自己做还是交给别人做，让事情更快更好地完成永远是第一位的。很多优秀的工程师最初都是独行侠，他们单枪匹马完成了很多丰功伟绩，也更习惯自己独立工作，但一旦他们发现团队协作可以做出更大的成就时，就会从亲力亲为转变为授权模式，帮助别人成功，团队才会获得更大的成功。
回顾一下，今天，我和你讨论了为什么工程师出身的技术领导更容易亲力亲为，如何从亲力亲为模式转变为授权和分配任务模式，以及我们在进行任务分配的时候，应该注意哪些方面。
最后给你留一个思考题。如果你在分配任务的过程中，对方不认可你设定的目标，或者不同意你对项目成功的定义，你该怎么做呢？可以在留言中告诉我，我们一起讨论。
评论