如何处理团队中表现不佳的成员？

考察要点

这道题旨在考察你作为领导者的成熟度，具体评估你是否能够公平、果断且富有同情心地处理棘手的团队人事问题。

对于 Amazon，这道题重点考察以下 Leadership Principles (LP)：

1. Hire and Develop the Best: 考察你如何识别绩效差距，并投入精力去培养和发展员工。同时也考察当发展无效时，你如何有勇气“Raise the Bar”。
2. Earn Trust: 你是否能与员工进行坦诚、直接且富有建设性的沟通，即使在困难时期也能保持信任。
3. Deliver Results: 识别并解决团队中的短板，以确保整个团队能够持续交付高质量的结果。

高分示范答案（STAR）

Situation（背景） 在 2021 年，我担任某电商公司推荐算法团队的 Engineering Manager，团队有 8 名工程师。我们负责为首页信息流提供个性化推荐服务，这是一个 QPS 高达 10 万的核心系统。当时，团队里有一位叫李雷的工程师，入职半年，表现一直未达到预期。

Task（任务） 李雷负责的模块，在连续两个迭代周期（一个月）内都未能按时交付，并且他提交的代码引起的线上告警次数是团队平均水平的 3 倍。我的任务是，必须在下一个季度（3 个月）内，明确诊断出问题根源，并帮助他将性能提升到团队基线水平（即：迭代任务按时完成率 >90%，代码 bug 率降低 50%），或者做出对他和团队都更负责任的决定。

Action（行动） 我采取了分阶段、有记录的系列行动，而不是直接下结论：

• 第一步：数据收集与诊断 (I did my homework)。我没有立即找他谈话施压。相反，我花了一周时间，系统性地收集客观数据。我 review 了他过去所有的代码提交，发现他的问题主要在于对我们自研的分布式机器学习框架理解不深，导致代码逻辑复杂、缺乏健壮性。我还和他合作过的两位同事进行了 1-on-1 沟通，确认了他存在技术卡点但羞于求助的情况。

• 第二步：坦诚沟通与共建计划 (I created a safe space)。我把他约到咖啡厅，在一个轻松的环境下，首先肯定了他积极的工作态度，然后直接、坦诚地展示了我收集到的数据（迭代延期天数、线上告警截图等），并询问他自己的看法。他承认了在技术上的确遇到了困难，感觉压力很大。基于此，我和他共同制定了一个为期 6 周的“绩效提升计划”（Performance Improvement Plan, PIP），这更像一个辅导计划。

• 第三步：投入资源与高频跟进 (I invested my own time)。这个计划不是扔给他了事。我为他安排了团队里最资深的工程师作为他的“技术伙伴”，每周进行两次、每次一小时的结对编程。我自己则将我们的 1-on-1 频率从每两周一次提升到每周一次，专门跟进计划的进展，并帮他拆解下一个迭代任务，确保他能小步快跑。我甚至亲自和他一起 review 了一个关键模块的代码，向他演示如何更好地做系统设计。

• 第四步：评估结果与艰难决策 (I made the tough call)。在 6 周计划的末期，尽管他的态度非常积极，代码质量也有所改善，但他的产出速度和独立解决复杂问题的能力，仍远未达到团队的平均水准。他自己也感到非常吃力。在与 HR 和我的上级总监沟通后，我做出了艰难但必要的决定。我在最后一次 1-on-1 中，再次回顾了我们共同制定的目标和过去 6 周的努力，坦诚地告诉他，目前这个岗位可能确实不适合他，并和他一起探讨了更适合他技能背景的职业方向（例如测试开发或数据分析）。

Result（结果） 最终，我们以一种相互尊重的方式结束了雇佣关系，他本人也表示理解。这次经历带来了几个正向结果：

1. 团队影响: 在我们重新招聘到合适人选后，团队的迭代交付速度在接下来一个季度提升了约 20%，线上问题率下降了 30%。更重要的是，团队其他成员看到了公司对待绩效问题的公平、透明和严肃的态度，高绩效员工的士气得到了提振。
2. 个人成长: 这件事让我深刻理解到，作为管理者，既要有帮助员工成长的耐心和投入，也要有为了团队整体利益而做出艰难决定的勇气。这个结构化的流程后来成为了我们部门处理类似问题的标准实践。

低分陷阱（常见扣分点）

• 用“我们”代替“我”："我们团队发现他有问题"、"我们一起帮助他"。这让面试官无法判断你的个人贡献。反例：“我主动分析了他的代码”、“我为他制定了计划”。
• Result 缺乏量化："项目进展更顺利了，团队氛围变好了"。这太空洞。反例：“团队交付速度提升 20%，线上问题率下降 30%”。
• Action 过于简单或负面："我直接把他开除了" 或 "我把他边缘化了"。这体现了你缺乏管理能力和同理心。
• 将责任推给 HR："我把这个问题报告给了 HR，让他们去处理"。这表明你缺乏 Ownership，不是一个合格的管理者。
• 故事太“完美”："我帮助了他，然后他变成了团队的 Top Performer"。虽然可能发生，但概率很小，面试官可能会觉得故事不真实或问题太简单。处理失败的案例更能体现你的领导力。

高概率追问（3 个 + 示范回答要点）

1. 追问：在这个过程中，你遇到的最大阻力是什么？

   • 要点 1 (情感阻力)：最大的阻力来自内心。李雷是一个非常努力和友善的人，做出可能导致他离职的决定，在情感上非常困难。你需要强调你如何将个人情感与作为管理者的职责分开。
   • 要点 2 (时间成本)：执行这个计划占用了我和另一位资深工程师大量的时间，这在短期内影响了我们自己的项目进度。你需要解释你是如何向上管理，让你的老板理解并支持你这项投入的必要性。

2. 追问：你如何向团队其他成员沟通这件事？他们是什么反应？

   • 要点 1 (保护隐私)：强调你绝不会在团队面前公开讨论某个人的绩效问题。这是对当事人的尊重，也是建立团队信任的基础。
   • 要点 2 (透明化原则)：在李雷离职后，你可以在团队会议上简单、中性地宣布这个人员变动，并感谢他过去的贡献。同时，可以借此机会重申团队对卓越工程文化的追求和标准，让大家明白绩效标准是一视同仁的。
   • 要点 3 (观察反应)：团队的反应是积极的。高绩效的员工感到他们的努力被看见和尊重，整个团队的公平感和士气反而提升了。

3. 追问：如果可以重来一次，你会做哪些不一样的尝试？

   • 要点 1 (更早介入)：我会在他入职后的第一个月，而不是等到问题已经很严重时，就进行更深入的技术能力评估和沟通，更早地发现潜在的差距。
   • 要点 2 (优化招聘)：反思招聘环节。在未来的面试中，我会增加一个更贴近我们实际工作场景的编码或系统设计环节，以更准确地评估候选人与我们技术栈的匹配度，从源头上避免错配。
   • 要点 3 (改进 Onboarding)：我会优化新员工的 Onboarding 流程，为他们指派一个固定的“导师”（Buddy），并提供一个结构化的学习路径，确保他们能更快地融入团队技术体系。

故事复用建议

这个故事非常扎实，可以灵活调整侧重点，用于回答以下类型的行为面试问题：

• Ownership: "讲一个你主动承担责任解决难题的例子。" (重点讲 Action 第一步，你如何主动发现并着手解决问题)
• Deliver Results: "讲一个你为了交付结果而做出艰难决定的例子。" (重点讲 Action 第四步和 Result)
• Earn Trust: "讲一个你如何与同事建立信任的例子，尤其是在困难情况下。" (重点讲 Action 第二步，你如何坦诚沟通)
• Bias for Action: "讲一个你看到问题并迅速采取行动的例子。" (强调你没有拖延，而是立即开始收集数据和制定计划)
• Tell me about a time you had a conflict with a direct report. (整个故事都是这个问题的完美答案)
• Tell me about a time you failed. (如果最终结果是负面的，可以包装成一次“管理上的失败”，并重点讲学到了什么)