随便聊聊low performer

最近lz在lead两个pro‌ject,很不巧每个project里都有一个low performer,真的让lz看着心里着急又无力吐槽。lz虽然工作时间不长,但到目前为止大大小小总共合作过4个不同类型的low performer,这次借机会总结加吐槽一下。

  1. 技术基础薄弱,喜欢做表面功夫。
    这个是lz碰到的第一个low performer,也算是让lz大开眼界的一个人,以下称其为A。A入职我司之前在业界摸爬滚打了4年,换过不少公司,但是技术水平和基础之薄弱经常让周围所有人觉得A是不是一个知识都没学好的IC3。此君最大的特点是喜欢overpromise,脸皮较厚,喜欢抓着人不放问问题(其实相当于让人手把手帮其写代码)。A入职两个月后,周围的人都被A搞怕了,想方设法躲着A。不过A很机灵,学会了打游击,把一个问题拆分成几个小问题,问不同的人。其中很搞笑又很让我佩服的是,A因为cs基础太过薄弱,有些时候会根本无法理解别人给的答案,所以会用recursion,把这些不懂的答案再拆分成小问题去问另一批人。这个方式让A再撑过了3个月时间,但是效率非常低,所以A为了代码量达标,各种提交无意义的代码,并且找别组的人秒accept自己的code,造成了大大小小不少bug。当时组内senior为了帮A擦屁股,得夜里加班。后来目测其进了PIP,开始做一些与team goal不相关的小project,混了小半年之后在一个下午被security escort out。A是我最为反感的一个low performer,不仅仅是因为其自身能力不行,而是因为A的存在拖累了其它人的进度,给其他人加重了负担。同时A又是相当以自我为中心的人,take unnoticed PTO before project launch,为了混代码量乱交代码,到后期察觉自己呆不久之后各种直接消失了,各种meeting不来也不打招呼。我很惊奇A居然能在公司混这么久才被fired。
  2. 技术过关,写代码细心,抵触走出comfort zone,除写代码外贡献十分有限。
    这位同事应该是楼主最为惋惜的,人写代码很细心,技术也可以,工作也上心,最大的问题就是当时其负责的product area有其不熟悉的tech stack,但是其很抵触去学习和improve这个stack的代码,认为很多相关的tasks都不应该属于其的责任,让我们以下称其为B。我当时是B的mentor,一开始大家对其印象都不错,后来随着B项目的深入,需要其负责一个其并不熟悉的tech stack,结果B表现出了相当大的抵触情绪,对相关的tasks很反感。在与B多次1:1后我了解到其反感的原因有2,一个是觉得这部分代码之前没有clear ownership要其负责修legacy bugs并不合理,二是觉得这部分代码并不是其熟悉专精的领域,不想在上面多花时间。B认为manager以及大家是在刻意刁难,所以才让其负责这个部分的代码。LZ在与B之后的多次1:1中都是试图让其理解作为area owner需要承担的责任以及试图安抚其情绪,帮助其快速上手。虽然B之后态度上有所改观,并且承担起了area owner的责任,但是course correction来得较晚,所以rating并不理想。以及其始终想做回自己熟悉的领域,B最终选择了转组。
  3. 技术一般,责任心差,经常性怠工。
    以下简称C。C最大的问题在于经常玩消失,尽管多次提醒其deadline,依然无法阻止其delay project。C一开始给lz的印象还是不错的,会问对的问题,喜欢问为什么,而且会做笔记,相当organized。lz当时以为c在ramp up一个月之后就能productivity飞起,结果入职四个月依然甚至没有达到IC3的productivity。C经常会莫名其妙消失,不来office,也不说话。而且其平时就算在office,其也很少在group内活动,导致大家完全不知道C到底在做什么。代码方面,除了数量极少之外,虽然C在业界也有一定经验,但交的代码质量仍然难让lz满意,似乎喜欢不太思考地就copy-paste代码,交上来review的代码总是需要花一两个revision去改本应该在提交之前就发现的nits。当然最让lz最不能忍的还是C不能deliver promise。其中一个project的launch date就因为C went MIA以及反复delay delivering code,导致延期了2周。C对组的影响没有A恶劣,但是占用了一个headcount,并且无法deliver符合其级别的impact,在中长期来看影响其实也很不好。
  4. Ramp up速度极慢,心态失衡。
    以下称其D。D也是业界老兵,跳槽后来做一个自己完全不熟悉的领域。但无奈ramp up速度实在是太慢,除了无法在coding上contribute,也无法再其他上面make impact,让其心态有些焦急,造成恶性循环。lz其实非常能够理解其处境,经常帮助在技术上以及提升工作效率上给D tips和帮助,虽然有改观,但是成效不能算巨大。因为D是mid-level eng,公司对其的要求也很高,以D的情况来看,真的很危险。lz也希望D之后能够尽快适应并且贡献。

总结
情感上来讲,lz最讨厌的是A,其次是C,他们也是对其他人负面影响最大的类型。LZ更愿意花时间去帮助B和D这类型的同事。当然,如果B和D不能在短时间内表现出改变,也很容易让其他人放弃。
还有一点,lz觉得PIP现在在地里被严重妖魔化了,似乎PIP就是一个清除异己的政治工具。其实不是的,PIP大部分时间是用来帮助团队和公司健康运转的有效手段。各位同学设身处地试想下,如果A与C是你的同事,你会愿意长时间与他们一起合作吗?再退一步,就算你们愿意,你觉得对于你们team来说,有利吗?

在职场上,到底什么东西能帮你survive,甚至thrive?lz觉得其实就是老板对你的信任,以及周围同事对你的信任。你与其他人工作的过程,也是在建立trust的过程。
持续地deliver project可以让大家信任你,持续地帮助大家进步、解答问题,也可以让大家信任你,be nice,真诚地、职业地与他们相处,也可以让大家信任你。

lz同时也想引申一下,给职场新人一些不成熟地小建议,让大家避免成为别人眼中的low performer:

  • Keep your promise。只答应老板和同事你能做到的事情,不能做到的不要乱promise。
  • 急人之所急。这里的人只的是老板。要弄清楚老板想要你解决什么问题,然后专注在其期望内解决它。如果有余力,帮老板解决其他他关心的问题。
  • Be independent。要学会自己寻找资料,自己解决问题。A与C逐渐到后期让大家反感的一个重要因素就是他们一直在高频率地问问题,并且事无巨细地问,简直就是在浪费大家的时间。
  • 不要肆意消耗大家的耐心。一般越牛的人耐心越低。这里的耐心并不是只回答问题或者与你相处时的耐心,而是给你定性的耐心。如果你无法在有限地时间内meet他们的expectation,他们很可能就不会对你有更高的期望了。这一点我只能说manager更甚。
  • 要保持好心态。不要慌乱,稳扎稳打好好安排,只要你一直在做正确的事,会迎来质变的。

其实关于A和C LZ有很多想吐槽的地方,不过码了那么久字都想不起来了lol。今天就先到这吧。也欢迎大家分享你们的经历。

对于我来说B这个我觉得我有话要说,看起来是想让B接手一些l‍‍‍‍‌‍‌‌‍‌‍‌‌‍‌‌‍‌‌egacy code。 这显然不是他不想走出cz,而是这个活他很清楚是个坑

我当年也接过类似的活, 该类work item往往没有visibility,技术层面奇葩 ,遇到的不少问题往往没有办法通过逻辑去解决,严重依赖老员工的经验,如果写这些code的老员工都走了只能抓瞎。我做的这个活不光要写legacy code,还要配套使用的是我们内部的一套系统去deploy monitoring pipeline,除了看百科全书式的doc只能问别人,但别人基本上也不知道。被我打扰几次后就没人管我了。最后磕磕绊绊做出来了,花了2个月不说,也被老板警告说我的performance不行,于是果断转组,以及发誓再也不接这种坑proj。我认为B转组是个正确的选择。

LZ我可能有点恶意揣测,你是不是不太喜欢B,所以把这样的活交给他?以及我也很好奇,最后这个item是怎么解决的?

补充一下,我是IC2。在做这个活之前,老板和我1 ON 1一直都算比较温和,起码没什么不满意。做这个活的时候几次1 on 1气氛都显然比较紧张,按下不表。 做这个活之后我写了几个新feature,然后第一次1 on 1老板说他几乎忘了我做事情原来这么快。

所以我的performance本身我认为问题不大,而是有些work item真的很坑。 我拿这个item也纯属意外,并不是老板想坑我,是我太连清。但你把这个活assign给IC3,这显然是有点那啥。。。?

我觉得除了少数人少年老成, 大部分人都是要吃点亏才能成长的 ,所以在职业早期胆子大点多踩几次坑。当然,希望这个答案能帮助你们避开一点不必要的坑。

以及我们组之前并没有太多处理legacy code的经验,所以不论是我还是我的manager在这件事上都有不足,但我不认为他有恶意。很多时候你要教会ta如何正确地帮助你。

我觉得这也取决于企业文化,看愿不愿意从各个角度帮助IC成功 。如果大家觉得对象meet不了expectatio‍‍‍‍‌‍‌‌‍‌‍‌‌‍‌‌‍‌‌n就直接放弃,可能也是不妥当的。

我觉得除了A,对于BCD,可能需要manager花更多的时间了解一下原因。C有可能是有家庭有孩子需要处理,BD很有可能只是放错地方的资源。 他们不成功的确有他们自己的原因,但是如果周围的人能给予更多support,了解不成功的原因,看看他们是不是真的想成功,我觉得还是有救一下的必要的 。当然如果一个公司有8%的pip名额,大家都为了防止自己被calibrate掉,遇到能给自己垫背的也不愿意帮的话,那就只能任由bcd自生自灭了。

感觉越不牛的人耐心越低,越牛的人耐心越高。