批评下属不如当场展示解决方案

有人问了这么一个问题：因为工作不到位，在部门全员会议上批评了下属，下属从此甩脸子不搭理，三个月过去了，组长职责也不履行了，部门内工作不好安排，念及感情和现实情况不知道如何处理。

关于这个问题，我一般都是拉到小会议里，大多数人的脸皮很薄的，不建议当面批评。拉到小会议里，说明情况，并列出数据或者事实的证据。但是这样做，还远远不够的。我会当场告诉他，这个事情应该怎么做。

大多数人的脸皮比你想象的薄。一个40多岁的组长，在部门全员面前被领导点名说工作不到位，她回去之后想的不是「我该怎么改进」，而是「我在所有同事面前丢了面子」。

年龄越大、资历越深的人，对公开批评的耐受度越低。年轻人被说两句可能转头就忘了，但一个在团队里待了好几年、被你亲手提拔起来的人，她会觉得这是全盘否定，她会一直记着这个事的。

公开批评还有一个隐藏问题：它只传递了「你不行」这个信号，没有传递任何「该怎么做」的信息。对方知道你不满意了，但她不知道你期望的标准具体是什么样的。

我现在的做法是，不管问题多严重，一律拉到小会议室单独聊。

关起门来，双方都有退路。你批评得重一点，对方虽然不舒服，但至少没有旁人看到她的窘态，情绪上容易过去。同样一句话，在全员会议上说和在小会议室里说，对方的接受程度完全不同。

进了小会议室之后，不要上来就定性。不要说「你最近工作态度有问题」「你这个做得太差了」这类笼统的评价。拿出具体的事实：哪个任务延期了、哪个环节出了错、影响了什么结果。数据和事实摆出来，对方想辩解也辩解不了。

做到这一步，大多数管理者觉得够了。指出了问题、摆了事实、对方也承认了，谈话结束。

不够。

只批评不给方案，效果等于零。

对方承认了错误，回到工位上，她知道自己错了，但她不知道对的应该是什么样的。下次遇到类似的情况，她大概率还是用老办法，因为她没有见过更好的做法。

我现在的习惯是：指出问题之后，当场拿出我认为正确的做法给对方看。

技术团队有一个天然优势，代码是客观的。你说他架构不好、代码混乱，他心里可能不服，觉得你站着说话不腰疼。你把电脑打开，把你自己写的代码摆在他面前，让他自己对比。这时候不需要你多说什么，他看得出来差距。

团队里有个开发，写业务逻辑喜欢把所有东西塞到一个方法里。一个创建订单的校验逻辑，几百行代码全部平铺在一个方法体内。限额校验、时间校验、数量校验、模板校验，全混在一起。想改其中一个校验规则，要从头到尾看一遍才能定位。

我把他拉到会议室，打开IDE，先让他看他写的那段代码。不评价，不定性，只问一个问题：如果产品现在说要改最低起订量的校验规则，你需要多久能定位到相关代码？

然后我把我的写法展示给他看：

privatevoidvalidateCreateOrderRequest(CreateOrderRequestrequest){if(!OrderSourceEnum.AUTO_REPLENISH.getCode().equals(request.getSource())){return;}// 校验当天是否已存在同类型订单checkDailyOrderLimit(request.getShopId(),request.getTemplateId(),request.getExpectArrivalTime());// 校验当前模板是否支持补货checkTemplateAvailability(request.getIsReplenishment(),request.getTemplateId());OrderRuleConfigruleConfig=getOrderRuleConfig(request.getShopId(),request.getTemplateId());// 校验是否超过订货截止时间checkOrderDeadline(request,ruleConfig);// 校验最低起订量checkMinimumQuantity(request,ruleConfig);// 校验起订数和最大订货数checkQuantityRange(request.getTemplateId(),request.getOrderItems());}

这段代码的特征是：所有子方法处于同一个抽象层次。主方法读起来像一份校验清单的目录，每一步在校验什么，一眼就能看出来。想改某个校验规则，直接点进对应的子方法，改完出来，不影响其他逻辑。

不需要额外解释什么设计模式、什么编程原则。代码摆在那里，干净还是混乱，任何一个有两年经验的开发都看得出来。

这个开发看完之后说了一句「确实清楚很多」。比我说一百句「你代码写得不好」管用。

这种做法有一个前提条件：你自己的代码得比对方写得好。

如果你只是一个不写代码的管理者，空口批评代码质量，对方嘴上不说什么，心里一定在想「你行你上」。技术团队的管理权威不完全来自职位。一个技术组长、技术经理，如果手上的活拿不出来，批评就缺少说服力。

这也是为什么我一直强调技术管理者不能完全脱离一线。你不需要写所有的代码，但你至少要在关键模块上保持手感。这样当你指出下属的问题时，你能拿出具体的、可对比的解决方案。

对方不服你的管理，往往不是因为你批评了他，而是因为他觉得你没资格批评他。当场展示你的方案，就是在建立这个资格。

回到开头那个场景。已经在全员面前批评过了，对方已经三个月不搭理你了，怎么办。

我见过一个处理得很好的案例。25年的时候，我跟CTO去开公司的经营分析会，其中一位创始人不知道怎么回事，当面对CTO说了一些不太客气的话，场面非常尴尬。还好5分钟后是中场休息。回来之后，那位创始人直接当着所有人的面拥抱了CTO，握了一下手。

这个事情就这么过去了，后续依然合作得很好。

这个处理方式好在哪？当众说了过分的话，就当众把台阶给出来。在场的人都看到了，知道这事翻篇了。如果只是私下道歉，其他人心里还是会觉得两个人之间有裂痕，后续协作会变得微妙。

回到那个组长的问题。如果你当时是在全员面前批评的她，那修复这件事也需要让团队看到信号。不一定是拥抱这么戏剧化的动作，但至少在后续的团队场合里，公开肯定她做得好的地方或者在群里说也行，让所有人知道你对她的认可没有变。

如果三个月过去，你做了努力，对方仍然拒绝配合工作、不履行组长职责，那你需要考虑调整分工或人员安排。念及感情是人之常情，但管理者不能让个人感情影响团队运转。一个不发挥作用的组长，对团队其他成员也不公平。

对方不服你的管理，往往不是因为你批评了他，而是因为他觉得你没资格批评他。当场展示你的方案，就是在建立这个资格。

技术管理者的真正资本不是title，不是绩效打分权，是你在技术上确实比团队成员看得更远、做得更好。当这一点成立时，批评变成指导，对抗变成信任。当这一点不成立时，再高明的沟通技巧也只是在掩饰能力的不足。

最近在知乎出了「应付6000万会员的秒杀系统专栏」和「几亿用户,百万并发的C端商品系统实战」专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：

• 老码头的技术浮生录

它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。」

知识星球内后续将推出20+个付费专栏，覆盖电商全链路：

从前台选购到中后台结算，星球成员全部免费，后续新增也不额外收费。

我的知乎账号:

• SamDeepThinking