# 从专家到管理者

> 管理者不是「更厉害的个人贡献者」，而是**换了一套产出方式**：从自己交付，变成让团队持续交付；从追求技术正确，变成追求业务有效。

## 一、三个必须完成的转变

| 维度 | 做专家时 | 做管理后 |
| --- | --- | --- |
| 产出定义 | 我写了多少代码、解决了多少难题 | 团队交付了什么、业务指标有没有变 |
| 成功标准 | 方案对不对、质量高不高 | 目标达成了没有、代价是否可接受 |
| 时间分配 | 大部分时间在做事 | 大量时间在判断、沟通、协调、培养 |
| 权威来源 | 技术最强 | 判断力可信、承诺可兑现、团队愿意跟 |

最典型的失败是「用做专家的方式做管理」：抢最难的活自己干、评审时亲自改代码、所有方案都要过自己的手。结果是团队能力不涨，自己成为瓶颈。

## 二、管理者的四块能力

| 能力 | 具体内容 | 做不好会怎样 |
| --- | --- | --- |
| 定目标 | 把上级目标翻译成团队可执行的目标，明确不做什么 | 团队很忙，但年底说不清成果 |
| 配资源 | 人、时间、预算、注意力的分配与取舍 | 关键项目缺人，边缘项目堆人 |
| 带人 | 选人、授权、反馈、培养、处理不胜任 | 事必躬亲，一休假就出事 |
| 建机制 | 流程、规范、复盘、协作方式 | 同类问题反复发生，靠人肉兜底 |

四块里最容易忽略的是「建机制」——它见效慢，但决定了团队能不能规模化。

## 三、五个常见误区

1. **技术标杆型**：坚持做团队里最强的那个人。短期有效，长期锁死团队上限。
2. **任务分发型**：把自己变成派活的中转站，不做判断，不担责任。
3. **只对上不对下**：向上汇报做得漂亮，团队的问题没人管，半年内核心成员流失。
4. **把管理当开会**：用会议数量衡量工作量，实际问题一个没解。
5. **不敢做取舍**：什么需求都接，团队长期超负荷，最后全线延期。

## 四、前 90 天：看清、定标、改一件事

| 阶段 | 动作 | 产出 |
| --- | --- | --- |
| 第 1—30 天：看清 | 一对一聊完所有人；看最近三个月的目标、事故、交付记录；找出真正的瓶颈 | 一页纸：团队现状、三个关键问题 |
| 第 31—60 天：定标 | 和上级对齐目标与优先级；和团队对齐「什么算做好」；明确不做的事 | 季度目标 + 验收口径 |
| 第 61—90 天：改一件事 | 只挑一个最痛的点（比如需求插队、发布不可控）改流程 | 一个可验证的改进 |

新管理者最常见的错误是「上来就大改」。没有信任基础和组织理解，改革多半变成折腾。

## 五、持续向上：三个台阶

| 台阶 | 关注点 | 标志 |
| --- | --- | --- |
| 带团队 | 把事做成 | 团队目标稳定达成，成员能独立负责模块 |
| 带管理者 | 把体系做成 | 培养出能带团队的人，机制能自我运转 |
| 带方向 | 把选择做对 | 判断业务与技术方向，为组织争取资源与空间 |

每上一个台阶，**动手的比例下降，判断与选人的比例上升**。卡住的人通常是舍不得放下「亲手做」的成就感。

## 六、自检清单

- [ ] 我能用一句话说清团队季度目标，以及「不做什么」
- [ ] 我的时间里有 50% 以上花在判断、沟通、培养上，而不是亲自干活
- [ ] 团队里至少两个人能独立负责一块业务，不需要我盯
- [ ] 我每周有固定的一对一，能说出每个人当前的卡点
- [ ] 我知道团队最脆弱的环节，并有改进计划
- [ ] 我做的决定有记录，团队知道为什么这么定
- [ ] 我休假一周，团队能正常交付