本页目录

五个转型期最容易判断失误的场景

下面这些场景不是虚构的极端案例。它们是技术 leader 日常工作中反复出现的、看起来"做了对的事"但实际上正在把团队带向依赖的时刻。

"核心模块还是我来写比较稳"

你刚从高级工程师升为 tech lead。团队里有三个人能写业务逻辑，但核心模块——分布式锁、消息队列的消费者端、权限系统——你觉得只有自己写得出来。于是你白天开会、做 code review，晚上自己写核心代码。

两个月后你是团队里最累的人，但你觉得这是责任感。

你可能判断错了什么：你把"我是最适合写这段代码的人"当成了"我应该写这段代码"。这两件事不一样。你确实是最合适的人选；但你永远在写，团队里就永远不会出现第二个能接的人。

从 MOI 哪里切入：M 和 O 的复合问题。M——你有没有让别人觉得"挑战核心模块对我有价值"？O——你有没有创造安全的学习条件，让人能犯错、能提问、能拿到足够的上下文？两个维度都没做的话，你不是在负责，你是在垄断。

具体可以试的一步：挑一个核心模块，花一周和一个团队成员 pair programming，让他主导、你辅助。不是"你来写我来 review"，是肩并肩一起写。

团队里有个人，技术不差，但从来不主动提方案。你分配什么他做什么，做完就等着。你跟他谈过，他说"好的我会注意"，然后没有任何变化。

你开始想：是不是该换个人？

你可能判断错了什么：你把"他不主动"归因到性格或态度。温伯格会让你先看环境：他提过方案吗？提了之后发生了什么？是被认真讨论了，还是被你三句话否掉了？如果他发现"提了也没用"，不提才是理性选择。

从 MOI 哪里切入：M 维度。检查一下过去一个月里，团队成员提出的想法中，有多少被你以"先这样吧"或者"这个我们以后再说"打发了。激励不靠喊口号，靠的是让人相信自己的贡献会被认真对待。

下次他提出一个不成熟的想法时，别急着评价质量。先问"你为什么这么想？"——这个问题本身就是在告诉他：你的判断有价值。

离交付还有两周，进度落后了 30%。你的第一反应是加班——自己先带头，然后拉上团队。你觉得这是以身作则。

团队跟着加了两个周末。交付勉强赶上了，质量打了折扣。下一个项目又延期了，又是同一套操作。

你可能判断错了什么：你用"投入更多时间"来解决"时间不够"的问题，但从来没有问过"为什么会延期"。是需求变更没有控制？是依赖方交付晚了？是估算方法有偏差？还是中间有人被阻塞了两天没人知道？加班能盖住症状，盖不住原因。

从 MOI 哪里切入：O 和 I。O——团队里的阻塞能不能被更早发现和清除？有没有每天花五分钟同步一下"谁被卡住了"？I——有没有更好的排期方式、需求拆解方式或交付节奏，能在同样的工时里推进更多？

温伯格的提醒很直接：在决定"做得更多"之前，先检查"能不能做得不一样"。

你引入了 code review 流程、每日站会、迭代回顾。推行两个月后，团队开始抱怨"开会太多""review 太慢""写文档占了太多时间"。

你有点委屈：这些流程明明是为他们好。

你可能判断错了什么：你在做 O 维度的事，但跳过了 M 维度。团队不理解这些流程解决的是什么问题；他们只感受到了额外负担。任何流程如果不能被团队理解为"帮我减少痛苦"而是被感受为"给我增加工作"，都不会被真正执行。

从 MOI 哪里切入：O 不能脱离 M 单独运转。在推新流程之前，先让团队自己感受到"没有这个流程时痛在哪里"。更好的做法是让团队参与设计流程，而不是接受通知。好的组织方式让人觉得"顺手"，不是"被管"。

一个具体的检验：如果你休假一周回来，团队还在自觉执行这个流程，说明它解决了实际问题。如果你一走流程就停了，说明它只是你的流程，不是团队的。

技术评审会上，你发现一个模式：你不说话，没人先开口。你一发言，大家马上围绕你的方向展开。讨论效率看起来很高，但方向永远是你定的。

你觉得这说明团队信任你的判断。

你可能判断错了什么：这不是信任，是依赖。团队已经学会了"反正他会给答案，我先不费劲了"。你的技术判断力越强，这个依赖越深。你不在的时候，团队的决策质量会断崖式下降。

从 MOI 哪里切入：回到领导力的核心定义——"创造环境让每个人发挥更多才能"。你创造的环境实际上在压缩别人的判断空间。

试一个改变：下次技术评审时，你最后一个发言。或者明确说"这个决定你们定，我只在你们需要的时候提供背景信息"。前几次讨论效率会下降、结论质量参差不齐。

这就是成长低谷。团队的低谷，也是你的低谷。扛过去之后，你会得到一个不需要你才能思考的团队。