阿里妹导读:技术主管和团队成员应该是什么关系?只能是普通的领导与被领导的关系吗?如果,你作为一个一线技术主管,你会怎么管理团队?今天我们试试换位思考,假设自己是技术主管,反推团队成员如何做事才能获得更好的成长。欢迎同学们一起讨论、交流。
如果我是一线技术主管,那我可能是团队曾经综合实力最强的,我可能会被时间支配而不能再天天写代码,并且,团队充满各种挑战。
如果我是一线技术主管,依然是每周要写周报,每年要写绩效,想晋升,想加薪、想人生巅峰等等。
如果我是一线技术主管,在团队只有五、六个人的情况下还好,如果是十几个人的团队的话,会希望有人可以站出来帮我。
如果我是技术主管,我更希望:
不抱怨
如果我是一线技术主管,我不会喜欢团队有喜欢抱怨的同学:
1. 主管每天也很忙,听抱怨很消耗时间;
2. 团队有人抱怨,说明团队自然是有问题了,需要花一定的时间梳理出问题,需要及时给出解决方案,甚至要安抚对方情绪;
3. 一个喜欢抱怨的人会影响整个团队的士气。
其实大部分开发抱怨的工作内容很相似,团队成员不配合做事,PD 提了无理的需求等。
大促中我们的后端主管说了些很好理解的话:“看到大促有这么多问题,我很激动,这种情况很好。问题越多说明机会越大,如果都是稳定健壮的系统、完善的流程、合作良好的团队,那么,要大促 PM 干什么呢?”
如果问题都是机会的话,那就没有抱怨的必要。但是,如果真的就是有问题,还不能说了吗?
向上管理
一个管理十几人的团队主管很难有精力做到面面俱到,去了解所有人的细节,给大家找出合适的方向和机会,甚至认真读完每个人的周报都要用一个下午,很难做到你有一个不错的想法的时候,主管就有时间找你聊聊。如果我是一线主管,我更希望团队同学主动找我聊。
作为主管每天既要处理大量一线信息,又要领导团队做出正确的决策,还要照顾团队的每个成员,做出健康的梯队建设计划等,大部分人是没有这个精力的。
刚开始工作的时候,我们误解主管和下属的关系就是领导与被领导的关系,但其实主管也需要被下属管理,这也就是“向上管理”的由来,简单来讲就是主管也需要下属的协助和推动。
主管大部分时间很忙,这就要求下属在向上管理的时候要尤其注意高效、有质量的沟通,如果我是一线主管,我更希望团队和我交流的方式是让我做选择题、判断题,而不是问答题、思考题。
很多鸡汤文提到老板训斥高管:我请你来不是告诉我为什么不行,而是告诉我怎么实现我的构想。在主管不是拍脑子就做的决定的时候,困难肯定是已经想过了,更希望得到的是下属的帮助。
如果我是一线主管,我希望下属这样帮助我:
1. 主动承担团队面临的挑战,给出合理的解决方案;
2. 及时向我反馈经过整理的信息和数据,甚至是结论,辅助决策;
3. 主动关心同事,组织学习,帮助大家(包括我)进步成长。
除了面对面的交流,和主管最多的沟通机会可能就是周报,这是向上管理的重要途径,然而很多同学把周报当做一种负担,写的极其敷衍,就是一周的流水账,发送出来都是浪费自己和收件人的时间。
团队不会有人认真读完所有人的周报,读谁的取决于周报的质量。个人习惯粗略浏览组内所有人周报(周报有 highlights 多重要),坚持几周就能识别一些需要关注的周报,然后会针对这些人的周报设置邮件规则,必须认真看的,遇到不理解的还要过去问的,其它人的周报就被自动过滤掉了。一个普通员工都是如此,更何况一线主管。可见这么写周报可能在无意中浪费了许多次向上管理的机会。
每天忙不完的业务怎么办
还有一种抱怨的声音是:自己每天很辛苦,想拼命忙完业务后做一些技术的东西,造个轮子什么的,但一个需求还没做完,另外一个需求就安排过来了。
如果我是一线主管,我会把团队面临的问题分一下级:
1. 重要&紧急,不能按时完成,则都是失败;
2. 重要不紧急,是个很好的机会;
3. 技术想法,很好的撬动业务的点;
4. 单分析只是个业务需求,看不出明显的兴奋点。
团队的人可能也有几种特性:
1. 能力强,在某领域是专家;
2. 能力一般,有潜力,但是非常有积极性;
3. 能力一般,主动性一般。
其实不用特意说明就知道大部分主管分配任务的思路:
1. 重要&紧急的事情只能交给能力强的人去做,意愿上如果有问题,也要说服对方去做,因人成事,可见能力强有多重要;
2. 重要不紧急的事情就可以借事修人,如果做得好,这个人以后就有信心了,团队多了一员干将,做不好也有能力强的人给保底,不会造成业务问题;
3. 技术想法也可以交给有积极性的人做,这必然占用一些时间,那么这个人手头上无关痛痒的事情只好交给能力一般,主动性一般的人来做。
实际上按照这个向上管理的思路,需要主管去分配任务的时候,你就已经输了,甚至主管来找你问进度的时候也已经输了。
当然每个合格的主管都需要发现、解决团队人才培养的问题,不可能放任问题发生。
什么样的人有积极性
能力强的人很好识别,那什么样的人才是有积极性的,看过一个 AE 快速升 P8 的同学写的文章,他有个很好的习惯。
无论大小难易,永远不满足于做出来指定的事情,一定要给人惊喜。
如果我是一线主管,我不会凭空把一件重要的事情交给某个人去做,我会更期望:
1. 团队同学来教育我某件事情很重要,想去尝试;
2. 在很多微不足道的小事情上做出了惊喜,有理由相信这件更大的事情也可能做出惊喜;
3. 我被分配了纯业务事情怎么办?
上面也提到了简单分析只是业务需求,近五年在阿里将见了太多事在人为的案例,每个人身边肯定也有不少这样的案例。
我们以为自己在做业务,很多时候是因为两个误区:
这不是技术项目:没有什么所谓的技术项目,所有的技术项目除非是显而易见的项目,否则肯定脱胎于业务,只有业务一线的同学才可以抽象出来,做业务需求不是坏事情,拿着完成任务的心态做业务才是最要命的。
没目标:所有做的事情都要契合自己的目标,而自己的目标大部分时候应该和团队目标 match。今天让我开发一个前端组件,我要看到的是这个需求反应了我营销体系对某个分类能力的缺失,需求归纳到我营销可视化体系完善的目标中,在阿里这种人才济济的环境中目标不清晰的人和咸鱼没什么区别。
怎样才算业务负责人
很多小伙伴已经是实际的业务负责人,和三、四个小伙伴一块解决特定业务领域问题,但尴尬的是级别相同,在分配任务的时候会不好意思,觉得对方也有自己的"技术项目"要做,我得求他把这个业务需求做一下。
这种其实不算真正的业务负责人,如果业务负责人仅仅是分配任务,那么任何人辛苦一些都可以做。业务负责人的核心特质应该是有一条是了解业务的发展、引导相关人的个人目标。
这样可以把业务需求转换成每个人目标中的一环,和上面提到的自己做事情思路是一样的,无非就是写代码的那个人不自己。其实即使主管也不可能命令团队成员去做某事,采用命令那样的方式,团队早晚散伙。
最后,如果我是一线技术主管,我希望团队的业务负责人时刻在两个方面提醒自己:可衡量、可体系化。
你眼中的一线技术主管应该是什么样?欢迎在留言区讨论分享。
你可能还喜欢
点击下方图片即可阅读
阿里开源 OpenJDK 长期支持版本 Alibaba Dragonwell