之所以想聊这个，一方面转眼又到年底绩效季，又将有一批新的主管诞生，另一方面也发现身边一些单兵能力很强的专家或架构师一旦晋升为主管后，却无法管理好一个小团队。
我不是管理专家，不过仍可以从自身的经历出发，带来一些思考。
“技术主管”可以简单地理解为技术团队的主管，核心的职责我觉得有三个：
1）带领团队拿到业务项目的结果。
2）管控好团队内的技术架构。
3）提升团队的综合战斗力。
为什么是这三个？因为这么些年走下来，发现技术主管所做的工作都脱离不了这三个职责的范围。下面展开说说。
首先是带领团队拿到业务项目的结果。
所有公司的生存之道都是挣到钱，也就是商业价值。那么钱从哪里来？当然是客户。客户为什么会付钱？当然是公司提供了一些特殊的价值。而这些价值就是来源于公司的业务项目。所以技术主管的首要目标就是全力以赴拿到业务项目的结果，帮业务赢。
很多技术主管没有想清楚这一点，只想着做高大上的技术，高超的架构设计，极高的并发，看起来非常完美，但假如无法迅速适应业务需求的变化，那就是华而不实。
最优的当然是兼顾架构完美的同时能完成业务目标，但如果要从架构的完美和业务目标的按时交付二选一，毋容置疑，一定是先拿到业务目标。有时候就为了快速拿到业务目标，需要做一些架构上的取舍。
然后是管控好团队内的技术架构。
技术主管不只是项目经理，除了带领团队拿到业务结果外，还需要体现出对技术架构的把控能力。
前面有提到为了快速拿到业务目标，有可能会牺牲架构上的完美。但这不代表技术主管就什么事都不做，任由架构腐化下去。在打粮的时候全力打粮，在需要打磨武器时，仍需要锻造趁手的武器，以便下次更好更快地打粮。
这要求技术主管在业务没有那么紧迫时，预留出资源及时整顿技术负债。
对于管控技术架构，现实中经常发现存在三种类型的技术主管。
一类是管得非常细，根据自己的专家经验，以非常挑剔的眼光去看待团队成员的架构设计，最终结果就是团队成员畏手畏脚，成长较慢。
一类是管得非常松，基本等于不管，又容易因团队成员能力参差不齐，极易演变成灾难，到后面再做构架治理或重构，已经难于上青天。
我们最期望的是第三类：重点管控最核心的架构设计和对外接口，其它的由团队成员适当发挥。
为什么是重点管控最核心的架构设计和对外接口？比如领域模型的设计，存储模型的设计，一旦上线，升级改造的成本非常高。对外的接口也是如此，一旦发布出去，升级时就要求爷爷告奶奶，还不一定能排得上。
最后是提升团队的综合战斗力。
很多从专家或架构师刚晋升为技术主管时，单兵作战素质非常过硬，看到团队同学稍有迟缓，就忍不住亲自下场。结果自己累，团队成员没有成长，等下个项目过来时，恶性循环出现。
所以技术主管一定要成就他人的心态，打心底愿意做一个好教练，不要时不时亲自去踢球。只有每个团队成员的能力上升后，整个团队的战斗力才会有质的提升。
如何才能做一个好教练？有几点可以参考：
1）设定一个激情的目标。人都会有低谷，公司业务也是。如何在低谷时凝聚力量？那就需要一个大家都认可的有激情的目标。
2）坚持和团队成员每个月一对一沟通，及时反馈做得好的与需要改进的。如果容易忘记，就给自己设置一个按月循环的日程表或会议邀请。项目或周会上的沟通无法取代一对一沟通。
3）碰到难题，让团队成员先思考，让他们先给出他们的答案，主管做选择题，而不是一看到问题直接疯狂输出主管自己的答案。否则既看不到团队成员的成长，也可能错过一些创新的想法或方案。
4）要有容忍度，允许一定程度的犯错，不要过于苛求完美。很多时候没有标准答案，要分得清哪些是自己认为的最佳实践，哪些仅仅只是自己的习惯。把自己的习惯强加于别人，拿不到好的结果。一定要尊重心性，而不是反着来。
这三核心职责里面，最难的恰恰是第三个。
管理是一个永恒的话题，一点小经验，供参考。
