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

有人问了这么一个问题因为工作不到位在部门全员会议上批评了下属下属从此甩脸子不搭理三个月过去了组长职责也不履行了部门内工作不好安排念及感情和现实情况不知道如何处理。关于这个问题我一般都是拉到小会议里大多数人的脸皮很薄的不建议当面批评。拉到小会议里说明情况并列出数据或者事实的证据。但是这样做还远远不够的。我会当场告诉他这个事情应该怎么做。大多数人的脸皮比你想象的薄。一个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());OrderRuleConfigruleConfiggetOrderRuleConfig(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