从技术专家到管理者的转变
分享从开发者到团队 Leader 的角色转变经历，包括思维转变、时间分配、团队培养等挑战。这不是升职，而是一次职业路径的转换。
被迫的转变
做了7年开发，代码写得顺手，bug 修得痛快。
突然有一天，老板说：“你来带这个团队吧。”
我以为是升职，后来才发现，这是一次职业路径的转换。
最大的思维转变
从”我”到”我们”
开发者思维：
- 这个模块我来重构
- 这个 bug 我来修
- 我能搞定
管理者思维：
- 谁能成长最快，就让谁来做
- 如何让大家都能搞定
- 系统性地避免 bug
从”完美”到”足够好”
代码可以追求优雅，管理追求效率。
技术债务 vs 业务价值：
- 开发：“这块代码太烂，必须重构”
- 管理：“业务价值是否值得投入2周重构？”
学会在质量和速度间权衡。
时间分配的困境
1. 不写代码的焦虑
第一周，我的日历被会议填满：
- 需求评审
- 1on1 面谈
- 跨团队协调
- 绩效评估
周五晚上，我打开 IDE，一行代码没写，有种莫名的失落。
适应过程：
- 接受”代码产出减少”是新角色的必然
- 把”团队产出”当作自己的产出
- 保留20%时间做技术深耕（review、架构设计）
2. 从救火到防火
初期：每天都在救火
- A说环境有问题
- B说需求不明确
- C说和别人有冲突
后期：建立机制防火
- 新人 onboarding 文档
- 需求评审 checklist
- 冲突升级流程
培养团队的挑战
1. 授权的艺术
问题：“这么简单，我自己10分钟搞定，教他要1小时”
觉悟：如果每次都自己干，一年后还是只有我能干。
方法：
- 第一次：我做你看
- 第二次：你做我看
- 第三次：你做我评
- 之后：完全授权，只在需要时支持
2. 绩效管理的痛苦
最难的一课：当你知道某人跟不上，却迟迟不敢行动。
拖延的原因：
- 怕被讨厌
- 觉得自己没尽力培养
- 幻想对方会突然开窍
现实：拖延对双方都不公平。
我的方法：
- 明确期望（文档化、可量化）
- 及时反馈（不要等季度 review）
- 提供支持（培训、换岗机会）
- 如果还不行，果断行动（对团队负责）
3. 激励不同的人
新手工程师：需要明确指导和成长路径 资深工程师：需要自主权和技术挑战 佛系工程师：需要理解他的动机，也许不是晋升
没有万能激励公式，需要1on1了解每个人。
向上管理
1. 管理老板的预期
错误做法： 老板说”这个功能下周能上吗？” 你明知不可能，却说”我尽量”
正确做法： “按目前资源需要2周。如果下周必须上，需要砍掉测试或增加人手。您倾向哪个方案？“
2. 争取资源
不是抱怨”人手不够”，而是：
- 用数据说明当前负载
- 量化延迟的风险
- 提供解决方案（招聘/借调/砍需求）
3. 汇报的艺术
金字塔原理：
- 先说结论
- 再说关键论据
- 最后补充细节
老板没时间听你娓娓道来。
保持技术敏锐度
1. 代码审查
虽然不写业务代码，但坚持 review：
- 了解技术演进
- 保持代码直觉
- 发现培养机会
2. 技术决策
架构选型、技术债务优先级，这些需要管理者参与。
3. 个人项目
业余时间维护 side project，保持手感。
三年后的感悟
最欣慰的事： 看到团队成员成长，独当一面。
最后悔的事： 早期 micromanagement，限制了大家的发挥空间。
最大的收获： 学会通过他人完成工作，而不是自己亲力亲为。
给即将转型的你
- 这不是升职，是转行：准备好重新学习
- 拥抱不确定性：管理没有标准答案
- 保持谦卑：向团队成员学习
- 关注人：技术是手段，人才是目的
角色转变很难，但值得。