先说结论：如果你也是刚当上工程经理、不知道从哪下手，我现在的做法是先了解人，再搞清楚现状是怎么来的，然后读代码，大致按这个顺序。之后把上下文给足，就别挡团队的路了。
这个月我开始带一个工程团队，距离我写从工程师到工程经理到底变了什么才过去几周。没人提前告诉我的是：什么事看起来都很急。新团队、新公司，还有一份在我来之前就堆好的待办清单。一次做不完，所以我决定先把三件事做好。
认识团队#
我在和每个人约1:1，尽量让话题围绕人本身，而不是冲刺进度。他们的职业目标是什么？最近什么事让他们烦？如果明天就能改一件事，想改什么？在这些谈话里，我的任务基本就是闭嘴听。信任第一周建立不起来，但第一周就把它搞砸是完全可能的。
每个人的工作方式也不一样。有人需要具体的方向，有人放手不管反而干得最好，弄反了双方都难受。Camille Fournier的《The Manager’s Path》把这一点讲得很清楚。说到底，共情和认真倾听就是管理的大半。
搞清楚现状是怎么来的#
流程也好，看起来奇怪的架构也好，背后都是过去的决策留下的痕迹。在改任何东西之前，我想先知道：以前试过什么，什么失败了，公司真正在乎的是什么。
每家公司还有一套潜规则，决定事情实际上是怎么拍板的。越早摸清这些，我能替团队争取到的就越多。Andrew Grove在《High Output Management》里说得对：自己不先理解大局，就没法让团队的工作对上大局。
读代码#
我不再需要是团队里代码最强的人，但架构、痛点、技术债埋在哪，这些必须心里有数。所以我在读代码、翻部署流水线，还挨个问大家：“要是有一整周空闲，你想修什么？”这个问题的答案，往往就是最诚实的路线图。
还有个附带的好处：大家能感觉到我关心的是工作本身，而不只是围着工作转的流程。
然后就别挡路#
基础打好之后，要做的事很简单：给足上下文，讲清目标，技术决策交给团队。经理的工作不是审批每一个PR，而是确保团队有需要的资源、方向没有跑偏。Gene Kim的《The Phoenix Project》也是这个观点：能自己拍板的团队，比等上面批准的团队跑得快，软件也做得更好。
新任工程经理值得读的书#
把正文里提到的三本书放在一起：
| 书 | 对新任工程经理有什么用 |
|---|---|
| Camille Fournier《The Manager’s Path》 | 专门写给从工程师转管理的人，从导师、技术负责人一路讲到 CTO，每一级要做什么。刚上手时，讲一对一和带团队的部分最有用。 |
| Andrew Grove《High Output Management》（中文版《格鲁夫给经理人的第一课》） | 书很老，写的是经营英特尔的经验，但核心观点今天依然成立：经理的产出就是团队的产出，所以时间要花在能推动它的地方。 |
| Gene Kim、Kevin Behr、George Spafford《The Phoenix Project》（中文版《凤凰项目》） | 一本小说，讲一个 IT 经理拯救一个快要失败的项目。比教科书好读，把工作怎么在团队之间越堆越多、卡住不动讲得很清楚。 |
另外，每次有人问新任工程经理该读什么，常被提到的还有两本：Will Larson 的《An Elegant Puzzle》，讲这份工作偏系统的一面（团队规模、规划、组织设计）；以及 Lara Hogan 的《Resilient Management》，一本短小实用的书，讲怎么了解团队、讲清期望、把话说明白。
半年后再来汇报进展。