今天来跟大家讨论一下技术主管需要什么样段位的技术？
首先我要说明的一点，技术主管前提一定是技术出身。对于那些完全不懂技术，但是又身兼技术主管或者总监的同学，我这里就不再赘述，毕竟这个已经超出我目前理解力的范围。比如阿里云的王坚博士，基本上不懂技术细节，但是依然是阿里云的CTO，一手缔造了阿里云。
那我们这里再详细讨论一下，作为一名技术主管，到底应该有什么样的一个技术的段位？或者换句话来说，你的主管的技术水平需要到达什么样的一个水位？
先说结论，作为一名技术主管，一定是整个团队的技术架构师。像其他的一些大家所讨论的条件我觉得都是次要的，比如说写代码的多少，对于技术深度的钻研多少，带的团队人数多少等等，最核心的是技术主管一定要把控整个团队整个业务技术发展的骨架。
为什么说掌控团队技术架构是最重要的？因为对于一个团队来说无非就两点，第一点就是业务价值，第二点就是技术价值。
对于业务价值来说，有各种各样的同学都可以去负责业务上面的一些导向和推进，比如说产品经理，比如说运营同学。技术主管可以在一定程度上去帮助业务成功，甚至是助力业务成功，但是一定要明白技术同学一定要有自己的主轴，就是你对于整个技术的把握。因为业务上的决策说到底技术主管是只能去影响而非去决策，否则就是你们整体业务同学太过拉胯，无法形成战术合力的目的。
对于一线开发同学来说，你只要完成一个接一个的技术项目即可。但是对于技术主管来说，你就要把握整体的技术发展脉络。要清晰的明白什么样的技术架构是和当前的业务匹配的，同时又具备未来业务发展的可扩展性。
那为什么不能把整个技术架构的设计交给某一个核心的骨干研发同学呢？
所以这里就要明白，对于名技术主管来说，未必一定要深刻的钻研技术本身，一定要把技术在业务上的价值发挥到最大。所以在一定程度上来说，可以让适当的同学参与或者主导整个技术架构的设计，但是作为主管必须要了解到所谓的技术投入的产出比是什么。但是如果不对技术架构有一个彻底的理解，如何能决定ROI？
也就是在技术方案的选型里面一定要有一个平衡，能够用最小的技术投入获取到最大的技术利益，而非深究于技术本身的实习方式。如果一名技术主管不了解技术的框架或者某一些主干流程，那么就根本谈不上怎么样去评估这投入的技术产出比。一旦一名技术主管无法衡量整个技术团队的投入产出比，那就意味着整个团队的管理都是在抓虾和浑水摸鱼的状态，这时候就看你团队同学是否自觉了。
出现了这种情况下的团队，可能换一头猪在主管的位置上，业务依然运行良好。如果在业务发展好的时候，可能一直能够顺利推动，你只要坐享其成就可以了，但是一旦到了要突破困难的时期，或者在业务走下行的时候，这个时候你技术上面的优势就一点就没有了。而且在这种情况下，如果你跳槽到其他公司，作为一名技术主管，对方的公司对你的要求也是非常高的，所以这个时候你如果都说不出来你的技术价值对于业务上面的贡献是什么那想当然，你可能大概率就凉凉了。
那问题又回到了什么样的水平才能到达架构师这个话题，可以出来另一篇文章来描述，但是整体上来说，架构的本质首先一定要明白，为的就是业务的增长。
其次，架构的设计其实就是建造一个软件体系的结构，使得具备清晰度，可维护性和可扩展性。另外要想做好架构，基本的基础知识也必不可少，比如说数据库选型、分布式缓存、分库分表、幂等、分布式锁、消息架构、异步架构等等。所以本身来说做好架构师本身难度就非常大，需要长期的积累，实现厚积而薄发。如何成为一名优秀的架构师可以看我的公众号的其他文章，这里就不再详细的介绍了。
第二点是技术主管需要对于技术细节有敏感度。很多人在问一名主管到底应该具备什么样的综合能力，能不能用一种更加形象的方式来概括，我认为就有一句话就可以概括了。技术主管应该是向战略轰炸机在平常的时候一直遨游在大气的最上层能够掌控整个全局，当到了必须要战斗的时候，可以快速的补充下去，定点打击。
我参加过一次TL培训课程，讲师是阿里云智能交付技术部总经理张瑞，他说他最喜欢的一句管理概括，就是“心有猛虎，细嗅蔷薇”，也就是技术主管在平常的时候会关注于更大的宏观战略或策略，也就是注重思考全局，但是在关键的时候一定要关注和落地实际的细节。
换句更加通俗的话来说，就是管理要像战略轰炸机，平常的时候飞在万丈高空巡视，当发生了战斗的时候，立即能够实现定点轰炸。
所以如果说架构上面的设计就是对于整个团队业务和技术骨架的把握，那么对于细节的敏感度就是对于解决问题的落地能力。
那怎么样能够保证你自己有一个技术细节的敏感度？
我认为必要的代码量是需要的，也就是说对于一个主管来说，不必要写太多低代码，但一定要保证一定的代码量，让自己能够最好的，最快的，最贴近实际的理解实际的业务项目。自己写一些代码，其实好处非常多，一方面能够去巩固和加深自己对技术的理解，另外一方面也能够通过代码去更加理解业务。
当然贴近技术的方式有很多种，不一定要全部靠写代码来完成，比如说做code review的方式来完成，做技术方案的评审来完成，这都是可以的。对我来说，我就会强迫自己在每一个迭代会写上一个需求，需求会涉及到各方各面的业务点。有前端的，有后端的，也有数据库设计的。
自己亲自参与写代码或者code review，会让自己更加贴近同学，能够感知到同学的痛点，而不至于只是在空谈说教。
总结
所以对于一个技术主管来说，我认为首要的就是具备架构设计的能力，其次就是要有代码细节的敏感度，对全局和对细节都要有很强大的把控能力。
当然再总结一下，这一套理论只是适用于基础的管理者，而非高层的CTO等，毕竟不同的层级要求的能力和影响力都是不一样的。
