上篇文章,我们谈过了“Hire slow,fire fast”的前半句,今天我们聊下后半句,也即“fire fast”。

历经千辛万苦,新人终于到岗并开始适应新环境,大部分人都可以在两到三个月时间恢复战斗力,进而产出符合预期的价值。 但也有少数例外情况,由于种种原因,新人并没有达成预期。应该怎么处理这样的情况呢?

一定要 fire 吗?

首先我们要界定这个人是不是达到了需要 fire 的标准,具体各团队可能都有些适合自身的判断。 我个人比较偏向的标准是:

  1. 不能达成预期的预期是长期性的,短期内很难改观

    如果新人只是因为对于当前技术栈不熟悉,或者因为外语、远程办公等工作环境的剧烈变化导致的不符合预期,那么我们是可以考虑多给些时间以进一步考察。 但如果新人是因为自身能力问题,譬如一个高级工程师无法产出合格的系统方案设计,或者总是用两倍甚至三倍以上的时间才能交付质量下乘的项目, 这类问题通常无法短时间内通过培训等助力方式快速提升

  2. 存在一些原则性的根源问题

    每个团队可能都有一些”红线“,譬如一个非常分布式的基于信任构建的团队里,非常依赖高度自驱来推进各项目,如果新人无法自律,划水严重, 如果在管理者进行警告督促后仍无有效改正的话,可以认定存在原则性问题。类似的红线问题还有不诚信、泄露公司机密牟利等等

其实第二点只是第一点的一种特例,本质上第一点这一标准就够了。

Fire 其实阻力重重

即便我们内心的天平已经偏向于 fire,但实操层面,往往还有各种因素导致我们无法快速做出决断:

  • 这位工程师只是解决问题速度慢了点,其它例如沟通方面还是可以的
  • 代码写的虽然糙了点,但是也能如期交付
  • 自律比较差,但是多催一催也能出活

从根本上来讲,本身这个世界就是复杂的,并不是非黑即白,我们往往要在灰色地带做取舍。 大部分未达预期的新人既然能够通过层层筛选,肯定也有自己的相对优势。 那么怎么权衡要不要 fire 就高度依赖团队管理者对于情势的判断,尤其是团队定位和个人定位的调和空间。 如果他的某方面核心能力能够在未来一段时间提升团队的短板,那么即便管理者适当补位也可以接受的话,那可以先留任看看。 相反,如果他的核心能力或者很弱或者并非团队将来所需的情况下,就没有必要继续。

另外一个 fire 的阻力点是:这某种程度上证明了招聘流程存在疏漏。让人正面和解决问题需要高度自信,有的管理者可能由于这方面的疑虑, 往往都优先选择再观察一段时间,直到很久之后迫不得已才动手。其实大可不必,即便是类似 Netflix 之类的优秀团队, 也有可能遇到一些针对性比较强的候选人或者遗漏了一些要点。就像我们维护一个产品或者系统,逐步迭代查漏补缺就好。

还有人担忧说如果新人愤愤不平,故意捣乱怎么办,譬如实名或匿名开始语言攻击或者诋毁团队,破坏团结等。 其实我倒是觉得,这样的人越早暴露越说明我们做对了。

容忍低绩效者是对大多数人的惩罚

在上一篇文章里我们分享过平庸的工程师带来的一些负面影响,其中我认为最重要的一条是:

  • 向团队表明你接受平庸,从而使问题更加严重

正如那篇文章开头的例子一样,低绩效者一旦在团队中被其他人显著地识别了出来,那么大家就会开始质疑团队是否还在一个健康发展之中。 一旦他们做出了肯定的判断,那么高绩效者们的离开只是时间问题。因此我一向认为,容忍低绩效者实际是对大多数人的惩罚,是在向大家表明这个团队越来越平庸。

对于管理者,我理解非常类似 Jon Snow 这样的守夜人,核心职能之一就是能够营造出一种让团队的大部分人充分发挥自己的聪明才智为公司贡献价值的氛围。 当有一些噪音或者负面情况出现时,守夜人能够及时发现和干预,以保障团队主体免遭影响。

也因此,即便困难重重,我依然建议管理者从整体利益出发,在负面影响扩大之前,早做决断。

所有的底气来自于有能力招更好的人

不少管理者在是否 fire 之间犹豫不决还有一个重要因素:招人不易。试问:如果一个月内就可以招到符合要求的候补成员,还用得着犹豫吗?当然不用! 所以,类似我在招聘驱动的组织建设中提到的

工程师组织建设的核心就是招人,招足够优秀的人

如果我们整个组织是优秀高效稳定的,辅以适当的面向招聘的各项举措,自然能够吸引到足够的候选人,从而实现自然可持续增长。

结语

”Hire slow, fire fast” 看似简单,实则是大智慧,关乎高人才密度团队建设的一体两面。我自己在平时工作中受用良多,对于“做正确而不是容易的事情”也有了更深的理解。这两篇粗浅的思考也希望能给更多人提供参考。