技术管理 – 一定要抓大放小
技术管理者要懂得放权，这是经典个老话题，基本上每个管理的教程中都会体现，而每个管理者也都会遇到这个问题。
本文是根据个人的体验，再聊一下这个话题，聊一些可能不一样的事情。
1 身边的案例
1.1 异常忙碌的研发一号位C君
C君带后端团队近10人，有代码洁癖，他事无巨细，所有的研发细节都去关注，表现在以下几个地方
- 绝大部分库表自己设计
- 仔细review组员的代码，细节到抠英文命名含义，有时顺手修改组员写的代码
- 所有的会议亲力参与，所有的需求都去了解
- 所有的运维工作自己来做
1.2 其余案例
- 修改组员代码的架构师
某同事A君，下班提交了代码之后，第二天早上拉取代码，发现项目运行有问题，看过git记录才发现，架构师晚上修改了他的代码，引发了新问题 - 亲自下场写代码的CTO
这是在之前的一家中型公司，我们的大boss跟我们开会的时候说，“之前的CTO一直带项目，我跟他聊过好几次才转变了他的管理思路”
2 带来的后果
技术leader做事大包大揽，虽然使项目进度、质量得以把控，但会带来如下几个后果
2.1 自己累死累活，组员轻松但成长缓慢
还是上面的C君，很长的一段时间，他每天10点之后下班，甚至忙到后半夜，而组员不到8点就撤了，刨去不好意思走太早的因素，组员还能下班更早。
而且C君不敢随意请假，因为很多事情没有backup，他请假的话，别人不容易立马接手
倒不是想强留同事一起加班，主要是C君干的一些活，是可以分给大家的，可以团队成员一起来努力的
这样时间久了，组员得到的实践锻炼很少，成长就会比较慢
管理者虽然很累，但很多活并没有多少技术含量，做的再多只能是对这块越来越熟练，对本身技术的提升，帮助不大
2.2 容易形成一言堂，组内没有活力
由于C君的事无巨细，所有规范、复杂模块，都有C君的重度参与
组员只去做C君分析划定好的内容模块，要么无需思考，要么继续按照C君的思路继续来做
目前该项目，就是C君一个人说了算，因为整体项目他了解的最多，其余的人加起来，不如他自己一个人
这样的话，组员发挥自主设计的空间会被压缩，思考与发言也变少，团队就没有了活力
2.3 分散了做核心价值的时间与精力
不管是作为技术leader的C君，还是上面的架构师、CTO，处于管理位置，工作重心就不能是coding了
团队人员的培养、业务的长远规划、技术的研究落地、项目模块的优化迭代……这些都是需要耗费大量精力去做的事情，而且也是作为技术leader，最应当的产出
这个时候，作为技术管理者，每天去抠员工的代码，甚至做一些基础的业务coding，就是捡了芝麻，丢了西瓜
3 为什么会这样
归根结底，做管理的思维、火候不够
3.1 对组员的不放心
很多时候，并不是舍不得手中那点微末的权力，而是对组员的不放心
比如项目工期比较紧，一些交给其余的人做，就怕做不完，有的管理者恨不得所有的事情都自己做完
3.2 个人性格使然
之前一个前端大佬X君，技术很厉害，也带团队，不过他私下跟我聊的时候经常说，某某组员，跟他讲过需求的功夫，我都能把这个需求实现好几遍了
就是因为他喜欢写代码，写的也快，所以之前经常遇到他一个人写几个项目的时候
3.3 真舍不得放权
这种人比较少，但也有，做了技术leader之后，觉得自己应当把所有事情抓在手里，怕自己掌握不了核心，怕被底下能力强的员工排挤出去
还有就是比较享受自己掌管一切的感觉
3.4 性格太好
有的时候，管理者也放权了，也安排了组员做很多事情，但如果有组员叫苦说完不成，就会立马出手来帮助
4 该做的 - 放权
最主要的，是相信组员，相信他们可以做好
4.1 把非leader的工作，交给别人做
如果项目能做到完全不用leader写代码，也是正常的，因为不写代码并不代表对项目无法cover，反而有了充足的时间，从各个角度上更好的把控全局
4.2 各自负责自己模块的所有设计
自己的业务模块，自己去设计，包括库表、组件，如果是比较复杂或重要的模块，可以让组员提前做好设计，leader来review设计
对组员的设计，做点到为止的提醒，告诉他哪块会有问题，
即使任务明显超出该组员的能力范围，也可以以打辅助的方式帮助其实现，毕竟这种打怪升级，才是工作的必经之路
4.3 运维轮班
建立运维轮班制，每个人都需要肩负，项目是大家一起的，不是管理者自己的，有压力一起扛，有光荣一起享
4.4 细节不去过多干预
在有团队各种规范的基础上，让组员自己去遵守规范
平时静默review，把review的list发给组员去做，不去打断组员的思路
4.5 适当给组员压力
把任务分给组员时，可能他们会压力大，这个时候，该自己去补课就要去补课学习，该加班就需要加班
管理者可以陪着一起加班，但不要随意出手帮忙去做
5 该做的 - 把握最主要的事情
精力放到刀刃上
5.1 项目的核心架构、黄金流程
可以让别人来写，但自己一定要熟悉，知道上下游的数据流转，知道系统的业务限制、性能瓶颈
5.2 项目进度、交付质量
通过jira等管理工具，关注项目的运行情况，做到大方向不出问题
5.3 团队的发展
技术产出、人员成长，仍需要花大力气去做
6 总结
我也跟C君聊过很多次，道理他也明白，他现在也逐步把手上的事情分出去，团队运行慢慢回到正规。
因为我之前也遇到过类似的事情，有段时间像C君一样，独自扛着项目费力走的时候。
一路走来，跟不同的领导、同事交流过很多，基本统一的认知都是，“该放就应该放”、“管理抓住核心的事情”
这样的话，管理者的格局、视野才会高，才会有更好的发展。