技术部门Leader是不是一定要技术大牛担任？

现在在腾讯做技术Leader，之前在阿里，绿厂也带过技术团队，每家的情况有共同点也有区别。现在总结下来，除去特别通用的技术/责任心/沟通/主动性这些，作为Leader很关键的个人素质我认为是三点：学习能力，抗压能力和情商，下面就对于这几点做一些展开：

核心：高效产出

在降本增效的背景下，产出不高的团队是非常危险的。技术Leader很忌讳又很常见的就是做成PM, 把需求接住了也完成了，最多也就是60分。在这之上，为了确保更高的产出，Leader日常需要做的包括以下几点：

• 合理区分优先级和资源投入方向，确保在关键方向拿到关键结果；
• 对于技术上的嗅觉和判断力，这很考验一个Leader的技术沉淀和对业务的理解；
• 参与到方案的设计，关注方案实现的细节，确保方案最优；
• 团队成员能力和凝聚力提升，持续优化团队，确保团队的战斗力；
• 向上沟通，与合作方搞好关系，提升团队信任度和影响力，争取更多资源。

具体到业务上则是：

1 大型方案的推动和落地

在大公司很多项目在横向上都有多个团队参与，这类的方案一般会由Leader直接负责，横向项目的挑战除了方案本身，多个团队的协调，节奏把控和风险梳理也是很大的问题，技术Leader对现在的问题，进度最为了解，中间很多协调的工作其实不是PM而是技术Leader在做。这种情况特别是在阿里，阿里的项目很多都是横向，我参与过的五福/都江堰双十一等项目都有多个BU参与，中间涉及到的开发同学可能有上千人，在这种情况下即便方案定了，想要按照既定方案顺利落地都是很困难的事。

2 满足不同维度的要求

来自业务方/老板的要求既要快，又要多，更要好。但人力和资源总是有限的，Leader要在中间辗转腾挪，要去主动跟业务方沟通达成共识，需要向老板解释为什么需要这么多的资源和排期，更需要考虑到团队的容量和发展。这里特别考验Leader自身的综合素质，沟通能力自不必说，平时在团队/合作方/老板对你的信任度，和合作方的关系都是很重要的点。Leader很核心的是对于团队的运营，这里的运营包括对于团队内部的关注，也包括与外部团队的协作，还包括在部门内部的影响力。

3 压力的隔离和疏导

压力来自于业务方/老板的要求，来自于业务/公司/大环境的压力，来自于组员工作/生活上遇到的问题，来自于合作方的协同/关系的处理；对于外部的压力，基本都到我为止，对于内部的压力，需要及时的感知和疏导。这两年由于疫情和行业的特殊情况，基本所有公司都开始了降本增效，这对于行业里所有人都会有影响，包括晋升，调薪，年终和内部机会等，这些都是和大家的切身利益直接相关的点，也会变相增加团队的压力。在这样的背景和压力下，如何争取到更多的资源，把有限的资源发挥最大的价值，团队内部成员核心诉求的满足，引导团队继续朝同一方向前进，对Leader都是极大的考验。

4 极强的心理素质

工作中的各种被骂，被挑战，被质疑都是家常便饭。能任命为Leader一般在之前的工作中都是成绩很突出的同学，在之前的工作中，遇到这种情况很少，即使在很被动的情况下，也需要自己迅速调整心态，继续把工作推进下去。过去这一年对我来说，改变特别大的点就是学会了否定自己，在刚工作的时候觉得自己能力强，自己搞怎么样都能做出来，不太需要在意别人的看法，但作为Leader要对于团队负责，需要主动去改变不足，适应环境。这点说起来很容易，但真正做起来特别难。

在18年去阿里的时候，有很大程度的原因就是想去带团队，但当时的能力其实是没有完全准备好的，现在想想可以改进和提高的地方也很多。很感谢当时我的老板瓦雷，从他身上我学到了很多。

同事是位研发小leader，带了10来个人

今天闲聊的时候，他说最近帮助下属梳理了几个业务需求和技术方案选型的问题

沟通了大概30分钟后的结论是可以帮全组人节约至少一周的工期时间

我觉得这是一种典型的Leader价值表现

他需要比下属看得更高更远，他要具备**技术思维、业务意识、沟通协调**的综合素质

否则，一将无能会饿死三军

题主所述的技术大牛该如何定义呢？

是要像谷歌Jeff Dean，还是百度楼教主那样才算是技术大牛？

这种技术大牛在整个业界本来就没几个，中小公司甚至全公司可能都拿不出一个能让知乎用户信服的技术大牛，那么这些公司就不用选leader出来了吗？

而且真正硬核的技术大牛，可能更适合单干或者带极少量几个精英下属的模式

比如阿里多隆

作者：simpx
链接：https://www.zhihu.com/question/25158759/answer/30271902
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

多隆在阿里的层级是P11，相当于副总裁。刚来阿里的时候，我以为专家组，一定是都是高P的大团队。哪知道进来发现，多隆下面包括我，仅有3个下属，其中一位师兄还长期在北京。每天中午一起吃饭，可以当团建，吃完饭一起散步，就算是outting了。。

多隆不爱带团队，团队一般沟通成本高、水平参差不齐，而他一个人就能顶一个高效顶尖的团队（所以每次问他问题打断他，我都深深内疚，感觉拖了阿里的后腿）。作为淘宝最早的程序员之一，很多产品早期就是他一个人开发维护的，文件系统tfs、key-value系统tair，cache、搜索、通讯框架等等，引用行颠对他的评价：
在内网的标签上，他被称为神，这不是恭维，在所有工程师眼中，他就是个神。多隆做事一个人能顶一个团队，比如说写一个文件系统，别人很可能是一个项目组，甚至一个公司在做，而他从头到尾都是一个人，在很短的时间内就完成了。从03年到07年，淘宝搜索引擎就是他一个人在写，一个人在维护，而且这还不是他全部的工作，另外他还做了其他很多事情。

多隆不擅交际，不常分享，也不玩什么社交网络，一般很难在公众场合见到他，只要能不参加的会议、采访，他都不会参加。就算去，他也常常会带上笔记本。据说他也曾经带着笔记本去outting，在车上写代码。。虽然被所有人视为神，但他真的由心底觉得自己是一个凡人，他做的最多的就是是默默的坐在工位上，对着屏幕上的黑框，写代码、解决问题。

因为一旦当了Leader，就要分很多精力去跨部门沟通、业务评审、概要设计等等，对于技术大牛来说就是浪费时间，并没有将其的能力价值最大化

一个大团队，如果公司愿意花更多人力成本去构建更好的团队的话，一般同时会设置两类角色：

一类是总监，负责团队价值输出和业务目标管理；

技术总监职责

一类是架构师，负责技术攻坚和架构落地；

架构师职责

这样就可以明确分工，各司其职

然而，很多人力成本比较捉急的中小型公司，一般只会存在总监一种角色

那么在选择总负责人时就要做一定的取舍，通常都是选择具备技术思维、业务意识、沟通协调的综合素质较高的那位

我简单地把一个100人的团队汇报层次分为三层

每层的管理者通常不适合同时直接带太多人，这也符合管理学理论所建议每层不超过十几个人（两个披萨原则）

两个披萨原则
是指与会人数不能多到两个披萨饼还不够他们吃的地步。 亚马逊CEO杰夫·贝索斯(JeffBezos)认为事实并非公司开会参与人数越多越好，他认为人数越多的会议将不利于决策的形成，而是会导致与会人员的人云亦云，称之为两个披萨原则。

所以会产生这样的汇报情况，

一线Leader直接管理下面的10位左右的普通员工；

二线Leader直接管理下面的N个一线Leader；

三线Leader直接管理下面的M个二线Leader；

以确保每层Leader都不会直接面向超过10人的下属

显然，越往上走，技术能力在晋升的评比要求的占比会越来越低，而业务意识、沟通协调的占比会越来越高

这也是符合我们日常所见，往往最高的Leader并非技术最好的那位，技术最好的那位大概率在上面例子中的二线Leader，甚至一线Leader当中。

我举个例子，如果三国演义是所有武将都在这个技术团队里面，技术排名靠前的大概有这些：吕布 关羽 张飞 赵云 马超 颜良 文丑 许诸 等等…

那么技术最牛逼的吕布会是最高Leader吗？武力超群的张飞是最高Leader吗？

我相信很多人的答案都是否

这道理和我们技术人员的职场晋升也是一样的道理

咱们看看身边晋升比较快的哥们，是不是比普通人多具备了一些能力？

譬如格局、沟通、担当、情商等等的一些软实力

作为技术人员，很容易陷入一种「唯技术论」的思维惯性，就是衡量一位工程师的价值只用技术水平来衡量。

比如说，工程师A技术水平略高于工程师B，但工程师B却更加能受到主管的青睐，授予其更多的职责或者更好的项目，并成为重点培养对象。这很容易导致团队中其他普通工程师的不理解，因为大家可能不清楚主管层面的价值衡量体系。

作为技术管理者，必须有自己的一套相对完备、初步可量化的价值评估模型，对团队中的每位成员的价值、特长指标有良好的理解，这样才能让每位成员发挥他们最高的能力输出，分配合适的项目、任务以适配他们的职业发展和成长。

再用我熟悉的NBA为例，好的Leader不一定是团队里面最牛逼的攻坚得分手，但他需要更强的大局观和赛场阅读能力

组织者：

负责全队组织、串联，是团队的战术发动机，具备良好的大局观【代表人物：詹姆斯、保罗、哈登、纳什】

这种角色可以类比具备长远的规划能力，能挖掘每位组员的潜能，能带领团队走向正确方向的Team Leader

例子：

控球后卫–魔术师约翰逊，身高206cm，利用身高优势用大屁股碾压对位的防守者，具备良好的大局观和无死角的传球能力；

得分手：

顶尖的得分能力，关键时刻能依赖个人能力打破得分僵局【代表人物：乔丹、科比、杜兰特、艾佛森、麦迪】

这类角色类比能在某些方向具备强悍技术攻坚能力或者达到有业界影响力水平的技术专家

例子：

得分后卫–篮球之神乔丹，身高198cm，历史最顶尖的得分能力，攻防一体，无需多介绍；

作为一个前技术流程序媛，看到这个问题我脑子里第一反应是“这是肯定的啦，技术不强的老大怎么能带好技术团队？”

但是等我静下来仔细思考，发现这个问题其实很有层次。经过几天的琢磨，我把自己的认知记录下来分享给大家，希望能够给大家一些启发。

首先，基层研发团队由技术大牛来担任Leader比较便于管理

（这里所谓的“基层研发团队”指50人以内的开发团队）

古人云：“文无第一，武无第二”。简单来说，同样两篇锦绣文章可以各有千秋，人们在赞叹的同时很难排出优劣；

然而如果两个武林高手想分出高下却很容易：拉在一起打一架就好了：）。

而技术和武术是一样的，很容易分出高下。同样一个技术难题，A解决不了而B可以解决，我们就可以认为B的技术能力比A强。

然而，人自古以来都是愿意追随强者的。大家可以试想这样的场景，组内技术人员解决不了的问题，领导过来三下五除二就搞定了，这个时候团队成员还不对领导佩服的五体投地。

自然，这个领导在团队里管理起来就如鱼得水了。反之，如果领导死活搞不定的问题经常被下属分分钟搞定，那么团队成员自然觉得领导好无能，这样又怎么会死心塌地的执行领导的命令呢？

同时，**基层研发团队的Leader往往是招聘的第一筛选者，**在整个面试过程中候选人的技术能力也是基于基层研发团队Leader的判断。如果一个Leader技术能力较弱，对候选人技术能力的判断也不会精准。

所以，在基层研发团队里，Leader的技术水平最好高于下属，这样团队比较容易管理，也容易选拔出优秀的下属。当然，这样也容易出现问题，比如【领导能力决定团队能力天花板】等，今天在这里先不做赘述。

其次，研发团队越往上，越看重领导的综合能力而非单一的技术专精程度

（这里指的研发团队指部门级别，一般在百人以上）

大家观察一下自己所在部门的老大，往往会发现他不会是团队内技术最全面和精通的。这个其实很好理解，技术的面很广，一个人精力又有限，很难每线每点都研究的很透彻。

但是作为一个部门的老大，往往对综合能力要求很高，比如要具备很好的技术视野，团队管理能力，对业务的深入理解以及沟通协调能力。换而言之，部门级别的领导需要在技术一定深度的基础上扩展自己的综合能力，这点比某项技术的专精对于团队更为重要。

比如阿里云的创始人王坚博士，他能够看到云计算的发展趋势以及重要性，在合适的时间点提出建立阿里云，并能够说服马云从阿里集团获取资源。在早期大家都不看好阿里云（包括阿里内部人员以及外部李彦宏和马化腾这样的大佬），团队内的技术人员纷纷流失，整个部门的绩效也一直垫底。

但他能够一直坚持，这才有了今日阿里云的成就。阿里云涉及的技术点多如牛毛，如果随便挑一个技术点来讨论研究深度，我相信阿里云里一定有工程师比王坚博士强。但真的能够看到行业发展趋势，能够在弱小时争取到外部支持，能够在艰难的环境下聚拢人才进行死亡行军，这才是一个“技术老大”所必须具备的能力。

在我们普通人眼里，江湖高手是那么神秘和高不可攀，似乎世间没有可以阻挡他们的困难。然而在现实中，不管高手武功多么高强，遇到军队都是“战五渣”。小说中那些视万军如无物，轻取上将首级的武林高手终究只能存在于小说之中。同样的道理，韩信并非高手，但你能说他不是名将吗？

最后，真正意义上的领导人早已跨越了行业区隔

还是以阿里云举例，王坚博士好歹也是获得过【中国IT十大杰出青年】并在微软证明过自己的技术大师，但真正帮助阿里云落地的人却是马云——一个完全不懂技术的英语教师。如果大家关注过阿里云的发展历程，在早期是马云亲自要求当时阿里金融的系统架构必须建立在阿里云基础上，即便那个时候阿里云非常的不稳定。说实在话，我觉得马云是有大智慧的战略家，他虽然不懂技术，但却在技术这条路上看的很远。

有句话叫做“条条大路通罗马”，在某一个方面有深入了解的人往往会触类旁通——哪怕并非他的专业。

最早让我有这种感觉的是姚明，姚明在面对记者采访时所说的话充满了人生哲理，但大家都知道他在NBA时并未接受过任何高等教育，甚至连高中都没有毕业（后来读的大学，非常上进），由此可见，姚明是通过他自己的专业（篮球）来探索人生和世界的，当站在篮球届的顶点时，他的认知也已经到了一个令人仰慕的高度。回过头来，当他再去思考其它问题时，依然能够给出让人惊讶的看法。

在职业生涯早期，我非常崇拜技术大牛，但到了现在我心中理想的老大就是这种已经在自己领域抵达颠峰，对人生和世界有通透看法的人。至于他是不是技术大牛我丝毫不关心。看到这里，大家可能会说，那为什么你觉得基层团队的老大最好是大牛呢？我觉得主要还是基层团队成员的级别不够，很难感受到这种抵达堪境大佬的魅力。如果真要举例子，大家可以回想一下马云成功之前有多少次被人当成骗子就好了。

回到本文的问题，我觉得在一家优秀的公司里，组织结构应该是这样的：

一个抵达堪境的大佬->某一领域中有综合能力人才->某一领域中的专业人才->普通专业员工（->代表领导）。

看到这里，我建议大家首先认知自己所处的阶段，并学会欣赏高于自己一级甚至两级老大的能力——只有先懂得欣赏才会有学习的动力和意愿不是？

最后，希望大家都能够通过自己的努力，踏踏实实规划自己的职业生涯，最终都能够成为一方大佬：）

点赞是原创者继续创创作的动力:)

欢迎大家关注我微信公众号：空白女侠 与你分享职场与数据的故事。曾经是名互联网数据专家目前在伦敦从事数据及顾问工作，想通过写一些自己的心得给大家呈现不一样的职场感受。

10人以下小团队，领导最好是技术大牛。

10人以上的团队，领导最好是业务大牛和管理大牛。

10人以下，基本上只要一层管理即可。底下人都可以向领导直接汇报。再培养两个技术骨干，就可以支撑起一个摊子。

10人以上，业务就会多样化，以及人员分工更加多样。10人以上是团队战，要求领导如何发挥团队能力。和你们竞争的也是大团队，所以更需要领导力。

领导力这个对于做技术的，10个人的的确确是个分水岭。

举个例子，一般做技术的领导，都有一些迷之自信。或者骨子里认为自己是一个技术无敌。总是对下属的技术嗤之以鼻。如果遇到更“笨”的下属，就是有个技术问题或者思路，给他讲好几遍不理解的人。

通常情况会直接上手，这就导致领导自己的活越来越多。下属有心无力，并且自信心越来越低，责任感也越来越低。领导就会感觉拖着乌合之众，只有自己最能。那团队产出肯定越来越少，试想你的团队一个人和对方10人团pk，凭啥你能赢？

所以，领导还是要学会适当放手，至于10人以下的团队，会点管理就可以，培养2个核心、3个核心就可以撑起来一团。

10人以上就考验领导带管理者，就是说不但要求你有领导力，还需要带初级管理者。如果你的下属没有做过管理，那你就得手把手带。这个真的很难。

我理解，好的管理就是眼里能“揉沙子”。一般做技术的管理都很直。委婉的话他们听不明白，别看做技术很牛逼，思路清晰。因为。做技术非黑即白，做人不是，有很多灰色地带。需要管理平衡。

举个例子，

公司的规章制度很严格，来晚一分钟都算迟到。那最近业务紧张，员工经常加班，按照公司规定也没有加班费。

长时间加班大家疲惫。突然，有一天你核心骨干迟到了，然后你发现hr告诉你他提前打卡。打卡上没迟到。你怎么办？如果你装不知道。他下次还这样你怎么办？如果你找员工谈，他心里不爽不加班了，不好好干活了怎么办？

如果不是你直接下属，是你下属的下属，下级管理者的下属。你要怎么提醒他？直接说还是暗示？

管理就是这样，好的管理都是游走在灰色地带。非黑即白的规则，有时候就很难有效激励员工。做技术的喜欢非黑即白，所以大部分搞技术的，都需要经过一个很长的实验期。

管理，说白了就是管人和理事。人管不明白，就把事搞明白，一件事一件事拿出来，看看团队谁来做合适。按事索骥，把合适的人放到适合的位置。一开始，先不要考虑人情世故，先把这些放一边。管理必须脸皮厚，要不就是给自己挖坟。

比如，一个业绩很差的下属，经常无缘无故迟到。你和他交流了几次，他答应了改正，却不改正。那就坚决要做出惩罚。赏罚分明才能服众。惩罚之前，也要提前预警。迟到两次你就要直接找他聊聊。假如，你无视这种情况，最后达到公司的辞退标准，你直接给辞退也不是个好领导，你没有给改正机会。

我之前总是会遇到这样的小领导，下属犯了错误，他不好意思指出，批评，要求改正。一直坐视不管，美其名曰不好意思。等下属犯错不可收拾的地步，那只好开掉。这时候员工也懵逼，不知道自己干了什么，直接就给开除了。

最后在一起谈辞退员工的时候，员工来个灵魂拷问，“你为什么不早说？一次机会也不给？”

这时候其实是最难过的，你本是好意，却是这样的结果。

管理是技术也是艺术，也是一门哲学。管理的最高境界，就是眼睛里可以“揉沙子”。但什么时候揉，什么时候不揉，那真得好好研究一番。

推荐一本书《10人以下小团队管理者》，非常适合新手管理者。

技术部门领导是不是一定要是『技术大牛』，取决于『部门』的规模、成熟度和团队的文化。

举几个假设场景：

• 一个刚开张的创业公司，所有技术部门员工只有三个刚毕业没工作经验的毛头小伙，你说这个部门技术领导是不是应该是『技术大牛』？太应该是了。
• 一个已经有成熟产品的公司，某个技术部门员工有一百人，员工来源很多样，有刚毕业的，有工作很多年的，有外企来的，有国企来的，这个部门技术领导是不是应该是『技术大牛』？这个领导是不是技术大牛不重要，重要的是他能够hold住这么多样化的员工群体。
• 一个跨国公司，某个技术部门的办公室分布在中国、美国和以色列，员工数量近千，就跟不用说很多样了，这个部门技术领导是不是应该是『技术大牛』？最好别拿『技术大牛』的标准来衡量他，重点看他管理多文化环境下工作团队的能力。

很明显，不同的团队规模，不同的成熟度，不同的公司文化，决定了应该选择什么样的人来当技术领导人。

现代管理方式，非常明确了——不是要『管理』人，而是要『赋能』人。

赋能，Empower，就是赋予员工能量，让员工自我爆发出最大的工作效率，而不是像指挥官一样高高在上下命令『朝这走』『往那打』。

道理大家都明白，重点是，赋能这事，因人而异，因团队而已，就和孔夫子说的『因材施教』一样，要根据个人和团队特点来确定策略。

规模小、成熟度不高的团队，领导人可以是『技术大牛』

注意，我说的是『可以』是技术大牛，不是说『必须是』技术大牛，不是技术大牛也可以胜任。

规模小的团队，要么是从属于一个大团队的小分队，要么就是创业公司的全部技术家当，不管如何，都就是最基层的技术团队，好比军队中的班一级作战单位，就好像班长的单兵作战能力必须也要过硬一样，这种小规模的技术领导，因为在最前线，所以最好也要技术过硬。

为啥？

因为基层就服能力强的领导啊。

你枪法准，士兵服你；你编程能力强，程序员服你——就这么简单。

而且，成熟度不高的团队，也就是成员缺乏经验，你傻呵呵地『赋能』，和他们说：『这个设计你们自己决定就可以，我完全相信你们。』

表面上看是信任，实际上害了他们，因为他们啥都不会，判断力有限，怎么能由着他们来？当然应该给予直接指导了！

这种团队的『赋能』，就是直接给予指导，这种工作技术大牛最适合。

只有当成员成熟度提高的时候，才可以放手让他们去做。

规模大、成熟度高的团队，领导人不要追求成为『技术大牛』

我说的是『不要追求』成为技术大牛，意思就是，这个外置的领导可以是技术大牛，但是不必强求。

当团队成熟度变高之后，成员可以自主做出决断了，这时候领导就不应该代替团队成员做日常的判断，只需要跟踪观察和做出适当建议就行，过多干预团队运作，就会让团队感觉你是一个讨厌的家长，总把他们当长不大的孩子一样管着，他们不会开心的。

这时候的『赋能』，就是给予信任，做适当的跟踪和帮助。

你可能会问了：规模小而且成熟度高的团队呢？规模大而且成熟度不高的团队呢？

规模小而且成熟度高的团队，这种梦幻团队，领导人是什么类型都可以。

规模大而且成熟度不高的团队，领导人必须是一个管理能力超强的人，他必须要想办法解决这个团队规模大成熟度不高的问题，我不觉得这样的人有时间让自己成为所谓『技术大牛』。

团队文化非常多样的团队，领导人必须舍弃『技术大牛』的身份

这样的团队往往是在有很大规模的跨国公司，帮工地点世界各地，团队成员来自于各个国家和种族，所受教育也各不相同，在这种团队里，领导人需要思考什么问题呢？他们要思考的是这些：

• 如何让纽约和上海的团队协调彼此的工作进度
• 如何建立制度，让产品中的设计不要踩到某国文化的雷区
• A组的工程师觉得B组是傻X，B组觉得A组是傻X，如何协调他们的关系
• 招募到顶级的程序员我们需要什么样的人力策略
• 如何打击办公室性骚扰现象
• 如何让外籍的工程师们觉得我们公司值得努力
• ……

你看，这些需要思考的问题，有哪一个适合『技术大牛』身份相关呢？

一个都没有。

所以，即使你曾经是『技术大牛』，到了这样的领导岗位，你必须要舍得丢掉这个『技术大牛』的帽子，然后，别人来吹捧你，称你为『技术大牛』的时候，你要说：我不是技术大牛，我只是为技术大牛服务。

很好的问题。

其实这是两条线。我将管理这条线上的领导称为Manager，而技术这条线上的领头人称为Leader。我觉得这也应该是这两个词的原意。

如果能够正确区分这两个词（角色），那么我觉得种种困惑就迎刃而解了。Manager的主要任务就是统帅，工作对象是人心；而Leader的主要任务就是尖兵利刃，工作对象是产品（或者服务）。

这是两种完全不同的工作和角色，一个人有可能可以分饰两角，但是一来这样的人很少，二来这也要求要有高素质的兵（老兵）才能配合好。所以我认为理想的情况是将这两个角色分开，让不同的人担当。

当然，这会引入另外一个麻烦，那就是double report line，也就是组织内存在多条汇报线的问题。有行政管理上的汇报对象，也有日常业务上的汇报对象。对汇报者（兵）的要求其实也不低。

对Manager/Leader同样。在这种体系下，Manager要更多地把自己定位成一个服务者，心理疏导者，而不是命令者，所有工作以维护组织健康和劳动者个人身心健康为中心，要习惯不插手具体业务（切忌外行管内行，直接干涉业务，自以为是），特别是要充分尊重Leader；而Leader则要端正清晰地认识自己，将提高自己以及团队的业务能力，完成业务的既定目标作为自己的工作重心，切忌想要依靠行政管理权利来强化自己的影响力的想法，而是应该通过自己的专业性（expertise）来树立权威。不要眼馋地位，要真心热爱现场业务。（这也要求公司的人事晋升制度能够给现场人员足够高的天花板）

是不是有些难？我认为的确是这样。所以如果你就是在这样的一个组织当中，请珍惜它。如果不是，也不用太担心，因为大多数组织都不是。如果你有能力，那么请试图改变它，让它成为那个样子。如果没有，那么就适应它，或者离开。

不是的，比如我。我现在就是个技术Leader，带了16个人了。不是技术大牛，有超过半年没正经写过代码了，最常写的是sql。具体来说就是在阿里的D2工具上去查询一些表，做一些数据分析，主要是当团队成员遇到问题的时候，我基本上第一招就是去做数据分析，因为大部分的算法问题其实都是数据问题。

那么我平时的主要工作是什么？

1.评审业务需求，挡掉很多垃圾需求和无用的东西，这是耗费我很多精力的。因为这需要收集足够的信息。一个东西有用还是没用取决于多方面的信息，能成功狙击掉一个需求是需要很多准备的，要想说服别人必须说服自己。大家都很聪明，必须要有理有据。

2.项目顶层技术设计，内部任务拆分。我的设计其实就是技术选型，大方向的指定，就跟研究生导师一样，区别是我更实际，我给的方案更合理一些。技术方案里很多小trick其实是很重要的，这其实就是大牛和非大牛的一个重要区别。大牛指导这些小trick，这么多trick叠加起来产生的效果是非常恐怖的。我作为Leader，不关心这些细小的trick，更关心项目的顶层设计。内部任务拆分，就是分饼，这个技巧多的一比。反正目的就是既要保证事情能做好，同时又能调动大家的积极性，让大家热情满满。

3.出去给大家请功。在阿里，做了事情你得让别人指导，要营销自己的团队。怎么营销呢，其实就是华丽的ppt外加牛逼的成果。这一年来得益于左膀右臂们的给力表现，让我能邀功成功好几次，灰常开心。给大家请功成功了，大家愈发信任你，工作愈发好做。

其实就这么三个主要的方面，其他的都是些带兵打仗的老生常谈了，大家自行百度即可。

请相信我。是，就是，别说那些虚的，下面会给出不可抗拒的解释

知乎里很多回答我不知道是否真正是经历之谈

反正我是，我生涯核心的岗位就是在技术部门，对技术这个特殊岗位我太有感触

真不想谈管理学那套东西。题主的题目，“一定”“大牛”这两个词基本把大家已经往管理那个方向引了，毕竟谁也不能说那么绝对，索性讲讲管理的重要性吧

结果讲了半天，如同打太极

我只想说明，很多公司没有用技术大牛当技术部门领导，基本就两个原因，一个是，没有大牛，二个是，这技术大拿管理水平极其有限扶不上去

所以我个人回答这个问题，就针对从更优解的理想情况上是否应该选择大牛这个角度来说，不考虑你能不能招到

要大牛，因为

1，大领导绝对喜欢有闭环能力的二级负责人

如果你是老总或者一个线条的大总，你要管的很多，你肯定希望自己下面的那几个二级负责人能对他管的领域全权负责，

大多人都喜欢管人，不喜欢管事，所以管人的人肯定希望自己管的人是去直接管事的。你只要问这个技术负责人这个事行不行，他能以他的专业力直接回答你，yes or no，OK，闭环了

假设你直接管的这个技术负责是个管理型人才，他的作用只是帮你分摊精力去管一部分人。平时做常态化工作的时候，没问题，他会运用他搭建的管理系统，让每个技术员做好自己该做的事，维持公司运转

然而——当你想要对一个比较新的，主线外的技术问题获得反馈或者实施某项动作，结果他只能帮你去做二传手去收集和传达信息，久而久之，效率不高，你偶尔可能直接去问技术负责下面的一个更精通技术的主管，得到更及时的反馈，更偶尔可能直接让主管向你汇报。

那你和技术负责之间，技术负责之间和技术主管之间的关系，就会发生改变，这样的技术负责的管控力度就会被逐渐打破。而这些是久而久之必然会出现的情况

所以，从上级做事的角度，任命一个技术负责人，肯定希望他是越专业越好

2，专业大拿拥有技术权威性后，对下属专业人员的管控话语权才会稳固

在此，我先强调一点，不是什么带技术两个字的部门就是真正的技术部门。我们在这里讨论的技术部门，一定是真正需要技术进行把关、输出生产、革新的部门，而这么一个公司也一定是拥有技术发展需要的公司(像一个电视台，里面设的技术部，说白了就是设备支持部，提供的是服务和响应，这样的部门和我们讨论的技术应该没有任何联系)

所以这样一个真*技术部门需要的技术人员是真正来做和专业强相关的事的，发挥专业思考和价值的人。这些专业人员，做的专事一旦比较深入，往往都有那些破毛病，做事效率不高，选择困难，瞻前顾后，孤芳自赏，不乐于沟通……

这样的团队，如果没有一个比他们更专业的人来带领，而是像电视剧里那些霸道总裁，女白领一样，张嘴就是“我要的文件怎么还没有看到”“我不管，你必须给我解决”，我敢保证这些技术人员会被逼走

而且，如果不够专业，对这批人的劳动成果和过程效率判断也会失误，很容易失去信任，进而让这个部门失去初心，我并不信靠管理能解决这个问题

况且，人性如此，人们可以接受自己的专业能力不如别人强，但很少愿意接受自己的管理能力不足。所以面对一个管理派领导，不少专业人员都会产生我能取而代之的想法，对团队稳定一定会造成影响

所以，要直接管专业人员，你必须要足够专业，越专业越好

3，公司需要技术大牛的大脑来驱动这个部门裂变和进化

说到这里，我不得不说，几乎所有回答都没触及过一个技术部门可能给公司带来的的战略性契机，因为他们的眼界只能看到那些成熟的，既有的行业，公司中，一个技术部门所做的常规工作

而我还是可以不要脸地说一句，我算是在技术部门经历过公司搭建、长期运维，甚至行业变革的人

当一个公司要跨越行业周期，而这个周期的转变点是发起于技术时，你就会知道技术大牛的重要性，他们可以运用自己的专业积累，形成的专业认识来主动，积极地适应甚至引领公司在行业中的革命。我经历过，所以我很有感触

这一点，是管理能力再强的人也绝不能替代的。这种时候，很多公司要么走在别的公司的后面，要么请外部咨询专家出主意，这时候都毫无疑问会心底里想，要是有个更专业的人在，该多好

综上，技术部门的负责人，就是要大牛

而大家回答的常见盲点无非那几个：

技术大牛不一定管理好，对公司不能发挥应有作用

——如果有几个技术大牛，公司一定会尝试培养他们的管理能力选最优的，重要的是根本没有大牛

当leader最重要的是能管住人，如果有个管理天才管的住部门里那个技术大牛，让他在部门里只要能发挥作用就行

——且不说这样的技术大牛会不会一直待着。当真正出现这样的管理天才和技术大牛都在，一般公司都会设置总监＋总工模式，甚至现在的机械，能源，科技，土木这些技术型生产行业，都是设总工和院长(项目经理)的，总工就是技术线条老大，专做技术型管理，不矛盾

成熟阶段的技术部门，需要的是统筹者，而非技术深耕者，技术人员的可替代性更高——且不说一个公司的技术部门能不能成熟到技术已经成为定式的程度(忽略了行业革命)，如果真正有，那么这个领域就已经不存在技术大拿，或者人人都是，那和我说的也不矛盾

最后加一段：很多人回答一个专家不适合管技术部门的时候，列举了管制度，管经营，管汇报很多可能做得不到的方面，这本质上已经把他当做一个总经理来考虑，这是错的，那些东西可以通过公司的流程运营，人事激励相关部门来管。明白这一点，你自然会知道，一个专业部门被专业人员来管的重要性

技术Leader尤其部门级别及以上，最重要的并不是技术能力，而是技术管理力。

能否做出好的技术选型节约团队研发时间？能否管理好老板不合理的预期？能否整合公司其他部门资源为本部门所用？能否把本部门的价值输出最大化？能否给部门产品技术赋能，形成对竞争对手的技术竞争优势？

这些才是管理几十人上百人的技术Leader需要重点思考的事情。真正硬核的技术大牛，可能更适合单干或者带一只特种部队（10人以内），因为他们的价值更多在于技术攻坚而非技术领导力。

我认为：每一位真正的部门技术Leader，都需要具备超强的技术领导力，都需要跨越的四道槛：

1.第一个跃升，叫责任跃升

部门技术Leader的主要职责是：

平台规范：与技术经理/架构师/程序员共建软件公共平台
提升效率：提升技术团队的工作效率，构建技术团队的文化
资源协调：管理和协调公司各个部门占用本部门各条线的资源
教练技术经理/架构师，提升技术经理的管理能力，提升架构师的业务思维
参与商业决策
确定对竞争对手的技术优势

我刚担任创业公司技术总监时，团队遇到技术困难，习惯于上阵去解决。问题是解决了，回头发现团队的产出反而慢了。原因很简单，关键的技术决策、规划、资源协调、培养下属、商业决策等工作都被耽误了。

部门技术Leader需要对技术团队业绩负责。当团队规模变大，除非问题真的只有你能解决，否则不能轻易陷进去。承担新的责任，很重要。

2.第二个跃升，叫业务跃升。

要实现这种跃升，先做到四个理解：

从用户价值视角去理解业务：业务必须为用户价值服务，需要洞察用户真正需求。

从用户视角去理解业务：用户从哪来，整个流转过程做了哪些事、用户使用业务的具体场景是什么？

从商业视角去理解业务：业务方向跟公司的商业战略是否一致，怎么通过业务流程赋能商业腾飞？是降本增效还是增大投入取得突破？

从产品视角去理解业务：产品怎么完成对业务的支撑？开发哪些产品重要，哪些没那么重要？

这四个理解，又可以称为：业务洞察力。

部门技术Leader需要提升对用户的理解、具备基础的商业知识和一定的产品能力。并将这些能力应用到对业务的驱动中，最终培养出卓越的业务洞察力。

这就是第二个重要的跃升：业务跃升。

3.第三个跃升，叫战略跃升

部门技术Leader必须具备一定的战略决策能力。什么是战略决策能力？战略决策能力不是有很多天才Idea，每个Idea都可以颠覆世界。比决定做什么更重要的是你能决定不做什么。

只有真正理解了用户、业务、商业、产品，才能做出最重要的关键决策。进而才能具备战略决策能力。技术团队是成本团队，资源用在哪，资源投入的多少，都需要决策。

拿阿里举例：阿里要求P9管理者要具备一年的战略决策能力，P10要具备三年的战略决策能力。

能不能在有限资源下，做出正确的选择，这是做好技术总监的第三个重要的跃升：战略跃升。

4.第四个跃升，叫认知和能力跃升

认知和能力的提升离不开工作和读书学习，尤其是读书学习，很容易被大家忽视。

其实不管工作多忙，都应该坚持看经典书的习惯，看好书就是和牛逼的人直接对话，自然能获得高速成长。

技术管理者需要认知需要能力，广泛阅读计算机经典技术书籍几乎是必须的！

5.第五个跃升，叫沟通跃升

既然是部门技术Leader，自然需要跨部门协调资源、推进合作、判断需求，有时候可能还要做跨公司的沟通。这个过程，真正理解其他部门/公司的需求非常重要。

有时候，技术人和其他部门的同事会有沟通困难的感觉，甚至相互都觉得对方不能理解自己，其实往往是沟通语言上出了问题。

对部门技术Leader而言更困难的是如何跟老板沟通。前几天，和几个做安全的技术VP聊天，大家谈到一个问题：企业的安全投入力度怎么控制。

一个朋友说了这么一段话：安全防护这件事很头疼，不出事老板觉得团队没什么价值，出事了老板也会觉得团队没什么价值。其实不仅是安全团队，只要是技术支撑型团队，遇见不是技术出身的CEO，都有可能存在这种困境。

大家讨论了半天，最后结论是：这必须有一个能向上做好管理的CTO。他需要能用老板听得懂的语言，告知投入的必要性，并获得老板的支持。

部门技术Leader如果不能做到和老板的良好沟通，结局一般都会暗淡出局。

以上五点是我认为部门技术Leader需要具备的能力。

其实这个问题稍微推理一下就能得到答案。

如果一个人的技术一般，管理能力超强，就会有两个问题出现：在成为Leader前，你技术一般，他技术好，凭什么你成为了Leader？就凭你管理能力强吗？你又怎么展现出自己的管理能力强？

成为基层领导者，必定是因为你的技术水平较高，能服众，别人解决不了的问题，你能解决；管理能力的强弱，只是次要条件，身在其位某其事，成为基层领导者后，管理能力自然会慢慢上来，只是时间的问题，还有就是你愿不愿意去学习的问题。

此时，团队内的所有人，都处在同一赛道上竞争，赛道的名字叫“技术”，而不是“管理”。谁的腿部肌肉发达，要领到位，谁先到达终点，谁就取胜。如果裁判说A先到终点不算，B的腿毛更长，所以裁定B赢…想想都不可思议。

成为基层领导者后，就和普通的程序员不在同一个赛道上，和你在统一赛道的，是同级别的管理者。同级别的管理者，不再拼技术，而是拼团队产出，BOSS评价你，也从原来的“个人评价”变为“团队评价”。技术水平仍然重要，但已经不再是唯一的指标，升职的判断标准，变成了“团队”而不是“个人”。

越往后，在同一赛道的人，对技术的要求越低，管理要求越高，直至公司的最高领导者-CEO。

有人凭写代码起家，逐渐成为CEO的，但从来没有人因为技术水平高，成为CEO的。因为编程水平的高低，对CEO来说一文不值。

举个例子，马化腾、雷军都是技术出身，他们的技术水平可能比很多普通程序员要高，但绝对不会高于公司内部的技术大牛。

“我一个干CEO，业余写代码的，你都干不过我？那我请你来干什么？”

“写代码，我不如你，当CEO，你不如我，咱谁也不会不服谁”职位无大小，只是分工不同，分工不同，专精必然不同。

回归问题，假定限定在技术部门的Leader上，这个Leader是不是一定要技术大牛？

基层领导之所以能成为基层领导，是因为它比普通职员能解决更多的问题，而不是技术水平高。CTO之所以能成为CTO，是因为他比底下的人，能解决更多的问题。

解决问题，技术水平的高低只是其中一个体现而已。公司缺资金，你技术水平高，能解决吗？非要说能，那只能等有关部门给你送上银手镯以及豪华私人单间了。

综上，我认为技术部门的leader，是由普通程序员进化而来，技术水平肯定要高于普通程序员，并不一定要达到“大牛”级别，但一定要比团队内的任何一个人，有能力解决更多的问题，这样才能服众，也才有资格领导。