mcpField
R
retaining-developers

retaining-developers

github.com/manager-dot-dev其他116119 次安装25 周前更新
代码仓库

关于 retaining-developers

面向工程经理的开发者留任指导技能,通过识别员工状态与风险信号,帮助经理核实离职原因并制定具体行动。内容涵盖认可、成长、薪酬权益沟通及收到外部聘用时的应对。

主要功能

  1. 01诊断留任风险与员工状态
  2. 02识别脱离投入的早期信号
  3. 03规划认可、挑战与成长机会
  4. 04指导薪酬及股权沟通
  5. 05处理员工收到外部聘用的情形

适用场景

  1. 01员工参与度下降时准备一对一沟通
  2. 02为开发者设计成长或认可措施
  3. 03讨论期权、加薪或离职选择
  4. 04评估是否对外部聘用提出反建议

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/manager-dot-dev/manager-skills --skill retaining-developers

安装后在 Claude Code 中输入/retaining-developers确认已加载。

附带文件references/sources.md

详细介绍

留住开发人员

开始之前

首先检查是否有 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 个有针对性的问题
  • 给出下一步具体行动,并在有帮助时提供经理人可直接使用的确切措辞
  • 简要提及相关框架,但不要解释每个部分
  • 先给出直接答复,再提供更深入的版本

如何使用此技能

  • 工程师似乎失去投入或有离职风险 -> 使用「5 种状态」进行诊断
  • 薪酬或加薪对话 -> 从「未受重视 -> 受到认可」入手
  • 入职、股权刷新或离职时讨论股权或期权 -> 使用「股票期权与股权对话」
  • 想认可某人,但没有预算 -> 使用「零预算认可」
  • 担心某人可能要离开,但对方尚未明说 -> 使用「工程师失去投入的 5 个预警信号」
  • 工程师已经有了其他录用机会 -> 使用「有人收到其他录用机会时」

默认回复结构

用户寻求留人方面的帮助时,给出实用的经理人应对方案:

  1. **风险评估:**低/中/高,并列出提示中的依据。
  2. **可能的状态:**未受重视、孤立、厌倦、受阻、漠不关心,或多种状态交织。
  3. **下次 1:1 要核实的事项:**提出 3-5 个直接但不带审问意味的问题。
  4. **行动计划:**说明本周、本月以及结构层面要做什么。
  5. **对话脚本:**提供经理人可直接使用的具体措辞。
  6. **避免的做法:**指出会让情况恶化的常见过度反应。

如果有人已经辞职或另有录用机会,不要假装常规留人手段就足够。应转而:了解原因、决定是否有可信的反报价、尊重地对待对方,并维护双方关系。


留人风险诊断

选择干预措施前,先使用以下诊断:

  • **信号强度:**这是一个微弱信号、持续数周的模式,还是对方明确表示可能离开?
  • **状态:**五种状态中,哪一种最能解释其行为?
  • **具体性:**经理人能否指出导致变化的确切时刻、项目、决定或模式?
  • **可控性:**经理人实际能改变什么,还是这超出了经理人的控制范围?
  • **时间范围:**风险是迫在眉睫、正在显现,还是长期性的?
  • **信任程度:**工程师会相信经理人这么做是因为在乎他们,还是只因为担心失去他们?

最后一个问题很重要。有人失去投入后才开始尝试留人,可能会让人觉得这是利益交换。必要时,应当直接承认这一点。


5 种状态

开发者离职,往往是因为他们有以下 5 种感受之一。用其反面来判断并采取行动。

他们的感受他们的需求
不受重视感到自己有价值
孤独感到有所联结
无聊感到有挑战
停滞不前感到自己在成长
漠不关心对工作充满热情

1. 不受重视 -> 感到有价值

起薪至关重要。 你提供的第一份薪资会形成一个很难在之后调整的基准。入职时薪资过低,意味着你之后总要努力追赶。加薪听起来像是在纠正错误,而不是给予奖励,而且对方感受到的认可差距会不断累积。

在他们提出要求前加薪。 当开发者不得不开口要求加薪时,伤害已经造成。这表明你没有留意他们的情况,或者没有为他们争取。要主动一些。另外,不要因为工程师赚得比你多就拒绝给他们加薪。这不是一场竞争。

不要抢走风头。 有好事发生时,比如晋升、达成里程碑或成功发布产品,让工程师自己宣布。好消息应该由他们亲自分享。如果你替他们宣布成就,就抢走了属于他们的时刻;如果由他们自己宣布,你就是在为他们扩大声势。

直接告诉他们。 许多经理会在心里认可出色的工作,并以为工程师知道这一点,但他们往往并不知道。在 1:1 谈话中直接说:“我想告诉你:你处理 X 的方式正是我需要的。这确实带来了很大的影响。”

认可: 给他们展示自己的机会。让他们撰写自己发布的功能的 Slack 公告,在公开场合标记他们,并积极争取让团队成员获得公司认可。让赞扬由发出赞扬的人亲自传达:如果副总裁很欣赏他们,就请副总裁直接告诉团队。


2. 孤独 -> 感到有所联结

你无法强迫人们建立联结,但可以创造机会:团队会议、在办公室外安排专注日、工作时间内的活动,以及能留下真实共同回忆的协作工作。

面试时,要如实介绍团队的真实文化。如果你的团队大多数人已婚并有孩子,而且没人下班后聚会,就直说。不要让人加入团队时误以为这里有实际上并不存在的氛围。


3. 无聊 -> 感到有挑战

最有效的方法是委派有意思的任务:撰写技术设计、指导新工程师、牵头跨团队工作,或负责你目前掌管的某个项目领域。

直接问:“你觉得工作有挑战性吗?你现在的工作还缺少什么?”经理常常以为自己知道开发者想要什么,却没有真正和他们沟通。


4. 停滞不前 -> 成长

即使开发者面临挑战,如果看不到前进的道路,也会感到停滞不前。职业规划是你的职责。

一起梳理以下问题:

  • 晋升到下一级别需要满足什么条件?
  • 他们距离目标还有多远,原因是什么?要完全坦诚。
  • 他们需要承担哪些任务才能达到目标?
  • 晋升决策者需要看到哪些证据?

如果他们希望走管理路线,但目前没有空缺,在合适的情况下让他们担任你的副手,并让他们体验部分管理工作。帮助他们做好准备。绝不要承诺你无法掌控的时间安排。


5. 漠不关心 -> 充满热情

如果开发者不关心产品或客户,只对技术难题感兴趣,他们的投入就很脆弱。让团队了解业务:分享客户成功案例,请高级领导与团队交流,并尽可能让开发者参与客户沟通。

不要假装有热情。找到工程师真正关心的客户、业务、专业技艺或所有权方面的联结。


股票期权与股权对话

股权是薪酬中最容易被误解的部分之一,也是最常引发无声怨恨或错失留才机会的因素之一。作为 EM,你往往掌握相关背景,或者能够获取这些信息,从而妥善地展开这类对话。

入职时

开发者加入公司并获得期权授予时,有三个重要数字,但大多数人都不会把它们解释清楚:

  • 行权价(执行价): 他们为获得每股股票需要支付的价格。该价格按授予日的公平市场价值设定。
  • 当前价格(FMV): 公司目前每股的价值。
  • 10 倍情景: 如果公司增长 10 倍,这些期权可能值多少。

大多数人签署聘用信时,并不明白这些。做那个愿意解释清楚的人。

任职期间

追加授予是常见但未被充分利用的留才工具。经过一两年的出色表现后,开发者最初获得的期权大多已归属,“金手铐”的约束也随之减弱。追加授予能重新确立留任价值,并表明你愿意长期投资于他们。

如果公司设有追加授予计划,就主动使用。不要等开发者开口要求,或开始面试时才采取行动。

离职时

有人离职时,常见的情况有三种,每种情况都需要不同的沟通方式:

  1. 离开初创公司,前往更大的公司: 他们可能会放弃尚未归属的股权。帮助他们了解自己将要放弃什么。
  2. 在流动性事件发生前离职: 大多数期权会在离职后 90 天到期。如果他们持有价内期权,可能需要决定是否行权并支付相关费用。
  3. 长期任职后离职: 如果大多数期权都已归属,财务状况会更明朗,但仍值得一起梳理。

这些沟通不是为了强行挽留员工,而是为了尊重他们,确保他们了解自己的财务状况。


零预算认可

一些最令人难忘的认可时刻不需要花一分钱。以下是一些行之有效的具体做法:

创意入职欢迎。 新开发者加入时,发送一份介绍他们的专属团队简报。介绍他们的背景、关心的事情以及一个有趣的事实。这传达出他们作为一个人很重要,而不只是一个资源。

实体晋升仪式。 开发者晋升时,不要只在 Slack 上发布消息。订制一块印有他们新头衔的实体铭牌,亲自颁发或寄给他们。这个实物能让这一刻变得真实。

生日小组件。 在工程仪表板或状态页上添加团队成员的生日。当某人的生日出现在团队整天盯着看的 Grafana 屏幕上时,就会成为一个虽小却令人注意的时刻。

与高层领导的惊喜交流。 安排一场 30 分钟的轻松交流,让表现出色的开发者与他们平时不会接触到的副总裁或高级领导聊一聊。不是做演示,只是交谈。它传达的信息是:高层也看到了你的表现。

个性化赠书。 发现开发者正为某个问题苦恼时,送他们一本相关的书,并附上一张亲笔便条。这是在说:“我足够留心,知道你正在做什么。”


工程师开始失去投入度的 5 个警示信号

等到有人递交辞呈时,你通常已经错过了数周甚至数月前出现的信号。留意以下情况:

  1. 他们不再在架构会议上发表意见
  2. 他们不再推动改进实践
  3. 文档工作停滞
  4. 技术债工单不断被降低优先级,他们却不再提出意见
  5. 站会汇报变得越来越简短、机械

单独出现时,每个信号都可能毫无意义。但如果同时出现,往往说明某人心里已经接受了另一份工作邀约,只是在等正式文件。


当有人拿到另一份工作邀请时

放慢节奏。不要立刻问:“要怎样才能留住你?”这会让关系显得纯粹是交易。

按以下顺序处理:

  1. 了解情况:“是什么让你开始找工作?”以及“你觉得这份新工作提供了什么,而你在这里却得不到?”
  2. **确认是否可行:**你能真正改变根本原因,还是只能暂时补救?
  3. **决定是否提出挽留方案:**只有在解决办法真实、迅速,且对团队其他成员公平时,才提出挽留方案。
  4. **维护关系:**如果对方要离开,就让离职过程保持尊重。离职员工关系很重要。

如果根本原因是感到无聊、停滞不前或薪酬问题,只有在你能采取切实行动时,挽留方案才可能奏效。如果根本原因是缺乏信任、冷漠或长期被忽视,那么挽留方案往往只会推迟辞职。


不要这样做

  • 对方需要具体认可、薪酬调整或成长机会时,不要只给出笼统的赞扬。
  • 不要创造没有实际职责范围或决策权的虚假成长机会。
  • 不要因为有人要离开而让对方感到内疚。这会让团队其他成员觉得坦诚并不安全。
  • 不要承诺你无法掌控的晋升时间表。
  • 如果眼下已经存在留任风险,不要等到年度评估周期再处理。

最后的提醒

并非所有事情都由你掌控。有人会收到你无法匹配的工作邀请,想换领域、创业或搬迁。到了分别的时候,请好聚好散。不要往心里去。


深入了解

如果用户询问某个框架的出处、想阅读原文或想了解更多背景,请阅读 references/sources.md。


相关技能

  • engineer-motivation - 三大驱动因素框架有助于在员工失去投入之前,了解每个人的动力来源
  • managing-high-performers - 高绩效员工有特定的留任风险:感到无聊、停滞不前、倦怠
  • delegation - 委派有挑战性的工作是留任手段之一
  • 1on1s - 用于判断某人处于五种状态中的哪一种
  • team-health - 更广泛的团队信号通常与这五种状态相对应

评论

支持 Markdown