有时候你以为是在帮忙，其实是在替团队做决定

有一种帮忙，刚开始看起来特别有效。

开发同学方案没想清楚，你帮他补完整。

测试同学不知道怎么验证，你直接列清单。

产品需求边界模糊，你替大家定下来。

项目卡住了，你开个会，把每个人接下来做什么安排好。

事情确实往前走了。

但时间一长，你会发现一个不太舒服的问题：团队越来越等你。

这不是突然发生的。

一开始只是你在群里多回了几句建议。后来大家习惯了，有问题先等你看。再后来，方案评审之前没人敢定，接口改动之前也要等你点头。

你会觉得团队怎么越来越不主动。

但仔细想想，可能是你太主动了。

一、帮忙和替团队决定，只差一步

我以前不太分这个边界。

只要项目卡住，我就觉得应该介入。毕竟负责人不就是要解决问题吗？

后来发现，介入也有不同方式。

一种是帮团队看清问题。

比如把目标说清楚，把风险摆出来，把几个选择的代价讲明白。

另一种是替团队把决定做完。

比如直接说就按这个方案，接口这样定，页面这样做，异常先这么处理。

前一种会让团队继续思考。

后一种会让团队少想一步。

这一步少多了，团队就会越来越依赖负责人。

我有次就是这样。一个功能联调不顺，我直接在群里把处理步骤列了出来：谁改接口，谁补字段，谁验证数据。

当天问题解决得很快。

但第二次遇到类似问题，大家又在等我列步骤。

那时候我才意识到，我上一次解决的是事情，不是能力。

二、为什么负责人容易过度介入

说到底，还是因为你看得见风险。

你知道这个方案后面会有坑。

你知道这个任务再拖会影响联调。

你知道这段代码这样写以后不好维护。

所以你很难忍住。

尤其项目时间紧的时候，你会觉得：“算了，我直接说吧，别绕了。”

这很真实。

但问题是，如果每次都是你直接说，团队就没有机会练习判断。

他们会变得很会执行你的判断，但不一定会形成自己的判断。

三、真正有用的帮忙，是把问题推清楚

现在我更喜欢用另一种方式帮忙。

不是直接给答案，而是把问题往前推一步。

比如对方案不放心，我会问：

这个方案最怕哪个异常？

如果数据量翻十倍，还能不能跑？

如果客户现场断网，状态怎么恢复？

如果后面要加一个类似功能，会不会复制一套？

这些问题问完，有时候对方自己就会调整方案。

如果还是想不清楚，我再给建议。

这样慢一点，但团队会记住判断过程。

我也会刻意多问一句：“你倾向哪个方案？”

这句话很有用。

它会把对方从“等负责人给答案”的状态里拉出来。哪怕他的方案还不成熟，至少他开始为自己的判断负责。

四、有些决定，还是要负责人来做

当然，不是所有事情都要让团队自己慢慢想。

如果项目风险已经很高，负责人就要拍板。

如果方向明显错了，就要及时拉回来。

如果团队经验不足，又赶上关键节点，你就要把方案定清楚。

问题不在于你能不能决定。

问题在于，你是不是每次都默认由自己决定。

技术负责人要能拍板，但不要用拍板代替团队成长。

五、小结

有时候你以为是在帮忙，其实是在替团队做决定。

短期看，项目会顺一点。

长期看，团队会弱一点。

好的帮忙，不是把答案塞给别人，而是让问题更清楚，让边界更明确，让团队能自己往下走。

负责人要做的不是少帮忙。

而是帮到刚刚好。

这个“刚刚好”挺难。

少一点，团队可能摔得太疼。

多一点，团队又长不出来。

所以我现在更愿意先帮团队看清问题，再看要不要给答案。

本系列：