如果我是一线技术主管…… 1

阿里妹导读：技术主管和团队成员应该是什么关系？只能是普通的领导与被领导的关系吗？如果，你作为一个一线技术主管，你会怎么管理团队？今天我们试试换位思考，假设自己是技术主管，反推团队成员如何做事才能获得更好的成长。欢迎同学们一起讨论、交流。

如果我是一线技术主管，那我可能是团队曾经综合实力最强的，我可能会被时间支配而不能再天天写代码，并且，团队充满各种挑战。

如果我是一线技术主管，依然是每周要写周报，每年要写绩效，想晋升，想加薪、想人生巅峰等等。

如果我是一线技术主管，在团队只有五、六个人的情况下还好，如果是十几个人的团队的话，会希望有人可以站出来帮我。

如果我是技术主管，我更希望：

不抱怨

如果我是一线技术主管，我不会喜欢团队有喜欢抱怨的同学：

主管每天也很忙，听抱怨很消耗时间；
团队有人抱怨，说明团队自然是有问题了，需要花一定的时间梳理出问题，需要及时给出解决方案，甚至要安抚对方情绪；
一个喜欢抱怨的人会影响整个团队的士气。

其实大部分开发抱怨的工作内容很相似，团队成员不配合做事，PD 提了无理的需求等。

大促中我们的后端主管说了些很好理解的话：“看到大促有这么多问题，我很激动，这种情况很好。问题越多说明机会越大，如果都是稳定健壮的系统、完善的流程、合作良好的团队，那么，要大促 PM 干什么呢？”

如果问题都是机会的话，那就没有抱怨的必要。但是，如果真的就是有问题，还不能说了吗？

向上管理

一个管理十几人的团队主管很难有精力做到面面俱到，去了解所有人的细节，给大家找出合适的方向和机会，甚至认真读完每个人的周报都要用一个下午，很难做到你有一个不错的想法的时候，主管就有时间找你聊聊。如果我是一线主管，我更希望团队同学主动找我聊。

作为主管每天既要处理大量一线信息，又要领导团队做出正确的决策，还要照顾团队的每个成员，做出健康的梯队建设计划等，大部分人是没有这个精力的。

刚开始工作的时候，我们误解主管和下属的关系就是领导与被领导的关系，但其实主管也需要被下属管理，这也就是“向上管理”的由来，简单来讲就是主管也需要下属的协助和推动。

主管大部分时间很忙，这就要求下属在向上管理的时候要尤其注意高效、有质量的沟通，如果我是一线主管，我更希望团队和我交流的方式是让我做选择题、判断题，而不是问答题、思考题。

很多鸡汤文提到老板训斥高管：我请你来不是告诉我为什么不行，而是告诉我怎么实现我的构想。在主管不是拍脑子就做的决定的时候，困难肯定是已经想过了，更希望得到的是下属的帮助。

如果我是一线主管，我希望下属这样帮助我：

主动承担团队面临的挑战，给出合理的解决方案；
及时向我反馈经过整理的信息和数据，甚至是结论，辅助决策；
主动关心同事，组织学习，帮助大家（包括我）进步成长。

除了面对面的交流，和主管最多的沟通机会可能就是周报，这是向上管理的重要途径，然而很多同学把周报当做一种负担，写的极其敷衍，就是一周的流水账，发送出来都是浪费自己和收件人的时间。
团队不会有人认真读完所有人的周报，读谁的取决于周报的质量。个人习惯粗略浏览组内所有人周报（周报有 highlights 多重要），坚持几周就能识别一些需要关注的周报，然后会针对这些人的周报设置邮件规则，必须认真看的，遇到不理解的还要过去问的，其它人的周报就被自动过滤掉了。一个普通员工都是如此，更何况一线主管。可见这么写周报可能在无意中浪费了许多次向上管理的机会。

每天忙不完的业务怎么办

还有一种抱怨的声音是：自己每天很辛苦，想拼命忙完业务后做一些技术的东西，造个轮子什么的，但一个需求还没做完，另外一个需求就安排过来了。

如果我是一线主管，我会把团队面临的问题分一下级：

重要&紧急，不能按时完成，则都是失败；
重要不紧急，是个很好的机会；
技术想法，很好的撬动业务的点；
单分析只是个业务需求，看不出明显的兴奋点。

团队的人可能也有几种特性：

能力强，在某领域是专家；
能力一般，有潜力，但是非常有积极性；
能力一般，主动性一般。

其实不用特意说明就知道大部分主管分配任务的思路：

重要&紧急的事情只能交给能力强的人去做，意愿上如果有问题，也要说服对方去做，因人成事，可见能力强有多重要；
重要不紧急的事情就可以借事修人，如果做得好，这个人以后就有信心了，团队多了一员干将，做不好也有能力强的人给保底，不会造成业务问题；
技术想法也可以交给有积极性的人做，这必然占用一些时间，那么这个人手头上无关痛痒的事情只好交给能力一般，主动性一般的人来做。

实际上按照这个向上管理的思路，需要主管去分配任务的时候，你就已经输了，甚至主管来找你问进度的时候也已经输了。

当然每个合格的主管都需要发现、解决团队人才培养的问题，不可能放任问题发生。

什么样的人有积极性

能力强的人很好识别，那什么样的人才是有积极性的，看过一个 AE 快速升 P8 的同学写的文章，他有个很好的习惯。

无论大小难易，永远不满足于做出来指定的事情，一定要给人惊喜。

如果我是一线主管，我不会凭空把一件重要的事情交给某个人去做，我会更期望：

团队同学来教育我某件事情很重要，想去尝试；
在很多微不足道的小事情上做出了惊喜，有理由相信这件更大的事情也可能做出惊喜；
我被分配了纯业务事情怎么办？

上面也提到了简单分析只是业务需求，近五年在阿里将见了太多事在人为的案例，每个人身边肯定也有不少这样的案例。

我们以为自己在做业务，很多时候是因为两个误区：

这不是技术项目：没有什么所谓的技术项目，所有的技术项目除非是显而易见的项目，否则肯定脱胎于业务，只有业务一线的同学才可以抽象出来，做业务需求不是坏事情，拿着完成任务的心态做业务才是最要命的。

没目标：所有做的事情都要契合自己的目标，而自己的目标大部分时候应该和团队目标 match。今天让我开发一个前端组件，我要看到的是这个需求反应了我营销体系对某个分类能力的缺失，需求归纳到我营销可视化体系完善的目标中，在阿里这种人才济济的环境中目标不清晰的人和咸鱼没什么区别。

怎样才算业务负责人

很多小伙伴已经是实际的业务负责人，和三、四个小伙伴一块解决特定业务领域问题，但尴尬的是级别相同，在分配任务的时候会不好意思，觉得对方也有自己的"技术项目"要做，我得求他把这个业务需求做一下。

这种其实不算真正的业务负责人，如果业务负责人仅仅是分配任务，那么任何人辛苦一些都可以做。业务负责人的核心特质应该是有一条是了解业务的发展、引导相关人的个人目标。

这样可以把业务需求转换成每个人目标中的一环，和上面提到的自己做事情思路是一样的，无非就是写代码的那个人不自己。其实即使主管也不可能命令团队成员去做某事，采用命令那样的方式，团队早晚散伙。

最后，如果我是一线技术主管，我希望团队的业务负责人时刻在两个方面提醒自己：可衡量、可体系化。

原文发布时间为：2019-03-26
本文作者：谦行
本文来自云栖社区合作伙伴“ 阿里技术”，了解相关信息可以关注“ 阿里技术”。