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