由劝退一名员工所想到的
这周五我做了一件"恶事" – 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的,但却真实地让我给碰到了。
我以前只是有招人的经验,但从未做过"开人"的事情,这是第一次,心里总有些不忍。原计划由这名同事的直接Leader与他谈这件事情,但这名女leader更是抹不开面子,索性我就直接上阵了。过程还算顺利,这名同事表面上也没有太多意见,但我心里清楚:他肯定很郁闷,这个周末估计会很失落。我们也不想这样的事情发生,但之所以做出这个决定也是因为这名同事"所作所为"实在是太不给力了。
这名同事进入我们产品线大约有一年半时间,他并非是我们招入的,而是由领导从其他项目组安排过来的(恰逢那时我们缺人)。最初安排他做开发侧的技术支持角色,负责产品的升级支持以及生产环境问题的解决,算是隶属开发运维团队。但一段时间后他似乎没有得到运维团队内部的信任,给他派的活儿都是很边缘的,生产环境遇到大的问题基本都绕过他而直接找到原开发人员解决,形成这一局面的原因无非有二:一是他无法独立地及时解决生产环境中的问题;二是在自己无法解决的情况下,也没能很好地协调他人将问题解决。长此以往大家索性就不找他了。团队内部不能养闲人,我们还是给了他机会 – 尝试让他做些开发团队的工作,把他直接安排到上面提到的那位女Leader的项目组里面。经过了大半年,他给出的成绩单却是:失去了所有团队对他的信任,大家把他彻底孤立了起来。团队并非一开始就失去对他的信任,而是不断给他机会,给他的工作都是相对比较简单的,时间上也相对宽松。但即使这样,他也是不断延误进度,提交上来的东西也是频频出错,耽误了自己不说,还耽误了其他团队的整体进度,大家逐渐开始对他都不耐烦了,我这里也不断收到大家对他的抱怨,局面就是这样形成的。年中面谈时,还曾明确给他指出了不足,并就改进绩效计划达成一致,但他依旧没有达到我们的预期。木桶理论告诉我们:在一个团队里,决定这个团队战斗力强弱的不是那个能力最强、表现最好的人,而恰恰是那个能力最弱、表现最差的落后者。于是我们从全局考虑,从团队的整体考虑,我们做出了上面那个无奈的决定。
我做了一下换位思考,如果我是这名同事,到底是什么原因让我走到了这步田地呢?下面我就来帮他分析分析。
首先,我想这位同事没有走好融入团队的第一步棋 – 赢取团队的初始信任
对于一个刚刚进入团队的新人(无论是有工作经验的还是刚毕业的新人),赢取团队的初始信任都是最最重要的。下好这第一步棋其实并不难,把你的直接上司分配给你的第一个任务做好即可。当然如果要赢得超出预期的信任,那就得做的完美一些。在这个阶段,你最好能专心投入,甚至“牺牲”一些个人时间(对于程序员来说,这很容易理解^_^),快速地熟悉新环境、行业领域业务知识、产品以及团队风格。一旦你的第一个任务达到或超过了大家的预期,团队对你的信任也就建立了起来,后面的事情就变得自然而然了;而一旦你搞砸了第一个任务,那就相当于从团队成员那本来就积蓄不多的情感账户中取款,那后续走势如何就要看这个团队的耐心了,他们到底会给你多少次犯错的机会呢!
其次,能力不足且没有努力做出改进
赢得信任需要有资本,这最起码资本就是个人从事这个行业工作的能力。绝大多数行业中处于能力平均水平的人维持一份稳定的工作都不难。但问题就在于如果这个人没能认识到自己能力的不足,或是即使认识到能力不足,但也不努力改进,那这个人就危险了。我的这位同事身上显然就发生了这个问题,这一年多以来他的能力或技能只能说是原地踏步,在IT这个行业里,大家都知道这意味着什么。
最后,态度!
俗话说:"世上无难事,只怕有心人"。这句话从侧面反映的是一种做事的态度,而我的这位同事被诟病最多的就是做事的态度上。我从多方面反馈了解到,他似乎就没有把分配给他的任务当成自己的事来做,总是囫囵吞枣,不断犯错,不断被指出,之后依旧不断重复犯错,似乎一点改进的意识都没有。如果把工作视为可敷衍了事的事情,那后果可想而知。
也许还有一种更为深层次的原因,我也不敢肯定,那就是他也许根本对程序员这个行当不感兴趣。缺少动力,行将就木,做一天和尚撞一天钟,因此有了糟糕的表现。如果真是这样的话,那就是严重地对自己不负责任了!说得严重些叫浪费生命,也许他换个行当就能出类拔萃呢。
在组织层面如何为避免此类事情发生呢?也许只能严把入口。但说起来容易做起来难,仅仅通过几次面试,很难全面地去认识一个人。刘未鹏不是写过一篇文章叫"怎样花两年时间去面试一个人"吗,显然也印证了这一点。
最后还是要对这位同事说一声:你还年轻,这仅仅是一时的挫折,绝不应该就此消沉,反思一下,找到一条更适合自己的路,好好的走下去。
评论