低绩效同事，先别急着下结论

团队里最难处理的，往往不是最差的同事，而是那些卡在board line上，挤挤能出活、但不挤就磨洋工的low performer 同事。

这类 low performer 一出现，很多Manager的第一反应就是：ownership 不行。问题是，这句话太空了，空到几乎没法行动。

我更喜欢用一个简单的框架看这件事：先判断原因，再调整支持，接着设观察期，最后做去留决定。

先判断：到底是哪一类问题

low performance 不等于 low ability。常见情况其实不一样：

• 不会做：能力还没到，拆问题、推进、沟通都卡住。
• 不想做：知道怎么做，但投入不够。
• 做错方向：很努力，但目标理解偏了。
• 岗位不匹配：人不差，只是不适合这个角色。

比如：

• 一个同事总是晚交，但每次都能把问题讲清楚，可能是任务切太大了。
• 一个同事总返工，而且自己看不出风险，可能是判断力还不够。
• 一个同事开会很多、邮件很多，但总对不齐预期，可能是协作方式有问题。

先把类别分清楚，后面才知道该怎么处理。

再调整：给对支持，不要只加压力

很多 manager 一看到 low performer，就开始加压。但压力不是万能药。

• “不会做”，就补方法：更细的目标、更短的检查点、更明确的标准。
• “方向错了”，就尽早对齐：任务边界、优先级、成功标准。
• “岗位不匹配”，就认真想是不是该换项目、换 scope，甚至换角色。

举个例子：

我组里有个同事总是 late delivery，先别急着说 execution 差，先看他问题出在哪。

我和他设了一个月的daily 1-1，并且他把自己的hourly execution 写在了文档里。后来发现他的问题是：

• 对领域知识了解很肤浅，又不好意思去问别人。于是只好用ai在reverse engineer。结果理解的更奇怪
• 带着这种奇怪的领域知识，他看很多问题都抓不住要点，于是在corner case 里疯狂打转
• 进而，他就卡在各种corner cases里，导致late delivery

我给他的plan是：

• 先定期和pm聊天，理解我们产品在服务什么客户
• 用我们自己的产品，看应用场景和他理解的偏差有多少
• 然后更新自己的知识库
• 最后再把不重要的部分deprioritize，这样其他的工作的进度就提高了
• 一个月后再checkin

设观察期：看变化，不看口头承诺

只聊一次不够，必须给一个短观察期。

这段时间重点看三件事：

• 目标有没有重新对齐
• 行为有没有真的变化
• 同样的问题会不会再出现

如果两三轮之后还是老样子，就别继续自我安慰了。拖着不处理，最后只会让其他同事替他买单。

最后做决定：培养、换岗，还是离开

low performer 的处理，最后一定要落到决定上。

有些人是能救的，框架一清楚就起来了。

有些人适合换到更匹配的位置。

也有些人，已经不是 support 能解决的问题了。

真正难的，不是做决定，而是早点做出正确判断。因为拖得越久，团队消耗越大。

结尾

处理 low performer，不是为了“整顿人”，而是为了让团队恢复正常运转。

最有效的做法，通常不是一句狠话，而是：先判断原因，再给针对性的支持，最后基于观察期做干净的决定。

这件事不好看，但很重要。