那个百无一用的技术主管

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

先讲个故事。

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

管理者身在聚光灯下，红屁股自然是分外耀眼。尤其是技术这门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）两条线，参谋官可以兼而有之，一个项目采取什么架构，哪些部分是第一期就必须上的功能，哪些部分可以降级，哪些部分可以用第三方的服务；产品需求的轻重缓急如何，哪些需求该马上做，哪些需求还得等外部资源到位，哪些需求产品经理还想不清楚得打回去，哪些困难得提前告知让合作方有心理预期。这些都是战场上生死存亡的大事，既要求参谋官的技术能力到位了，宏观的思考和认识也少不了。

好了，班门弄斧的文章写到这，也得直奔主题了，咳咳，关于技术管理，有位前阿里研发总经理的兄长无论履历、见识都远胜于我，讲得既深入又全面，已给无数知名企业讲过课，他的公众号如下，请大家立刻马上迅雷不及掩耳盗铃扫码关注一下，多谢多谢。