工程经理
工程经理负责的是一个团队如何运转，而不是它的代码写成什么样。职责覆盖人——招聘、成长、绩效、晋升——以及围绕人的条件：团队构成、流程、与其他职能的协作，以及这个群体能否被可靠地依赖去完成交付。这与工程是两门真正不同的职业，本指南说明它包含什么，以及如何评估它。
工程经理做什么？
工程经理对一个工程团队的运转负责：团队里有谁、他们如何成长、他们的表现如何、他们如何协作，以及团队能否稳定地交付。职责通常包括招聘、一对一沟通、反馈与绩效对话、职业发展与晋升材料、团队构成与归属边界、流程设计、与产品、设计及其他职能的协作，以及向更大范围的组织汇报交付情况。关于软件本身的技术决定，通常由技术负责人或工程师们自己承担；经理负责的是让这些决定得以被做好的条件。
进入这个角色是换了一门职业，而不是在同一门职业里升了一级。亲手完成一件事的满足感，被隔着距离、带着延迟、通过他人施加的影响所取代。结果在数月之后才出现，而且很难归因。没有在内心完成这次转变的经理会不断伸手去够自己知道怎么做完的工作，可见的症状是：一位经理在关键路径上写代码，而那场没有人愿意开启的反馈对话又被推到了下一个季度。
这份工作的大部分是在出事之前完成的。一个构成合理、归属清晰、期望明确、成员各自得到支持的团队，几乎不会产生危机。这让这份工作在评价上安静地困难，因为最强的经理看上去要处理的事情比吃力的同侪更少，而用可见的忙碌程度来衡量这个角色的诱惑，正是许多组织把错误的人提拔上来的原因。
这个职责比交付更宽，也比「什么都管」更窄。工程经理不是团队的首席架构师，不应凭资历推翻团队的技术决定；那个习惯会把所有权从工程师手里拿走，并稳定地削弱团队的能力。反过来，一个完全不涉入技术实质的经理，既无法判断风险，也无法可信地为一次晋升背书，更无法向团队之外的人陈述团队的约束。可行的位置是：具备技术素养，并在技术上保持克制。
组织何时需要这项能力
工程管理常常被一位资深工程师或创始人尽可能长时间地兼着。以下是这种安排已经不再奏效的信号。
人员方面的工作只在其他事务的间隙里进行
交付一紧张，一对一就被取消；反馈只在故障期间发生；晋升一年谈一次，因为那时候要交表。人员方面的工作正在以「剩余时间所允许的质量」被完成。
优秀的工程师在离开，而原因没有被弄清楚
离职被归因于薪酬或机会，因为没有人更早、更认真地问过。离职之前通常有数月可被察觉的信号，而察觉这些信号是一种实践，不是一种直觉。
晋升停滞，而且无人负责
工程师说不出什么能让自己走到下一级，晋升材料靠主张而不是靠证据来论证，最有能力的人于是得出结论：成长需要换一家公司。这个结论会很快自我实现。
交付因为组织原因而不可预测
承诺被推迟，原因是归属不清、依赖无人管理、持续被打断和相互竞争的需求，而不是因为工程本身困难。这些原因不在任何一位工程师的控制之内，也不在纯技术职责范围之内。
跨职能协作是非正式的，或者根本不存在
产品、设计、数据和商务各自握有一部分图景，团队则在实现过程中才发现缺失的部分。必须有人对职能之间的接缝负责，而这与对代码负责是两回事。
一个团队即将大幅扩张
往一个从未把自身规范讲明白的群体里加人，会稀释这些规范。快速招聘、把入职做好、并在扩张期间让文化保持可理解，是一项具体的工作，而且有意识地去做，远比事后修补便宜。
核心能力
能提前暴露问题的一对一
一场由对方主导议题的定期对话，频率高到困难还很小的时候就会浮出来。把一对一开成状态汇报的经理，与其他所有人同时得知问题，而这恰好抵消了开一对一的主要价值。
反馈与绩效对话
尽早、具体、不含糊地把难说的话说出来。持续的表现不足被推迟处理，是最常见的管理失败，而它的代价在落到当事人身上之前，早已由替他兜着的同事承担。
职业发展
了解每个人想去哪里、对距离保持诚实，并安排能够缩短这段距离的工作。成长主要通过任务发生，而不是通过课程，这让它既是一个辅导问题，也同样是一个排期与协商问题。
招聘
定义一个岗位真正需要什么、设计能检验它的面试流程、校准参与者使评价可比，然后做出决定。凭习惯拼凑出来的面试流程，往往测出的是舒适感与熟悉度，而不是把工作做好的能力。
团队构成
塑造技能、资历与归属的组合，使团队既不头重脚轻，也不被摊得太薄，并且不存在某个关键系统只有一个人能碰的情况。构成方面的决定，其后果比经理做的几乎任何其他事情都更长久。
对交付负责
诚实地预测、在知道延误的第一时间而不是在无可避免时才通报，并守住「承诺」与「期望」之间的差别。这里的可信度靠早说坏消息建立，靠迟到的安慰摧毁。
流程的引入与移除
为一个已识别的问题引入最低限度的仪式，并移除已经失去用途的部分。流程会默认累积，因为每一次增加在当时都有其道理，而没有人被指派去注意总重量。
跨职能协作
维持与产品、设计、数据、运维和商务职能之间的工作关系，协商优先级，并在依赖咬人之前把它暴露出来。许多被归咎于工程的摩擦，其实源自这些边界。
读懂团队健康度
解读那些先于麻烦出现的指征——持续加班、评审里的沉默、值班疲劳、总是同一个人主动顶上——并在干预还便宜的时候采取行动。
向上代表团队
向没有工程背景的人解释约束、取舍与风险，并带回决定和推理，而不是带回指令。一个只吸收压力却不传递信息的经理，会让团队对「为什么什么都变了」感到困惑。
这门学科是如何实践的
这个角色不由技术栈定义，因此以下描述的是方法。下列实践与产出物是业界普遍在用的——它说明的是这门学科如何运作，而不是关于任何一位经理工作方式的说明。它们也很容易被表面地采用，正因如此，值得检验的是它们背后的实质。
人员实践
- 定期一对一
- 成长与发展计划
- 职级与能力模型
- 绩效与晋升周期
- 结构化的反馈约定
招聘实践
- 岗位评分卡
- 面试环节设计
- 面试官校准
- 结构化复盘
- 入职计划
交付管理
- 路线图与承诺规划
- 依赖梳理
- 风险清单
- 人力与投入分配规划
- 面向干系人的汇报
团队运作节奏
- 规划节奏
- 回顾会
- 协作约定
- 归属与升级路径
- 打断与值班轮换策略
健康度指征
- 敬业度与脉搏调查
- 留任与流失复核
- 值班负荷复核
- 交付流动度量
- 故障后续跟进
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应关注什么
管理岗候选人面试表现好，因为这份工作本身有一部分就是表达能力。真正能把他们区分开的证据是具体且回溯性的：有名有姓地成长起来的人、按时发生的困难对话，以及关于团队形态、至今仍能自圆其说的决定。
那次转变是否真的发生了
问他们怀念工程的哪些部分，以及如何处理被拉回去的冲动。把管理描述成「工程再加上会议」的候选人，往往会把有意思的工作和关键路径留给自己。
- 先谈团队的成果，再谈自己的贡献
- 对自己还应该写多少代码有过思考后的立场
- 能描述自己忍住了接管一项陷入困境的工作的冲动
处理表现不足
这是最被回避、也最能说明问题的工作。请他们讲一个具体案例，包括从察觉到开口之间隔了多久、发生了什么变化、最后如何收场。
- 很早就用直白的措辞提出了这个问题
- 能区分能力问题与匹配度或环境问题
- 既有挽回成功的案例，也有没有挽回的案例
具体地培养人
问他们培养过的具体个人，以及自己做了什么起了作用。对成长的笼统热情人人都有；一段关于拉伸性任务、耗时数月建立的晋升材料，或一次关于差距的坦诚对话的具体叙述，则不是。
- 说得出为弥补具体差距而安排的任务
- 告诉过某人还没准备好，并且保持了建设性
- 能描述一个成长到超出团队、并在他支持下离开的人
不做表演的交付
问他们如何处理一个注定会被错过的承诺。有区分度的行为是尽早、具体地沟通并附上选项，而不是把乐观维持到期限让真相变得无可回避。
- 证据一支持就通报了延误
- 在与干系人沟通时区分预估与承诺
- 能在不指责团队的前提下解释团队为何延迟
招聘上的判断
问他们如何设计过一套面试流程，以及在看到录用者的实际表现后改了什么。从未修订过流程的经理，要么招得很少，要么没有跟踪结果。
- 根据录用者的实际表现调整过流程
- 能描述一次不成功的录用，以及流程漏掉了什么
- 追求面试官之间的可比性，而不是一致的热情
在技术决定上的克制
问他们在不认同团队的某个技术决定时会怎么做。凭资历推翻的经理会拿走所有权；完全不涉入的经理无法评估风险。想要的答案位于中间。
- 以提问的方式提出挑战，而不是以拍板的方式
- 能描述自己接受了一个并不认同的决定，以及原因
- 与技术领导者协作，而不是与他争夺同一块地盘
在崩掉之前察觉
问他们凭什么在任何指标变化之前就知道一个团队有麻烦。这个回答会显示他们观察得有多近，以及他们对团队的认识来自团队本身还是来自一块看板。
- 引用行为层面的信号，而不只是交付数字
- 干预过一个安静的问题，并说得出它是怎么浮现的
- 把持续加班当作系统的缺陷，而不是投入的证明
值得一问的面试问题
作为您自己所主持的面试流程的素材。这些问题指向真实发生过的行为，因为管理能力很难通过假设性推理来预测。
讲一位团队里表现不佳的成员。从你察觉到你开口，中间隔了多久？
What a strong answer shows
面对不适仍愿意行动。那段间隔就是信号，而完全想不起任何类似案例的候选人，要么管理时间还不长，要么一直在回避这种情形，而不是从未遇到。
描述一次你准备的晋升材料。你收集了哪些证据，结果如何？
What a strong answer shows
晋升是被当作公平且有据可依的过程来管理，还是被当作为亲近者的主张。要听长期积累的证据、对标准的理解，以及对同期还有谁在竞争的认识。
你的团队将要错过一个业务上已经对外沟通过的日期。请说说接下来几天你会怎么做。
What a strong answer shows
他们如何让坏消息向上传递。较强的回答会迅速给出一条具体的信息，附带选项和后果，而绝不会包含「希望在有人问起之前局面自己好转」。
你移除过哪个流程？是什么让你确信它不再值回成本？
What a strong answer shows
他们是否把流程同时当作成本与收益。只讲得出自己引入了什么的经理，通常正在累积无人被指派去质疑的仪式。
你们团队的技术方向是怎么决定的？你在其中的角色是什么？
What a strong answer shows
边界是否清晰。两个极端都令人担心：一位默认由自己做技术决定的经理，以及一位根本说不清决定是怎么做出来的经理。
一位很优秀的成员告诉你他在考虑离开。你会怎么做？更早的时候本应发生什么？
What a strong answer shows
把留任理解为一项长期实践，而不是一次挽留报价。有用的答案在问题的后半段，只关注当下反应的候选人，通常没有检视过此前的那段过程。
你现在这个团队里最难的、你还没有解决的问题是什么？
What a strong answer shows
坦率与自我评估。一个没有未解问题的经理，要么处在异常幸运的处境，要么没有认真看自己手上的这个团队。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 一个正在成长的工程群体，已经超出了原本支撑它的那套安排。发展方面的对话在交付允许时才发生，晋升的期望没有写下来，与其他职能的协作依赖个人关系，而承诺被推迟的原因大多与工程本身无关。
- Approach
- 追加的管理能力完全在客户的组织之内运作——客户的汇报关系、客户的晋升框架、客户的优先级、客户的工程标准。关于绩效、晋升、薪酬与团队结构的决定仍属于客户，所有技术与架构方向也是如此。
- What this adds to the team
- 该组织获得了运营一个团队所需的经验能力，而关于人、结构、产品与技术方向的每一个决定，仍留在客户及其自身的领导层手中。
Related disciplines
Frequently asked questions
- 工程经理与技术负责人有什么区别？
- 他们对同一个团队的不同方面负责。经理回答的是团队如何运转：谁加入、人如何成长、绩效如何处理、工作如何协调、交付能否被依赖。技术负责人回答的是工作的技术实质——它如何被设计、评审，并按一致的标准构建。在较小的组织里，常常由一个人同时承担，这在团队小的时候行得通，随着规模扩大往往会失效，因为两组职责争夺注意力，而紧急的那一组会赢。
- 工程经理与项目经理有什么区别？
- 项目经理对一项界定明确的工作抵达完成负责——范围、进度、依赖、汇报——这份责任随项目结束而结束。工程经理对一个长期存在的团队负责，包括团队里的人，而这不会因为当下在交付什么而改变。项目经理协调工作；工程经理构建并维持那个做工作的能力。
- 工程经理需要懂技术吗？
- 需要足够的技术素养去判断风险、就取舍进行有实质内容的对话、可信地为一次晋升背书，并在团队之外陈述团队的约束。他们不需要是在场技术最强的人，而认为他们应当如此的观念，会造就与自己团队竞争的经理。来自非工程背景的经理在技术决策确实由他人拥有的地方可以做得很好，不过通常需要一位有力的技术搭档，以及对自己无法评估之事的相当程度的谦逊。
- 工程经理还应该写代码吗？
- 在不处于关键路径的工作上写一点，是保持技术素养、并亲历团队所面对的障碍的合理方式。作为一项常规承诺则通常会失败：管理工作可被打断且不可预测，于是代码成了被挤掉的那一项，经理也就成了自己团队的一个不可靠依赖。较安全的形态是：小、可延后、不挡任何人的路。
- 一位经理应该支持多少位工程师？
- 可行的幅度在个位数，并随这个人还承担了多少其他事务而变化。一位同时兼任技术负责人、或者正在支持多位成员经历重要成长、或者承担了大量跨职能协作的经理，会更早触到上限。判断幅度过大的可靠指征不是一个数字，而是一种模式：一对一被取消、反馈被推迟，以及经理从别人那里得知本团队的问题。
- 哪些事情应当留在团队而不是留在经理手里？
- 技术决定、设计方案、估算，以及工作具体如何完成的细节。把这些揽过来的经理，会拿走那份让团队能够在他不在时照常运转的所有权，并制造一个随团队变大而恶化的瓶颈。经理的贡献是确保这些决定由正确的人、在掌握正确信息的情况下做出，并让后果保持可见。
- 工程经理如何与现有的工程团队协作？
- 在贵组织的结构之内，绝不凌驾于其上。当一个岗位通过技术团队扩展的方式补充时，汇报关系、绩效与薪酬决定、晋升、团队结构、优先级与流程仍归贵组织，架构、技术方向与产品所有权同样如此。工作由您的领导层指挥。Talent.ID 只承担雇佣一侧——雇佣关系、薪资发放、员工福利与人才管理，以及与员工之间持续的关系——运营您工程组织的任何部分都不会随之转移。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.