角色

Engineering Manager

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

最近审阅: 2026-05-24 审阅人Kevin Riedl wiki ↗

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

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

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

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

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

相关:Fractional CTO 奥地利

// FAQ

常见问题

应该。没有技术可信度的 EM,会被工程师当行政岗位看待,决策被绕过。但他不需要是团队里最强的工程师,反而需要愿意停止做技术 IC 的人。
5 到 8 人。超过 8 人,1-on-1、绩效、招聘叠在一起就吃掉全部时间。低于 5 人,EM 的杠杆不够,倾向于退回去写代码,模糊角色边界。
因为创始人偏好招看起来「能直接产出」的工程师,把管理当作之后再说的开销。结果团队到 8 人左右就开始摇晃:没人开难对话、招聘流程混乱、Onboarding 看运气。EM 不是奢侈品,是规模阀。