很多技术TL晋升后都会撞上一堵墙：以前自己写代码搞定的事，现在得看着别人写，心里急得不行。我刚当TL那会儿，最爱干的就是抢键盘——组员卡壳，直接一句”让开我来”。结果组员轻松了，但下次遇到同样问题还是不会，而且越来越不敢拿主意。后来才明白，当领导不是当超级替补，是当教练。
教练式辅导的核心不是给答案，而是提问题。听着简单，做起来反人性。技术人习惯用逻辑说话，看到问题就想直接指出最优解。但教练式辅导要求你管住手和嘴，把”你应该这样做”换成”你觉得有哪些办法”。
比如同事写的接口性能有问题。以前我会说”加个缓存不就行了”，现在我会问：”你观察过这个接口的调用频率和数据变化规律吗？如果让你自己选一个地方优化，你会先动哪里？”这么一问，他得自己梳理逻辑、权衡方案。哪怕最后选的路子不是最漂亮的，只要大方向靠谱，我就让他试。试完他记得比谁都牢。
光会问问题还不够，还要懂得分层引导。
– 新人：手把手教流程，但别替他们想业务逻辑
– 熟手：给挑战性目标，比如重构一个老模块
– 骨干：放手让他们带小项目，哪怕节奏和你预期不一样，也要忍住不插手
我见过不少TL，嘴上说要团队，转头就把任务拆得只剩执行细节，组员完全没有思考空间。这种不叫辅导，叫外包。真正的辅导是让组员感受到”这件事是我做成的”，而不是”领导帮我做成的”。
另一个实用技巧叫复盘式反馈。别只在月度总结才聊，最好每个迭代结束后花十五分钟，问三个问题：这次哪里做得好？哪里做得不顺手？下次想改变哪一步？
这比直接指出错误更容易让组员接受。比如有人上线忘了加监控，你要是劈头盖脸说”你怎么这么粗心”，他下次只会更紧张。换成”你觉得监控应该在什么时候加比较合适？我们下次怎么保证不漏掉这一步？”他的注意力就从”我被批评了”转移到”我怎么改进流程”上。这种对话多了，组员会主动来找你聊问题，而不是躲着你。
还有一点容易被忽略：教练式辅导不只针对工作内容，还要关注人的状态。
有一次组里一个挺靠谱的同事连续两个迭代交付质量下滑。我一开始以为是能力问题，差点准备给他补课。后来约他吃午饭聊了聊，才发现他家里孩子生病，晚上睡不好，白天根本没精力。那段时间我调整了他的任务优先级，让他先做一些不赶时间的活。两周后他状态回来了，质量也恢复了。
这件事让我特别感慨：教练式辅导首先要看见人，其次才是看见事。用技术术语说，你得先检查系统负载是不是过高，再决定要不要优化代码逻辑，而不是一上来就改算法。
可能有人会问，这种提问式辅导遇到紧急情况怎么办？比如线上故障，火烧眉毛了还问”你觉得怎么办”？那确实不行。
教练式辅导也要分场景。紧急救火的时候直接下指令是负责任的表现。但救完火之后，教练的动作必须跟上：召集相关人员做一次事后剖析，让每个人说出自己当时的判断依据和处理思路。这个过程本身就是最好的学习机会。久而久之，团队的应急能力会越来越强，需要你亲自冲上去的次数反而越来越少。
我自己的体会是，教练式辅导最难的地方在于”忍”。忍住不直接给答案，忍住不嫌组员做得慢，忍住不用自己的标准去要求别人。
每一次忍住之后，你都可能看到一些意想不到的成长。组员写的代码可能不够优雅，但那是他们自己的方案；组员带的会议可能有点拖沓，但那是他们自己的节奏。你要做的就是在旁边看着，偶尔点一句，像站在球场上却不碰球的陪练。
时间一长，你会发现自己真的从”解决者”变成了”者”，团队也不再依赖你一个人撑场面。技术TL这个角色，说到底不是证明自己多能打，而是让团队每个成员都能打。这就是我理解的教练式辅导，也是走了不少弯路才换来的心得。
ID:4602
