Retaining Developers

Retaining Developers

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it. If a specific person is mentioned, check .agents/reports/[name].md.

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

• Engineer seems disengaged or at risk -> diagnose with The 5 States
• Compensation or raise conversation -> start with Unappreciated -> Valued
• Equity or options conversation at hire, refresh, or departure -> use Stock Options and Equity Conversations
• Want to recognize someone but have no budget -> use Zero-Budget Recognition
• Worried someone might be leaving but has not said anything -> use 5 Warning Signs of a Disengaging Engineer
• Engineer already has another offer -> use When Someone Has Another Offer

---

Default Response Shape

When the user asks for help with retention, produce a practical manager response:

1. Risk read: low / medium / high, with evidence from the prompt.
2. Likely state: unappreciated, lonely, bored, stuck, apathetic, or mixed.
3. What to verify in the next 1:1: 3-5 questions that are direct but not interrogating.
4. Action plan: what to do this week, this month, and structurally.
5. Conversation script: concrete wording the manager can use.
6. What not to do: common overreactions that will make the situation worse.

If someone has already resigned or has another offer, do not pretend normal retention tactics are enough. Shift to: understand the reason, decide if there is a credible counter, treat them respectfully, and protect the relationship.

---

Retention Risk Diagnostic

Use this before choosing an intervention:

• Signal strength: Is this one weak signal, a pattern over weeks, or a direct statement that they may leave?
• State: Which of the five states best explains the behavior?
• Specificity: Can the manager name the exact moment, project, decision, or pattern that caused the shift?
• Agency: Is there something the manager can actually change, or is this outside the manager's control?
• Time horizon: Is the risk immediate, emerging, or long-term?
• Trust level: Will the engineer believe the manager is acting because they care, or only because they are afraid of losing them?

The last question matters. Retention attempts that appear only after someone disengages can feel transactional. Acknowledge that directly when needed.

---

The 5 States

When a developer quits, it is often because they feel one of these five things. Use the inverse to diagnose and act.

---

1. Unappreciated -> Valued

Initial salary is critical. The first salary you offer sets an anchor that is hard to correct later. Underpaying at hire means you will always be playing catch-up. Raises feel like corrections, not rewards, and the gap in perceived appreciation accumulates.

Raise salary before they ask. When a developer has to ask for a raise, the damage is already done. It signals that you were not paying attention or were not advocating for them. Be proactive. Also: do not deny raises because the engineer earns more than you. That is not a competition.

Do not steal the thunder. When something good happens, like a promotion, milestone, or successful launch, let the engineer announce it. Good news should come from them. If you announce their achievements for them, you take the moment; if they announce it themselves, you amplify it.

Just tell them. Many managers recognize good work internally and assume the engineer knows. They often do not. Say it directly in a 1:1: "I wanted to tell you: the way you handled X was exactly what I needed. That made a real difference."

Recognition: Give them the stage. Let them write the Slack announcement for features they shipped, tag them publicly, and push for your people to get company recognition. Route praise through its source: if a VP is excited, ask them to tell the team directly.

---

2. Lonely -> Connected

You cannot force people to connect, but you can create opportunities: team meetings, focus days outside the office, activities during working hours, and shared work that creates real memories.

Be honest in interviews about what your team culture actually looks like. If your team is mostly married with kids and nobody hangs out after work, say so. Do not let someone join expecting something that is not there.

---

3. Bored -> Challenged

The best lever is to delegate interesting tasks: writing technical designs, mentoring a new engineer, leading a cross-team effort, or owning a project area you currently hold.

Ask directly: "Do you feel challenged? What's missing from your work today?" Managers often assume they know what developers want instead of having the conversation.

---

4. Stuck -> Growing

Even challenged developers can feel stuck if they cannot see a path forward. Career planning is your job.

Work through it together:

• What are the requirements for the next level?
• How far are they from it, and why? Be fully honest.
• What tasks do they need to take on to get there?
• What evidence will promotion decision-makers need to see?

If they want a management path and there is no open slot, make them your second-in-command where appropriate and let them experience parts of the work. Help them prepare. Never promise a timeline you do not control.

---

5. Apathetic -> Passionate

When developers do not care about the product or customers, and only care about technical puzzles, engagement is fragile. Connect the team to the business: share customer success stories, bring in senior leaders to talk with the team, and involve developers in customer conversations when possible.

Do not fake passion. Find a real customer, business, craft, or ownership connection that the engineer can actually care about.

---

Stock Options and Equity Conversations

Equity is one of the most misunderstood parts of compensation and one of the most common sources of silent resentment or missed retention opportunities. As EM, you are often the one who has, or can get, the context to have this conversation well.

At Hire

When a developer joins and receives an options grant, three numbers matter and most people do not explain them clearly:

• Exercise price (strike price): What they will pay per share to own it. Set at fair market value on grant date.
• Current price (FMV): What the company is currently worth per share.
• The 10X scenario: What this could be worth if the company grows 10X.

Most people sign offer letters without understanding any of this. Be the person who explains it.