不是升职，是换了一份工作
我自己很快就要走这一步了，所以最近一直在找过来人聊，能找到的书也都翻了翻。目前最清晰的一条结论是：从工程师到工程经理，不是往上走一级，而是横着跨进一份完全不同的工作。你的产出不再是代码，而是团队做出来的一切。这话人人都说，但据说人人都还是低估了它的分量。
到底变了什么
你不再亲手解决技术问题，转而去解决人的问题。日历被 1:1、计划会议和跨团队协调填满，招聘和绩效评估也落到了你桌上。工作的重心变成：确保团队拥有干活所需的东西——背景信息、清晰的优先级，以及尽可能少的干扰。
别扭的地方在于，你还得保持足够的技术水平，能在架构讨论里站得住脚、做出靠谱的技术判断，同时又要接受"写代码的人不再是我"这个事实。我见过几个两头都想抓的经理，结果多半是两头都做砸。
工程师和工程经理，放在一起看
| 软件工程师 | 工程经理 | |
|---|---|---|
| 你的产出 | 代码、设计、代码评审 | 团队交付的东西，以及团队本身 |
| 评判标准 | 你自己工作的质量和影响 | 交付、留人，以及大家成长了多少 |
| 典型的一天 | 专注时间、pull request、设计讨论 | 1:1、做计划、招聘、帮人扫清障碍 |
| 反馈周期 | 几小时到几天：测试通过，功能上线 | 几个月：招来的人站稳了，有人升职了 |
| 亲手做的技术工作 | 一周里的大部分时间 | 评审和架构上的拍板，很少再处在关键路径上 |
过来人提醒得最多的，就是反馈周期这一行。当工程师时，你几乎每天都能拿到一点小小的成就感。当了经理，成就是真的，但来得很慢，你得习惯在一段时间里都不知道某个决定到底对不对。
看起来最要紧的几项能力
沟通占了大头。你成了团队、产品和管理层之间的翻译，光是确认这三拨人在聊同一件事，就能耗掉多得惊人的时间。比任何流程都管用的是信任：如果大家不敢告诉你哪里坏了，你就会是最后一个知道的人。日历是真的会把人活吞的，守住思考的时间、留给团队的时间，是一场没有尽头的仗。还有，你得明白公司到底想干成什么，否则你根本没法把团队带向一个有意义的方向。
头衔到手之前的准备
我反复听到、也能亲自作证的一条建议：在别人给你头衔之前就开始带。带一个项目，指导一个人，牵头做点什么。过去一年我一直在做项目负责人的角色，这段经历比任何一本书都管用。当然书也有用——Camille Fournier 的 “The Manager’s Path” 是人人都推荐的那本，读完确实明白为什么。技术也别放下，架构之争永远不会停。最后，找一位已经完成这个转变的导师，他们能帮你绕开那些事后看来"这也能踩？“的坑。
取舍
你对"东西怎么造"的影响力变大了，但很少再亲手去造。我猜有些日子会觉得很爽，有些日子会想写代码想得不行。过来人都说这很正常。半年后再来问我吧。