QCon上海站购票倒计时最后3天!查看精彩日程 了解详情
写点什么

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:522206

评论 1 条评论

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

前端 JavaScript 获取字符串中重复次数最多的字符

编程三昧

JavaScript 前端 数组 指针思想

高性能计算在人工智能(AI)智药中的应用

北鲲云

快手严厉整治违规商业内容:必须构建平台良性生态链

石头IT视角

七种方式教你在SpringBoot初始化时搞点事情

L

Java

Scrum | 你需要知道这些

Python测试和开发

项目管理 Scrum 敏捷

JavaScript学习(九)

空城机

JavaScript 前端 6月日更

TcaplusDB亮相全球云计算大会 一举斩获优秀解决方案奖

TcaplusDB

数据库 nosql tencentdb TcaolusDB

带老弟做项目,凉了

程序员鱼皮

Java c++ Python JavaScript 技术

Kubernetes手记(22)- K8S包管理器

雪雷

6月日更

[TcaplusDB知识库]TcaplusDB高可用部署

TcaplusDB

nosql tencentdb TcaplusDB Tcaplus

JSON 数据格式该怎么使用

网络安全学海

json 网络安全 安全 信息漏洞 渗透测试

国际禁毒日 | 和TcaplusDB一起向毒品say NO!

TcaplusDB

nosql tencentdb TcaplusDB database

敏捷项目管理是不是可以缩短项目周期,或者说“敏捷就是快”?

万事ONES

项目管理 敏捷开发 ONES 项目管理工具

极光开发者周刊【No.0625】

极光开发者

5分钟速读之Rust权威指南(三十)多线程

码生笔谈

rust

矩阵分解推荐算法(十八)

数据与智能

推荐算法 矩阵运算

zookeeper客户端zkclient和curator的api

赵镇

zookeeper

“动态规划”这词太吓人,其实可以叫“状态缓存”

华为云开发者社区

Java 动态规划 超时 dp数组 状态缓存

Vue源码学习 | 从源码中学习Javascript技巧

devpoint

JavaScript Vue 6月日更

【熬夜整理近百份大厂面经】2022校招提前批面经总结分享(腾讯、字节、阿里、百度、京东等招聘信息+必考点+简历书写)

学无止境的阿奔

c++ 程序员 面试 后端开发 秋招

mysql的存储引擎知多少

卢卡多多

KV存储引擎 MySQL 数据库 6月日更

[译] R8 优化: Switch 场景下的枚举

Antway

6月日更

极光统一消息系统UMS新版上线!多维数据统计分析助推运营增长

极光开发者

Linux之touch命令

入门小站

Linux

Django搭建个人博客网站---模块划分

IT蜗壳-Tango

6月日更

在线html链接提取工具

入门小站

工具

带你认识Flink容错机制的两大方面:作业执行和守护进程

华为云开发者社区

flink 守护进程 容错 作业执行 Flink 容错机制

华为云官网前端的技术演进与低代码实践

华为云开发者社区

前端 低代码 可视化 页面 华为云官网

敏捷项目管理实践,如何正确使用故事点预估工作量?

万事ONES

项目管理 敏捷开发 ONES

阿里内部不外传的50万字Java面试手册,首次开放,一天遭狂转10w次

Java架构师迁哥

AI云市场的繁盛之夏:AI花开果熟,百度抢先品尝第一口甜

脑极体

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