写点什么

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

  • 2020 年 6 月 24 日
  • 本文字数:5259 字

    阅读完需:约 17 分钟

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

作者介绍:我是一名程序员,985 硕士,前亚马逊 Java 工程师,参与过创业,目前是一家 B 轮电商公司的技术总监。在这里会持续分享我个人的成长之路,写一些关于技术和管理方向的总结。


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


这句话用来形容 2019 年互联网行业最适合不过了。从 18 年开始,大大小小的互联网公司开始了不止一轮的裁员,19 年网上开始充斥一类文章,专门写互联网公司超过 35 岁的人,如果到这个年龄,还不是 leader,业务又不核心,那么请焦虑吧。


昨天听罗胖的跨年演讲,主题是:基本盘。意思是不要受到人云亦云的情绪影响,而是转过头,看手中的资源,基于基本盘看清自己的努力方向,非常感慨和受启发。中国互联网经过过去十多年野蛮式的发展似乎这 2 年开始慢下来了,程序员 35 岁的退休年龄虽然只是贩卖焦虑的一种说法,但是整个行业对人的要求越来越高是不争的事实,要求我们的成长速度必须跟上。2020 年开始,希望自己在技术、管理、业务 3 个维度再做更深层次的学习,体系化个人的认知,做一个有特点的 IT 人。


下面要写的主题是关于『工程师如何从技术转型做管理』,这是我在团队管理上第一篇系统性的总结。之所以选择这个主题,一方面,个人觉得转型做管理是当前环境下大部分程序员会选择的职业路径,另一方面,自己亲身经历了比较漫长的转型过程,应该能写出点心得体会。希望下面的内容对于『正在转型挣扎期』或者『后续有规划往管理转型』的同学,让你们有所启发,内容大概分成以下 4 个部分:


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

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

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

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


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


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


技术方面:常用技术的深度和宽度缺一不可,架构能力非常关键。否则技术方向都把握不好,技术决策也容易出问题。如果技术能力没达到一定水平,不建议太早转管理(个人感觉能力至少要接近阿里的 P7,腾讯的 T3-1,百度的 T6)。


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


软性素质达标:软性素质这个词有些泛,我个人觉得最核心的两点,沟通协调能力和做事靠不靠谱。软性都是可以锻炼的,但是一定要有意识去提升。著名管理学家陈春花老师说,“一个人被组织提拔,其实不是因为能力,而是因为信任”,聪明的人很多,但是靠谱的人很少,比能力更重要的是工作的投入感和靠谱的态度。


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


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

之前有人问过我一个问题,“你觉得我适合做管理吗?能给我些建议吗?”,我当时没有正面回答他,而是反过来问他,“你能先告诉我,做管理对你意味着什么?它能给你带来什么呢?”。当然我不是在质疑他,而是想让他反思他做管理的初衷。我觉得『最原始的动机』会决定你在管理路上能扛多大的压力以及能走多远。关于初衷,我见过最普遍的说法有这么几种:


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

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

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

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

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


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


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


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

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

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


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


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


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


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

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


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

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

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

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

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


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


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

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


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

  • 注重执行细节

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

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

  • 做好时间管理


学会从团队角度考虑问题

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



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


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


注重执行细节

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


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


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


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

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


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


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

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


每天和不同的人打交道,这个是管理者的日常工作,因为你需要调动所有可能的资源去解决团队的困难。面对不同职位、不同 level、不同性格的人,你要反复琢磨采取何种沟通方式和沟通技巧。上一节提到一种情况:一件你认为很简单的事情,推动起来却很困难。可能是因为你对外的沟通方式太生硬,别人不想配合你,或者别人确实有其他更重要的事情,但是如果私下关系建立好,你再当面软磨硬泡,多半也是可以解决的。人际关系上,难免会有碰壁的时候,不要气馁,这跟技术同学写出 1 个 bug 一样,是家常便饭的事情,但是一定要注意积累经验。线下和关键的配合方维护好私人关系,多吃饭喝酒,别人有困难能及时伸出援手等等,套路有很多。


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


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


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

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

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


做好时间管理

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


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


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


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


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

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

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


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


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


2020 年 6 月 24 日 19:11415

评论 1 条评论

发布
用户头像
2020 年 11 月 10 日 14:28
回复
没有更多了
发现更多内容

HTML笔记 —— 标签和超链接,java面试数据库隔离级别实战

Java 程序员 后端

Java transient关键字的使用,java商城项目面试

Java 程序员 后端

Android开发:button的text文本是字母默认显示大写的解决步骤

三掌柜

11月日更

Java 多线程 —— 定时器,svnlinux使用教程

Java 程序员 后端

Java 方法的使用(方法重载、形参和实参调用关系,java高级面试最新

Java 程序员 后端

InnoDB(4(1),java技术架构知识

Java 程序员 后端

Jaeger知识点补充,java菜鸟教程面向对象

Java 程序员 后端

如何编写 Go 包

baiyutang

golang 11月日更

Java this关键字详解(3种用法),Java程序员最新职业规划

Java 程序员 后端

HDU-3038-How Many Answers Are Wrong【 带权并查集 】题解

Java 程序员 后端

jackson学习之八:常用方法注解,复习指南

Java 程序员 后端

Java 反射:框架设计的灵魂,springboot运行原理

Java 程序员 后端

Java 世界里的垃圾回收规则你搞懂了吗?,springboot输出视频流

Java 程序员 后端

Java 低代码开发平台“光”发布 2,javapdf模板下载百度云

Java 程序员 后端

学生管理系统-详细架构设计文档

joukosusi

架构

Prometheus HTTP API 查询(三)查询元数据

耳东@Erdong

Prometheus PromQL HTTP API 11月日更

一行代码爬取微博热搜数据

老表

爬虫 python学习 11月日更

James邮件服务器,高级java工程师简历模板

Java 程序员 后端

HashMap + 软引用进行缓存,java程序设计案例教程第二版答案

Java 程序员 后端

IDEA这样配置,好用到爆炸!,Java开发必须要会

Java 程序员 后端

InnoDB(3,韩顺平java从入门到精通课件

Java 程序员 后端

JAVA 微信小程序 解密 用户信息encryptedData,linux系统架构与目录解析

Java 程序员 后端

如何做架构设计

天天向上

架构实战营

Hello Git快速入门,三年经验Java开发面经总结

Java 程序员 后端

IDEA的Docker插件实战(Docker Image篇),rabbitmqpdf百度云

Java 程序员 后端

InnoDB(4,java中级工程师面试题

Java 程序员 后端

IDEA类和方法注释模板设置(超详细教程),java程序执行过程与编译原理

Java 程序员 后端

Android C++系列:JNI调用 Java 类的构造方法和父类的方法.md

轻口味

c++ android jni 11月日更

jackson学习之八:常用方法注解(1),java虚拟机实现原理

Java 程序员 后端

java 数据结构与算法之稀疏矩阵算法,BTAJ面试有关散列(哈希)表的面试题详解

Java 程序员 后端

JAVA 获取系统日期时间,java基础百度云

Java 程序员 后端

基于英特尔x86平台构建AI软件生态系统

基于英特尔x86平台构建AI软件生态系统

我,程序员,32岁,距离退休,只剩3年了!-InfoQ