今天我要批判技术管理者
上一期分享了今天我要批判架构师，今天我来批判一下不合格的技术管理者！
我在阿里巴巴工作期间是一个名副其实的“刺头”，批判中台、批判架构师、批判技术管理者，当然，也包括自我批判。
今天来聊聊批判技术管理者！
在某些业务技术团队中，有一个不好的趋势就是团队越来越业务化，越来越没有技术味道。每个人都在谈业务，技术大会上在谈业务、周会上在聊业务、周报里写的是业务项目……唯独少被谈及的是技术本身。这里并不是说业务不重要，而是说理解业务和把控业务需求是技术人员的基本要求，但并不是全部。
对技术团队来说，技术味道的缺失是非常可惜的，不利于技术人员的成长和发展。很难想象一个没有技术追求的团队能开发出一个健壮、可维护性好、可扩展性好的系统。业务代码的堆砌，从短期看也许较快实现了业务需求，但是从长远来看，这种烂系统的增加会严重阻碍业务的发展，形成一个个的“屎山（shit mountain）”系统，而工程师被裹挟在业务需求和烂系统之间心力交瘁。
这种情况会导致系统腐化堕落、技术债越垒越高、丑陋的代码疯狂滋长，像肿瘤一样消耗你所有的能量。就像Robert C. Martin说的，
不管你们有多敬业、加多少班，在面对烂系统时，你仍然会寸步难行，因为你大部分的精力不是在开发需求，而是在应对混乱。
造成这种局面，技术管理者负有主要责任，说严重一点是工作上的失职。这种失职主要体现在两个方面，一是技术不作为，二是业务不思考。
现在很多的技术人员一旦晋升到TL岗位就开始脱离技术工作，俨然一副“道法自然”的模样。试想，如果一个TL从来不关注技术、不写代码，对技术没有热情也不学习，甚至其本身技术就很差，那又怎么能指望在他领导下的团队能有技术味道呢？
实际上，我们不需要这么多“高高在上、指点江山”的技术管理者（Manager），而是需要能真正深入系统和代码细节中，给团队带来实实在在改变的技术领导者（Leader），如图1所示。
图1 Manager和Leader的区别
现在很多TL每天混迹在各种会议上，忙着做各种沟通协调的事情，可是我们真的需要这么多的会议和沟通吗？
不是说沟通不重要，只是现在的会议太多了。以我个人的经验来说，很多会议其实是低效无意义的，所以TL需要更注重独立思考，而不是人云亦云。
雷军说过，永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰。这句话用来形容大部分的PD简直再贴切不过了，所以我宁愿PD“无为”，也总比做出很多无价值的产品要好，很多系统的复杂性就是由大量无意义的需求造成的。在一定程度上，技术人员的疲于奔命，内因是团队缺失技术味道，外因主要是PD的乱作为。
这里给PD的意见是：请一定要深入理解并思考业务，不要退化成一个PPT设计师和业务需求的传话筒，不要只停留在写PRD、画Demo上，要用系统化的思维来规划产品并解决业务问题，从而赢得技术人员的尊重。
给TL的意见是：TL必须深入思考业务，严格把控PD提出的“客户需求”，把伪需求、无价值需求挡在门外，防止它们侵占团队原本有限的技术资源，从而让技术团队将更多的精力投入到系统优化上去。
不知道是不是对技术负责人的这种失职行为积怨已久，在一次年底绩效沟通会上，我当着HR的面对我当时的主管说：“你是一个不合格的技术负责人，有以下几点。
第一，你没有思考，你所做的事情无外乎就是传话筒，上传下达；
第二，你没有价值，不管是汇报会还是周会，没有看到你任何有价值的建议；
第三，你没有和下属建立信任关系，正襟危坐，不接地气，下面的人像一盘散沙；
第四，你没有过程管理，平时打哈哈没有要求，年底给一个‘惊喜’。”
本文节选自《程序员的底层思维》一书，想要了解更多相关内容，欢迎阅读本书！
▊ 《程序员的底层思维》
张建飞 著
这是一本超越具体编程技法的技术书：职场晋升不仅需要技术能力，更重要的是思维能力。本书带你学会用底层思维解决复杂技术问题，突破职场“天花板”。
这也是一本培养思维能力的通用技能书：打破认知局限，培养通用的思维能力。本书帮你跳出思维定势，轻松解决生活及工作中遇到的问题。
本书涵盖程序员应知应会的16种思维能力，共18章，分为三部分。
第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力。
第二部分结合软件行业的特点，主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。
第三部分主要是对上述思维能力的综合运用实践。
粉丝专享六折优惠，扫码即购！
往期推荐