角色

Engineering Manager

面向工程师的人事经理,负责绩效、成长、招聘与团队健康。

最近审阅: 审阅人Kevin Riedl wiki ↗

工程经理管的是人,不是架构。他们站在工程师与公司其余部分之间:把策略翻译成团队层级的优先级,主导招聘流程,承担没有工程师愿意主动开的对话。技术决定留给 Tech Lead;EM 确保做这些决定的人在成长、被支持、且不会即将离职。

一名好的 EM 具备技术可信度(工程师认可他),同时不会与团队的资深 IC 互相竞争。糟糕的 EM 要么离代码太远而无法带人,要么钻得太深而无法管理。这个角色是最难招的之一;多数早期初创会在技术侧超额招聘、在管理侧招聘不足,于是八人的团队开始摇晃。

举个实际例子:一支团队一年内从五名工程师长到十名。没人补上管理,于是创始 CTO 现在一边跑十场 1-on-1、三个招聘流程和两个绩效问题,一边还想扛架构。速度暴跌,两个人离职,所有人都怪「流程」。真正的原因是缺一位 EM。这个信号在离职潮之前几个月就到了:最资深的人花在关于人的会议上的时间,多过花在代码库或 SDLC 上的时间。

常见的错误是把一位强资深工程师在没有任何培训的情况下提拔进这个角色,并假定人的技能会跟着技术技能自然到来。它们通常不会;这两套技能近乎相互独立。按对人事工作展现出的兴趣来提拔,然后再教技术上下文,而不是反过来。

诚实的取舍:一位出色的 EM 会让团队的产出对创始人变得更不易读,因为他最好的工作(留存、扫清阻碍、艰难对话)不会出现在甘特图上。只衡量已发布功能的创始人,往往会低估并少招这个角色,直到那点摇晃变成离职潮。

相关:Fractional CTO 奥地利

// FAQ

常见问题

这个角色既要工程上的可信度,又要带人的本事,而大多数在其中一项上强的工程师,在另一项上都弱。把一位资深 IC 在没有明确培训的情况下提拔成 EM,大约有一半的概率会失败。按带人的能力来招,再去教技术上下文。
大约在 6 到 8 名工程师时,当 1-on-1、绩效管理和招聘开始吃掉 Tech Lead 的日历。低于这个规模,一位强 Tech Lead 加上一位兼职的外部教练通常就够了。高于这个规模,缺一位 EM 就会表现为离职潮。