performance-reviews

绩效评估

开始之前

首先检查 EM 上下文：

1. 如果 .agents/em-context.md 存在，请阅读（了解评估周期格式、评级标准等）
2. 如果提到了某个人，请查找 .agents/reports/[name].md——其中包含此人的角色、级别、目标、当前项目和反馈历史
3. 使用这些上下文——只询问尚未涵盖的信息

如果 .agents/em-context.md 不存在，请先询问最基本的经理人资料并保存，然后再提供详细建议：角色/职称、团队规模、团队使命或负责范围，以及当前挑战或优先事项。

如果对话的核心涉及某个特定人员，且 .agents/reports/[name].md 不存在，请先询问该人员的基本资料并保存，然后再提供详细建议：职称/级别、任职时间、优势，以及当前挑战或发展方向。

如果之后的对话透露出持久有效的新上下文，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、短暂的沮丧情绪或尚未解决的解读。

回复风格

首次回复应简洁且有用。除非用户要求深入说明，否则不要一次性给出完整框架。

默认做法：

• 先说明可能的诊断结果或建议
• 仅在缺失的上下文会改变建议时，提出至多 2-3 个有针对性的问题
• 给出下一步具体行动；如有帮助，提供经理可以直接使用的确切措辞
• 简要提及相关框架，但不要逐一解释其所有部分
• 直接回答后，再提出可以进一步展开

---

如何使用此技能

先判断具体情况：

• 团队中有人表现不佳，但不确定原因 → 诊断表现不佳：从左到右逐步排查（从这里开始）
• 已诊断出问题，现在需要处理相关行为 → 处理持续性行为问题的四阶段流程
• 不确定是否容忍表现不佳太久 → 尽早识别表现不佳
• 正在认真考虑解雇某人 → 做出艰难决定 + 何时采取行动
• 撰写或组织自己的经理绩效评估 → 元绩效评估问题

---

默认回复结构

在协助处理绩效问题时，应将诊断与行动分开：

1. 绩效判断： 行为、影响、模式和严重程度。
2. 根本原因假设： 资源、培训、意愿、匹配度或能力。
3. 所需证据： 示例、预期、过往反馈和业务影响。
4. 经理行动： 反馈、支持计划、PIP、晋升理由或离职流程。
5. 措辞： 评估用语或谈话脚本。

不要让同理心导致表达含糊。既要有人情味，也要具体明确。

---

尽早识别表现不佳

最常见的陷阱：把进步和潜力混为一谈。某位工程师从差劲进步到平庸，确实有所进步——但他们仍可能达不到要求。

关键问题不是“他们有没有进步？”而是“他们是否达到了我所需的水平？”

Ray Dalio：“如果某人一直得 30 多分或 40 多分，后来有几个月提高到 50 多分，那么说他们有所进步是准确的——但他们仍然远远不够格。”

为什么经理会容忍表现不佳者太久

1. 情感牵绊——你在这个人身上投入了很多，你喜欢他们，不想伤害他们
2. 沉没成本谬误——你花了几个月培训他们，不想从头再来

这两种情况都是真实存在的，也都会让你自欺欺人，满足于平庸表现。

如何保持客观

• 在问题出现前设定具体预期 — 设定 30/60/90 天目标、值班准备度和项目负责人标准。没有明确的标准，“有所进步”总会显得足够。
• 问自己“如果今天招聘，我还会录用吗？” — 不要问“有他和没他，哪种情况更好？”（这总会让人受到沉没成本的影响。）而要问：“以我现在掌握的信息，我会录用这个人吗？”如果不会，答案就很明确。
• 提前设定检查节点 — 30 天、60 天或周期结束时。设定必须做出决定的节点，可以避免无限期拖延。

保持谦逊

你有时会判断失误。表现不佳的工程师，随着时间推移、环境合适，或找到更适合自己的职位，都可能成为表现出色的人。框架只是指引，不是判决。

---

做出艰难决定：让人离开

在内心深处，你通常早已知道答案。当你开始认真考虑解雇某人时，这件事很可能早就该做了。

如释重负测试： 想象员工告诉你他要辞职。你会如释重负，还是感到难过？如果是如释重负，答案就很明确。

（Netflix 的“留任测试”——你会极力挽留他吗？——是更严格的版本。对大多数团队来说，如释重负测试更现实。）

为什么总是很难

通常有三种情况之一：你招了不适合这个职位的人；你没有给出明确预期或提供足够支持；或者职位发生了变化，他们不再适合这个职位。在这三种情况下，你都对现状负有责任。这就是为什么这件事应该很难，也解释了为什么优秀的管理者也会纠结。

不要把“他们有潜力”和“我无法做出艰难决定”混为一谈。这是两回事。

拖延的代价

• 员工受苦 — 每天来到一份自己做得不好的工作中，会让人筋疲力尽
• 你受苦 — 明知某人无法真正胜任，却仍努力帮助他们做好工作，这会让人心力交瘁
• 团队受苦 — 与表现不佳的人共事会打击士气；等你终于采取行动时，团队几乎总能理解

我还没遇到过后悔解雇某人的管理者，只遇到过后悔拖延的人。

行动之前：先做好这些

要确信在让某人离开之前已经尽力做到位：

1. 立即提供反馈 — 一旦他们偏离正轨，就马上指出。不要等问题累积起来。
2. 具体说明 — 举出问题所在的具体例子，并说明怎样做才更好
3. 让他们复述 — 直到他们说的与你的意思一致为止。人们常以为自己理解了预期，却其实没有。
4. 写下来 — 列出需要改变的事项，做到清晰、可衡量，并让你们双方都能看到
5. 保持耐心 — 改变行为需要付出切实努力，而且往往值得等待。

注意：绩效改进计划中的人员有 50% 会再次表现不佳。聪明的员工知道如何暂时应对，达到要求。留意这种模式。

---

何时采取行动：“尽早解雇”启发式原则

一个粗略但有用的信号：如果你哪怕只认真考虑过一次解雇某人，就很可能应该尽早采取行动。

面对真正优秀的员工，你不会产生这种念头。这个念头一旦出现，本身就说明了问题。

这并不意味着要冲动解雇。而是说：如果你已经开始认真考虑“我是否该让这个人离开”，却迟迟没有行动，就该审视自己为何等待。最常见的原因是不自在，而不是有证据表明情况会自行好转。

---

Meta 绩效评估问题

评估经理绩效最有用的问题是：“如果这个人不在这里，哪些事情会有所不同？”

这关注的是经理带来的增量——不是团队交付了什么，而是经理促成了哪些本来不会发生的事情。也用这个问题来审视自己：你对哪些成果有所贡献，而这些成果是你的团队在没有你的情况下无法取得的？

常见的有效贡献包括：

• 一次改变了某人发展轨迹的艰难对话
• 提高了招聘标准的决策
• 移除了其他人都无法移除的阻碍
• 帮助一个停滞不前的人成长

---

解决持续性行为问题的四阶段流程

对于反复表现出问题行为（不断抱怨、未能兑现承诺、人际关系摩擦）的工程师：

阶段 1——倾听并理解。 尽你所能去了解这种行为背后的原因。其背后几乎总有某种合理的不满。不要跳过这一步——直接说“别再做 X”会忽视其中的信号。

阶段 2——解决根本原因。 找出 1–2 个最重要的潜在问题，并与对方合作加以解决。这意味着要真正解决问题，而不只是表示理解。

阶段 3——讨论行为本身。 解决根本原因后，明确沟通行为需要如何改变：哪些可以接受，哪些不可接受，以及今后的期望是什么。

阶段 4——让他们离开。 如果完成阶段 1–3 后，行为仍然持续，那就是一种选择，而不是客观情况所致。采取行动。

失败的做法是跳过阶段。没有完成阶段 1–2 的经理，不应以可信的方式与员工进行阶段 3 的对话。

---

诊断表现不佳：从左到右依次排查

在决定“提升或淘汰”之前，按顺序排查以下各项。从左向右，责任逐渐从你转移到员工身上：

1. 资源——他们是否拥有所需的一切？访问权限、软件、工具、支持。如果没有，这完全是你的问题。在对他们下任何结论之前先解决。
2. 培训——他们是否具备胜任工作所需的知识？这是共同责任：你要确保他们能够获得培训；他们要负责利用培训。避免陷入无穷无尽的培训陷阱——目标是足够，而非面面俱到。
3. 意愿——他们是否真的愿意做这份工作？这是最难进行的对话，对他们而言也关乎切身利益。如果你从第一天起就明确了期望，而他们仍不愿达到这些要求，那就由他们自己负责。你可以支持他们，也可以指导他们——但你不能替他们产生意愿。
4. 匹配度——这个职位是否适合发挥他们的优势？一个人可能很有才华，却仍不适合这份特定的工作。
5. 能力——他们是否具备达到要求水平的基本能力？

多数表现不佳的诊断都会直接跳到第 3 或第 5 项，而不处理第 1 和第 2 项。这是个错误：它回避了经理的责任，损害信任，也会削弱绩效案例。

---

深入了解

如果用户询问某个框架的来源、想阅读原文，或想了解任何主题的更多背景信息，请阅读 references/sources.md，其中列出了所有来源文章（含链接）和书籍。

---

相关技能

• feedback——及时、具体的反馈是做好这一切的前提
• hiring——设定明确的期望要从招聘时开始