写点什么

32 岁程序员距离退休只剩 3 年?

  • 2020-04-23
  • 本文字数:5523 字

    阅读完需:约 18 分钟

32 岁程序员距离退休只剩 3 年?

“我,32 岁程序员,距离退休只剩 3 年!”


这句话用来形容 2019 年互联网行业最适合不过了。


从 2018 年开始,大大小小的互联网公司开始了不止一轮的裁员,2019 年网上开始充斥一类文章,专门写互联网公司超过 35 岁的人,如果到这个年龄,还不是 Leader,业务又不核心,那么请焦虑吧。


听了罗胖的跨年演讲,主题是:基本盘。意思是不要受到人云亦云的情绪影响,而是转过头,看手中的资源,基于基本盘看清自己的努力方向,非常感慨和受启发。


中国互联网经过过去十多年野蛮式的发展似乎这两年开始慢下来了,程序员 35 岁的退休年龄虽然只是贩卖焦虑的一种说法,但是整个行业对人的要求越来越高是不争的事实,要求我们的成长速度必须跟上。


2020 年,希望自己在技术、管理、业务这三个维度再做更深层次的学习,体系化个人的认知,做一个有特点的 IT 人。


下文的主题是关于「工程师如何从技术转型做管理」,这是我在团队管理上第一篇系统性的总结。


之所以选择这个主题:


  • 一方面,个人觉得转型做管理是当前环境下大部分程序员会选择的职业路径;

  • 另一方面,自己亲身经历了比较漫长的转型过程,应该能写出点心得体会。


希望下面的内容对于「正在转型挣扎期」或者「后续有规划往管理转型」的同学,让你们有所启发。


内容大概分成以下四个部分:


  • 什么样的工程师会被提拔做管理?

  • 你选择做管理的初衷是什么?

  • 转型期你会遇到哪些困惑或者挑战?

  • 转型期应该具备哪些心智?

什么样的工程师会被提拔做管理?

一般来说,满足这三个条件的工程师会被提拔做管理:技术能力强、业务熟练、软性素质达标。(当然还要看公司是否有管理岗位的空缺以及你个人的意愿),下面分别展开说下重点。

技术方面

常用技术的深度和宽度缺一不可,架构能力非常关键。否则技术方向都把握不好,技术决策也容易出问题。


如果技术能力没达到一定水平,不建议太早转管理(个人感觉能力至少要接近阿里的 P7,腾讯的 T3-1,百度的 T6)。



业务方面不了解业务,技术没法落地,不仅要求熟悉业务而且应该具备比较强的业务意识,(如果能从技术维度提出好想法,帮助业务拿到更好的结果,这种 Leader 是非常受欢迎的)。


软性素质达标软性素质这个词有些泛,我个人觉得最核心的两点,沟通协调能力和做事靠不靠谱。软性都是可以锻炼的,但是一定要有意识去提升。


著名管理学家陈春花老师说,“一个人被组织提拔,其实不是因为能力,而是因为信任”,聪明的人很多,但是靠谱的人很少,比能力更重要的是工作的投入感和靠谱的态度。


如果你觉得上述三个方面都达到要求了,我觉得只是差一个机会,否则好好提升自己吧。

你选择做管理的初衷是什么?

之前有人问过我一个问题,“你觉得我适合做管理吗?能给我些建议吗?”,我当时没有正面回答他,而是反过来问他,“你能先告诉我,做管理对你意味着什么?它能给你带来什么呢?”。


当然我不是在质疑他,而是想让他反思他做管理的初衷。我觉得『最原始的动机』会决定你在管理路上能扛多大的压力以及能走多远。


关于初衷,我见过最普遍的说法有这么几种:


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

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

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

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

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


上面这几类都属于「外部因素」驱动,说实话,都很难在管理路上走得很远。


因为[技术管理](https://s.geekbang.org/search/c=0/k=技术管理/t=


0 是极其复杂和琐碎的工作,它远没有你想象中的轻松和风光,而在这些外力下,你做出决策后的结果很多时候跟你的预期是不一致的,这个时候你的怨气和转型痛苦就会出现,你开始质疑你选择的这条路是不是错了?


再来看另外一个问题,作为技术管理者,对于公司、团队以及你个人,你觉得它的价值分别是什么?


我个人的解读是这样的:


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

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

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


这是对于技术管理岗位的基本认知,你的初衷必须建立在这个认知基础之上。然后试问你自己:是否认可这个岗位的价值?


如果你觉得全是牺牲自己来成就公司和团队,那你不可能做得开心,也不可能做好。


第二个问题,你是否对管理者的工作充满热情?并且享受这个过程呢?比如项目协调,比如制定流程并推动落地执行,比如招聘。


如果你说我只喜欢做技术相关的工作(比如架构设计、技术评审等),那么你还是走技术路线吧。


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


转型期你会遇到哪些困惑或者挑战?

转型期会经历心态、工作方式的转变,很多事情会刷新你的认知。


下面几点,我认为是绝大部分人在转型过程中会遇到的困惑或者挑战:


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

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

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

  • 成就感不强:偶尔会收到上级、平级、甚至下级的负面反馈,你开始质疑自己的管理能力,不像做工程师那样经常被认可,落差感强;


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


上述疑惑是我个人转型过程中体会最深的几点,我在后文中会分别给出自己的看法和建议。

转型期应该具备哪些心智?

从技术转型做管理,更多的不是能力的变化,而是思维方式和行为的改变。


很多刚转型的 Leader 管理做不好,绝大部分不是因为能力不行,而是出现在了认知上。


以下几点,我认为是转型期 Leader 一定要具备的心智:


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

  • 注重执行细节;

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

  • 重视情商,做好自我情绪控制;

  • 做好时间管理。

学会从团队角度考虑问题

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



上面四项对比,是我个人认为比较典型的 Case,比如上一节提到的一种情况:Leader 觉得某个问题很简单,嫌员工处理效率低,然后自己跳出来三下五除二给解决了,这种就属于很典型的员工思维。


单从搞定这件事情来看,这也许是很好的处理方式,业务方也会很满意,但是带团队是长远的事情,上述做法紧急情况可行,但是变成常态就是非常大的问题。


团队能力不提高,Leader 永远不会解放,这是作为 Leader 应该具备的意识。


如果通过这个问题能够提升组员某方面的能力,Leader 应该扮演好教练的角色,放手让组员自己去做,你要做的仅仅是观察、给一些指点、适当给予时间上的支持。


这次处理也许效率不高,但是下次碰到类似的问题,团队是不需要依靠你来解决的,另外组员也有自己的发挥空间,觉得团队在帮助他成长。

注重执行细节

对于刚转型做管理的一线 Leader,切忌被放权式的管理方式洗脑。


放权式管理对于对管理者的经验要求很高,它比较适用于工作流程清晰,团队骨干目标认知以及自驱力很强的团队。


当你个人的管理水平还处于菜鸟期时,一定要从细节抓起,通过手把手带员工,教会他们如何正确的做事,怎么才能达到你的要求,以及如何培养出团队骨干,搭建出团队的核心组织架构。


所有这些都经历过了,你在管理上才会有自己的心得体会,才会走得更扎实。


通过观察执行细节,你能非常清楚团队每个人的优劣势,深入感受自己的管理方式是否存在问题,然后再辅以 Leader 思维去思考和解决问题,管理上才能真正获得成长。


这个过程,你可能会收到上级、平级、下级的很多反馈,清楚细节后其实你就有了自己的判断,知道是否是自身的问题,是否要调整,而不是沮丧抓瞎。

学会用人所长,具备包容心

知人善任、人尽其才,是每个管理者都懂的道理,但是能做到的不多。


尤其在技术管理岗上,我见过有些 Leader 在技术上非常强势,技术权威不容有任何挑战,当组员提出更合理的技术方案时,他会用职级强制要求按自己说的执行,根本不做任何解释。


对于新晋 Leader,团队对你的信任感还在磨合期,上述做法很容易打击组员的积极性,消灭他们的创造力,这对你带团队来说是非常致命的。


如果组员的方案更合理,Leader 应该倍感欣慰,包容并鼓励这种行为,因为组员某方面的专业能力超过你了,你不再是团队各方面最强的人,你需要做的是调整自己的心智,学会用人所长。


另外,还有一种情况是:组员和 Leader 的技术方案都可行,我个人倾向将选择权交给组员,毕竟他们是真正的执行者,应该给他们自由发挥的空间,最后就算出问题对他们来说也是很好的经验积累。

重视情商,做好自我情绪控制

管理上能做多大事情,真的和情商有非常大的关系。IT 界的技术人员由于工作性质的原因,普遍注重技术上的提升,而忽略情商的培养和维护,作为新晋 Leader 必须从一开始就意识到情商的重要性。


管理是一个复合型的岗位,当你的专业技能和处理问题的方法论已经形成后,越往上发展,为人处事的软技能占比会越来越重。


每天和不同的人打交道,这个是管理者的日常工作,因为你需要调动所有可能的资源去解决团队的困难。


面对不同职位、不同 Level、不同性格的人,你要反复琢磨采取何种沟通方式和沟通技巧。


上一节提到一种情况:一件你认为很简单的事情,推动起来却很困难。


可能是因为你对外的沟通方式太生硬,别人不想配合你,或者别人确实有其他更重要的事情,但是如果私下关系建立好,你再当面软磨硬泡,多半也是可以解决的。


人际关系上,难免会有碰壁的时候,不要气馁,这跟技术同学写出 1 个 Bug 一样,是家常便饭的事情,但是一定要注意积累经验。


线下和关键的配合方维护好私人关系,多吃饭喝酒,别人有困难能及时伸出援手等等,套路有很多。


情绪控制,是一个比较难的事情。情绪很容易传递,如果 Leader 碰到不爽的事情,把组员当做出气筒,这是非常伤士气的,之前建立的信任感很容易消失,受不了的组员也可能就离职了。


另外,对外沟通上,如果 Leader 控制不好情绪,不将重点放在解决问题上,只是抱怨或者发火,也非常容易引起配合方的不满,认为你不专业,久而久之,你的团队也会被打上这种标签。


个人在情商方面目前做得也很差,踩过很多坑。提供三点建议:


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

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

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

做好时间管理

时间管理的 4 象限理论可以百度一下。重点说下我个人遇到时间管理问题是怎么解决的,以及技术和管理两个维度如何分配时间。


第一步,可以拿过去一周或者一个月的时间跨度为例,详细列一下你的时间花在哪些具体事情上了,以及每类事情大概的时间占比。


对于技术 Leader 可能的事情包括:需求评审,资源规划和项目排期,技术评审,团队周例会,研发规范制定和落地,项目管理,技术调研,架构设计,Coding,紧急任务协调和处理,业务以及新技术充电等等。


第二步,针对第一步列举的每类事情,考虑下哪些是非必须的,哪些是可以授权给团队骨干去做的,哪些是可以优化提高效率的。


比如一些简单的需求评审或者技术方案评审让骨干把关即可,项目管理制定好流程规范同时培养一些 Scrum Master 或者项目经理下放给他们来做。


不用凡事都事必躬亲,Leader 应该把时间聚焦在对团队最关键的事情上,学会授权和放权。


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


  • 大部分时间 Leader 是不需要亲自写代码的,但是如果有需要,Leader 要能够随时顶上,所以不能长期远离一线,纸上谈兵。长此以往,技术判断可能容易出现失误,而且如果管理不合适再转型回去代价太高。

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

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


上面这些内容,就是关于工程师转型管理的个人心得。关于管理,后续我会将更多实用的技巧以及方法论结合具体 Case 进行总结和分享!


2020 年,又一个十年的开端,认清基本盘,不忘初心,再接再厉!

作者简介

骆俊武,一名程序员,985 硕士,前亚马逊 Java 工程师,参与过创业,目前是一家 B 轮电商公司的技术总监。在这里会持续分享我个人的成长之路,写一些关于技术和管理方向的总结,希望对你有所启发。




TGO鲲鹏会,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。


会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。


2020-04-23 11:523001

评论 1 条评论

发布
用户头像
开玩笑,老衲早就退休5年了
2020-04-24 09:54
回复
没有更多了
发现更多内容

极客时间架构 1 期:第4周 系统架构 - 命题作业

Null

「架构师训练营」第四周课后练习

L

第四周

等燕归

设计模式

Zzzz

极客大学架构师训练营

「架构师训练营」第四周课后练习

L

第10周作业

Vincent

极客时间 极客大学

【架构师训练营】第四周作业:系统架构

MindController

系统架构

架构师训练营 - 第四周 - 作业二

行者

手把手教你AspNetCore WebApi:认证与授权

AI代笔

Token ASP.NET Core JWT web api

手把手教你如何在Oasis Second State 社区黑客马拉松获得 50 ROSE

WasmEdge

区块链 智能合约 以太坊 hackathon

极客时间架构 1 期:第 4 周 系统架构 - 学习总结

Null

设计一套RPC框架并非易事

架构师修行之路

分布式 微服务 RPC

架构师训练营第1期第4周作业

业哥

极客大学架构师训练营

【架构笔记之系统架构】架构师训练营第1期第4周

业哥

极客大学架构师训练营

架构师训练营 - 第四周 - 作业一

行者

架构师训练营1期第4周作业

木头发芽

第10周学习总结

Vincent

极客时间 极客大学

第四周作业 (作业二)

Geek_83908e

极客大学架构师训练营

架构师训练营 - 命题作业 - 第四周

徐时良

[架构师训练营第 1 期] 第四周学习总结

猫切切切切切

极客大学架构师训练营

第四周作业

wanlinwang

极客大学架构师训练营

浅析 synchronized

朱华

Java 并发编程 synchronized

第三周作业

m

第四周作业 (作业一)

Geek_83908e

极客大学架构师训练营

架构师训练营 - 学习笔记 - 第四周

徐时良

第四周学习总结

alpha

极客大学架构师训练营

架构师 1 期 - 系统架构作业

ltl3884

极客大学架构师训练营

第四周后端常用技术总结

solike

[架构师训练营第 1 期] 第四周命题作业

猫切切切切切

极客大学架构师训练营

极客大学 - 架构师训练营 第四周

9527

高并发系统设计负载均衡架构

架构师修行之路

负载均衡 分布式 微服务

32 岁程序员距离退休只剩 3 年?_技术管理_骆俊武_InfoQ精选文章