从一名卓越的个人贡献者（Individual Contributor, IC）成长为优秀的技术主管（TL），最大挑战在于“如何带出一支高效能的自组织团队”。在平衡矩阵或弱矩阵组织中，成员往往来自不同的职能部门，兼顾多个项目，团队容易陷入推诿扯皮或效率低下的泥潭。TL 需要理解塔克曼团队演进模型（Tuckman Model），掌握 PMP 5 种冲突解决模式，从“命令控制型”管理者转型为“仆人式领导（Servant Leader）”。7.0 一支“明星团队”为什么三个月就散了某公司抽调各部门最强的 6 名工程师，组建一支攻坚团队，目标是三个月内完成一个高难度平台重构。TL 是公司公认的技术权威。第 1 个月：进展惊人。每个人都独立能力强，代码提交量高，TL 对前景非常乐观。第 2 个月：问题开始冒头。前端和后端在接口设计上产生分歧，各自按自己的理解开发，联调时发现字段不匹配；一位资深工程师认为另一位同事的架构方案“不够优雅”，在 Code Review 里写了很长一段批评，对方在群里回了两句，此后两人不再直接沟通，全部经由 TL 中转。第 3 个月：TL 每天花 4 小时做“传话筒”，同时自己还要写最难的模块。项目按期上线了，但延期两周、返工三次。上线后第二个月，团队里 3 人申请转岗。复盘时的共识很残酷：这支团队从头到尾没有真正成为一个团队，它只是 6 个独立高手在同一间会议室里工作。问题出在哪？TL 做了他擅长的事——技术攻坚、方案评审、问题诊断；但他没做三件关键的事：没有建立协作契约：接口怎么定、评审怎么给反馈、分歧怎么升级，全都没约定过。没有识别团队阶段：他把一支刚组建的团队（形成期）当作成熟团队（成熟期）来管理，默认大家“应该会自己协调好”。把冲突当成了干扰：冲突出现时他的第一反应是“我来裁决”，而不是“让他们学会解决”。结果冲突被压下去两次，第三次直接爆发。本章的核心命题：技术能力可以让一支团队启动，但只有协作机制与冲突处理能力能让它持续。而这两样，恰恰是 TL 从 IC 转型时最容易忽略的。7.1 塔克曼团队演进模型（Tuckman Model）在研发团队的应用任何团队的发展都必须经历五个阶段，TL 在不同阶段需要采用截然不同的领导力姿态：形成期（Forming）：团队初建，成员礼貌但保守。TL 姿态：指导型（Directing）。明确定义研发规范、DOR/DOD、架构原则与协作工具。震荡期（Storming）：由于技术方案歧异、代码风格冲突或工期压力，争执频发。TL 姿态：教练型（Coaching）。建立心理安全感（Psychological Safety），引导团队聚焦于问题而非人身攻击。规范期（Norming）：团队形成统一的技术信任与协作契约，工作步入正轨。TL 姿态：支持型（Supporting）。鼓励团队自主决策，完善 CI/CD 和自动化工具。成熟期（Performing）：团队具备高度自组织能力，能够高效应对复杂技术攻坚。TL 姿态：授权型（Delegating）。充分授权，关注团队长远的技术梯队建设与人才培养。解散期（Adjourning）：项目结束，总结沉淀资产并进行团队关怀。1. 五个阶段的识别信号与 TL 动作对照表塔克曼模型的实用价值在于识别信号——你必须先知道团队在哪个阶段，才知道该用哪种姿态：阶段可观察信号TL 的核心动作最容易犯的错误形成期会议沉默、互相客气、等 TL 拍板、问题都抛给 TL明确目标、规范、角色与协作方式；建立基本规则误以为“没冲突就是好团队”震荡期技术争论升级为人身评价、Code Review 语气尖锐、小圈子形成、进度波动建立冲突解决规则；引导聚焦问题；保护心理安全感回避冲突，希望“自己会好”规范期团队开始自行约定规范、主动互相 Review、新人被接纳逐步放手，把决策权下移；完善工具链在该放手时继续强控，压制自组织成熟期团队自主排期、主动暴露问题、自我纠偏、TL 缺席也能推进授权、关注梯队建设与外部环境优化继续做技术最高决策者，成为瓶颈解散期成员开始关注下一个项目、注意力分散沉淀资产与文档、复盘、正式认可贡献无声解散，无复盘无认可2. 关于震荡期：最重要也最被误解的阶段震荡期不是团队失败的征兆，而是团队走向成熟的必经之路。一支从不震荡的团队，通常是两种情况：要么成员