Engineer Motivation

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.

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

---

How to Use This 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)

---

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.

---

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.

---

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?"

---