技术走向管理第一站 技术经理

技术经理

技术经理会有很多不同的定义，我们这里说的技术经理是技术团队的经理。规模在 4～15 个人左右不等，有些公司会更倾向于项目团队的配置，前后端测试都有，针对特定项目。目前来看更多的是前后端分属不同的团队。

技术经理是最基层的一个常备管理层，属于从技术走向管理的第一个转变。就类似士兵转军官的概念，这个例子不是很准，但是这一层转变代表的含义非常接近。

候选人

小团队也会有技术经理的设置，但是团队越小技术经理越像是一个过渡层。工作任务更多的是粘性，要保持住团队的稳定，也要应对各种团队不健全和需求高频变动的团队稳定性，以及摇摆的技术实现之间的平衡。在上层和基层之间粘合，让研发动作能持续的更久，团队更强只存在于希望中。

在 80 人以上的技术团队里，技术经理更多的都是来自团队内部的培养。因为团队的基数已经够大了。有很多的候选人可以筛选。这个体量的团队，有稳定的技术栈，新鲜血液的补充也比较及时，技术团队分工明确，研发体系和流程已经相对成熟稳定。

这样的团队不管是出于结构调整、人员补充还是团队扩充，经常会有技术经理的岗位空缺，需要补充技术经理。这时候更倾向于从内部提拔选聘技术经理。一个是给自己的研发人员提供向上的晋级通道，再一个是内部人员已经完全熟悉了自己的研发全环节，适应度更高会和内容融合更好。

晋升的动机，扶上马

当线出现的岗位确定由内部提拔的时候，会有两类人选，第一类人选是自己举手的，他们会和上级明确自己可以承担更重的担子，希望能更进一步。第二类是上层中意的，工作中表现好，有潜质。可能是听从安排执行力高，也可能是头脑灵活能搞定业务方千奇百怪的需求。

不管什么类型的，都是优点千秋各自不同。如果能有一个占据绝对优势，那还好说，很快就能胜出。平分秋色的情况比较难平衡。

上层看上的候选人是最让人纠结的。能看上说明一定有表现非常好的地方，大多数都是因为技术层面占比更大。这一类人中有些会对提升技术经理表现出兴趣缺缺，这样的人会非常困惑是走管理还是技术路线。技术是硬实力，能看见摸着让人更有信心，只要努力一定在进步。管理太虚，能走多远还不好说。浪费几年时间可能管理没做好，技术也没啥提升，就得不偿失了。

从实际看大多数人是主动举手的，但是主动举手的这些小伙伴是真的对管理有信心有兴趣还是对官帽的兴趣更大，其实都不难猜--当前社会共识还是对有官身的人更认可。所以主动举手的人中大多数也是冲着官帽而去。在管理的理解、需要的付出、角色转换带来的工作改变这些事项上都盲目自信了。

被看上的纠结也让人很不解，他不会是第一个技术经理，技术经理已经让大家误以为都放弃技术了吗？

初期的培养--送一程

任命下达后，新官上任，要开始履新。不管出自什么意愿和背景都有一个共同的难题就是如果快速改变。

旁观其他人做管理看着都很简单，照葫芦画瓢最容易。所以一段时间过去，发现抄了一个表面。做成了项目经理。

初期的技术经理最容易犯的错是用项目经理的思路管职能团队。关注点就是任务拆分、进度、质量。接受到任务后安排到人，确定各个里程碑排期和交付时间，看一下上线质量。再多一些的就是充当技术小能手，那些需要救火那里去救火。

技术经理管理要从职能团队的角度来进行，角色的改变还是非常大的。最起码要关注团队的技术成长、团队所涉及的研发流程通畅性，要识别团队研发过程中的风险，要承担团队在外面树立形象的主要职责。

管理课程很多，单纯的讲解这些肯定是不佳的送一程的方法。我们现在用一句口号来启发新任的技术经理们思考：如果一年后你还是这个团队的经理你希望这个团队是什么样？团队做出的系统是什么样。不设约束的去想，结合实际的去干。

技术经理的岗位职责

扶上了马，还要明确后期的考核要求。考核要对照着岗位职责来确定。技术经理的岗位职责包括以下：

• 带领团队在要求时间内完成工作任务；

• 带领团队提升技术水平；

• 改善工作过程中的流程问题；

• 识别团队中的风险问题，包括但不限于：骨干情绪异常、项目进展异常、团队与其他团队沟通障碍、技术储备不足等；

• 协作参与更大领域范围的提升和工作；

• 在有条件的情况下将团队发展到更大规模。

在招聘环节，很多对技术经理还要求能搭建开发环境和标准、编写核心代码，具备解决技术难题的能力。但从内部提升而来就不太考虑这些问题，算是默认条件。不满足也就不会进入候选人名单中。

岗位职责写下来都很干，相对比较枯燥，但是总是会被人忽略，即便有些已经干了一段时间的技术经理也是如此。技术经理要能够灵活的掌握，把自己的风格和特色融入到日常带队中。最终带出的团队能具有自己的烙印。

我就见见过一次，技术经理面试完非常遗憾的说，技术不错，背景不错，都不错，就是感觉好像风格和现在团队的风格不契合。最后都不错的候选人还是被放弃了。技术经理在考虑自己团队的日常氛围。

袖里乾坤--技术经理的舞台

技术经理有个尴尬的地方，就是舞台是固定的，演员也基本都是固定的。不具备主动更换人员的权力（多数时间都是这样的），不具备做什么的权力（通常也总是这样的）。除了上述这些，还要面对以前的历史债务。不管什么时间留下的，都贵当前的技术经理负责。

所以说技术经理的舞台是袖里乾坤，看着很大，但是腾挪的空间其实很小。

但是毕竟也是有空间的。想起我做风控技术总监的时候，面临同样的困局：系统非常陈旧，产品的意识就很 low 一直习惯于用技术的人力来解决问题；团队的平均技术薄弱，有能力的都走了；线上异常层出不穷，业务未必闭环逻辑随处可见。

那时候我大概用了这么几招：

1. 集中需求：将需求都统一由一个人去评审，评审完了以后说是统一安排。但是统一安排的过程就预留了第二个招数；

2. 虚报人力：从业务需求里预留几个人力出来，预留的人力主要在做线上异常特别多的几个漏洞，像卡单处理、重新推单等。既然能找到规律，那就可以落到代码上。所以虚报的人力预留出来做了最常见问题的自从处理，打着构建补偿的旗号。

3. 争取资源：虚报人力做了一些零散的小需求，到处漏风的系统有所提升，技术人员不在每天都是四处救火，能更聚焦在业务系统上了。这时候就和大家一起讨论，形成了未来系统重构的雏形思路。拿着这个思路去和领导争取了 hc。

4. 拆分任务：系统重构的思路具备了，也不敢集中人力大张旗鼓的进行系统重构。人力的重头还是要留在业务需求上。即使有了人力富余，但是也只是富余了一点罢了。只能拆分任务，将任务拆解到很细的粒度，一点点的来。每次下发新需求涉及到有改造的，都先对着长远设想比对一番，看怎么改能一步步的走到理想的程度。

那时候真的想的就是我干活怎么欺上瞒下、不符合业务节奏、还时不时偷偷摸摸，不能摊开了说撸袖子干。没办法，不能掌握人力权力，不能对工作任务有评议权的管理者确实有些憋屈。只能在划出了各种限制的舞台上用尽气力，盯着未来，做到最好。

初为技术经理最容易困惑的地方

• 总是在变，尤其需求。刚想好了要怎么改造一下，偿还到一些技术债，安排刚下发，跟着而来的是需求变了。技术债的优先级通常都比需求的要低，所以要重新改变人力分布，重新调整计划。但是业务需求无穷无尽，都不用太多，只需一而再，再而三。很多技术经理就已经说了锐气，回到了听从需求从天而降，完成任务回家睡觉的状态下。

初为技术经理总是会分不起变的和不变的。业务需求会一直来，会一直变。这个是永恒的不变。如果需求来了就不变了，也不会推动技术架构的进步。不变的自己的目标，希望带着团队走向什么高度，希望自己团队做出来的系统能有更多功能更强更稳定。所有的变化都要围绕着不变来设计，目标是不变的，无非就是行进过程中的路径向哪边弯曲了。

• 对人力没有太多的决定权。经常会听见类似手里就这些牌怎么干呢这样的牢骚。初为技术经理尚未建立权威的时候，更习惯亲力亲为不给领导找麻烦的方式来工作。等没有反对的声音的时候，大家也都习惯了技术经理多干点的情况了。所以技术经理时常会感慨，任务安排太难了，活太多了干不完啊。

技术经理其实对人力决策权的感慨的核心是技术产出的困扰而非人事本身。技术经理不需要干预人事，而是技术产出效率低带来了好像人力很紧张的错觉。所以问题的核心是如何提升技术产出效率即可。这个是技术经理的职权范围的，培训、绩效都是直接端起可见效的工具和手段；必要时杀鸡儆猴，新需求时申请新 hc。

• 新时代新旧文化交织，尤其现在的技术经理基本都是 90～95 年左右的。新旧的矛盾冲突非常明显。最深的就是要当出头鸟吗，还是随着大流就别太显眼，甚至扮猪吃老虎更开心呢？以前将新官上任三把火。现在新思维更提倡扮猪吃老虎。所以很多人在考虑是不是别太张扬？一上来就搞什么系统重构、工作分工改变啥的好像太张扬了些。

在实际上，有上面这样想的，也有上来就轰轰烈类热火朝天的干的，都是看个人的性格。其实不管用什么思路，唯一要注意的是行为一致性，要上下一致性行动，统一目标、重点、工作机制和协同方式。都能朝向一个目标一起使劲。是敲锣打鼓齐步走还是人衔枚马裹蹄都不重要了。

继续提升

管理是条不归路，能将一个团队的战斗力发挥到最大所形成的价值要远远超过单打独斗完成的工作。所谓没有最好只有更好。尝到甜头了就会一直走下去。

但是技术经理毕竟只是初级的管理岗位。要想继续提升，在没有位置之前，可以做的就一件事：经常站在你的上司的角度考虑问题。站在更高层去想去发现，然后回到自己这一层去改善去落地。

经过持续的锻炼一般的管理技能和手法都很容易提升。最难的是格局、魄力。什么时候能意识到自己是管理者，不只是一个员工，也是管理者。企业的发展和自己的决策都有关系的时候，就具备向上继续前行的条件。不然不敢决策，更多的是考虑一点得失或者个人的得失。还是不具备最突破的那一点改变。