Skip to main content

末位淘汰制下的生存感悟,我是受益者?

 

Image

The pessimist complains about the wind; the optimist expects it to change, the realist adjust the sails. - William Arthur Ward

Image


来地时间不长,却看到了很多帖子里有同学遭遇的各种Dev List / PIP,也有各种各样的评论替遇到的同学鸣不平,主流声音都是鄙视实施末位淘汰制的公司有毒和天杀的Manager心狠。作为一个曾经的亚麻Manager,我考虑了几天,觉得有必要写一下如何在有末尾淘汰制 公司的生存。毕竟多数人改变不了所在公司的文化制度,但却可以调整自己的策略,希望能对大家有帮助。


下面的例子是我读到和看到的(如有雷同替你鸣不平):


例子1:

你刚刚毕业,加入了一个不错的公司,什么都不熟悉,发觉身边的同事都很忙,mentor也不太积极回答你的问题,那只好自己努力了,你加班加点的钻研了很多问题,结果过了3个月,manager说你绩效不好,你说我天天加班啊;manager说不太出活,你说大家都不帮你;manager说你在接下来3个月要提高xxx yyy, 你开始担心DL/PIP,觉得是不是得重新刷题了?


例子2:

你在SDE I上工作有几年了,一直不温不火,团队老换manager,项目也很不稳定,你一直没能升到SDE II。你发觉新来的manager似乎跟你合不太来,但自己算是团队的元老了,管他呢铁打的营盘流水的manager。结果不久manager说你在SDE I上太多年,遇到上升瓶颈,需要自我突破了。你觉得他是要用DL/PIP清洗你,再招自己人。


例子3:

你在公司某边缘团队里混的还可以不是明星也不垫底。你希望能有所突破,想去公司里的明星团队。那里有一群聪明有能力的人,跟他们一起工作能学到很多东西。理想很美好,可你内转去了之后,顿时发现工作中遇到的技术挑战比以前大多了,而身边高手如林,各个不但技术精通而且比你聪明还比你勤奋。压力山大,你拼尽全力熬了半年,manager在1-1里开始提示对你的工作有不满,DL/PIP若隐若现了。

上面的问题如何应对呢。有句老话叫:


“希望你能有一双慧眼识别出哪些是你能改的,然后接受你不能改变的“。


那就分析一下你面对的现实是什么,又有什么是你能改变的。


Image

绩效考核流程

Image


认清现实-不讨论制度合理性,仅讨论如何应对!】


建议大家一入职就尽快想办法搞清楚公司的

绩效考核流程内网、Blind等),比如是每季度一次还是半年,怎么打分。我了解的末位淘汰制的绩效考核体系通常会这么做:

Step 1: Peer/ Customer Feedback



Manager会根据大家的产出和收集到的peer/customer feedback在小团队内stack ranking(排名次),然后根据rank分层为top tier - achieved - least effective , 常见的分层比例有1-8-1 ,2-7-1 和 3-6-1。Stack ranking 会综合多个维度考量“Performance(result),Leadership, Growth Potential" 。分层之后,TT和LE都是要重点分析写 Justification。

Step 2: Manager Review



    有了小团队的分层和打分就进入再上一级的review流程,通常在Sr Manager / Director级别。这个review是全体manager参加,会很长,亚麻要一整天,我也参加过一天半的。会上每个IC都会过,大概5分钟,TT和LE会讲的多一点,然后其他manager提问,TT、LE通常会被问很多。同一级别一个个讲完,讲完就这个级别统计TT,LE比例,TT超了或LE不足就开始PK环节了。

    怎么PK就看Sr Manager/ Director想怎么做了,通常是各manager再重复讲一下各自团队当前非TT但排次位的或非LE但排在末尾的,然后有的时候是manager自由评论互相challenge。。。Smoking Room。。。直到达成一致,也有让其他manager根据介绍匿名投票的。

Step 3: VP Review



     下一步是更大范围的review,所有Sr Manager, Director参加VP层面的review,TT/LE又会被逐一拉出来讲,如果LE比例不够,非LE末尾的要仔细的讲。总之最后各轮结束后就是录入系统,审批,调薪,谈话,公布结果。

Step 4: Dev List



    LE从一确定就录入Dev List,manager准备dev plan文档,过程通常30~60天,然后每周记录1-1的谈话内容(法律要求),如果manager认为你成功了,他会写一个evaluation doc,L8 review,approve了就结束DL。没有通过,就准备进入PIP,PIP与DL是几乎一摸一样的流程,相对于给你第二次机会,但PIP出来的概率小很多。


综上所述,TT/LE rating有多方制约也需要多方认同,所以真不是说Manager想DL/PIP谁就是谁的。说提了内转manager为了留人立马DL的,你的想象力很丰富,但智商正常的manager不会这么留人,因为它本质上manage people out的一个流程。manager们为DL/PIP投入的体力和心力也是巨大的,唯恐避之不及。那些遭遇到DL Surprise的同学,要么是你manager日常给你提的concern,你没get到,要么是你manager也不想DL你,但你被排在了org末尾10%


Image

总结对应策略

Image

解释了常见的流程,聪明如你有没有注意到两点:


0

1


你的Manager只有几分钟来讲你的performance。所以你辛辛苦苦干一年manager只能讲亮点!比如manager一说谁挑起了某项目的大梁,谁解决了上次SEV-1的production problem, 全体manager都微微点头。

所以你工作中20%的产出决定了你80%的绩效,干的多不一定好,要挑重点出亮点

0

2


LE是一个流程的产出,peer manager, skip level manager 都参与其中,所以跨团队项目做的好的或着Peer team找你帮忙你做的好的,他们会站出来替你说话的。Skip manager review做的好的,他更会力挺你的!所以有cross team influence, high visibility 的项目都是好机会,好好表现。


【如何避免陷入DL/PIP】

理解了这个流程,那我们再回想看看开头的例子,如何避免陷入其中呢?

例子1的策略

新人第一件事就是要搞清楚公司、manager、你的职位希望你deliver什么。公司要的是结果,不只是你加班加点,而绝大多数绩效问题都是不清楚你被期望做到什么样导致的。搞清了期望,你就得动用你所有的能量交付了,组内同事,组外同学朋友。新人第一年只要deliver result按时按量,你通常都是安全的。

例子2的策略

认清很多公司的级别有Tenure限制的,比如SDE I最长4年,说我不追求晋升的同学看清楚了,不进则退啊!为了你能达到晋升的要求,3年多还升不了就得DL/PIP了。遇到了烂组1~2年没项目产出,或者manager变动频繁没人给你做升职,你就要果断找机会了。超过2年的SDE I内转,新组manager都要回答一个问题,他为啥还没升II,如果新manager判断你离着很近了,过来马上可以升,很多人也是可以接盘的。

例子3的策略

避免去一个强组成为倒数第一第二。有的组一年培养好几个人晋升,有的好几年没有人晋升。强组确实成长性好,但你要看看你有什么优势去了强组可以立足,缺什么但可以快速补足。一个策略是寻找能利用你至少50%现有知识和技能的新组,确保你去了不是cold start, 而是立马能展现才能。


【Manager的视角DL/PIP】

假如你已经上了DL/PIP该怎么办呢?所谓知彼知己百战不殆,看一下manager会怎么看DL/PIP:

0

1


 Manager会考虑你的GAP是可以提高的还是无法coach的。技术和知识多半是可以提高的而Leadership很难。假如你上DL/PIP是因为你产出不足,没有别的concern了,manager有可能会帮你找对的项目,找人支持,而你努力投入多半是可以交付然后从DL/PIP上出来的。假如你上DL/PIP是因为Leadership, 比如“ownership”,那就悬了。客观来说人的价值观是很难提高的,而且很难度量,基本上靠feedback来判读。

0

2


Manager是不是已经做出manage-out的结论了。有的manager会直说,或者建议你开始看看外面机会。也有很多信号会告诉你他不是在帮你从DL/PIP里出来而是在执行manage-out了,比如你连续多次1-1都没有收到鼓励和认可,收到的都是各种问题。

0

3


对团队里有经验的老人上DL/PIP,Manager会考虑替换成本的。是努力coach你,提升走出DL/PIP 还是让你走了再招一个人培养替换。很多团队里都有这种干了很多年的老人,系统业务人脉都很熟悉,要么工作积极但脾气大;要么人很nice,但工作不太积极。Manager收集peer feedback的时候一堆抱怨,从Leadership的角度把他们放到DL/PIP里对上对下都说得通。假如你是因为这类原因上的DL/PIP,好好配合manager改变自己的behaviour,你也是很有希望出来的,毕竟家有一老如有一宝,很多经验都是无法替代的。









总结一下,末位淘汰制是看起来反人性的,但又有它存在的合理性。


如果你在这样的公司生存了下来,你其实是受益者,杀不死我的只会让我更强大。如果你离开了,不要怀疑自己,只是这个环境不适合你,你总会找到适合你的地方。但无论你喜欢它也好,反对它也罢,如果它是你生存环境的规则,那就认清现实,寻找适合你的生存策略。


希望每个读了这篇帖子的你,既有认清现实的头脑,又有看到世间美好的双眼,更有一双勤奋灵巧的双手,年年拿TT!

Comments

Popular posts from this blog

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into ...

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checkin...