工程师如何成功转技术管理_服务工程师转技术

一、工程师如何成功转技术管理

1、正确认识 技术管理的初衷

一般人做技术管理，一般会有下面几个真实想法：

    •    技术不能做一辈子，很多前辈在能力达到一定水平后都转管理了，自己也这么想


    •    在技术路线上遇到了晋升瓶颈，想尝试下管理方向，看自己是否合适


    •    公司发展太快了，老板让我带团队，自己也没办法


    •    管理者工资高，在别人眼中是优秀的代表


    •    指挥做事即可，可以脱离执行层面，越往上走越轻松


上面这几类都属于『外部因素』驱动，说实话，都很难在管理路上走得很远。因为技术管理是极其复杂和琐碎的工作，它远没有你想象中的轻松和风光，而在这些外力下，你做出决策后的结果很多时候跟你的预期是不一致的，这个时候你的怨气和转型痛苦就会出现，你开始质疑你选择的这条路是不是错了？

再来看另外一个问题，作为技术管理者的价值是什么，个人对其定义如下：

    •    对于公司：能带领技术团队支撑好业务，帮助业务实现公司定的战略目标。


    •    对于团队：规划好方向，别让组员瞎忙，同时能帮助他们成长。


    •    对于个人：提升自身的技术和管理能力。


这上面是对对于技术管理岗位的基本认知，你的初衷必须建立在这个认知基础之上。然后试问你自己：是否认可这个岗位的价值？如果你觉得全是牺牲自己来成就公司和团队，那你不可能做得开心，也不可能做好。

第2个问题，你是否对管理者的工作充满热情？并且享受这个过程呢？比如项目协调，比如制定流程并推动落地执行，比如招聘。如果你说我只喜欢做技术相关的工作（比如架构设计、技术评审等），那么你还是走技术路线吧。

认可技术管理岗位的价值所在，并且能激发你的投入意愿。这些就是底层最好的动力，你的成长和回报都是付出后水到渠成的东西。所以这个初衷很重要，三观一定要正。

2、转型期你会遇到哪些困惑或者挑战？

转型期会经历心态、工作方式的转变，很多事情会刷新你的认知。下面几点，我认为是绝大部分人在转型过程中会遇到的困惑或者挑战：

    •    时间不够用：成为团队leader后有很多日常事务要处理，要参加各种会议，有时候还需要分出一部分精力在一线coding上，时间完全被碎片化，根本不够用。


    •    嫌组员效率低：一个你认为简单的需求或者技术问题，交给团队成员后，他们的处理时间远超出你的预期，当外界施压时，你忍不住抱怨和责怪，并开始自己动手处理，久而久之，习惯自己冲在一线，觉得这样效率最高。


    •    恨人际关系复杂：对内对外、对上对下，每天需要和不同职位、不同level的人打交道，有靠谱的，有不靠谱的，某些你认为很简单的事情推动起来却很难，感觉情商不够用。


    •    成就感不强：技术管理成效慢，不想写代码立马看到结果；另外偶尔会收到上级、平级、甚至下级的负面反馈，你开始质疑自己的管理能力，不像做工程师那样经常被认可，落差感强。


    •    不敢放弃一线：担心自己不合适做管理，如果脱离一线执行，感觉技术能力会停滞不前。不放弃一线，精力又跟不上，这个度把握不好。


3、 转型期应该具备的心智

从技术转型做管理，更多的不是能力的变化，而是思维方式和行为的改变。很多刚转型的leader管理做不好，绝大部分不是因为能力不行，而是出现在了认知上。以下几点，我认为是转型期leader一定要具备的心智：

    •    学会从团队的角度考虑问题


    •    深入业务一线，注重执行细节


    •    学会用人所长，具备包容心


    •    重视情商管理，做好自我情绪控制


    •    做好时间管理，多线程调度管理专家


3.1 学会从团队的角度考虑问题

以前作为工程师，更多是从事情本身或者从个人角度出发，成为leader后，转变成团队思维是最最重要的，因为你的KPI取决于你整个团队的完成情况，你要权衡的是团队整体的利益和效能。

员工思维

leader 思维

别人不会自己上

教会其他人，帮助团队共同成长

出问题责怪、抱怨、负面

风险意识比较强，事情做好任务分工、提醒、跟进、支持；事后做好复盘总结分析以及改进提升措施

完成自己的任务就行

不仅仅关注自身，同时关注每个人的任务情况，保证每个人按质按期完成

技术决策 主要考虑自己会不会以及自己有没有技术提升

技术决策会整体考虑团队现状以及对团队的整体技术提升，同时长远考虑复用性、可扩展性、业务影响等

关注个人成长进步

关注团队每个人的成长进步，同时有帮助他们成长的思维意识，形成梯队建设，从而形成团队荣誉感

归功于自己

弱化自己，归功于团队中表现优秀的人

上面6项对比，是我个人认为比较典型的case，比如leader觉得某个问题很简单，嫌员工处理效率低，然后自己跳出来三下五除二给解决了，这种就属于很典型的员工思维。单从搞定这件事情来看，这也许是很好的处理方式，业务方也会很满意，但是带团队是长远的事情，上述做法紧急情况可行，但是变成常态就是非常大的问题。

团队整体能力不提高，leader永远不会解放，这是作为leader应该具备的意识。如果通过这个问题能够提升组员某方面的能力，leader应该扮演好教练的角色，放手让组员自己去做，你要做的仅仅是观察、给一些指点、适当给予时间上的支持。这次处理也许效率不高，但是下次碰到类似的问题，团队是不需要依靠你来解决的，另外组员也有自己的发挥空间，觉得团队在帮助他成长。

 3.2 深入业务一线，注重执行细节

对于刚转型做管理的一线leader，切忌被放权式的管理方式洗脑,放权式管理对于对管理者的经验要求很高，它比较适用于工作流程清晰，团队骨干目标认知以及自驱力很强的团队。

当你个人的管理水平还处于菜鸟期时，一定要从细节抓起，通过手把手带员工，教会他们如何正确的做事，怎么才能达到你的要求，以及如何培养出团队骨干，搭建出团队的核心组织架构，所有这些都经历过了，你在管理上才会有自己的心得体会，才会走得更扎实。

深入业务一线，通过观察执行细节，你能非常清楚团队每个人的优劣势，深入感受自己的管理方式是否存在问题，然后再辅以leader思维去思考和解决问题，管理上才能真正获得成长。这个过程，你可能会收到上级、平级、下级的很多反馈，清楚细节后其实你就有了自己的判断，知道是否是自身的问题，是否要调整，而不是沮丧抓瞎。

 3.3 学会用人所长，具备包容心

知人善任、人尽其才，是每个管理者都懂的道理，但是能做到的不多。尤其在技术管理岗上，我见过有些leader在技术上非常强势，技术权威不容有任何挑战，当组员提出更合理的技术方案时，他会用职级强制要求按自己说的执行，根本不做任何解释。

对于新晋leader，团队对你的信任感还在磨合期，上述做法很容易打击组员的积极性，消灭他们的创造力，这对你带团队来说是非常致命的。如果组员的方案更合理，leader应该倍感欣慰，包容并鼓励这种行为，因为组员某方面的专业能力超过你了，你不再是团队各方面最强的人，你需要做的是调整自己的心智，学会用人所长。另外，还有一种情况是：组员和leader的技术方案都可行，我个人倾向将选择权交给组员，毕竟他们是真正的执行者，应该给他们自由发挥的空间，最后就算出问题对他们来说也是很好的经验积累。

 3.4 重视情商，做好自我情绪控制

管理上能做多大事情，真的和情商有非常大的关系。IT界的技术人员由于工作性质的原因，普遍注重技术上的提升，而忽略情商的培养和维护，作为新晋leader必须从一开始就意识到情商的重要性。管理是一个复合型的岗位，当你的专业技能和处理问题的方法论已经形成后，越往上发展，为人处事的软技能占比会越来越重。

每天和不同的人打交道，这个是管理者的日常工作，因为你需要调动所有可能的资源去解决团队的困难。面对不同职位、不同level、不同性格的人，你要反复琢磨采取何种沟通方式和沟通技巧。

比如一件你认为很简单的事情，推动起来却很困难。可能是因为你对外的沟通方式太生硬，别人不想配合你，或者别人确实有其他更重要的事情。但是如果换一个沟通方式，或者私下关系建立好再当面软磨硬泡，多半也是可以解决的。人际关系上，难免会有碰壁的时候，不要气馁，这跟技术同学写出1个bug一样，是家常便饭的事情，但是一定要注意积累经验。线下和关键的配合方维护好私人关系，比如私下一起聚餐吃饭聊天增加了解互动，别人有困难能及时伸出援手等等，套路有很多。

情绪控制，是一个比较难的事情。情绪很容易传递，如果leader碰到不爽的事情，把组员当做出气筒，这是非常伤士气的，之前建立的信任感很容易消失，受不了的组员也可能就离职了。另外，对外沟通上，如果leader控制不好情绪，不将重点放在解决问题上，只是抱怨或者发火，也非常容易引起配合方的不满，认为你不专业，久而久之，你的团队也会被打上不专业不靠谱这种标签。

在情商提高方面，个人提供3点建议：

    •    保持积极乐观的心态，正能量少负面抱怨，同时提高自己面对问题时的承受能力，想清楚情绪化是解决不了问题的，只会加大解决问题的难度。


    •    能够自我反省并吸收别人的建议和反馈，做得不好的地方要勇于正视并且持续改进。


    •    培养亲和力，不要觉得自己是leader就带着架子，要有一种鞠着的姿态，能够尊重人并且真诚待人，和团队能打成一片。


 3.5 做好时间管理

时间管理的4象限理论可以百度一下，重点说下作为技术管理者如何进行更好的时间分配管理，以及技术和管理两个维度如何分配时间。

第1步：可以拿过去一周或者一个月的时间跨度为例，详细列一下你的时间花在哪些具体事情上了，以及每类事情大概的时间占比。对于技术leader可能的事情包括：需求评审，资源规划和项目排期，技术评审，团队周例会，研发规范制定和落地，项目管理，技术调研，架构设计，coding，CodingReview, 紧急任务协调和处理，业务重构方案设计以及业务新技术充电等等。

第2步：针对第一步列举的每类事情，考虑下哪些是非必须的，哪些是可以授权给团队骨干去做的，哪些是可以优化提高效率的。比如一些简单的需求评审或者技术方案评审让骨干把关即可，项目管理制定好流程规范同时培养一些scrum master或者项目经理下放给他们来做。不用凡事都事必躬亲，leader应该把时间聚焦在对团队最关键最重要的事情上，学会授权和放权。

对于一线leader，技术和管理两个维度如何分配时间，个人的建议是：

    •    作为一线leader是需要亲自写核心代码的，也就是不能长期远离一线，纸上谈兵，长此以往，技术判断可能容易出现失误，而且如果管理不合适再转型回去代价太高。


    •    技术维度：可以将重点放在架构设计、代码审查、技术调研、以及一些框架性的代码开发上，这些事情对于维持技术优势是足够的。


    •    如果管理维度的时间占比超过60%，个人觉得比例是有些失衡的，要么团队太大了（比如超过了10人），要么自身的管理存在问题或者时间管理存在问题，需要关注并考虑做出调整。


二、技术团队管理的六个进化阶段

1、第一阶段：团队规模小于10人（技术Leader）：团队规模小，管理成本很低，重点是带几个人把事情分配好，目标很明确，更偏执行层面，结果导向，目标导向即可。

2、第二阶段：团队规模大于10人小于 20人(技术经理)：从之前的关注过程和目标，逐渐转移到关注团队整体，减少了执行层面的比重，管理思维要开始逐步打开，体现在 关注 流程机制、团队执行力、团队整体目标管理、对上管理 等等。

3、第三阶段：团队规模大于20人小于30人（高级经理），对于大型项目的把控能力、工程管理、架构管理、团队管理、流程管理、组织梯度建设上 都有了自己成形的理论和实践经验。主要是团队管理上逐渐系统化：从招人、新人 Onboarding、人才培养、绩效考核、晋升考核、人员职业发展规划指导、团队人才梯队建设、团队目标规划管理。

4、第四阶段：团队规模大于30小于50人 （总监级别）：前面三阶段都属于基层管理者，对于一个基层管理者来说，能按时保质交付即可；但是对于第四阶段属于一个中层管理者来说，这还远远不够，你不仅仅要为交付负责，更需要为「业务成功结果」负责，想尽一切办法去达成组织绩效。要以始为终，以产品和业务视角去做项目管理，要以业务成功为导向。另外管理的第四阶段，需要对于 “组织架构、协同效率、团队活力、技术框架重构、业务导向” 有自己一些新的理解，同时对于CTO的战略规划落地，使命感驱动、价值感自我驱动的按照最佳方案去推动落地执行。

5、第五阶段：团队规模大于 50 小于100人（ 高级总监级别）： 除了具备上述阶段的能力之外，此外要求技术比较全栈，不局限于某个专业领域，可以负责多个领域的跨端协同项目，可以使命感驱动 配合CTO落地公司战略项目。

6、第六阶段：团队规模大于100人，统筹全盘，全面负责产品和研发中心（ 技术VP/CTO 级别），具备的十个能力如下：

    •    1、整体技术专业，横跨多个技术领域，不局限于 前端、中台、大数据 、运维、架构框架。


    •    2、业务Sense很强，懂产品和业务。


    •    3、整体战略规划能力很强。


    •    4、整体架构设计能力很强。


    •    5、技术前瞻性（技术创新，技术驱动业务的发展）。


    •    6、大团队整体管理能力很强：组织建设、梯队建设、人才培养。


    •    7、创新学习能力很强，可以创新开扩多个新的业务领域，项目从0到1或者1到10。


    •    8、有强的人格魄力和领导力。


    •    9、强的跨团队沟通协调组织能力。


    •    10、有比较大的格局和高度。