关于java:工程师如何从技术转型做管理

“我，程序员，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 人），要么本身的治理存在问题或者工夫治理存在问题，须要关注并思考做出调整。

下面这些内容，就是对于工程师转型治理的集体心得。