写点什么

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

2020 年 4 月 23 日

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 年 4 月 23 日 11:521855

评论 1 条评论

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

阿里最“短命”的P10?入职不到3周,钉钉副总裁张志琦因个人原因离职

程序员生活志

阿里巴巴 互联网热点

架构师训练营第8周作业

邵帅

为什么你总觉得自己是对的?

池建强

个人成长

week9作业1

第9周总结+作业

林毋梦

尚未到来的远程工作

ThoughtWorks洞见

敏捷 敏捷开发 软件开发 远程办公 thoughtworks

总结

Kiroro

不仅性能秒杀Hadoop,现在连分布式集群功能也开源了

爱倒腾的程序员

大数据 涛思数据 tdengine 物联网 时序数据库

训练一个数据不够多的数据集是什么体验?

华为云开发者社区

数据 数据集 华为云 标签 modelarts

数据库实践丨MySQL多表join分析

华为云开发者社区

MySQL 数据库 华为云 join 多表join

【得物技术】流量之战—性能优化三十六计

得物技术

Java 流量 得物技术部 商品 电商平台

架构师训练营第8周总结

邵帅

并发-草稿

superman

SpreadJS 纯前端表格控件应用案例:SPDQD 质量数据云

Geek_Willie

SpreadJS 案例

作业一

Kiroro

高教授:区块链软硬件相结合能提升系统性能 也能保持一定的灵活性

CECBC区块链专委会

分布式 行业资讯 区块链技术 落地应用

加快速度推进区块链融合发展

CECBC区块链专委会

区块链 行业资讯 产业落地

HomeWork

天之彼方

计算机网络基础(十四)---传输层-UDP协议详解

书旅

计算机网络 网络 协议栈 通信协议

NOSQL or NEWSQL

大唐小生

sql nosql

技术贴丨教你使用华为云鲲鹏服务器部署Discuz!论坛

华为云开发者社区

鲲鹏920 服务器 华为云 Discuz! 华为云鲲鹏

Docker-compose实战

北漂码农有话说

《RabbitMQ》如何保证消息的可靠性

Java旅途

我还在生产玩 JDK7,JDK 15 却要来了!|新特性尝鲜

楼下小黑哥

Java jdk

面经手册 · 第2篇《数据结构,HashCode为什么使用31作为乘数?》

小傅哥

Java 数据结构 小傅哥 面试官

JVM系列之:从汇编角度分析Volatile

程序那些事

Java JVM JIT 汇编

Ubuntu启动盘无法格式化

kraken0

树莓派上安装docker记录

田振宇

一周信创舆情观察(7.27~8.2)

统小信uos

地方政府争夺数字货币试点,互联网巨头参与测试,央行数字货币即将来临

CECBC区块链专委会

行业资讯 央行数字货币

白鹭引擎助力《梦幻西游网页版》刷新h5游戏新高度

DT极客

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