engineer-motivation

工程师动机

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请阅读。如果提到了某个人，请检查 .agents/reports/[name].md——其中可能包含此人的动机档案。

如果 .agents/em-context.md 不存在，请先询问并保存最精简的管理者档案，再提供详细建议：职位／头衔、团队规模、团队使命或负责范围，以及当前挑战或优先事项。

如果对话的核心涉及某个特定人员，且 .agents/reports/[name].md 不存在，请先询问并保存此人的最精简档案，再提供详细建议：职称／级别、任职时间、优势，以及当前挑战或成长方向。

如果之后的对话透露了持久有效的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、短暂的挫败情绪或尚无定论的解读。

回复风格

第一条回复要简洁实用。除非用户要求深入说明，否则不要一次性倾倒整套框架。

默认做法：

• 先说明可能的诊断或建议
• 只有当缺失的背景信息会影响建议时，才提出最多 2-3 个有针对性的问题
• 给出下一步的具体行动；有帮助时，提供管理者可以直接使用的措辞
• 简要提及相关框架，但不要解释每个部分
• 先直接回答，再提出可以提供更深入的版本

---

如何使用此技能

• 不知道什么能驱动某个人／需要找出对方的驱动力 → 如何识别某人的驱动力
• 知道对方的驱动力，想委派能让对方投入的工作 → 与驱动力匹配的委派方式
• 想为某位特定工程师寻找具体活动点子 → 阅读 references/activities.md
• 考虑招聘或团队构成 → 团队构成
• 你自己的驱动力正在影响你管理所有人的方式 → 三种驱动力（EM 常见错误）

---

默认回复结构

诊断动机时，避免给出泛泛的“激励他们”建议：

1. 可能的驱动力： 成长、连接、影响力或混合型，并说明依据。
2. 需要核实的信号： 行动前要询问或观察什么。
3. 匹配的干预方式： 委派、活动、曝光度、客户背景信息或关系建立。
4. 不匹配的风险： 如果管理者判断有误，什么可能会让此人失去动力。
5. 下一次 1:1 的沟通脚本： 简短说明如何与工程师验证这一假设。

如果此人可能正在积极考虑离职，请改用 retaining-developers，不要把这当作普通的动机问题处理。

---

三种驱动力

理解什么能激励软件工程师，最有力的框架是：

成长——此人希望接受挑战、提升技能并推进职业发展。他们厌恶无聊或重复性的工作。新的技术难题、学习机会和明确的晋升路径会让他们充满干劲。

连接——此人的动力来自人际关系。他们可能主要因为同事而在同一家公司待上多年。孤立会消耗他们的精力。协作、团队活动、指导他人以及在组织内建立关系会让他们充满干劲。

影响力——此人关心公司所做的事情，以及这些事情是否有意义。他们希望看到功能真正被使用、贴近客户，并了解自己的工作如何影响业务指标。如果能明确帮助业务，他们也会毫无怨言地承担不起眼的工作。

每个人都或多或少具备这三种驱动力，但大多数人都有一种主要驱动力，可能还会有一种次要驱动力。

EM 常见错误： 在支持团队时，默认套用自己的驱动力。注重成长的 EM 会为所有人争取晋升机会和挑战性工作。注重影响力的 EM 会让所有人关注业务指标。注重连接的 EM 会为所有人组织活动。优秀的 EM 会兼顾这三种驱动力，包括那些自己并不擅长理解的驱动力。

如何识别某人的驱动力

留意他们对不同事物的反应：

• 谈到晋升路径或新的技术挑战时，他们会不会眼前一亮？→ 成长
• 他们会不会直呼队友的名字、在意团队氛围，并在协作环境中如鱼得水？→ 联结
• 他们会不会询问客户、使用情况和业务成果？会不会毫无怨言地承担不起眼的工作？→ 影响

如果不确定，可以问：“你更愿意做哪种项目——拓展新技术能力的项目、能与组织内许多人密切合作的项目，还是能直接解决客户重大痛点的项目？”

---

与驱动力匹配的委派

这是作为工程经理（EM）腾出时间最有效的方法。

如果你委派的工作与某人的驱动力不匹配，事情就不会顺利推进。他们会拖延，你会催促，他们勉强完成，而你下周还得再次跟进。委派与驱动力匹配时——就能激发动力。

“每一项你不喜欢的任务，都可能成为别人的成长机会。”

示例：

• 让成长型工程师代表团队参加他们感兴趣的技术架构评审——他们会精神焕发；你也能腾出一小时。
• 让联结型工程师指导新员工或组织团队活动——他们乐在其中；你也不必再为这些事感到内疚。
• 邀请影响型工程师参加客户电话会议，或让他们查看使用指标——他们会对那些让别人觉得只是额外负担的工作充满热情。

这对技术债尤其有效：把它描述为它能解决的业务问题，再交给希望看到指标改善的影响型工程师。

---

按驱动力划分的活动创意

每种驱动力都有几个生动示例——如需查看针对个人职责的具体活动完整列表，请阅读 references/activities.md。

成长： 给他们一块技术领地（全面负责一个系统，包括与产品经理协作以及确定技术债的优先级）。安排他们牵头负责一项长期技术计划，解决他们自己发现的痛点。帮助他们撰写真正的技术文章——不是 AI 生成的，而是深入剖析他们实际解决的问题。

联结： 让他们负责新工程师的入职培训（你继续负责 1:1 沟通，他们处理其他所有事项）。让他们主持回顾会——联结型工程师通常比你更清楚队友的不满之处。

影响： 邀请他们参加客户电话会议或业务会议——在 1:1 沟通中私下询问，避免给他们压力。在 1:1 沟通中分享更深入的业务背景：指标、销售管道，以及团队正在构建的东西背后真正的利害关系。

---

团队构成

从长远来看，要让团队保持高效，就需要涵盖这三种驱动力。

全由成长型成员组成的团队技术能力很强，但往往与他人脱节，也可能不关心功能是否有人使用。全由影响型成员组成的团队能交付成果，但技术方向可能逐渐偏离。全由联结型成员组成的团队文化出色，但可能缺乏紧迫感。

考虑招聘时，看看哪种驱动力类型代表不足。如果每个人都独自坐在工位上吃午饭——值得考虑招一位更外向的人。如果没人询问业务成果——就寻找一位影响型工程师。

这些驱动力可以很好地共存。在实践中，将他们组合起来，能让团队中总有人自然而然地接手那些其他人觉得麻烦的工作。

---

深入了解

如果用户询问某个框架的来源或希望了解更多背景——请阅读 references/sources.md。如需查看按驱动力整理的个人职责活动创意完整列表，请阅读 references/activities.md。

---

相关技能

• delegation — 与驱动因素相契合的授权，是采取行动的主要机制
• retaining-developers — 工程师离职的 5 个原因通常对应未满足的主要驱动因素
• managing-high-performers — 高绩效者也有驱动因素需求，但情况更复杂
• 1on1s — 了解并更新你对某人驱动因素认知的场合
• hiring — 利用驱动因素平衡来评估团队缺少什么