04-08-06 管理多个团队 (Managing Multiple Teams)

04-08-06 管理多个团队 (Managing Multiple Teams)

章节概述

本章探讨如何管理多个团队，这通常意味着晋升为Director或更高级别。此时你不再直接管理工程师，而是管理经理们。这需要全新的思维方式和技能组合。

核心概念

角色转变

从：管理个人工程师 到：管理工程经理们 从：关注项目执行细节 到：关注战略和方向 从：一个团队的目标 到：多个团队的协调 从：技术深度 到：组织能力和战略

管理层级的变化

Engineering Manager (EM) ├─ 管理：5-10名工程师 ├─ 关注：一个团队的执行 ├─ 时间跨度：周/月 └─ 技术参与：偶尔 Director of Engineering ├─ 管理：2-5个团队（20-50人） ├─ 关注：多团队协调和战略 ├─ 时间跨度：季度/年 └─ 技术参与：很少 VP of Engineering ├─ 管理：整个工程组织（50-500+人） ├─ 关注：组织战略和文化 ├─ 时间跨度：年/多年 └─ 技术参与：基本没有

关键知识点

1. 管理经理们

管理经理 vs 管理工程师的区别

管理工程师：

• 关注任务执行
• 频繁的指导和反馈
• 技术问题的解决
• 日常障碍的移除
• 职业发展辅导

管理经理：

• 关注团队健康和产出
• 战略性的指导
• 管理能力培养
• 组织级别的问题解决
• 领导力发展

核心差异：
更少的干预，更多的信任
更战略，更少战术
通过他人的成功获得成功
培养领导者，而非执行者

与经理们的一对一

频率：每周或双周
时长：30-60分钟

议程结构：

1. 团队健康（20分钟）
   □ 团队士气如何？
   □ 有什么团队动态需要关注？
   □ 团队成员表现如何？
   □ 流失风险？招聘需求？

2. 项目进展（15分钟）
   □ 关键项目的状态
   □ 风险和阻碍
   □ 需要的支持或决策
   □ 跨团队依赖

3. 经理发展（15分钟）
   □ 作为经理的挑战
   □ 管理技能的提升
   □ 职业发展讨论
   □ 需要的指导和资源

4. 战略和方向（10分钟）
   □ 对部门方向的想法
   □ 改进建议
   □ 行业趋势讨论

不要做的：
微观管理他们的团队
绕过经理直接管理工程师
只关注项目进度忽视人
不给予足够的自主权

培养和指导经理

新晋经理（前6个月）：
□ 更频繁的一对一（每周）
□ 更多的指导和支持
□ 分享管理资源和书籍
□ 介绍其他经理形成peer network
□ 观察他们的团队会议
□ 及时反馈

成熟经理：
□ 给予更多自主权
□ 战略性讨论
□ 挑战性项目
□ 跨团队领导机会
□ 准备晋升到下一级

资深经理：
□ 更像peer的关系
□ 共同决策
□ 可能成为你的继任者
□ 代表部门的领导

评估经理的标准

团队产出（30%）
□ 团队交付质量和速度
□ 目标达成情况
□ 技术质量

团队健康（30%）
□ 团队士气和满意度
□ 人员流失率
□ 团队成员成长

管理能力（20%）
□ 人员管理技能
□ 项目管理能力
□ 沟通和协作

领导力（20%）
□ 战略思维
□ 影响力
□ 主动性和责任感
□ 文化建设

2. 战略规划和执行

从战术到战略的转变

战术（Tactical） ├─ 如何完成这个任务？ ├─ 时间跨度：天/周 ├─ 由团队执行 └─ 关注效率 战略（Strategic） ├─ 我们应该做什么？为什么？ ├─ 时间跨度：季度/年 ├─ 由领导层决定 └─ 关注方向和优先级

制定战略的框架

1. 理解背景（Context）
   □ 公司战略和目标
   □ 市场和竞争态势
   □ 技术趋势
   □ 组织能力和限制

2. 明确愿景（Vision）
   □ 3-5年后我们想成为什么样子？
   □ 我们的独特价值是什么？
   □ 成功是什么样的？

3. 分析现状（Current State）
   □ 我们现在在哪里？
   □ 优势和劣势
   □ 机会和威胁（SWOT）

4. 设定目标（Goals）
   □ 年度/季度目标
   □ SMART原则
   □ 与公司目标对齐

5. 制定策略（Strategy）
   □ 如何达成目标？
   □ 关键举措
   □ 资源分配
   □ 优先级

6. 执行计划（Execution）
   □ 谁做什么？
   □ 时间表
   □ 里程碑
   □ 成功指标

7. 监控和调整（Monitor & Adjust）
   □ 定期回顾进展
   □ 根据反馈调整
   □ 保持灵活性

OKR框架

Objectives and Key Results

Objective（目标）：

• 定性的、鼓舞人心的目标
• 回答"我们想要什么"
• 通常3-5个

Key Results（关键结果）：

• 定量的、可衡量的结果
• 回答"如何知道我们达成了"
• 每个Objective 2-5个KRs

示例：

O: 建立行业领先的工程团队
KR1: 工程师满意度从7.5提升到8.5/10
KR2: 关键岗位90天内填补率达到90%
KR3: 技术分享会参与率达到80%

O: 提升系统可靠性和性能
KR1: 系统可用性从99.9%提升到99.95%
KR2: P95延迟
KR3: 生产事故

O: 加速产品交付速度
KR1: 部署频率从每周2次提升到每天
KR2: 交付周期从4周缩短到2周
KR3: 客户功能请求响应时间减半

设定原则：
雄心勃勃但可达成（70-80%达成算成功）
与公司战略对齐
结果导向，而非活动导向
公开透明
定期回顾（每季度）

资源分配和优先级

投资组合管理：

核心业务（Run the Business）- 60%
├─ 维护现有系统
├─ 支持当前产品
├─ 保证稳定性和质量
└─ 必须做的工作

成长和优化（Grow the Business）- 30%
├─ 新功能开发
├─ 产品改进
├─ 市场拓展
└─ 战略项目

创新和探索（Transform the Business）- 10%
├─ 新技术探索
├─ 创新项目
├─ 技术债务偿还
└─ 流程改进

优先级决策矩阵：

影响 vs 努力
高影响 + 低努力 = 优先做（Quick Wins）
高影响 + 高努力 = 战略项目（Major Projects）
低影响 + 低努力 = 填充任务（Fill-ins）
低影响 + 高努力 = 避免（Avoid）

决策考虑：
□ 业务价值
□ 战略重要性
□ 紧急程度
□ 技术风险
□ 团队能力
□ 依赖关系

3. 跨团队协作和组织设计

团队拓扑

功能型团队（Feature Teams）
优点：
端到端交付
跨功能协作
业务目标对齐
缺点：
可能缺少技术深度
知识分散

平台型团队（Platform Teams）
优点：
技术深度
可复用组件
基础设施统一
缺点：
可能脱离业务
"内部客户"服务意识

混合模式（Hybrid）
├─ 多数功能型团队
├─ 少数平台/基础设施团队
└─ 根据需要调整

Conway定律

"组织设计系统的架构会不可避免地反映 组织的沟通结构" 含义： - 系统架构反映团队结构 - 要改变架构，可能需要改变团队 - 团队边界决定系统边界 应用： **正确做法** - 设计团队结构时考虑目标架构 **正确做法** - 给团队明确的边界和接口 **正确做法** - 减少跨团队依赖 **正确做法** - 必要时重组团队

跨团队协作机制

定期同步会议：
□ 各团队Lead参加
□ 每周或双周
□ 同步进展和依赖
□ 识别风险和问题

共享路线图：
□ 可视化各团队计划
□ 识别依赖和冲突
□ 协调时间表
□ 定期更新

跨团队工作组：
□ 针对特定项目或问题
□ 临时性质
□ 跨团队成员参与
□ 完成后解散

技术委员会：
□ 技术决策论坛
□ 架构评审
□ 技术标准制定
□ 定期会议

内部文档和知识库：
□ Wiki/Confluence
□ 技术规范
□ API文档
□ 最佳实践

内部技术会议：
□ 技术分享会
□ 架构讨论
□ 读书会
□ Hackathon

处理跨团队冲突

常见冲突：

资源竞争
└─ 多个团队争夺同一资源（人/预算）
解决：明确优先级，资源分配透明

依赖延迟
└─ 一个团队被另一个团队阻塞
解决：提前规划，建立SLA，必要时重新分配任务

技术分歧
└─ 不同团队对技术方向有分歧
解决：技术委员会决策，架构师仲裁

目标冲突
└─ 团队目标不一致甚至冲突
解决：更高层面对齐目标，沟通大局

文化差异
└─ 团队工作方式和文化不同
解决：建立共同规范，促进交流

处理原则：

1. 早期识别
2. 促进对话
3. 寻找共同点
4. 基于数据决策
5. 必要时上级介入
6. 建立预防机制

4. 招聘和团队扩张

招聘战略

何时招人：
持续过载的工作量
关键技能缺口
业务扩张需求
预期的项目需求
替换离职人员

何时不招人：
临时性的工作量峰值
流程问题导致的低效
不清楚要招什么人
预算或空间限制
现有团队士气低落

招聘计划：

1. 明确需求

   • 职位描述
   • 技能要求
   • 职级定位
   • 团队分配

2. 招聘流程

   • 筛选简历
   • 电话面试
   • 技术面试
   • 文化匹配面试
   • 团队面试
   • 最终决策

3. 招聘标准

   • 技术能力
   • 沟通能力
   • 文化匹配
   • 学习能力
   • 团队合作
   • 高标准（宁缺毋滥）

4. Offer决策

   • 团队反馈汇总
   • 评估一致性
   • 薪酬确定
   • 快速行动

入职体验

入职前（Preboarding）：
□ 发送欢迎邮件
□ 准备设备和账号
□ 分享入职日程
□ 安排Buddy
□ 分享预习材料

第一天：
□ 欢迎和介绍
□ 环境设置
□ 团队介绍
□ 公司/部门文化
□ 第一个小任务

第一周：
□ 团队规范和流程
□ 代码库浏览
□ 开发环境完整配置
□ 参加团队会议
□ 完成小任务

第一月：
□ 独立完成功能
□ 参与代码审查
□ 理解系统架构
□ 建立工作关系
□ 30天反馈会议

第一季度：
□ 成为团队productive成员
□ 贡献有价值的工作
□ 融入团队文化
□ 90天绩效回顾

入职指标：

• Time to First Commit
• Time to Productive
• 入职满意度
• 90天留存率

团队扩张的挑战

快速扩张的风险：

文化稀释
└─ 太多新人，文化难以传承
应对：控制扩张速度，强化文化宣导

生产力下降
└─ 培训新人占用老人时间
应对：预期生产力下降，调整目标

沟通成本增加
└─ 团队变大，协调变复杂
应对：优化流程，必要时拆分团队

质量下降
└─ 新人经验不足
应对：加强代码审查，mentor制度

管理瓶颈
└─ 经理管理跨度过大
应对：培养新经理，增加管理层级

健康的扩张速度：

• 每季度增长不超过25%
• 保持老人/新人比例（至少2:1）
• 有足够的mentor capacity
• 优先质量而非速度

5. 向上管理和横向协作

向上管理

管理你的老板：

理解期望：
□ 老板最关心什么？
□ 成功的标准是什么？
□ 沟通偏好如何？
□ 决策风格如何？

主动沟通：
□ 定期更新进展（不要让老板问）
□ 提前告知风险和问题
□ 提供解决方案而非只提问题
□ 好消息和坏消息都要说

寻求反馈：
□ “我哪里可以做得更好？”
□ “这个优先级对吗？”
□ “你对这个方向怎么看？”

支持老板成功：
□ 帮助老板达成目标
□ 让老板在上级面前有面子
□ 分担老板的压力
□ 成为老板的得力助手

What to escalate（何时向上升级）：
跨部门冲突
重大风险或危机
需要更高层级的决策
资源或预算请求
重要的人事问题

How to escalate（如何升级）：

1. 清楚描述问题
2. 说明你已尝试的方案
3. 提供建议的解决方案
4. 说明需要的决策或支持
5. 给足够的背景信息

横向协作

与同级经理协作：

建立关系：
□ 定期非正式交流
□ 了解对方的目标和挑战
□ 建立信任关系
□ 相互支持

信息共享：
□ 透明分享信息
□ 提前告知影响对方的变化
□ 共享最佳实践
□ 协调资源

解决冲突：
□ 直接沟通而非背后抱怨
□ 寻找双赢方案
□ 必要时上级协调
□ 以公司利益为重

跨部门协作：

理解不同部门：

• 产品：关注用户价值和业务目标
• 设计：关注用户体验和一致性
• 销售：关注客户需求和成交
• 市场：关注品牌和推广
• 运营：关注效率和成本

有效协作技巧：
学习对方的语言和视角
建立共同目标
定期同步
相互尊重专业
解决问题而非指责

实践工具

工具1: 部门仪表板

工程部门仪表板

组织健康

• 团队数量：X个
• 总人数：X人
• 本季度离职率：X%
• 员工满意度：X/10
• 招聘进度：X/Y (目标)

交付指标

• 季度目标达成率：X%
• 上线功能数：X
• 平均交付周期：X周
• 技术债务指数：X

质量指标

• 生产事故：X（环比↓Y%）
• 系统可用性：99.XX%
• Bug率：X/千行代码
• 代码审查覆盖率：X%

各团队状态

本季度亮点

关键风险和应对

工具2: 经理发展框架

经理能力评估

人员管理

□ 有效的一对一
□ 给予清晰反馈
□ 绩效管理能力
□ 人才培养
□ 处理困难对话
评分：___ /5

项目管理

□ 目标设定
□ 任务规划和跟踪
□ 风险管理
□ 跨团队协调
□ 按时交付
评分：___ /5

技术领导

□ 技术决策能力
□ 架构理解
□ 质量把控
□ 技术指导
□ 债务管理
评分：___ /5

沟通协作

□ 清晰沟通
□ 向上管理
□ 跨团队协作
□ 利益相关者管理
□ 冲突解决
评分：___ /5

战略思维

□ 理解业务
□ 长期规划
□ 优先级判断
□ 创新思维
□ 行业视野
评分：___ /5

领导力

□ 影响力
□ 文化建设
□ 变革推动
□ 团队激励
□ 以身作则
评分：___ /5

总体评分：___ /30

发展计划：
强项：
发展领域：
行动计划：

工具3: 季度战略规划模板

Q[X] 战略规划

背景和回顾

上季度回顾：

• 完成情况：
• 主要挑战：
• 关键学习：

外部环境：

• 市场变化：
• 竞争态势：
• 技术趋势：

本季度战略目标

Objective 1: [目标]

为什么重要：
成功标准：
负责团队：

Key Results:

1. KR1: [具体指标]

   • 当前基线：
   • 目标值：
   • 如何衡量：

2. KR2: [具体指标]

   • 当前基线：
   • 目标值：
   • 如何衡量：

Objective 2: [目标]

…

资源分配

关键里程碑

风险和缓解

跟踪和复盘

• 每周：团队Lead会议同步
• 每月：月度业务回顾
• 季末：全面复盘和下季度规划

工具4: 跨团队依赖跟踪

跨团队依赖矩阵

依赖管理原则：

1. 提前识别和沟通
2. 明确交付标准和时间
3. 建立检查点
4. 有备用方案
5. 定期同步状态

💭 常见问题

Q1: 如何避免微观管理经理们？

A:

• 明确授权边界：清楚说明他们的决策权
• 关注结果而非过程：看团队产出，不是每个细节
• 建立信任：给他们犯错和学习的空间
• 定期而非频繁：不要每天追问
• 提供支持而非控制：问"需要什么帮助"而非"为什么这样做"
• 自我检查：如果经理们总是来问你决策，可能是你干预太多

Q2: 经理之间能力差异大怎么办？

A:

• 接受现实：人有差异是正常的
• 个性化发展：根据每个人的能力制定发展计划
• 高潜力者：给更多挑战和机会
• 待提升者：更多指导和支持
• 必要时做决定：如果长期无改善，可能需要调整角色
• 团队互助：促进经理们相互学习

Q3: 如何平衡战略思考和日常执行？

A:

• 时间分配：战略60%，执行40%
• 固定战略时间：每周固定时间块思考战略
• 授权执行：让经理们处理日常执行
• 定期复盘：每月/季度回顾战略进展
• 不要被琐事淹没：学会说不，学会授权
• 向上学习：观察更高层级如何平衡

Q4: 团队快速扩张，感觉失控怎么办？

A:

• 放慢速度：可能扩张太快了
• 建立结构：清晰的组织架构和流程
• 培养经理：让经理们分担管理职责
• 标准化：建立可复制的流程和文档
• 优先级：不是所有事都同等重要
• 寻求帮助：向上级、HR、其他Director求助

Q5: 如何在技术和管理之间保持平衡？

A:

• 接受现实：这个级别很难保持深度技术参与
• 技术广度：保持对技术趋势的了解
• 信任专家：依赖团队的技术深度
• 偶尔参与：参加架构评审、关键技术决策
• 学习转型：管理和组织能力变得更重要
• 但不要完全脱离：保持基本的技术判断力

本章行动计划

立即行动（本周）

• 评估与每位经理的一对一质量
• 识别跨团队的主要依赖和风险
• 审视部门的战略目标对齐
• 与一位经理进行深度发展对话

短期目标（本月）

• 建立或更新部门仪表板
• 组织一次经理们的战略讨论会
• 优化跨团队协作机制
• 为每位经理制定发展计划

长期目标（季度）

• 完成季度战略规划和执行
• 提升至少一位经理的能力一个层级
• 解决主要的组织或流程问题
• 达成部门关键指标

个人学习笔记

我的部门现状

团队数量和组成： 主要优势： 主要挑战： 战略重点：

经理团队观察

[记录各经理的情况] 优秀的经理： - 名字：优势 / 可培养方向 需要支持的： - 名字：问题 / 支持计划

战略思考

[记录战略层面的思考] 当前战略： 市场机会： 组织能力差距： 下一步：