技术人如何应对晋升

1,386 阅读21分钟

学习极客时间李运华老师《大厂晋升指南》有感

前言

其实犹豫了好久,应不应该写这篇总结,或者说分享。我个人21年度的两次晋升都以失败告终,失败让我重新回顾我任职期内的工作以及对整个答辩面评过程的准备和表现,并试图从中找到问题。从结果角度来说,我在今年的的晋升之路上是个实打实的loser。一个loser来分享如何成功的经验,其实有点诙谐。但不管怎样,我依然想把自己这些年的一些职场晋升感受以及这段时间学习的一些认知分享出来,希望对大家有帮助。

正如电影《中国合伙人》中孟晓骏对成东青说的一句话:没有人比你这样一个loser校长去讲梦想更有说服力。

重新理解晋升

晋升困惑

工作中我们经常碰到一些晋升方面的困惑或者说短暂的瓶颈,比如:

  • 和自己差不多的,甚至不如自己的同事都晋升了,而自己还在原地踏步。不知道怎么做才能晋升。
  • 自己得到了领导和同事的认可,信心满满的去参加晋升答辩,却感觉自己的表现不尽如人意,总感觉自己的能力没有表现出来,面对评委提问也容易答非所问。
  • 晋升答辩自我感觉良好,但评委还是判定没有达到下一级别要求,很迷茫,不知如何做才能打动评委。
  • 低级别的时候晋升很快,一路绿灯,到达高级别时屡屡受挫,直至怀疑一切,无奈换环境。 遇到这些问题,心中自然委屈,但同时,我们需要更加系统的了解自己公司的职级要求,来先自我判断是否达到了要求。很遗憾的是,一般公司在职级要求上的描述都以“熟练”、“系统性”“深入”、“前瞻性”、“领先”等等比较模糊的描述,一个职级要求什么能力,要求到什么程度,每个人的理解都不一样。而我们要做的就是:和你的主管/直接领导的理解要一致。否则可能连晋升的机会都没有。

晋升的不确定因素

公司的晋升机会基本是和绩效结果对应的,能够参加晋升的,都是绩效结果比较好的。得到团队和领导的认可,拿到了比较好的绩效结果,去参加晋升,明明自己已经做的很好了,为什么还有不确定性呢?

  • 公司通过率指标的不确定性 大部分公司的都有一个晋升通过比率,而且这个比例往往不是固定,随着公司发展的情况,会发生变化。这个比例又会被分配到各个部门或者更低一级的团队中。如果你的团队在这次参与的晋升的都比你更有优势,那情况就不乐观,反之亦然。
  • 评委团的不确定性 往往你晋升答辩的评委都有来自于其他的团队的leader或者同事,这些评委中可能会有你平时工作中产生过交集的,也可能有与你没有交集,不了解的。了解你的,认可你工作成果的那就有一定的优势,不了解你的不能说有劣势,但至少你只能通过那几十分钟的时间来打动他。一般来说评委都会客观的在答辩过程中寻找你的亮点和工作成绩。但是对你本已有好印象的人来坐镇你的评委,优势是确实存在的。

我们不能控制这个两个不确定因素,只能尽力提升自己的能力,争取避免成为被调控的对象。如果晋升不通过,也不要过于悲观,从另一方面来说,自己的能力还不是毫无争议的,退一步讲,只要持续的提升,多参加几次晋升,总会运气好的。晋升确实会受运气影响,提升自己才是关键

晋升逻辑

什么样的人更容易获得晋升机会,或者更容易通过晋升?这里总结了三条核心原则,当你准备晋升或者晋升遇到挫折的时候可以对照一下

  • 主动原则。主动并不是指我们常说的做事积极主动。而是要主动提升自己的专业能力,如果你再当前岗位上已经没有什么挑战和能力提升空间的时候,要主动寻找下个级别专业能力的技术来学习进步
  • 不断挖掘成长点原则。工作中存在大量的重复工作,比如业务开发。当你业务开发已经做到组里骨干,工作效率又高质量又好,那就去尝试完成方案设计,架构设计,架构重构和系统优化的工作。对自己的工作进行定期复盘,找到需要提升的那个点。
  • 价值原则:学习为公司产出价值的技能。要认识到能力级别和公司价值这两个的区别,大部分开发者都会走进这个误区,认为我技术提升了,我就应该获得晋升,而评委在考察你的能力的时候往往会从你这个技术的应用带来的价值来衡量,所以无论你把能力描述的多么宏大,如果不能体现在对公司的价值的实际产出上,那一切都是徒劳。

当你理解了这三个原则,就应该了解,能够为公司创造价值,又能够快速提升自己的人才是基本符合晋升标准的人。所以,不要只顾埋头干活,也要学会抬头看路

除此之外,还要把我晋升的两个关键逻辑

  • 做好当前级别的事,只有把当前级别的事情做好了,才能有晋升的机会
  • 提前做下一个级别的事,在当前级别做下一个级别事情的人,晋升的机会更大。 先做下一级别的事,再做下一级别的人

建设能力模型

上面讲的都是我们认知偏差方面的一些内容,那具体我们该怎么去做,有没有指导性的方法论呢,李运华老师在他的《大厂晋升指南》中提出了COMD模型。

这里我整理介绍一下。 面向复杂度的多维度能力模型(Complexity-Oriented & Multi-Dimension Capability Model),简称 COMD 能力模型。COMD 的 CO 是指 Complexity-Oriented,意思是“面向复杂度”(灵感来源于“面向对象”);MD 是指 Multi-dimension,意思是“多维度”,也就是技术、业务和管理 3 个维度。COMD 的核心指导思想是,通过事情的复杂度来判断能力的高低,级别越高,所做的事情复杂度也越高。为了描述不同能力层级的差异,COMD能力模型还进一步地明确了复杂度,具体包括规模复杂度、时间复杂度、环境复杂度和创新复杂度4种类型。

规模复杂度

规模复杂度指和规模大小有关的复杂度。规模越大,复杂度越高,原因在于规模越大,节点就越多,阶段间的关系就越复杂,如下图,很直白的描述了节点多少对于复杂度的直接影响: image.png 按照这个原理,我们可以把一些常见的工作维度的规模复杂度进行对比,具体如下表所示: image.png

时间复杂度

时间复杂度是指和时间跨度有关的复杂度。时间跨度越长,复杂度越高。其原因就是万事万物都出于不断的变化当中,时间跨度越长,潜在的变化因素就越多,越难准确判断。

环境复杂度

环境复杂度是指和环境不确定性有关的复杂度。我们很多的判断、决策和行为依赖于对环境的认知和反应,环境的不确定性越高,复杂度越高。环境的不确定性具体分为环境的稳定性、环境的透明性、和环境的可预见性 image.png 从表格可以看出,对于互联网行业来说,环境稳定性、透明性和可预见性都是比较低的,所以他的复杂度是最高的,这也就是在互联网大厂里面,技术大佬更多的都投身在业务上的主要原因。

创新复杂度

创新复杂度指和创新程度有关的复杂度。常见的创新包括理论的创新、思想的创新和技巧方法的创新。理论创新的复杂度要高于思想创新,思想创新的复杂度有高于技巧创新。 这里特别想强调的是,创新是要参考环境维度的。这个环境即公司。如果你再头部大厂里,那你的创新可能是要提出行业方面的新思想或者方案。如果在中小公司,那你的创新可以是公司一直没有实践的思想或者技术方案。

如何应用COMD

一般来说,公司都会对各级别有一个抽象的描述,如“系统性思考”、“前瞻判断”、“理解本质”、“诠释战略”等,但实际的指导意义不大。COMD能力模型,吧能力分成技术、管理、业务三个维度,并通过规模、时间、环境和创新四个复杂度来判断能力的高低。我们可以静下心来填一个能力矩阵的表格,把每一项都列出来,这个就可以作为你能力的达标参考,下面是一个某大厂P6的能力矩阵。 image.png 如果这个表格里的内容你填写不出来,说明你对这个级别的理解还不够。你可以请教你的主管、HR和同事等人,来完善和细化表格内容。当你详细的填完这个表格,你也就对这个级别有了清楚的理解。

面评部分

面评就是在评审阶段的当面交流,一般包括的内容有:PPT(前期准备的材料)、讲PPT(晋升时陈述)、答辩(回答评委提问)等环节。可以肯定的是,你的面评表现很大程度的决定了你的晋升结果。如果把影响面评结果的因素做个排名的话,你的能力占比是50%,而面评技巧可以占到30%,剩下的20%上面讲到过。

PPT误区

晋升PPT是你向评委展示自己能力的关键性材料,非常重要。如果写好App,避免走进误区?先看看晋升PPT常见误区:

  • 误区一:晋升PPT的形式越酷炫越好 有些人以为 PPT 就是要做得漂亮、做得炫酷,所以采用了大量的图表和区块,明明简单的一两句话就能说清楚的事情,也要用区块占一整页 PPT,甚至还专门加一些动画效果。事实上,PPT 的漂亮和炫酷程度并不是关键,有时候反倒会成为累赘。
  • 误区二:晋升PPT列的事情越多越好 有些人在总结自己能力的时候,以为列的事情越多,就越能证明自己的能力很强,于是干脆把做过的事情全部罗列出来,逐个介绍。这会导致评委无法判断哪些能力才是你的核心能力,产生一种他“啥都会但又啥都不精”的感觉。参加过面试的朋友应该都知道,一旦面试官对你形成了这种印象,多半是要凉的,其实晋升答辩也是这样。
  • 误区三:晋升PPT的内容越详细越好 有些人虽然知道 PPT 不要列太多事情,而是要挑几件主要的来讲,但是对于挑出来的这几件事,介绍得特别详细,什么细节都不放过。他们这么做可能是担心因为紧张而漏讲一些事情,也可能是因为不知道评委会关注什么,以为只要都讲,总能踩到“得分点”。我也做过评委,虽然不是很高级别的,但是站在评委的角度,他们无法吧你连续几页的PPT的内容整合成某个主题相关的完整内容,也无法抓住你要讲的重点,自然也就没办法对这个方案做出准确的总体判断。

PPT标准框架

上面我们说到了晋升PPT的三大误区,那什么样的PPT算是好的?简单来说,内容好才是真的好。 具体要求如下:

  • 结构清晰:比如用金字塔原理或者思维导图来讲解思路,用时间线模型来讲解发展历程,用架构图来讲解系统,用流程图来讲解业务,用UML类图来讲解代码等。
  • 重点突出:在PPT上,将核心内容提炼成3~5个点,让评委能够快速理解你要将的内容范围。无论是总体上要讲的事项还是每个事项的两点,都应该遵循这个思路。
  • 与实际讲述内容匹配:你要讲什么,PPT就配合呈现什么,最忌讳的就是讲的内容和PPT内容不符。

自述部分

自述部门是整个PPT的核心部分,自述部分总体的写作指导思想就是金字塔原理,围绕“我达到了xx级别的要求”这一个中心主题,设计3~5个核心论据,每个论据氛围背景、任务、行动和结果4个部分展开,整个机构就像金字塔,中心明确,层次分明,逻辑清晰。

image.png

上图论据论证方法或者说方式都写了STAR,什么是STAR呢,就是Situation-Task-Action-Result。你可能在准备简历和面试的时候用过 STAR 方法,但其实它在晋升答辩的时候也很管用。STAR 方法的具体介绍如下:

  • Situation(背景) 描述事情的背景。提炼1~3条关键内容摘要
  • Task(任务) 描述你在这件事情里的角色和负责的任务,千万不要本末倒置,一味强调事情有多牛逼,还忽略了自己的角色,等到评委提问诸如:你在其中做什么的时候,已经是一个不好的情况了
  • Action(行动) 讲清楚自己做了什么,展现了哪些能力。
  • Result(结果) 讲述事情的最终结果,这是最不容易讲好的部分。正确的做法是“虚实结合”,而且重点是“实”,所有的事情都应该围绕效率、效果、质量和成本这4个维度进行量化评估

答辩部分

答辩环节才是直接决定你能否通过晋升的关键,因为及时你在写PPT和讲PPT的时候表现不那么好,答辩环节还是可以弥补的,反过来就不行。所以我们要注意一下几个重要的点:

  • 虽然很重要,但是不要紧张 太过于紧张,导致压力很大,有时候真的会导致晋升失败,可能有些人有过这样的精力,评委闻到某个问题,答不上来,感觉整个人就蒙了,整个画面禁止了,甚至等到切换成别的问题的时候,都还没有回过神来。提高抗压能力没什么诀窍,就是平时要多练,比如内部模拟面评、给别人培训、向高级别的管理人员汇报工作以及在技术分享或者技术大会上做演讲等。
  • 明确问题类型,回答关键内容 评委提的问题可以氛围两大类:相关问题、开放性问题。相关问题基本围绕你的过往经历、PPT内容、团队问题等,这些相关问题又可以分为三个小类,即:What、How、Why,针对这三类的提问,我们可以按下表中的思路进行答案组织,如下图: image.png
  • 不要急于回答,不要过于发散 评委话音未落,就赶紧回答,如果回答到点子上还好,如果没有,评委会认为你没有抓住重点,对问题相关内容掌握的不太好。评委问的问题正好你了解,所以你想回答的足够好进行了较多的发散,这样做会导致两个问题:1.答辩时间有限,很容易造成超时,甚至可能造成评委打断你的回答。2.发散的点可能评委了解的更加深入,继续追问下导致“翻车”,从而影响了整个结果,所以回答关键内容即可。
  • 遇到不会的问题怎么办 遇到不会的问题,正确的做法是,不要编,不要蒙,不要扯,老老实实承认不会,然后引导评委关注自己的其他技能,回到自己熟悉的领域,因为晋升的时候,你根本用不着证明自己全知全能,只要向评委展示你的核心能力就可以了。
  • 发生争执就及时终止话题 答辩中还有可能发生这种问题,关于某一个问题,或者技术点的回答与评委产生了分歧,谁也无法说服谁,这个时候千万不要争下去,即使你的对的,此时的争论也对你没有任何好处。首先大部分的评委都会为了证明自己,不断的抓住这个问题跟你一直辩论下去,这样你就没有时间来回答其他评委的问题,展示你的其他能力了。其次,一般来说评委的工作经验比及丰富,对技术的理解,以及应用场景的理解都要更全面一点,你出错的概率是较大的。所以,遇到这种情况,直接说:这部分内容我可能还没有研究透彻,后面我自己再深入研究一下。

关于业务及管理问题

没做管理,为什么还会被问到管理问题

说到这里我们先回顾前面说的三个核心原则中的一个:价值原则。为公司创造价值才有机会晋升。 对于高级别的人来说,业务能力和管理能力都是创造价值的核心能力。如果你不懂业务和管理,职场天花板就会很低,很难晋升到比较高的级别。 接下来,我分别针对业务和管理进行说明。

为什么要懂业务?

首先,懂业务能让你更好地理解需求。绝大部分技术人员从事的项目都属于业务项目,比如 2C 的电商、支付、出行、旅游和本地生活等,以及 2B 的云平台、CRM 系统和广告系统等,这些业务项目是公司的核心利润来源。理想的情况是,产品经理和技术人员各司其职,技术人员只要按照产品经理的需求来实现就能完美地满足客户需求。但是现实的情况却没这么乐观。因为产品经理水平有高有低,有的业务经验丰富,有的还是新手,所以如果你完全依赖产品经理输出的需求,是会存在一定风险的。

其次,懂业务能让你更好地设计方案。假设我们的产品经理很厉害,能够准确地抓住客户需求,那么是否意味着你就不需要理解业务了呢?其实也不是。因为技术人员设计方案的时候,不但要考虑如何实现功能,还要考虑性能、高可用和可扩展等设计属性。这些设计不是凭空拍脑袋想出来的,而是需要根据业务的特点来设计。就算产品经理可以提出性能等要求,但是怎么实现、能实现多少,都需要技术人员结合业务来设计。

最后,懂业务能让你更好地规划技术。做业务规划就不用多说了,肯定要懂业务。而做团队规划也必须要懂业务,不然就没法对齐业务规划,你做得再漂亮也很难拿到好的业务结果,很难得到上级的认可。如果CTO的规划业务规划是“提升用户体验”,而下一级别的领导做的团队规划却是“引入 Flutter 提升开发效率”,那么就算最后提升了开发效率也没有意义,甚至还有反作用,因为引入 Flutter 可能导致踩了很多坑,影响了用户体验。

为什么要懂管理?

正如上面所讲的,理解业务才能创造更好的价值,那么学会管理才能让创造更大的价值成为可能。很多技术人一听到“管理”就会想到开会、做汇报、写 PPT。的确,管理者的日常工作是包括这些,但这些都是表象,管理真正的作用其实是整合团队的力量,让团队突破单个个体的能力上限,创造出更大的价值。如果你的职级越高,面临的挑战越大,需要创造的价值越多,你就越需要发挥团队的作用,管理能力对你来说也越重要。 技术人员晋升管理者后,往往会面临着这样的困境:不知道做什么,不知道怎么才能做好。或者在被问到管理相关问题是,不知道从哪里说起,很容易陷入:任务分工、进度跟进、风险控制。这老三样上,其他的挤不出来一个字。这里可能给大家分享一个管理四象限的图,能帮助我们快速整理出中小团队管理的核心事务,如下图:

image.png

其实,管理其实是一个很大的范畴,包括企业管理、行政管理、人力资源管理和团队管理等,技术人员需要学习的主要是团队管理。所以你不必花大力气去学所有和管理相关的知识和技能。尤其是在企业管理领域,有大量的名人效应和名人光环在里面,所以虽然介绍成功企业家的管理理念和管理方法的书有很多,但是这些内容对于技术人员管理团队来说没有什么作用(甚至可能还有负面作用)

总结

看完上面的内容,相信你已经掌握了一些晋升相关的方法,掌握了这些方法,更重要的是要把它应用在工作实践中。我建议你持续的学习和提升,因为不同的级别要求的能力在深度和广度上都会发生变化,要持续按照下一个级别的要求来给自己指定目标,才有可能突破自己的瓶颈。

写到最后

无论是我们学习技术类的一些课程,还是平时的工作实践内容,这些都是你不断挑战和提升自己的过程,至于晋升结果,只是确认你努力的效果而已。

也许你全力投入某个项目,希望它能够让你充分展现自己的能力,但是项目最终没有上线。 也许你做足了准备,信心高涨的去参加一个晋升答辩,表现良好,但是结果却让你很失望。 也许你的产品刚刚上线,前一个晚上还在庆功聚餐,隔天就告诉你公司的这个事业部要撤掉了

面对这些情况,你需要强大的内心来承受挫折,认识到这些不是自己能力因素而产生的结果,认识到失败的客观因素,也不用纠结于寻找这些问题的答案,不是所有问题,都有答案的。

我用我很喜欢的一句话来结尾吧。“世上只有一种真正的英雄主义,就是认清了生活的真相后还依然热爱它。” 这个世界当然不完美的,环境也不是对所有人都公平。在处于困境时,思考有哪些破局点,最大化利用自己的所学去寻找生活和工作中的最优解。