码农晋升为技术管理者后痛并快乐着的纠结内心
有一个非常有趣的现象:据说大部分的技术管理者,在其从程序员转为管理岗位的时候,都是在领导或公司的要求下,被动的推到管理岗位上的,并非是自己当初有强烈意愿、主动去选择管理岗的。这种被动的比例还不低,高达80%以上。
这个现象从我自己身边的同事中也可以感受到,最近两年我接触到的四五位新晋的技术管理者,全是因为技术/项目做得好,被上级提拔到管理岗的,几乎没有人是因为具备了管理技能后主动去选择的。其实包括曾经的我自己也是这样走过来的。
这里,我们不讨论这种普遍现象是否合理,我们先来看看这种晋升方式会带来什么样的结果。
既然有这么多人是「被动」的成为技术管理者的,那可以想象,在这些人刚步入管理岗位的时候,对管理知识的了解会是多么的薄弱,对即将要开展的管理工作会多么的心虚和纠结。甚至有些人,因为刚开始进行管理工作的不顺利,导致对自己能力的质疑,对技术管理岗位的排斥。
所以这也说明了很多程序员刚晋升为管理后,内心其实是痛并快乐着的。针对这个现象,那应该怎么办呢?
这里,我就以「过来人」的工作经验,结合近期读到的「刘建国老师」的一些的管理理念,计划从一名新晋的技术管理者角度出发,来聊一聊我们应该怎么走好初入管理岗的这段路,希望能给管理新人们一些启发。
一、我适不适合去做一名技术管理者呢?
很多初入管理岗的同学,可能会有这样一些内心的纠结:
「我没有做过管理,不知道自己能不能做得好?有点胆怯」
「是公司领导安排我做技术管理的,我也不知道自己适不适合?更不知道对自己职业是好还是坏?有点焦虑」
「晋升管理岗会给我带来工资福利和职位的提高,这是我很想要的。但我不知道管理这条路自己是否真的喜欢?有点迷茫」
……
其实对于一名新晋管理者,或者想要步入管理岗的同学来说,有这些纠结和不安也是正常现象。要解决这些问题,首先你得问问自己的内心:
你为什么要去做一名技术管理者,你对管理工作所需的 投入要求/意愿 以及 带来的回报 都清楚了吗?
- 对管理工作的投入要求/意愿:
- 认可管理工作的价值
我们都知道,在日常的管理中会有很多的「繁琐的」「协调性」「打杂的」的工作需要做。例如:协调资源、跟进项目、管理进度、员工面谈、绩效考评、开会沟通、邮件汇报、研发流程、关注项目和人员问题等等。这些工作在有的人看来就是打杂,觉得很没有价值,没有写牛逼的代码来得高大上。而在有的人眼中却非常认可这些工作,觉得能给自己带来多方位的素质提升。
那么,在你眼中,你是怎么看待这些工作的呢?
- 对管理工作发自内心的兴趣
很多管理工作并非一定要你到达管理岗位后才能做的。在你还是一名普通程序员的时候,在你还是团队技术骨干的时候,如果你真的对技术管理有兴趣,那么这些「管理」工作已经在你的日常工作中无形的开始了。例如:关注项目整体进度、了解项目目标、推进项目流程、关心身边的同事成长、优化研发与协作方式等等。
那么,你是否发自内心的对这些无形中的「管理」工作感兴趣呢?
- 愿意去提升管理能力
一旦从纯粹的技术岗转到管理岗,你可能需要面临很多管理技巧上的挑战,甚至还有很多在思维和认知上的颠覆。例如:首先,管理工作已经不再像敲代码一样非0即1了,管理工作中有很多中间态,不确定的因素,这些往往是对程序员之前习惯性思维的一个很大的冲击。其次,之前敲代码是与计算机打交道,转为管理之后,会花更多的时间与人打交道,与上司、与平级、与下属、与跨部门协作等等。另外,管理者会承担更多更大的责任,需带领团队穿山越岭实现公司的最终目标,这些压力也是作为程序员时候所没有的。
你愿意为此方向重构自己,提升自己的管理思维和能力吗?你做好这个准备好吗?
- 管理工作带来的回报:
- 你拥有了一个团队
步入管理岗之后,你就不是一个人在战斗,你拥有了一个团队,基于团队,你可以做出更大的成就。以前你的成绩可能就是技术做的好,代码写的好,而转入管理开始带团队之后,你可以和团队一起搞定更复杂的任务,做出更大的成绩。
- 能力、视野、影响力 都会得到显著提升
除了技术能力,你还获得了管理能力、领导力,你看待问题的视角不再是程序员思维了,会有更高的视野。由于团队间的协作,你还能获得更大的个人影响力。
- 物质的回报
这是非常现实的,看得见摸得着的回报。
好了,上面已经将一名技术管理者所需的要求和回报都简单捋了捋。作为程序员的你,可以对照一下,然后问问内心的自己是否真的合适。
如果你觉得没有问题,那咱们就继续来看看,一般有那些机会可以帮助我们成长为技术管理者。
二、有哪些机会能使我成为一名技术管理者?
首先,「管理比技术更需要机会」,我们做程序员的,都非常勤奋,挑灯熬夜的干活学习都是平常事,而且技术这东西也确实很公平,你不断的努力去研究去学习,迟早会提高一个层次,无非是不同人不同时间的问题。但是做管理呢,并不是这样。要想成为一名技术管理者,勤奋必不可少,然而其中的机会也很重要。
在职场上,经常有遇到这样的现象:
「你的能力非常不错了,可是团队中没有管理的空缺了」
「你是团队中技术最好的一个,可是管理岗的却安排给了别人」
……
其实可以发现,这里面除了你个人的条件以外,外部的「机会」因素相当重要。
想成为技术管理者,那我们应该抓住那些潜在的机会呢?
-
快速发展的公司最有机会,这类公司经常会建立新的项目新的团队,需要很多技术管理者
-
耐心积攒能力,掌握核心技术的人会更有机会,厚积薄发的道理人人都懂
-
手上负责的项目属于基础性、全局性、跨部门协作工作多的业务相对来说机会会多一些
-
在平时的工作中,经常得到上级认可、甚至上级能支持你转管理,这类人等待的就是以一个契机
-
身边有管理能力较好的导师朋友来解惑帮助的人也会更容易把握机会
最后就是,当你还不是管理岗,但你却已经在团队中做着技术管理者应该做的事情的时候,你最有机会。
在互联网公司中,很多管理岗的晋升不是给予的,更多是对既定事实的追认。
三、技术和管理应该怎么去平衡?
从一名程序员晋级为技术管理者之后,很多人的内心多多少少都存在这样一些顾虑:
「每天管理的工作越来越多,留给自己研究技术的时间却越来越少,时间一长,我会不会慢慢脱离技术了」
「写代码的时间变少了,对很多技术细节也没有以前敏感了,感觉自己离技术老本行越来越远,内心越来越发虚」
「脱离了一线编码,心里空落落的,很担心自己的职业发展」
……
其实有这些顾虑也无妨,这也是大多数新晋技术管理者都会遇到的问题。
但是,我们来想想,为什么这些问题在新管理者面前这么普遍呢?
主要原因还是因为新晋的技术管理者大多都是程序员出身,一直以来都是靠一线的编码技术能力去打江山混名声的。突然之间转为管理了,既担心把「技术」丢了没了退路,又对「管理」应该要做哪些事情、如何把「管理」做好,如何重新依靠「管理」这项能力去打江山混江湖还不熟练,正处于青黄不接的时期,自然而然就会觉得焦虑不安了。
那这些顾虑有解吗?有的。
- 要明白「放弃编码,不代表放弃技术」
转做技术管理之后,我们只是减少了编码的时间,并不是放弃了技术,事实上,作为一名技术人,我们永远永远也不能放弃技术。
但也千万不要把「编码能力」与「技术能力」之间划上等号。技术能力是可以更多的关注应用,但并不一定需要时时关注实现细节。
就像部队打仗一样,作战指挥官需要了解陆军、空军、海军等不同军种的优劣势,需要了解军舰、坦克、导弹等不同作战武器的最佳特性,才能部署出最佳的作战方针,统筹全局打胜仗,但是他并不需要了解军舰具体怎么开、坦克具体怎么驾驶。
另外,当你还是一名程序员的时候,编码可能就是你的全部实现,而当你成为一名技术管理者的时候,技术就应该是你的工具,你应该站在更高的视野去看待技术的价值,技术是为最终的目标而服务。
- 要保持对技术的评估能力
上面提到了「技术能力」并不等于「编码能力」,抛开一些非核心能力的话,可以简单点理解为「技术能力」=「编码能力」+「技术评估能力」。当我们还是程序员的时候编码能力是我们最为注重的,但当我们转技术管理之后,技术评估能力就应该成为我们的重点,编码能力在精力有限的情况下是可以放弃的。
技术评估能力主要是指我们通过自己的技术认知,去评估一个项目/开发任务 要不要做、值不得值得做、做到什么程度,技术方案边界在哪儿、技术选型用什么、可用性/拓展性方案是什么等等,甚至是对团队人员技术水平的边界评估。
怎样才能保持技术评估能力,以及怎样能不断增长自己的技术评估水平呢?作为技术管理者而言,很明显,已经不能通过大量编码的方式去提高技术能力了,只能依赖于:自己以往技术经验的积累、团队的技术分享、技术调研、与同行专家交流、培训学习等方式。这些方式有的时候会比编码的方式更快更有效率。
- 技术管理是多样性的,你总会找到一条你自己的路
我们要明白,技术管理并没有固定的模式,有的技术老大做着做着就往商业方向靠了,比如雷军这类。有的技术老大无论做到多高的级别,带几百上千人的团队,却依旧非常关注技术日常。每个人的技术管理风格不同,但最后都会找到一条自己风格的管理之路。
即使最后你发现自己不喜欢做管理了,想转回做技术架构师或创业,你通过管理获得这些经验能力和视野,对你的其它道路依旧会有莫大的帮助。
- 技术管理能力是每一个程序员都需要的技能
技术管理是一项能力,并不是一个职业。它是每一个技术同学在成长过程中,都应该去学习和具备的能力。无论你以后是走管理道路,还是做职业经理人、技术专家、架构师、创业,你都需要具备技术管理者应具备的团队管理能力、技术视野、技术规划能力、项目管理能力、沟通协调能力。
因此,你还需要有顾虑吗?反正无论如何你都得会一点嘛。
以上,就是对新晋的技术管理者如何解决初入管理岗时纠结心路的学习与分享,希望能给新步入管理岗的同学们一�
- 原文作者:知识铺
- 原文链接:https://geek.zshipu.com/post/%E4%BA%92%E8%81%94%E7%BD%91/%E7%A0%81%E5%86%9C%E6%99%8B%E5%8D%87%E4%B8%BA%E6%8A%80%E6%9C%AF%E7%AE%A1%E7%90%86%E8%80%85%E5%90%8E%E7%97%9B%E5%B9%B6%E5%BF%AB%E4%B9%90%E7%9D%80%E7%9A%84%E7%BA%A0%E7%BB%93%E5%86%85%E5%BF%83/
- 版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可,非商业转载请注明出处(作者,原文链接),商业转载请联系作者获得授权。
- 免责声明:本页面内容均来源于站内编辑发布,部分信息来源互联网,并不意味着本站赞同其观点或者证实其内容的真实性,如涉及版权等问题,请立即联系客服进行更改或删除,保证您的合法权益。转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。也可以邮件至 sblig@126.com