写点什么

识别不出团队能力的高低强弱,是管理者的懒惰

  • 2022-07-23
  • 本文字数:11843 字

    阅读完需:约 39 分钟

识别不出团队能力的高低强弱,是管理者的懒惰

2022 年过半,技术 Leader 如何做年中总结?如果团队里的核心人才要走,怎样才能留住他?技术团队的三年规划应该怎么做?如何从 0 到 1 带团队?公司有绩效强制分布,应该怎么办?面对裁员,普通员工如何规划个人成长与未来发展?

 

本期《超级连麦》,我们邀请到了马泷医疗集团 CTO、TGO 鲲鹏会(北京)董事会成员于游,和极客邦科技创始人兼 CEO & TGO 鲲鹏会发起人、校长霍太稳,极客邦科技事业合伙人、InfoQ 极客传媒总经理汪丹,共话技术 Leader 如何破解那些管理难题。内容有删减,感兴趣的同学可进入“霍太稳视频号”观看直播回放。


技术 Leader 如何做年中总结?

 

InfoQ:2022 年已经过半,于游老师作为一个管理多个团队的 CTO,是怎么做年中工作总结,并展望下半年工作的?霍太稳作为 CEO,又是怎样做年中总结的?

 

于游:我每年到这个时候,都会写一份比较详细的总结,这份总结包含了几个层面。第一个层面是给我的领导以及我的合作伙伴们看的,里面包含了我在上半年完成了什么样的工作,取得了什么样的成绩,最开始的目标是什么,这个目标最后达成了多少,以及有多少目标是错的,有多少是偏离的。最后需要给大家一个交代,甚至是一个业务上的帮助。

 

我今年并没有做这份总结,因为对于我们这样一个线下机构而言,我们的目标需要不断地调整,它并不是一个很静态的目标。我们今年有一个很重要的任务是把我们的 IT 产品公司化,集团公司有不同的板块,我们需要独立变成一个信息化、数字化的板块运作。同时,我们还要支援集团的业务,要去拟定整个产品的方向。在这个过程中,我自己发生了非常多的错位,从一个原始的集团公司的支持者,从偏中后端的服务者走向前台,作为一个公司的总经理,甚至要对所有的经营指标负责,要对自负盈亏负责。这一系列的目标,让我自己的思维习惯也在发生着巨大的变化。

 

如果我现在总结这半年来我的实际工作,完成集团业务的支撑是没有问题的,但是我还要对所有人有一个交代,告诉大家我做了什么,做完这件事情以后对业务有什么帮助,它的业务结果是什么,产出是什么,能否跟业务挂钩,以及技术的积累是什么。

 

如果你的角色是多方面的和全方位的,你需要针对你的全方位做个总结,面向的对象也不同,甚至更多的是面向你自己。这个总结应该让你自己去回看整个过程,是否学到什么,是否有所成长,以及你最开始的思考和现在产生的问题是不是能够匹配。这是我这半年来关于做总结,发生的一个重大的转变。

 

霍太稳:我在年初定的很多目标在实际执行过程中发生了非常大的变化,所以我觉得上半年给我最大的一个启发就是:理想很丰满,现实很骨感。极客邦这家公司穿越了经济周期,如果一家公司没有穿越过经济周期,那么就不能说这是一家成功的公司。因为创业者要一直往上走,如果你没有创业周期的经验,那么到了一个时间点可能就很难继续向前。当你拥有这方面的经历之后,就会更加稳健,因为你对自己的能力,对团队的能力和认知就会更多一点。

 

回到这个问题本身,对于年中总结,我认为一个公司的 CEO,或是部门的总经理,最终还是要先把自己管好,然后再去给团队设一个发展方向。前阵子我们团队开了年中会议,我要求所有的班委会成员必须去写好自己的年中的总结。当然,作为一个 CEO,我也要把自己的年中总结写好。我洋洋洒洒写了很多,后来发现这个东西写得越多,感觉好像越在为自己辩解,找各方面的原因做辩解。后来我直接从三千字缩减到一千字,后来又缩减到五百字,基本就只说上半年做得还不够好。

 

字越少,反思的痛苦越在其中。

 

其中的一个反思是,我们上半年有一点做得比较好,就是引入了非常优秀的人才;但有一点做得不够好,我们引入优秀人才的过程太快了,太快的话,犯错的几率也就提高了,这是个正负相关的事情。除了反思,我还需要告诉大家下半年,我们应该去做一些什么样的事情。我们公司有几条业务线,包括 InfoQ 以及极客时间的 C 端和 B 端,我给每条业务线都做了一个重新的定位。比如,InfoQ 是我们公司的现金流业务,它就是我们公司的氧气,氧气是不能缺少的;极客时间 C 端业务是我们的基石,基石越牢固,整个生态就会更好;极客时间企业版属于我们关键的主战场,主战场一旦失败,可能会造成更多的影响,就像多米诺骨牌一样。

 

有一点需要强调的是:日子再难,生活再苦,创新是不能丢的你要去想在三五年之后,公司还在不在,你要做一些什么样的事情可以对未来做投资,哪怕你拿出 10% 的精力去想这些问题,都是非常必要的。这就是我给我的整个的团队,给我们的高管以及公司的所有员工去做的年中总结。

 

InfoQ:于游老师作为资深技术管理者,您怎么看待您下属的技术总结,什么样的年中总结是你更希望看到的?

 

于游:我觉得所有年中总结的评估方式都与他自己的角色有关。实际上,我们在整个工作过程中,每个人都有自己不同的工作内容。比如,研发技术总监的工作总结需要包含他开发的项目数,交付周期是什么样子,项目结果如何,为什么会产生这样的原因,总结了哪些经验等等。

 

基本上,所有人的总结无外乎“回顾目标-评估结果-分析原因-总结经验”这个形式,只是每个岗位有所不同。

 

比如技术总结评估的方式通常以项目为主,如果他是一个架构部门的负责人,他需要告诉我,最开始拟定的目标和架构升级的方法,以及他解决了什么问题,为公司做了多少底层的相关工作。如果他是一个技术总监,那么我希望看到他的目标能够跟业务目标接近,他做的这些事情对业务产生了多少的帮助。就这一点来说,我在很多技术部门的年中总结中都看不到。如果他是运维总监,那他在总结中一定会以精度作为评估方法,他会告诉你全年几乎没有产生事故,或者事故原因是什么,有多少是外部原因,有多少是内部原因,他采用了什么样的方法,结果是什么。

 

以上这些总结其实全是偏技术化的,我对自己管理者的要求是,如果只是技术化的总结,那么这个总结是不合格的,作为管理者,你的总结一定要包含人,就是你的团队。要看团队有没有成长,或者你的团队任务指标、架构目标、底层升级目标等有没有完成。如果没有完成,原因是你个人管理的缺失,还是团队的执行不到位,或是其中某些人能力存在问题,需要成长。

 

技术人往往会限于事,但不要忘记你作为技术管理者,是带着管理二字的。不但要管事,还要管人,对于人要有要求,而且对于每个人都要有充分的评价。所以如果技术管理者的年中总结仅仅只是针对于事情,肯定是不合格的,这也是我目前对组织的一些要求。

 

霍太稳:我和我们的技术总监沟通得比较多的是,一方面看他目标的完成度,在年初定了什么样的任务,完成得怎么样。但并不是说把这个功能完成就可以了,还要看这个功能的完成对于业务到底有什么样的促进作用,有多少人去用,这也是考核的一个维度。另一方面,我会经常问研发同学,是否有业务上的思考。比起拥有解决 Bug 的能力,我更关注研发同学怎么利用技术或者产品让我们的业务发展得更快。

 

我认为,公司里的产品、研发和设计同学一旦到了总监这个位置,就不仅仅只是一个执行人员了,一定还要具备对业务上的思考和理解。这一点我也是向业界很多优秀的公司学到的,对公司中后台专业人才的要求应是能够将业务与技术相结合的复合型能力,无论对于个人成长还是企业发展来讲都是非常有价值的。

团队里的核心人才要走,怎么才能留住他?

 

InfoQ:如果团队里非常核心且优秀的架构师要离开,作为技术管理者应该怎么办?

 

于游:这个问题我经常遇到,因为在整个职业生涯过程中,不会有人会一直随着你往下走的,而且人都是个体,每个人都会有自己的职业规划,也会有自己的诉求。我们必须承认,理想和面包都是有的,你所在的空间不足以给他面包的基础上,人家是会有自己的选择的。

 

对于这种情况,首先需要冷静地思考,我一般会去先评估一下这个人的价值,他给公司带来的价值到底是什么,以及我现在能给到一个什么样的价值区间。这是很现实的。市场上是有这方面的基础估价的,一个人给公司带来的价值基本上是多方面的,一方面是他自己的技术价值所产生的经济价值,另一方面是他的经验价值。有些人的技术价值和经验价值加在一起实际上对公司是 1+1>2 的助力,也有很多人是经验价值大于技术价值的,公司失去这样的人可能会有一种阵痛,你需要考虑这个人应该用什么方式留或者是不挽留,我觉得这是一个技术管理者先要去平衡的一件事情。

 

作为一个管理者,应该兼顾事和人,你要管人,就得摸清楚他的诉求到底是什么。如果他只是职业发展上的诉求,那就得去看公司有没有他的空间,有没有给他划一条象限的路线。我们都有职业生涯的四个象限,当你在第四象限逐渐往上走,这条线逐渐陡峭的时候,你就会发现自己没什么挑战性了,而且自己也没什么发展了,怎么办?很简单,把他推到另外一个象限里面去,让他在这个象限有所发展,让他知道自己在公司的发展没有到头。这个过程就是摸人的一个过程。

 

另外作为管理者,很多时候你不得不去画饼。优秀的管理者需要时时刻刻记住自己画的饼,并且在一段时间之内将这个饼越画越圆,让人吃到嘴里。如果想留下一个人,你一定要有信誉,如果所有的事情你都画了一张饼,最后什么都没做到,那么你在去挽留这个架构师,或者挽留这个重要角色的时候,人家未必相信你画的饼,甚至是你的承诺。动之以情,晓之以理,附以于相应的经济基础和未来的理想,这是留人的一个基础方法。

 

霍太稳:我觉得对于创业团队而言,核心骨干离开是一个致命的打击,在这种情况下,创始人是弱势的一方。在我刚开始创业的时候,如果有人说要离开,我都会痛苦蛮久,我也会和他去沟通很长的时间。但是后来我发现这不能解决问题,人家该走还得走。

 

一个公司的发展真的像一列火车一样,如果说创始人 CEO 是火车驾驶员,从头开到尾,公司的核心高管或者是合伙人相当于火车的服务员,员工可能相当于乘客,乘客是没有必要从头坐到尾的,到了一站可能就会下车,或者换去另外一列火车,这都是非常正常的事情。但是考验驾驶员的是,你驾驶的这列火车驶向的目的地,是否能让列车上的同学在一开始买票的时候,就愿意跟着你从头跑到尾,这个非常关键。

 

你自己需要保持始终向上的精神,往前跑的态度,和管理团队一起打造良性的机制,带着整个团队,带着业务往前奔跑,让大家觉得公司对社会有价值,发展有前景,就不会在中途随意下车了。

 

InfoQ:您希望什么样的人加入您的团队?

 

于游:我会比较关注三点。第一是专业能力,毕竟我所在的是技术团队,如果这个人专业能力不够的话,那么在团队中的融合度也会比较弱。第二是个人追求,我会关心这个人学习力和成长过程,在面试中我会问他的学习过程,以及对自身技术领域深入的过程。第三是价值观,简单讲就是人和人之间是不是 Match 的,如果这个人和我是有冲突的,那么和我的团队也是有冲突的,他工作起来是不会舒服的。当然,如果这个人的前两各方面都很强,那么第三点也可以适当放松;如果前两方面其中一个方面比较差,那么第三点就变得非常重要。

技术团队的三年规划

 

InfoQ:直播间有同学提到一个问题,技术团队的三年规划应该怎么做?

 

于游:我的逻辑挺简单的。如果你要去带团队,首先看你能不能活过三年。要想活过三年,需要具备几个因素,一方面,你所从事的事业是否有成长性,并且和公司的战略、目标要有匹配度,只有这样,你的工作才有意义,否则你的工作就是空中楼阁,你做的所有事情可能对公司没有任何帮助。如果公司倒闭了,你的三年规划也没有任何意义。另一方面要看自己的心态,判断自己的底线,有多少底线是能够被打破的,有多少是你能够去坚持的,在什么情况下你会选择放弃。如果你自己都放弃了,那么做三年规划也没有任何的意义。在这两点都准备好的情况下,你再去想怎么做技术团队的三年规划。

 

从我个人经验上来讲,如果是以三年为限,那么首先要预测三年之后的业务发生量,一般预测方法是现有业务量的 10 倍到 15 倍,这是传统的互联网公司的成长曲线,我们可以管它叫古典互联网。在发展比较快速的一些赛道,基本上单年业务量能够增长 10 倍。你需要明确技术团队的人员是多少,团队要做一些什么样的事情活下来,怎么用降本增效的方式,让企业认定我的技术团队是有价值的。

 

比尔·盖茨有一句话说得非常正确,“技术总是在短期内被高估,但是在长期又被低估”。三年周期不长不短,中间你会经历低估和高估的过程。

 

第一年,大家在甜蜜期,要什么资源给什么资源,要干什么就干什么,当做到稳定期的时候,你可能会觉得技术是个没有存在感的地方。如果我们换一个角度去思考,如果你是企业的 CEO,当你的企业达到一定的规模的时候,你的业务增长是无限的,但在没有达到那个规模的前提下,技术还在不断往前铺路,还在不断地要求成本,这个时候你会怎么想?这其实是一个平衡,你是否能在一个阶段内找到它的平衡点?如果你在设定目标的时候就错了,那么就需要动态地去调整目标。

 

第二年大部分是打基础,如果公司发展是一个斜 45 度角,那么你做任何事都是有道理的,当公司遇到一些困难和问题的时候,你就要去思考缩减过程和投入,怎么动态地调整目标。这就是为什么现在我们有很多技术都是用云原生的技术,伸缩的技术,它实际上是在最下面的基础,我们用一些应用型的方式去解决掉公司的问题。有一些系统该上,有一些系统不该上,这些都是你的技术决策。

 

我的逻辑是,面对三年这样一个时间周期,最大的一个决策点是如何让技术不被低估。你一定要想明白,怎么才能对业务有帮助,你能把技术的价值用沟通的方法泛化出来,用量化的方法体现到 CEO 面前,这样你就赢了。当然,如果你从一开始就能完全想清楚这三年,我觉得显然是不可能的。

技术永无止境?

 

InfoQ:直播间有同学说,自己在一个终端的技术团队,工作偏驱动、安卓底层和算法,感觉三年还是会到顶,技术真的会永无止境吗?

 

于游:我觉得技术是否永无止境是跟业务相关的。我们自己非常明确地知道,技术是无止境的,但是对于一个公司或一个业务而言,技术有可能是有止境的。如果一个公司的业务容量或者业务需求就在这里,那么公司给你的三年目标或是半年目标,需要你关注的是你能帮助公司解决什么问题。大公司称其为技术的基础投入,并且大公司对于这些是有规划的。

 

同时,公司需要去评估一个边界,这个边界是真真正正技术领导力当中非常重要的,叫做技术判断。你要有自己的技术判断,一方面需要提升自身的见识,另外也要不断去跟同行交流。如果超过了这个边界,就很可能造成过度投入,从而浪费公司成本,到最后,你和公司都可能出现问题。

 

霍太稳:我做一点补充。上次我和华润雪花 CIO 郭老师沟通时,我问了他一个很傻白甜的问题:企业做数字化到底有用没用?郭老师直接回了我一句话,数字化本身不是一个技术的问题,而是你的企业想不想寻求第二发展曲线的问题。当然这个问题的背后没有说技术不重要,而是说你还是要把技术和业务结合在一起去考量,这又回到刚才于游提到的那个问题,就是你怎么去把你所做的事情产生的价值,给你的老板做一个很好的量化。

 

现在很多时候大家在讲管理数字化,我觉得技术也是可以数字化的。当你和老板汇报时,如果你能够表明用技术解决了什么样的问题,帮助公司哪一块节省了多少资源,提升了多少效率,这就是技术的数字化。我们 TGO 鲲鹏会的荣誉导师乔新亮在极客时间里写过一个专栏叫《乔新亮的 CTO 成长复盘》,他在里面经常强调的一个观点是,技术的存在就是要把业务团队干掉,技术团队需要让业务有一个非常蓬勃的发展,并且希望能够用尽量少的资源为业务创造尽量多的价值。

 

另外,刚才于游提到的技术投入的问题,也让我想到我之前看过的一本书,《锻炼》。书中提了一个特别有意思的观点:一个人如果做少量的运动,或者做中度的运动,对自己的身体是最有价值的,当你过了那个节点,做过量的运动,虽然对身体没有伤害,但也没有价值。身体如此,技术投入也是如此。

如何从 0 到 1 带团队?

 

InfoQ:有用户提问,团队从 0 到 1 应该如何带?他感觉这个比做产品还难,于游有什么经验吗?

 

于游:这是所有管理者刚刚上任的第一年都会提的问题。其实这个过程特别有意思,你刚上任的时候,领导说你工作不错,让你带四个人去完成一个工作。这个时候你可能会说,领导交给我吧,这事我来定。领导拍拍你的肩膀,对你说去干吧,这就是你的事情了。领导认为你能做这个事情,但这时已经产生了一个变量,就是领导的期许。从管理维度上而言,你要带领这个团队去完成四个人,甚至大于四个人所产生的效能,这是领导的期许。

 

从我的经验上来看,刚上任的管理者,如果带一个四人团队,最终能完成两个人的工作就不错了。为什么?因为每个人都是一个变量,每个人针对于这个管理者的管理纬度,以及工作的分配纬度都有变化,如果团队中有人完不成工作,管理者往往会身先士卒,把他的问题解决掉,但这样会使得管理者自身无比疲惫。

 

作为管理者,你的首要任务是认人和用人,需要认清这个人本身能够完成的工作量和他能够完成的工作标准,不要用自己的纬度去评估,而是要很明确地评估出这个人能做什么事。带人的一个核心逻辑是识人,你需要去看他能够做出什么样的成绩,这需要在工作中不断磨合。另外也需要评估这个人的投入度和他自己对未来的期许,如果他本身就是个“老油条”,用任何方式可能都解决不了问题,只是甩了个锅,让你来调解一下,那你就必须得接受他这样的状态,后期用考核标准,或者用其他的方式来解决掉他的问题,这是一个管理者优先要去解决的。

 

所有的管理者在从 0 到 1 带人的过程中,往往犯的第一个错误就是上来就给员工用团队的方法分配任务,先天性认为这件事他能完成,这一定是错的。很多时候,1+1 不是大于 2 的,三个和尚是没水吃的。你需要在最开始的时候,非常的明确地对于团队做一次摸排,要对团队中每个人的性格、工作内容,以及他的产出有一个公平的评价。刚上任,你们还没有形成团队,你需要先建立一个团伙式的认同,让大家对于你个人的认同,对于工作的认同,对于公司的认同达到统一,先有一个目标性的拉齐,你才能往下去安排工作。

 

从我个人的经验上来看,对于刚刚上任的管理者,我一般都会“扶上马送一程”。最开始的时候,我会参加他所有的例会,我会告诉他应该怎么去管理,每个人实际上是什么样的情况,如果这个人出现问题后,你应该如何去考核他,如果这个人已经到了他的上限,如何把他推到第一象限去,给他设定一个新的目标,能够让他在团队当中找到自己的发展。我委任了你,我就信任你能做好这个团队的管理,我会把自己的管理经验输出给你,送你一程,这样你才能管好团队。

 

霍太稳:于游讲得非常好,我在这块踩过太多的坑了。我发现有些人做了一段时间的管理工作,但还是不懂管理的常识。管理的知识没那么难,只要捅破那一层窗户纸。所以现在,我们公司有一项规定,就是当一个人要进入管理层之后,一定要先学习管理的常识。我们也做了一个未来领袖训练营,所有的经理人必须要参加过未来领袖训练营,目的帮助大家扫清管理上的一些认知问题。

 

另外在极客时间上有一个讲管理常识的专栏,叫做《技术管理实战 36 讲》,这也是我们 TGO 鲲鹏会的一个会员写的,里面讲了很多管理上的道理。包括我们还有《技术领导力实战笔记》,里面也讲了很多管理的常识。我现在会要求我们团队的同学,只要做经理,就必须学会这些最基本的管理常识。

 

于游:我完全认同这一点。我在之前的公司曾有过类似的感受。当我在一个人员极度膨胀的阶段,我是非常累的。这个阶段不要小看刚才那句话,“扶上马送一程”。一个人的管理半径是有限的,管理半径永远不会超过 10 个人,也就是 8 到 10 个人左右。如果你的团队处在极度膨胀的过程中,当你的管理半径超过 10 个人,到 20 个人、30 个人左右的时候,你是非常辛苦的,你的管理成本消耗也是巨大的。

 

有很多初入职场的人总觉得管理包括技术管理是一件很虚的事情,甚至并没有在管理上投入一些精力。但我觉得,每一个小团队的管理者都应该去学习,也要去切身地在自己的管理工作当中去体会,根据团队阶段的不同去分配自己在管理上面所耗费的精力。这件事很重要。

管理者如何应对绩效强制分布?

 

InfoQ:直播间有同学提问,很多公司都是有绩效强制分布的,例如 ABC 这种,如果团队里都是 A 级选手,但是公司又有绩效强制分布,应该怎么办?

 

于游:我想先抛出一个问题,如果你认为绩效强制分布这件事没有道理,你认为自己的团队应该全是 A,那么你自己是 A 还是 C?这个问题看似比较抽象,我再把它具像化一点。如果让别人评价你,你认为对方会给你一个什么样的评价?是合格还是不合格,是好还是不好?

 

我个人的一个经验是,理论上来说,所有人在任何一个工作上面,都有可能出现高低强弱,如果你不能识别出来这些高低和强弱,那是你管理的懒惰。如果你认为所有人全是 A,我只能认为你的管理缺位了,你没有办法评估出一个人的好坏。你这个团队得多优秀,没有一个人失误。如果按照这个逻辑来讲,你们公司应该是一个非常强的向前的公司。

 

但其实所有的团队,只要是你沉下心来管理,沉下心来针对于他的每一项工作做评估,一定有让你不满意的地方,一定有在平均线以下的工作内容,除非是你没有去管,没有去关注。所以我认为正态分布这件事情是存在的,而且从长期管理来看也是非常合乎常情的。

 

霍太稳:这个问题原来在我们公司也出现过。团队里的每个人都是 A,但问题是,大家都是 A,为什么整个团队业绩那么差?为什么目标就是完不成?这是一个非常残酷的问题。很多同学容易混淆为公司创造价值和团队氛围好,最终我们还是需要看你所在的组织去创造多大的价值。

 

我之前看过一个理论,就是作为一个公司里的员工,怎么去衡量他在公司中创造的价值?到市场上去衡量。如果你创造的价值是高于市场上的价值的,那公司理应给你一个比较好的待遇,或者给你一个比较好的考核结果;如果你创造的价值是小于市场上的价值的,那么不好意思,你可能真的会被开除,或者整个业务都有可能被拿掉。这是一个非常残酷,但又是非常现实的一个道理。

 

这也是为什么,刚才我和于游反复在强调,你所做的工作一定是可以被量化的,也一定是可以被市场化的。虽然最终相对比较残酷,但是当一个人理解了这个残酷的现实之后,他的职业就已经进入一个腾飞的阶段了。

技术更迭迅速,技术人应该如何学习新技术?

 

InfoQ:技术更迭非常快,很多人可能会产生这样的疑惑,正在学习的一项技术还没有完全掌握时,新技术又迭代出来了,这种情况应该怎么办?

 

于游:很多东西不代表新的就是好的,我们需要有个明确的概念,就是即使它新,它能解决掉以前的一些问题,但它会产生一些新的问题。它能不能适用到你现在的业务场景中去?这是需要非常细致评估的。如果你不深入到这个技术本身里面去学习,你是很难发现它的问题的。可能这项技术的发明者或宣传者会把它的价值说的天花乱坠,但只有你自己真正用了,才能发现其中的坑。所以我觉得,站在学习技术的角度,大家需要冷静。

 

第一,你要有选择、有限度地去学习新技术。往往一个新技术产生的时候,大家都在不断地说这个技术的好与坏,但你要切入到这个技术本身的逻辑当中,你需要问比自己技术更好的人,或者多去和行业里的人交流,另外还要结合自己的业务再具体评估一下。你需要去问你领导的意见,因为他是你的技术领导者,领导者不一定比你的技术强多少,这一点你要记住,但是他的经验要比你多,并且他有很大的一部分能力是对于技术和业务的结合,他能够给你一些意见,并且能够对你产生帮助。如果你决定跟这个人,你就要信任他的决策和决定,有可能他是错的,但是就这件事情本身来说,你要有限度地去学习,因为人的精力都是有限的。

 

第二,你要洞察技术的本质。很多事情,比如现在比较流行的 Rust 等语言,都是编程式的基本范式,我们需要把这些算法级的东西都了解清楚。语言没有实现方法,它只是一种实现手段,主要看你自己以及团队的习惯和舒适程度,只要你达成这种舒适程度,理论上这个语言就是好语言。

 

对于 CTO 或是技术管理者而言,最佳解决问题的方式就是在没有核心底层开发人员的情况下,能够快速地 Google 和百度到,这就是好技术。如果出现问题之后你还要把这个东西研究几天, 那线上可能早就崩了,业务早就对于技术团队失去信任了。当然,这主要指的是中小型团队,中小型团队最主要的技术选择栈就是,到底能不能快速地 Google 和百度之后解决这个问题,能够快速地定位并解决,这是我觉得团队选择技术栈和自己选择方向的一个逻辑。

 

当然我也非常支持往下看,自己去学习这方面的内容,但是这部分的内容要看自身的兴趣,还有一部分是公司的需求。这两个能够匹配到当然最好,如果没有,你只能用自己其他的时间想办法把这部分补上。其实这个过程就是师傅领进门,修行在个人,实战出真知,不练起来,你光学,可能永远都是纸上谈兵,看到的都是皮毛。

面对裁员,普通员工如何规划个人成长与未来发展?

 

InfoQ:今年发生了很多裁员事件,霍太稳站在 CEO 的角度,是如何看待企业裁员这件事的?作为企业中的普通员工,如果自己刚好是优化对象,应该怎么去考虑这件事情,怎么去进行自己人生的下一步?

 

霍太稳:虽然这是残酷的现实,但我们终归要面对。其实我更想说的是风物长宜放眼量,从更加积极的角度去看待,当前中国的数字经济正在蓬勃发展,很多传统行业对于人才的需求量非常大。

 

回到这个话题,在这种情况下,员工可以找到自己的老板并和他进行沟通,看下自己在哪些地方还可以再成长、再进步,以及对于自己接下来的职业生涯,对方有哪些建议。一般在这个时候,你的 Leader 会给你坦诚的真实的反馈,这些反馈可能会让你将来少走好多弯路。另外我想说的是,平时你就要和直属 Leader 做好沟通,对齐你们之间的目标,并尽最大的努力去完成这个目标,而且是超出他的期望值。如果你能做到这一点,那么你被优化的几率会非常低。

 

此外,还要保持积极的态度与学习的精神,虽然很多公司并不对这么要求,但我认为,如果你具备了积极的态度与学习的精神,就相当于给自己的整个职业生涯穿上了“护身符”,走遍天下都不怕,不管你去了哪里,职业都会发展得非常好。

 

简单总结一下,首先一定要有个好的心态,把任何一件坏事都往好的方向去发展;第二,和你的直属 Leader 做好沟通,哪怕你被裁员了,让他给你一个直接的反馈;第三,平时保持积极的态度与学习的精神,持续地去提升自己的能力。

 

于游:Kevin 已经说得非常全面了,对于个人成长,简单而言就是,你需要把自己的价值体现出来,这个价值本身是可以量化评估的。

 

我个人的感受是,选择比努力更重要。你的思维逻辑和你的视野决定着你的选择,你需要明确自己是否有多方面的选择,以及你在做选择时,决策漏斗是什么样子的?可能很多人只看眼前利益,比如两个 offer 一个薪资给到 2w,一个薪资给 1.8w,给你 2w 的公司就一定比 1.8w 的更重视你吗?不一定。你需要先看这条赛道是否正确,你是否能够伴随着公司的主营业务往前走,如果你认同,那么你和公司的目标就是一致的,这样当你往前走,只要你足够努力,并且能够给公司带来足够的价值,你被优化的几率就会相对小一些。

 

如果你为了短期的利益去了一条并不是很好的未来赛道,即便你能维持现在的目标,也一定要想明白自己的职业生涯是有阶梯的,当你在做这一步的时候,需要思考自己在什么节点可以去做下一步的选择,这一点非常重要。

 

在过去,我们整个技术行业都是垂直向上发展的,有很多人跳槽就能加薪 50%,甚至是 100%。现在我奉劝所有技术人的一点是,市场已经冷到一定程度了,大家做选择的时候要充分的谨慎,要明白自己做技术到底是几斤几两,如果你做了五六年技术,还是在给数据库加个壳,坦白讲,你觉得你的竞争力在哪?市场上有大量这样的人,有现在的成绩只是公司和平台成就的,当你离开这个平台后,你会发现自己一无是处,这句话非常残忍。

 

当然,这些观点都是我自身的感受,我自己也不一定所有的选择都是对的,但是确实,选择是你成功的一部分,如果你想要让自己的职业生涯有一个向上的发展,那么一定要做好规划,这跟 OKR 的目标管理没有任何区别,你自己要给自己做个 OKR,看自己能不能实现它。

“起点低,当下净,回头脏,平常道”

 

InfoQ:最后请于游老师给我们直播间的开发者们、朋友们送一些寄语。

 

于游:我最近看了一个非常有意思的故事,我想把这个故事分享给大家。一个百家讲坛的老师讲了一段故事,是《西游记》中的一个典故,就是唐僧扫塔。唐僧扫金光塔的时候,跟孙悟空两个人从第一层开始扫,一直扫到最上面的一层。网络上有很多人疑惑,说扫这个塔完全可以从最高层开始扫,否则扫完之后下面的灰都白扫了。

 

但是这位老师解读出了 12 个字,我觉得特别有道理,这 12 个字是:起点低,当下净,回头脏,平常道

 

起点低,就是不管什么事,你一定要把自己放低,扎扎实实从头做起。当下净,就是当你在打扫每一层的时候,需要把当前的事情做好,如果你连当前的事情都做不好,那么即便你考虑到了过去和未来,对于现在来说也是没有任何帮助的。回头脏,从下面开始打扫,一直打扫到上层,当你的见识达到了一定的高度和广度的时候,你回头去看你以前的路,一定是一路的荆棘,一路的肮脏,如果说这一路你觉得自己做得特别好,证明你是没有进步的,你一定要看到你回头路上遇到的所有问题,这些问题都是你前进过程中去扫除的动力。平常道,不要总想着做高大上的事,有很多平平常常的工作把它完成好就已经很好了。

 

我觉得这位老师把这个故事总结得非常有道理,我把这个故事送给大家,算是共勉,并且也做一个自勉。

 


2022-07-23 12:0011105

评论 2 条评论

发布
用户头像
嘉宾的视野很有高度
2022-10-08 18:42 · 北京
回复
用户头像
这篇文章写的特别好。我受益匪浅
2022-08-08 16:18
回复
没有更多了
发现更多内容

干货!这份阿里P8大佬纯手打总结Kafka学习笔记,真是yyds

了不起的程序猿

Java kafka java程序员 消息中间件 Java 开发

属实不赖!Alibaba开源GitHub星标114K微服务架构全彩进阶手册

冉然学Java

Java 阿里巴巴 开源 微服务 微服务架构

连流量染色都没有,你说要搞微服务?

得物技术

架构 微服务 云原生

创新能力加速产业发展,SphereEx 荣获“中关村银行杯”『大数据与云计算』领域 TOP1

SphereEx

数据库 开源 架构 SphereEx Apache ShardingSphere

Vue3知识点梳理(一)

青柚1943

Vue3

Android进阶(十六)子线程调用Toast报Can‘t create handler inside thread that has not called Looper.prepare() 错误

No Silver Bullet

android 8月月更 toast

用Rust编写的Linux内核GPU驱动程序,或将到来

非凸科技

Linux gpu rust 编程语言

《数字经济全景白皮书》银行业数字普惠金融发展与优化策略分析 发布

易观分析

金融 数字经济全景白皮书 易观分析

推荐一款微软出品的开发神器,体验不输IDEA!(含参考资料和项目源码)

收到请回复

面试 springboot 应届生 金九银十 java项目实战分享

前端监控系列2 |聊聊 JS 错误监控那些事儿

字节跳动终端技术

APM 前端监控 火山引擎 JS错误

MobPush丨iOS端SDK API

MobTech袤博科技

ios API MobTech袤博科技 mobpush

为什么电商云产品需要 Assisted Service Module (ASM) 模块的支持

汪子熙

typescript 电商 SAP 8月月更 Storefront

DAPP和APP有哪些区别?多链跨链NFT铸造挖矿dapp系统开发技术原理分析

开发微hkkf5566

为什么不做APP而要做小程序

源字节1号

小程序开发

一文详解特权访问管理(PAM)

SEAL安全

安全 访问权限 访问管理 特权访问

开源 | WLock:高可用分布式锁设计实践

开源 分布式 分布式锁

鄢贵海:DPU发展中的四个关键问题

硬科技星球

增强分析在百度统计的实践

百度Geek说

数据库

人手一套的K8S命令集合,它来了!

wljslmz

云计算 Kubernetes 容器 8月月更

Groovy语境下的Map

FunTester

开源一夏|OpenHarmony之如何实现震动

坚果

开源 OpenHarmony 8月月更

StarRocks 技术内幕 | 基于全局字典的极速字符串查询

StarRocks

数据库

微服务性能分析|Pyroscope 在 Rainbond 上的实践分享

北京好雨科技有限公司

Kubernetes 微服务 云原生

Linux下玩转nginx系列(八)---如何使用upsync模块实现动态负载均衡

anyRTC开发者

nginx Linux 负载均衡 音视频 服务器

35岁程序员危机,有何破解之法?

博文视点Broadview

一文搞懂│mysql 中的备份恢复、分区分表、主从复制、读写分离

MySQL 高并发 经验分享 签约计划第三季 8月月更

业务数据迁移上云的一些技术思考

京东科技开发者

MySQL 迁移 云数据库Redis

多原则等于无原则,微服务识别方法究竟该怎么选?

老坛架构

架构 微服务

以合规交易释放数据“红利”,合合信息旗下启信宝签约福建大数据交易所首批数商

合合技术团队

数据 峰会

阿里大佬 推荐的 “ Spring Cloud Alibaba项目文档 ” 正式发布

冉然学Java

Java 微服务 Spring Cloud Alibaba

基于RocksDB实现高可靠、低时延的MQTT数据持久化

EMQ映云科技

物联网 mqtt RocksDB emqx 8月月更

识别不出团队能力的高低强弱,是管理者的懒惰_文化 & 方法_凌敏_InfoQ精选文章