极客时间已完结课程限时免费阅读

17 | 管理者不用亲力亲为：关键是什么？

17 | 管理者不用亲力亲为：关键是什么？-极客时间

17 | 管理者不用亲力亲为：关键是什么？

2017-12-20 朱赟 来自北京
《朱赟的技术管理课》
课程介绍

讲述：丁婵

时长06:57大小3.18M

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

戳此获取你的专属海报
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 5

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
16 | 技术人如何建立个人影响力?
下一篇
18 | 每个工程师都应该了解的：API 的设计和实现
 写留言

精选留言(25)

  • 菠菜
    2017-12-20
    安姐的管理课学到现在，给我最大的感触：这就像是入门管理手册，可操作性特别强，即学即用，特别适合刚踏上管理岗位的人。
    17
  • 小情绪
    2017-12-20
    如果对方不认可设定的目标，一般有俩种方式：1.仔细聆听他的想法，认真思考看是否可以采纳，如果不行，用自己的想法结合他的意见去说服他。2.中国式安排任务：必须执行，无须异议。

    池建强回复: 其实沟通过程中可以产生出新的火花。第二种方式则容易留下隐患。 可以参考徐飞专栏的亚马逊领导力准则

    14
  • 刘剑
    2017-12-28
    技术骨干提拔上来我有以下缺陷： 1.不会规划团队工作 2.不会分配任务，不会授权 3.不会处理同事间关系 4.宏观和微观把控错乱 5.不会鼓励过多指责，情商较低 后续恶补了组织管理课程和案例分析就好多了，这里可以写系列文章了就不累述
    展开
    10
  • 二进制之路
    2017-12-25
    不用亲力亲维的关键是：思维的转变，从工程师思维到管理者思维的转变，从个人英雄到团体作战的思维转变。 关注产品、项目的成功，而不是具体功能的实现（把具体的功能做好也很重要）。 PDCA戴明环：计划、执行、检查、处理/调整。 做好计划，定好里程碑与检查点，分配好任务，信任、授权团队成员，定期沟通了解实施情况，肯定做得好的工作，对存在的问题提出改进意见。最后，对内对外做好沟通协调，排除各种干扰，让团队最高效率的工作。
    展开
    7
  • 元让
    2018-01-30
    如果遇到意见不一致，不要本能地上来就否定别人的意见即使是下属的意见。仔细倾听之后，再做出判断。可能是对方没有听明白你的方案，也可能确实是自己在当初指定方案的时候考虑不全。最终通过讨论让双方达成一致意见，心服口服。
    3
  • 元让
    2018-01-30
    如果遇到意见不一致，不要本能地上来就否定别人的意见即使是下属的意见。仔细倾听之后，再做出判断。可能是对方没有听明白你的方案，也可能确实是自己在当初指定方案的时候考虑不全。最终通过讨论让双方达成一致意见，心服口服。

    池建强回复: 无论多么充分的沟通都是不够的，要有批判性思维，也要能从对方的立场想问题

    2
  • 何慧成
    2020-08-23
    思维和习惯的转变很重要，决定了授权和任务分配的指令，最终影响目标的实现情况。 个人觉得还是对于授权还是要分人看，对于成熟度不郜的人员授权后做定期必要的指导；对于高成熟度的成员，可以减少中间介入次数，主要跟进风险。 对于最后一个问题，首先确定双方对目标定义不一致的原因是什么，是目标中的时间计划、难易程度分析不一眼，还是确实对最终目标的质量或者标的物有异议。如果是第一种场景，可以考虑先沟通，其次是调配资源或者进一步细化目标，分步实施；对于第二种情况考虑转为一个平等交流的事项，非任务分配性质的工作，这样有利于双方对最终目标的一致性认可。
    展开
    1
  • 亚祥
    2018-03-17
    转管理也有一段时间了，虽然心里知道要授权和工作任务下发，但是习惯还真是难改。
    1
  • 怀揣梦想的学渣
    2022-03-20
    如果不认可计划，依旧强制执行，这等于把自己当作工具人吧，进一步发展就变成了领导指哪我打哪，出了问题都骂领导规划差，下面人做事只需要完成即可，也不需要带脑子思考，这有点像特殊单位，不太像企业。
  • 码哥字节
    2022-01-18
    去沟通，了解他不认同的点的原因，知道了他的顾虑并提出可行性建议
    1
  • Ric
    2020-05-31
    之所以團隊協作是那麼困難的原因，正是各成員對目標的不一致性。
  • 杨宗超
    2019-11-19
    安姐写的太好了
  • mikejiang
    2019-11-11
    对方不认可你的任务分配，那么需要仔细聆听对方的理由，如何合理，那么就调整一下，如果你还是认为不合理，那么明确告诉对方你的看法。然后有空找一个信任的第三方帮忙评估一下，自己的做法是否合理？如何改进？
  • unicornmm
    2018-01-20
    “计而则管”，其实往往只是当时条件限制在的“优”，往往随着公司的发展就显示出它的限制性了
  • GeekAmI
    2018-01-11
    PK 理越变越明 可能会发现新的想法
  • buoge
    2017-12-30
    安姐抛出的问题很好，各抒己见，但我想问下，安姐可不可以给出自己的答案？还是这是个开放问题安姐不会解答？只是让大家发酵？

    池建强回复: 大部分是开放性问题

  • 刘剑
    2017-12-28
    如果不认可你设定目标：主要是信任问题，那需要通过一次次小事来建立信任
  • epic2005
    2017-12-24
    如果下属对分配的任务有疑议，个人认为还是要先听一下他的思路，如果认为考虑的不成熟可以给他建议，评估一下风险，如果都可以实现需求我觉得应该给他空间按他的思路去实现，下次重构的时候可能他自己就会去考虑你的办法是不是更好，强加给别人的想法我觉得还是不可取的
  • mattlin
    2017-12-21
    安姐 啥时候讲讲codereview

    池建强回复: 后面有文章专门讲

    共 2 条评论
  • 徐家喜
    2017-12-20
    我还不是一个管理者，但是刚开始带人了。我遇到这种情况，肯定是要先和不同意见的同学深入沟通，了解他的想法，思考他看问题的角度，再反过来看自己对目标定义有没有问题。如果确定自己没有问题，那就再想办法把我的想法传达给他，尽量沟通清楚。如果还不行，那就让他按照我说的做，由最后效果说话