这个月我开始带一个工程团队，距离我写从工程师到工程经理到底变了什么才过去几周。没人提前告诉我的是：什么事看起来都很急。新团队、新公司，还有一份在我来之前就堆好的待办清单。一次做不完，所以我决定先把三件事做好。

认识团队

#

我在和每个人约1:1，尽量让话题围绕人本身，而不是冲刺进度。他们的职业目标是什么？最近什么事让他们烦？如果明天就能改一件事，想改什么？在这些谈话里，我的任务基本就是闭嘴听。信任第一周建立不起来，但第一周就把它搞砸是完全可能的。

每个人的工作方式也不一样。有人需要具体的方向，有人放手不管反而干得最好，弄反了双方都难受。Camille Fournier的《The Manager’s Path》把这一点讲得很清楚。说到底，共情和认真倾听就是管理的大半。

搞清楚现状是怎么来的

#

流程也好，看起来奇怪的架构也好，背后都是过去的决策留下的痕迹。在改任何东西之前，我想先知道：以前试过什么，什么失败了，公司真正在乎的是什么。

每家公司还有一套潜规则，决定事情实际上是怎么拍板的。越早摸清这些，我能替团队争取到的就越多。Andrew Grove在《High Output Management》里说得对：自己不先理解大局，就没法让团队的工作对上大局。

读代码

#

我不再需要是团队里代码最强的人，但架构、痛点、技术债埋在哪，这些必须心里有数。所以我在读代码、翻部署流水线，还挨个问大家：“要是有一整周空闲，你想修什么？”这个问题的答案，往往就是最诚实的路线图。

还有个附带的好处：大家能感觉到我关心的是工作本身，而不只是围着工作转的流程。

然后就别挡路

#

基础打好之后，要做的事很简单：给足上下文，讲清目标，技术决策交给团队。经理的工作不是审批每一个PR，而是确保团队有需要的资源、方向没有跑偏。Gene Kim的《The Phoenix Project》也是这个观点：能自己拍板的团队，比等上面批准的团队跑得快，软件也做得更好。

新任工程经理值得读的书

#

把正文里提到的三本书放在一起：

另外，每次有人问新任工程经理该读什么，常被提到的还有两本：Will Larson 的《An Elegant Puzzle》，讲这份工作偏系统的一面（团队规模、规划、组织设计）；以及 Lara Hogan 的《Resilient Management》，一本短小实用的书，讲怎么了解团队、讲清期望、把话说明白。

半年后再来汇报进展。