Engineering Manager 三个月：在不熟悉的领域学着做管理
三个月前，我写了一篇关于即将升职到 Engineering Manager 的文章。那时候的我，一边兴奋一边焦虑，列了一堆准备工作：读管理书、做 team snapshot、写交接文档。
现在三个月过去了，回头看那篇文章，有些东西确实有用，有些就..
两个全新的项目
升职之后最大的变化，不是"不写代码了"——虽然这确实让我有点不适应——而是我接手了两个之前完全没接触过的项目。
注意，不是技术栈不熟悉。技术方面我还算有信心。真正让我不安的是业务领域。之前作为 Team Leader，我对负责的项目了如指掌，每个功能的来龙去脉、每个历史决策的背景，我都清楚。现在面对两个新项目，我变成了房间里最不了解业务的人。
这种感觉很微妙。你是这个团队的 Manager，但你对他们每天在做的事情，理解得可能还不如一个刚入职三个月的开发者。
我的笨办法
没有什么高级方法论，我做的事情其实很朴素：
参加每日例会。 不是走个过场那种参加，而是认真听每个人在说什么。碰到不熟悉的内容后面也会自己去查阅相关内容.
看 Jira。 这听起来很无聊，但确实有效。通过看每个人的任务分配和进度，我能逐渐拼出项目的全貌：什么功能在开发、什么问题反复出现、谁在负责哪一块。Jira 不会告诉你全部，但它是一个不错的起点。
问人。 遇到不熟悉的业务问题，我会直接去问之前熟悉这些项目的同事。这一点说起来简单，做起来需要一点勇气——毕竟你是 Manager，承认"我不懂"总会让人有一瞬间的犹豫。但我很快发现，大多数人其实很乐意帮忙解释，而且他们对你愿意主动了解这件事是正面评价的。
这些方法都不酷，没有一个是从管理书里学来的。但它们有效。
优先级：最大的挑战
如果你问我这三个月最难的是什么，不是适应新身份，不是不写代码，而是在信息不充分的情况下判断优先级。
两个新项目是最高优先级，这一点很明确。但我的团队成员不是全都在这两个项目上——还有其他的任务和项目需要关注。问题在于，对于那些我还不够了解的工作，我很难判断它们的紧急程度和重要性。
我现在的做法是：对于自己不确定的事情，先去了解背景信息，再做判断。听起来理所当然，但在实际工作中，总会有一种压力让你觉得应该立刻给出答案。学会说"我先了解一下再回复你"，是这三个月我学到的一个重要技能。
管理书籍：一个诚实的想法
升职之前，我认真读了《Become an Effective Software Engineering Manager》。那本书确实给了我一些框架和概念，帮助我在完全没有经验的时候有了一个起点。
但读完之后，我没有再去找下一本管理书。
倒不是觉得不需要学习了，而是我发现了一个更适合自己的方式：遇到具体问题的时候，直接问 AI。 比如"第一次做绩效评估要注意什么"、"怎么处理团队成员之间的意见分歧"——这种具体场景下的问题，AI 能给出针对性很强的建议，比从头读一本书效率高得多。
书的价值在于建立基础认知框架，这一步我已经完成了。接下来更多的是在实践中遇到问题、解决问题。当然，如果遇到一本特别契合当下需求的书，我还是会去读的——只是不再为了"我应该多读管理书"这个概念而焦虑了。
最近倒是在读《我们的箱根驿传》。一本关于接力赛的书，讲的是团队怎么配合、怎么在压力下坚持、怎么把接力棒传好。没有刻意去找管理方面的启发，但读的时候偶尔会觉得：嗯，这不就是我现在每天在做的事情吗。
三个月的小结
如果用一句话总结这三个月的感受，大概是：管理最难的部分，不是管理本身，而是在不确定中保持前进。
不确定自己对业务的理解是否正确，不确定优先级的判断是否合理，不确定自己说的"我先了解一下"会不会被团队解读为不够果断。
但三个月下来，我至少确认了一件事：承认不懂、老老实实去学，比假装什么都知道要好得多。团队不需要一个全知全能的 Manager，他们需要一个愿意理解他们工作的人。
这条路还很长。下一个三个月，我希望能从"了解业务"进阶到"能做出更有信心的判断"。
到时候再来写一篇。
这是我 Engineering Manager 旅程的第二篇记录。第一篇写的是升职之前的心情和准备，如果你也在考虑从开发转管理，也许那篇能给你一些参考。
