技术管理 / Team Lead 进阶路线

定位：从"个人贡献者(IC)"到"能带团队、担责任、建立信任"的管理方向。
适用对象：4 年以上 Android/移动开发，具备一定技术深度，希望转向技术管理路径。
抗替代性逻辑：管理的核心是责任承担 + 信任关系——团队出问题谁负责、员工绩效谁评估、跨部门冲突谁协调，这些都需要"自然人"承担后果并建立长期信任，AI 可以辅助分析数据、给建议，但不能代替你签字、代替你和人建立信任关系。

一、先想清楚：要不要走管理路线

1.1 技术管理 ≠ 技术能力的延伸奖励

常见误区："我技术最好，所以该我带队"
现实情况：管理是一种不同的能力（沟通、协调、评估他人、承担责任），
         技术好只是"入场门槛"，不是"胜任证明"

1.2 自我评估问题

- 我是否愿意把大量时间从"写代码"转向"开会、沟通、评审、协调"？
- 我是否能接受"团队成绩优先于个人技术炫技"？
- 我是否能在冲突中做出让部分人不满意但对整体最优的决定？
- 我是否愿意承担"团队犯错，我担责"的压力？

如果这些问题的答案偏向犹豫，可以考虑"技术专家/架构师"路线（见 02-架构设计与技术选型学习路线.md）而非纯管理路线，两条路线也可以在很多公司并行发展（双通道）。

二、能力地图

三、学习路线总览（建议 12～18 个月，多数需在实际管理岗位中历练）

阶段 0：管理心态转换与基础认知          → 1～2 月
阶段 1：一对一沟通与团队氛围建设        → 2 月
阶段 2：项目管理与风险控制              → 2～3 月
阶段 3：技术判断与授权平衡              → 3 月
阶段 4：绩效评估与人才培养              → 2～3 月
阶段 5：向上管理与跨部门协作            → 2 月
阶段 6：危机处理与团队文化建设          → 持续

重要提示：管理能力必须在真实带人场景中历练，看书/上课只能建立框架认知，无法替代实践。建议先争取 Tech Lead（带 2～3 人的小团队/项目）过渡，再考虑正式 Team Lead/EM。

四、阶段 0：管理心态转换与基础认知（1～2 月）

4.1 IC 思维 vs 管理者思维

4.2 阶段产出

• [ ] 写一页《我为什么想做管理》，明确动机（而非"技术卷不动了才想转管理"）
• [ ] 找一位在职管理者做一次深度访谈，了解真实日常

五、阶段 1：一对一沟通与团队氛围建设（2 月）

5.1 一对一（1:1）会议框架

频率：建议每 1～2 周一次，每次 30 分钟
内容结构：
  1. 近期工作进展与困难（员工主导）
  2. 职业发展与成长诉求
  3. 对团队/管理的反馈（营造安全说真话的氛围）
  4. 管理者的观察与反馈

5.2 常见沟通技巧

5.3 阶段产出

• [ ] 完成至少 4 次结构化 1:1（可先在带教/mentor 场景中练习）
• [ ] 写一份《团队氛围观察笔记》：目前团队士气、主要问题

六、阶段 2：项目管理与风险控制（2～3 月）

6.1 排期与风险管理

排期原则：
- 留缓冲（Buffer），不按理想情况排满
- 识别关键路径（哪个任务卡住会拖累整体）
- 定期检查点，而非等到 deadline 才发现问题

风险管理：
- 提前识别技术风险（新技术/新架构不确定性）
- 提前识别人员风险（关键人员请假/离职）
- 建立"提前预警"机制，而非"出了问题才上报"

6.2 跨团队协调

- 明确依赖关系：我们依赖谁，谁依赖我们
- 提前沟通排期冲突，而非临期才发现
- 建立跨团队的责任边界文档，减少"扯皮"

6.3 阶段产出

• [ ] 主导或参与过至少 1 个跨团队协调的项目排期
• [ ] 写一份《项目风险清单模板》并在真实项目中使用

七、阶段 3：技术判断与授权平衡（3 月）

7.1 管理者要不要懂技术细节

必须懂到能：
- 评估技术方案的合理性，提出关键问题
- 在团队意见分歧时，理解双方的技术论点
- 识别"这个技术决策有没有被过度简化/夸大风险"

不需要懂到能：
- 自己写出最优实现（这是团队成员的工作）
- 事无巨细地审查每一行代码

7.2 授权的艺术

过度控制的信号：什么都要过一遍、不放心让别人做决定
过度放手的信号：完全不参与技术决策、出问题才知道

平衡点：
- 明确哪些决策必须经过你（架构级、跨团队影响大的）
- 哪些决策完全授权（局部实现细节）
- 建立"决策权限清单"，团队和你自己都清楚边界

7.3 阶段产出

• [ ] 写一份《团队决策权限清单》：哪些事项需要报备、哪些完全授权
• [ ] 完成至少 1 次"放手让团队自己决定"并观察结果的实践

八、阶段 4：绩效评估与人才培养（2～3 月）

8.1 绩效评估原则

- 基于事实和产出，而非印象和亲疏
- 提前沟通预期，而非考核时才第一次提出问题
- 区分"能力问题"和"意愿问题"，处理方式完全不同

8.2 人才培养机制

8.3 阶段产出

• [ ] 完成至少 1 次正式绩效评估（含书面反馈）
• [ ] 建立 1 套团队 Code Review 规范
• [ ] 带教至少 1 名初级/新人成员并有可见成长记录

九、阶段 5：向上管理与跨部门协作（2 月）

9.1 向上管理

- 主动同步进展，不要让上级"来问才知道"
- 汇报要有结论和建议，不只是罗列问题
- 提前预警风险，给上级留出应对时间

9.2 向下传达目标

- 把公司/部门的战略目标翻译成团队能理解、能执行的具体任务
- 解释"为什么"而不只是"做什么"，提升团队认同感

9.3 阶段产出

• [ ] 完成一次向上汇报（如季度回顾），得到明确反馈
• [ ] 写一份《团队目标翻译文档》：把上层目标拆解为团队任务

十、阶段 6：危机处理与团队文化建设（持续）

10.1 常见危机场景

10.2 团队文化建设

文化不是喊口号，是通过日常决策体现出来的：
- 你在紧急情况下的选择，比平时说的话更能定义文化
- 对错误的态度（惩罚 vs 学习型复盘）决定团队是否敢创新
- 对"说真话"的鼓励程度决定团队信息是否透明

10.3 阶段产出

• [ ] 处理过至少 1 次真实的团队冲突或危机场景并复盘
• [ ] 写一份《我理想的团队文化》文档并在实践中验证调整

十一、简历/晋升表述框架

不要写：「负责团队管理工作」
要写：
「带领 X 人团队完成 XX 项目，通过建立每周风险检查点机制将项目延期率
从 XX% 降至 XX%；建立 Code Review 规范和晋升路径透明化机制，
团队半年内主动流失率为 0，2 名成员完成晋升。」

十二、能力自检清单（20 项）

打勾 ≥ 14 项，说明已具备基础管理能力：

基础认知

• [ ] 能清楚说出自己想做管理的真实动机
• [ ] 理解 IC 思维和管理者思维的本质差异

沟通

• [ ] 能做结构化的 1:1 沟通
• [ ] 能给出具体、非人格化的负面反馈
• [ ] 处理过至少 1 次团队冲突

项目管理

• [ ] 主导过跨团队项目排期
• [ ] 有风险清单模板并实际使用

技术判断

• [ ] 能评估技术方案而不需要事事亲自实现
• [ ] 有清晰的团队决策权限边界

人才培养

• [ ] 完成过正式绩效评估
• [ ] 带教过至少 1 名成员并有成长记录
• [ ] 建立过 Code Review 或晋升相关机制

向上/跨部门

• [ ] 完成过向上汇报并获得明确反馈
• [ ] 能把上层目标翻译成团队任务

危机与文化

• [ ] 处理过至少 1 次真实危机场景
• [ ] 有清晰的团队文化主张并能举例说明如何体现

结果

• [ ] 有可量化的团队产出改善数据
• [ ] 团队成员流失率/满意度有正向变化证据

十三、常见误区

十四、最短路径

1. 明确自己的管理动机，理解 IC vs 管理者思维差异（1个月）
2. 争取 Tech Lead 或小团队带教机会，开始实践 1:1 沟通（3个月）
3. 主导 1 次跨团队项目排期与风险管理（3个月）
4. 建立团队决策权限清单，练习授权（2个月）
5. 完成至少 1 次正式绩效评估周期，积累管理实践案例

一句话总结：

技术管理的护城河是"责任承担 + 长期信任关系"，这是 AI 能提供建议、但不能代替你和真实的人建立关系、也不能代替你承担团队后果的领域。

十五、关联文档

• 02-架构设计与技术选型学习路线.md — 若更倾向技术深度而非管理，可参考此路线
• ../Android高级架构师学习路线.md — 技术领导力章节的补充
• ../Android移动开发方向抗替代性与薪酬分析.md — 替代率与薪酬定位