我曾亲眼见证过这样一个事情:

一个内部工具团队,因为业务增长太快压力山大,某个时间点 lead 在招聘方面做出了妥协,放水招进来一个看起来还凑合的工程师。 过了一小段时间,团队里其他人慢慢开始离职。有几个是我非常熟悉的伙伴,平时跟他们沟通不少,大家普遍的一些感触是:我怎么和这样的人一起工作。 再后来,团队雪崩式解散,部门领导不得不抽调其他资源维系业务运转。

有一次我也跟原来的 lead 闲聊,当谈到为什么当初招那个人的时候,他坦言:业务太多了,内部服务开发又不招人喜欢,没办法。

这些年来,随着团队管理经验的逐步积累,我越来越意识到师傅曾经教给我们的那句话的重要性:“Hire slow,fire fast”。今天我们就先聊一下前半句:Hire slow。

业务压力大 => 不得不降低标准招人?

这是一个很自然的想法,没有人就没有资源迭代旧服务和开发新服务,要不然怎么办?

问题就在于这儿,作为团队负责人,切忌把自己逼得只有一个选择

认真思考下,真的就没有别的办法了吗?譬如,是否可以尝试:

  • 开源
    • 跟上级 lead 充分沟通,争取临时借调兄弟组资源等方式
    • 请求倾斜招聘资源,并推动内推、猎头等多种形式举荐人才
    • 尝试引入外包或者临时工等外部资源
  • 节流
    • 精简需求,把钢用到刀刃上
    • 采购 SaaS 服务或者基于成熟开源方案快速开发
  • 提效
    • 培养团队成员的核心技能,重点是开发能力和沟通能力,让他们成长更为快速一些,早日担当大任
    • 积累可复用的方案、框架、中间件等,提升工程效率

这里只是列出一些可能的办法,实际大家可能还能想出更多。

其实 lead 除了在开源节流方面做得不是很理想外,还有一个认知上的误区:

内部服务开发又不招人喜欢

也许他本心也是这么认为的,但笔者不敢苟同。 内部系统确实有一定的局限性:用户少,需求杂,工期短,反馈多。 基本都是围绕 CRUD,做得好没人说,有问题挨批评,经常吃力不讨好。这些都是现实问题。

但跳出这个层面来看,内部系统其实某种程度上是公司成败的“秘密武器”:

  • 内部系统对于降本增效有极大的促进作用

    一个好用的内部系统,实际上是围绕组织结构来深度定制的,取舍得当的话,往往可以对业务和组织的不断演进产生深远影响。 美团早期在快速上单方面做的一系列结构化深度改进让整个运营团队的效率提升了一大截,成功在千团大战等激烈竞争中脱颖而出。

  • 内部系统可以充分挖掘用户、业务的痛点,以及大家的正向反馈

    用户可以轻易触达,业务也比较方便深入调研,这都是难得的差异化优势。另外,lead 要去注意抓一些用户或者数据方面的正向反馈, 以此来给团队带来更多荣誉感和正向激励,让大家明白自己做的事情的价值

类似人的五官一样,没有哪个是可以或缺的,内部系统也很重要,让团队理解自己团队的价值是 lead 的最为重要的职责之一。

降低标准招人的后果

那实在是没有办法的情况下,不得不降低标准招人的话,会有什么后果呢?

Netflix 创始人 Hastings 在“不拘一格”一书中提到了平庸的工程师带来的一些负面影响:

  • 消耗管理者的精力,使他们没有时间把精力放在优秀员工身上
  • 团队讨论的质量得不到保证,拉低团队整体智商
  • 强迫他人国绕着他们开展工作,致使工作效率低下
  • 排挤其他追求卓越的员工
  • 向团队表明你接受平庸,从而使问题更加严重

最大的问题在于:劣币驱除良币,其他的优秀工程师其实并不缺乏好机会,一旦他们确信团队水平在逐渐变差,那么离开是迟早的事。 长此以往,团队只剩下一群次等工程师,交付能力愈加堪忧,撤职跑路也就为时不远了。

因此,原则上,绝不能优先考虑在招聘标准方面做出让步,这应该是所有尝试都失败的情况下才不得已而为之,仅限于短期手段的无奈之举。

招聘速度过快还有更多问题

Hire slow 除了说不要降低标准招人以外,还有一个内涵就是:不要招聘过快。

初听起来这是反直觉的,业务发展快,团队招人也很顺利,那么快速招兵买马应当是自然之举。 但事实并不是这样,和机器可以轻易水平扩容不同,工程师毕竟是人,平时工作的相当比例的时间其实是在沟通协作,扩张过快容易产生一系列问题:

  • 没有足够资源指导新人适应团队,任其自生自灭导致成长不稳定
  • 过分多样化的人员背景导致内耗加大,很多项目推进效率低下,争论不已
  • 团队优秀文化迅速稀释,认同感凝聚感逐步淡化

正如 Brooks 在“人月神话”中提到的,粗暴加人对于项目进度有可能是负面而非正面影响。

建设团队,需要“结硬寨,打呆仗”,稳扎稳打,才能在永葆精华的同时,有序提升组织能力。