Back to Details

engineer-motivation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Engineer Motivation

工程师动机

Before Starting

开始之前

Check for EM context first. If 
.agents/em-context.md
exists, read it. If a person is mentioned, check 
.agents/reports/[name].md
— it may contain their motivation profile.
If 
.agents/em-context.md
does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and 
.agents/reports/[name].md
does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update 
.agents/em-context.md
or 
.agents/reports/[name].md
automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先检查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
。仅保存稳定的事实和模式，不要保存猜测内容、暂时的挫败感或未明确的解读。

Response Style

回应风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
  • State the likely diagnosis or recommendation first
  • Ask at most 2-3 targeted questions only if the missing context changes the advice
  • Give the next concrete action and, when useful, exact wording the manager can use
  • Mention the relevant framework briefly, but do not explain every part of it
  • Offer a deeper version only after the direct answer
首次回答要简洁实用。除非用户要求深入讲解，否则不要全盘输出整个框架。
默认遵循以下原则：
  • 先说明可能的诊断结果或建议
  • 仅当缺失的背景信息会影响建议时，提出最多2-3个针对性问题
  • 给出具体的下一步行动，必要时提供经理可直接使用的话术
  • 简要提及相关框架，但无需解释每个部分
  • 仅在给出直接回答后，再提供深入版本的内容

How to Use This Skill

如何使用本Skill

  • Don't know what drives someone / need to figure out their driver → How to Identify Someone's Driver
  • Know their driver, want to delegate something that sticks → Driver-Aligned Delegation
  • Looking for specific activity ideas for a specific engineer → read 
    references/activities.md
  • Thinking about hiring or team composition → Team Composition
  • Your own driver is bleeding into how you manage everyone → The 3 Drivers (the common EM mistake)
  • 不清楚某人的动力来源/需要确定其驱动因素 → 参考《如何识别员工的驱动因素》
  • 已知其驱动因素，希望委派能让他们投入的任务 → 参考《匹配驱动因素的委派》
  • 为特定工程师寻找具体的活动建议 → 阅读
    references/activities.md
  • 考虑招聘或团队构成 → 参考《团队构成》
  • 自身的驱动因素影响了对团队的管理方式 → 参考《三驱动框架（EM常见误区）》

Default Response Shape

默认回应结构

When diagnosing motivation, avoid generic "motivate them" advice:
  1. Likely driver: Growth, Connection, Impact, or mixed, with evidence.
  2. Signals to verify: what to ask or observe before acting.
  3. Matching intervention: delegation, activity, visibility, customer context, or relationship-building.
  4. Mismatch risk: what would demotivate this person if the manager assumes wrong.
  5. Next 1:1 script: a short way to test the hypothesis with the engineer.
If the person may be actively leaving, switch to 
retaining-developers
rather than treating it as ordinary motivation.
诊断动机时，避免使用“激励他们”这类通用建议：
  1. 可能的驱动因素：Growth、Connection、Impact，或混合类型，并附上依据。
  2. 需验证的信号：行动前需要询问或观察的内容。
  3. 匹配的干预措施：委派任务、活动安排、曝光机会、客户背景介绍，或关系构建。
  4. 匹配错误的风险：如果经理判断错误，会让该员工失去动力的行为。
  5. 下一步1对1沟通脚本：用于向工程师验证假设的简短话术。
如果员工可能正准备离职，请切换至
retaining-developers
工具，而非将其视为普通的动机问题处理。

The 3 Drivers

三驱动框架

The most powerful frame for understanding what motivates a software engineer:
Growth — This person wants to be challenged, grow their skills, and advance their career. They hate boring or repetitive work. They're energized by new technical problems, learning opportunities, and a clear promotion path.
Connection — This person gets their energy from relationships. They can stay in the same company for years primarily because of the people. Isolation drains them. They're energized by collaboration, team events, mentoring, and building relationships across the org.
Impact — This person cares about what the company does and whether it matters. They want to see features actually used, be close to customers, and understand how their work moves business metrics. They'll do unglamorous work without complaint if it clearly helps the business.
All people have a little of all three, but most have one primary driver and possibly a secondary.
The common EM mistake: defaulting to your own driver when supporting your team. Growth-focused EMs fight for promotions and challenging work for everyone. Impact-focused EMs connect everyone to metrics. Connection-focused EMs organize events for everyone. Good EMs manage across all three — including drivers that don't come naturally to them.
理解软件工程师动机最有效的模型：
Growth — 这类员工渴望挑战、提升技能并推进职业发展。他们厌恶枯燥或重复性工作。新的技术问题、学习机会和清晰的晋升路径能让他们充满活力。
Connection — 这类员工从人际关系中获取能量。他们可能因为团队成员而在同一家公司待很多年。孤立会让他们感到疲惫。协作、团队活动、指导他人以及跨部门建立关系能让他们充满活力。
Impact — 这类员工关心公司的业务及其意义。他们希望看到自己开发的功能被实际使用，贴近客户，并了解自己的工作如何推动业务指标。如果某项工作能明确帮助业务发展，即使是乏味的工作他们也会毫无怨言地完成。
所有人都会受到这三个因素的影响，但大多数人有一个主要驱动因素，可能还有一个次要驱动因素。
EM常见误区：用自身的驱动因素来管理整个团队。关注Growth的EM会为所有人争取晋升机会和有挑战性的工作；关注Impact的EM会让所有人都对接业务指标；关注Connection的EM会为所有人组织活动。优秀的EM会兼顾这三种驱动因素——包括那些自己不具备的类型。

How to Identify Someone's Driver

如何识别员工的驱动因素

Watch how they respond to different things:
  • Do they light up when you talk about a promotion path or a new technical challenge? → Growth
  • Do they mention teammates by name, care about team dynamics, and thrive in collaborative settings? → Connection
  • Do they ask about customers, usage, and business outcomes? Do they take on unglamorous work without complaint? → Impact
When unsure, ask: "Which would you prefer — a project that pushes your technical skills in a new direction, one where you'd work closely with a lot of people across the org, or one that directly solves a major pain point for customers?"
观察他们对不同事物的反应：
  • 当你谈论晋升路径或新的技术挑战时，他们是否很兴奋？→ Growth
  • 他们是否经常提及队友、关心团队动态，并在协作环境中表现出色？→ Connection
  • 他们是否询问客户、产品使用情况和业务成果？是否会毫无怨言地承担乏味的工作？→ Impact
如果不确定，可以问：“以下三个选项你更偏好哪一个——能让你在新技术领域提升技能的项目、需要跨部门与大量人员紧密协作的项目，还是能直接解决客户核心痛点的项目？”

Driver-Aligned Delegation

匹配驱动因素的委派

This is the biggest unlock for freeing your time as EM.
When you delegate something that doesn't align with someone's driver, it doesn't stick. They procrastinate, you nag, they finish it reluctantly, and you follow up again next week. When delegation aligns — it sparks.
"Every task you don't like can be a growth opportunity for someone else."
Examples:
  • Sending a Growth-driven engineer to represent the team in technical architecture reviews they care about — they come alive; you get a free hour.
  • Assigning a Connection-driven engineer to mentor a new hire or organize team events — they love it; you stop feeling guilty about it.
  • Inviting an Impact-driven engineer to customer calls or giving them access to usage metrics — they become passionate about work that felt like overhead to others.
This is particularly powerful for tech debt: frame it as the business problem it solves, and assign it to an Impact-driven engineer who wants to see the metrics improve.
这是帮助EM节省时间的关键方法。
当你委派的任务与员工的驱动因素不匹配时，他们不会投入。他们会拖延，你需要反复催促，他们勉强完成后，下周你还得跟进。而当任务与驱动因素匹配时——他们会充满热情。
“你不喜欢的每一项任务，对别人来说都可能是成长机会。”
示例：
  • 让关注Growth的工程师代表团队参与他们关心的技术架构评审——他们会充满活力，你则能腾出一小时时间。
  • 让关注Connection的工程师指导新员工或组织团队活动——他们会乐在其中，你也不必再为此事感到愧疚。
  • 邀请关注Impact的工程师参与客户沟通会议，或为他们提供产品使用数据——他们会对之前在别人看来是负担的工作充满热情。
这一点在处理技术债务时尤为有效：将其包装成能解决的业务问题，分配给关注Impact的工程师，他们会希望看到相关指标得到改善。

Activity Ideas by Driver

按驱动因素划分的活动建议

A few vivid examples per driver — for the full list of specific individual-scope activities, read 
references/activities.md
.
Growth: Give them a technical kingdom (full ownership of a system, including PM relationship and tech debt prioritization). Assign them to lead a long-term tech initiative that they identified as painful. Help them write a real technical article — not AI-generated, but a deep dive into something they actually solved.
Connection: Assign them to onboard a new engineer (you keep the 1:1s, they handle everything else). Have them lead a retrospective — connection-driven engineers usually know what frustrated teammates better than you do.
Impact: Invite them to a customer call or business meeting — ask privately in a 1:1 so there's no pressure. Share deeper business context in 1:1s: metrics, the sales pipeline, the real stakes behind what the team is building.
每个驱动因素下提供几个生动的示例——完整的个人层面活动列表请阅读
references/activities.md
。
Growth：让他们负责一个“技术领地”（全权负责某个系统，包括与PM对接和技术债务优先级排序）。分配他们牵头一项由自己提出的长期技术改进计划。帮助他们撰写一篇真正的技术文章——不是AI生成的，而是深入讲解他们实际解决的问题。
Connection：安排他们负责新员工的入职培训（你负责1对1沟通，其他事务由他们处理）。让他们主持回顾会议——关注Connection的工程师通常比你更了解队友的不满之处。
Impact：邀请他们参与客户沟通会议或业务会议——在1对1沟通中私下邀请，避免给他们压力。在1对1沟通中分享更深入的业务背景：指标、销售渠道、团队所做工作背后的实际利害关系。

Team Composition

团队构成

Every team needs all three driver types to be effective long-term.
A team entirely of Growth drivers is technically sharp but often disconnected and may not care whether features get used. A team of all Impact drivers ships things but can drift technically. A team of all Connection drivers builds great culture but may lack urgency.
When thinking about hiring, check which driver type is underrepresented. If everyone eats lunch at their desk alone — it's worth bringing in someone more outgoing. If nobody asks about business outcomes — look for an Impact-driven engineer.
The drivers coexist fine. In practice, mixing them creates teams where someone naturally picks up the work that feels like a chore to others.
长期来看，高效的团队需要包含所有三种驱动类型的成员。
全部由Growth驱动型成员组成的团队技术能力出众，但往往缺乏凝聚力，可能不关心功能是否被使用。全部由Impact驱动型成员组成的团队能交付成果，但技术层面可能会逐渐落后。全部由Connection驱动型成员组成的团队文化氛围很好，但可能缺乏紧迫感。
考虑招聘时，检查哪种驱动类型的成员在团队中占比不足。如果所有人都独自吃午餐——值得招聘一位更外向的成员。如果没人关心业务成果——寻找关注Impact的工程师。
不同驱动类型的成员可以共存。实际上，混合搭配能让团队中有人自然承担那些对其他人来说是负担的工作。

Dive Deeper

深入了解

If the user asks where a framework came from or wants more context — read 
references/sources.md
. For a full list of individual-scope activity ideas organized by driver, read 
references/activities.md
.
如果用户询问框架的来源或需要更多背景信息——阅读
references/sources.md
。按驱动因素分类的完整个人层面活动列表，请阅读
references/activities.md
。

Related Skills

相关Skills

  • delegation
    — Driver-aligned delegation is the primary mechanism for acting on this
  • retaining-developers
    — The 5 reasons engineers quit often map to an unmet primary driver
  • managing-high-performers
    — High performers have driver needs too, but with additional complexity
  • 1on1s
    — The place to surface and update your understanding of someone's driver
  • hiring
    — Use driver balance to assess what your team is missing
  • delegation
    — 匹配驱动因素的委派是落实本工具的主要机制
  • retaining-developers
    — 工程师离职的5个常见原因通常与主要驱动因素未被满足有关
  • managing-high-performers
    — 高绩效工程师也有驱动因素需求，但情况更为复杂
  • 1on1s
    — 这是了解和更新员工驱动因素认知的场景
  • hiring
    — 利用驱动因素平衡评估团队的缺口