那个百无一用的技术主管

最近一个朋友刚结束了短暂的空降技术主管的生涯,饭局中忍不住吐槽:我几乎做到了老板要求我的一切,为什么下属们仍然认为我百无一用?我笑了笑,说这一点都不出奇,我刚毕业那阵儿,也常常觉得自己的主管百无一用。而我现在全力以赴的,也仅仅是避免成为一个百无一用的技术主管而已。

先讲个故事。

一群猴子在爬树,越是爬得高爬得快的猴子,它的红屁股就会被下面越多的猴子所看见,也就更容易被其他猴子所嘲笑,但是所有的猴子屁股都是红的,其他猴子不被嘲笑,只是因为爬得慢屁股没有机会被看见而已。管理学把这个归纳为「红屁股效应」。

管理者身在聚光灯下,红屁股自然是分外耀眼。尤其是技术这门Talk is cheap / Show me the code的手艺,觉得头儿技术能力不如自己的,恐怕不在少数,手艺不如人,威望就更加难以建立。

有人说:那我即便当了技术主管,也继续死磕手艺,代码量遥遥领先,这总镇得住了吧?

来来往往见过这么多的技术主管,也仅有一位采取了这种策略,落地还算成功的,但也只能在5个人以下的小团队维持。

团队一旦扩张,必然要分出大量的时间用于业务的梳理、团队的管理以及内外部的沟通,从而使管理者贡献代码的专注力下降,这也是为什么被选出的技术管理者往往是更有技术潜力的大咖,而管理干久了手艺的红屁股就露出来了的原因。

不只一个人问过我一个有意思的问题:作为技术主管,安排多大比例的时间写代码合适?

我的回答和普遍的观点反着来:战争时代(项目紧急或者复杂)尽量少写,和平时代(项目不紧急或者稳定)尽量多写

项目紧急或者复杂,就意味着项目之中存在大量有待梳理与优化的点,意味着技术主管要投入更多的时间去整合资源、精简需求和迭代方案,个体的代码贡献与整体的效能提升相比,就显得没那么重要了。反而到了项目的稳定期,作为技术攻坚的带头人,引入业界前沿的技术、算法或者框架,让战争时代Quick And Dirty的方式和不得不情况下做出的妥协变得优雅又牢固,持续深挖团队的技术护城河,营造团队以精进技术为导向的氛围,培养各个方向顶尖的技术梯队,本来就是技术主管在和平年代最重要的使命。

遇上和我一样爱偷懒的同学,追问就紧跟而来:如果一直是战争时代,是不是技术主管就可以一直少写代码甚至不写代码?

许多人的心中,技术的精进自古华山一条道,只有写代码。无可否认只有翻越每一处技术的险境,完成一个功能或者模块的上线,才能深入了解技术细节的方方面面。然而,对于技术主管,这显然不是最高效的精进技术的方式。最高效的学习方法,永远是通过别人学习。现今早就不是史玉柱一箱泡面闷出汉卡的时代了,不管是Review下属的代码,阅读顶会的Paper或者谷歌等巨头公司公布的技术方案,还是面对面扣细节的讨论一个技术方案,对于个人技术提升的帮助都要比闷头写代码价值要大。成为技术主管,意味着拥有了更宽广的技术触角,从只了解单一模块的技术细节,到需要了解上下游所有模块的关键技术细节。无论战争时代还是和平时代,技术的修行都至关重要,只是技术修行远不只写代码。

当然,这个问题还隐含着另一层意思:技术主管是不是可以不是团队之中技术最强的那个人?对于这类送命题,我心里早有防范。

回答之前,容我先卖个关子,我时常推荐一本十分实用质朴的小册子,给新晋技术主管的朋友,书名叫10人以下小团队管理手册,书中鲜明的提出一个观点:工作最拼的人不适合当主管!(至于为什么,请亲自到书中找答案)那么与之相对的是不是:技术最强的人不适合当主管?

这就要具体问题具体分析了。一提起技术最强的定义就够让人头疼了:是指技术的深度,还是指技术的广度?是能快速给出合格的技术选型,还是能快速整合最优技术选型的资源?是能给出效果最优的技术方案,还是给出成本最低产出最快的方案?是能写出整洁可维护、高效不粘人的代码,还是能一眼瞄过别人的代码,毫不费力指出关键优化点?我想每个技术人的答案都不一样,甚至每个业务根据所处的阶段,所需的技术主管类型也不一样。

至少有一点我是肯定的:技术主管(不是技术总监)需要具备对项目执行的技术方案进行细节粒度把关的能力,技术主管不一定具备某项单点技术上团队最强的实力,却必须有团队最为宽广的技术视野。比如负责推荐的技术主管不一定精通各种排序算法,但他(她)对排序、召回、离线、近线等一系列模块的理解程度将直接决定了推荐的最终效果好坏。

洋洋洒洒一大堆,好多人怕还是弄不明白技术主管究竟有什么用处,以我浅薄的理解,技术主管也是个兵,主要角色有这么三种,列举如下。

  1. 指导员。这种指导既可以是技术上的,也可以是业务上的。以实际场景为例:「喂 小王,KDD那篇阿里讲排序的论文你读过了没?我昨晚抽空看了下,对我们X系统的实用价值很大,你赶紧读一下,下午我们来讨论」「喂 小李,Y系统的近线模块内部知识平台有篇文章刚发出来,整体的设计与我们的需求特别匹配,快快调研一下」「喂 小张,你这个预测任务,我建议可以添加Z指标作为附加的标签,利用多目标学习提升性能,我周末跑了一版,性能有比较明显的提升,你可以继续跟进」,简直絮絮叨叨像个居委会大妈。遇上紧急情况,还可以抢过一把油腻的机械键盘来,啪啪啪,打个十环的靶。
  2. 政委。上至团队的使命传达(我信奉透明的工作方式,只要不是机密的,都应该向团队成员敞开),到个人技术成长或职业发展的困惑答疑,到考核晋升的结果同步,下至找不到女朋友的心理按摩,都是政委的分内事。没事谈谈心吃吃饭搞搞娱乐活动,谁会愿意和自己不喜欢的人工作呢?微软的纳德拉说过,文化是一家公司最重要的事情,那么小到一个团队,氛围就是最重要的事情。氛围搞好了,信任就起来了,大家能团结起来投入战斗,其他都是水到渠成。
  3. 参谋官。某公司内部划分了TL(Tech Lead)和PL(Project Lead)两条线,参谋官可以兼而有之,一个项目采取什么架构,哪些部分是第一期就必须上的功能,哪些部分可以降级,哪些部分可以用第三方的服务;产品需求的轻重缓急如何,哪些需求该马上做,哪些需求还得等外部资源到位,哪些需求产品经理还想不清楚得打回去,哪些困难得提前告知让合作方有心理预期。这些都是战场上生死存亡的大事,既要求参谋官的技术能力到位了,宏观的思考和认识也少不了。