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