读：空降管理者六个月踩坑实录
Anton Zaides 在 manager.dev 上写了一篇真诚的回顾。经过九个月的职业空白期后他加入了一家新公司，作为空降管理者接手已有团队。他之前做过四次管理者，前三次都是从内部晋升，第一次接手一个 不是自己建起来的团队 。他的计划很清晰，前六到八周安静地读代码，甚至做几周技术支持，在旁边观察团队怎么运转。入职前所有人都同意了这个方案。
结果这个计划第一天就废了。
阶段一，先看人，再看代码
他拿到电脑的第一个动作是跟七个工程师逐一聊了一轮。一聊才发现，三天前团队刚被重组到新的业务线，塞进一个全新的项目，换了一个新的产品经理。过去六个月更离谱，没有管理者，没有一对一沟通，七个人被拆到四个完全不相关的项目上。用他们自己的话说，这个团队已经名存实亡了。
原本的安排是，过渡期间工程师继续向原来的总监汇报，新总监负责日常管理。问题在于，原来的总监跟团队已经没有实际接触，新总监对项目毫不关心。如果他按原计划消失在代码里，等于这七个人继续处在没人管的状态。
他的团队配置也跟以往不同。一个前任 EM（现任 staff engineer），另外两个 staff 工程师，两个 senior，两个 mid-level。技术层面完全不需要他插手。六个月的混乱期加上新的项目、新的产品经理、新的总监，团队需要有人 把大家重新聚起来 。
于是他放弃了学代码的计划，第一个月 90% 的时间在开会，跟组织里所有相关的人做一对一沟通，跟新产品经理反复对齐，处理日常事务。他的总监其实希望他先把技术基础打好，但他觉得当时的局面不允许，坚持了自己的判断。
"前 30 天只学不干"这条建议有个前提，那就是团队没有燃眉之急。如果团队已经处于失管状态，你的消失只会让问题继续恶化。但快速切入的力度要有控制，否则会直接掉进下一个坑。作者自己也认为介入是对的，只是纠正得太猛了。
阶段二，别急着证明自己
作者在第一个月底开了第一次团队会议，把所有流程都摊开来讨论。迭代周期多长、冷却期要不要、站会怎么开、团队会怎么开，大家一起定了三周迭代加一周冷却的节奏。
Shape Up 是 Basecamp（就是做 Ruby on Rails 那家公司）提出的项目管理方法。跟传统冲刺不一样的地方在于，每个周期后面跟着一段强制冷却期，不接新活，不赶上一轮的尾巴，专门用来修修补补、还技术债、或者纯粹歇一歇。
然而他们团队负责的是一个全新的技术领域，到处都是意外和阻碍。作者自己也承认，技术对话大概只能听懂 30%，大部分是 Ruby on Rails 的后端，他完全没碰过。第一个迭代快结束时，他感觉就差一点点就能交付了，于是就要求三个工程师在冷却周继续加班赶工。这样一来，工程师很不满意，因为冷却周的本意就是让大家歇一口气，而不是接着赶上一轮的进度。
第二个迭代好一点，但主体部分还是没完成。这一次，团队里最资深的工程师把他拉到一边，说你逼得太紧了。他事后也承认，自己太想早一点拿出成果出来，所以拼命压缩范围想尽快发布。结果是所有人一直觉得在追赶、在承压。
当时处于太多未知数的状态，持续施压是不健康的。如果他是从内部晋升上来的、对技术栈有理解，这个情况可能不会发生。但他没有这个背景，就更容易把"感觉快完成了"当成"确实快完成了"。到第三个迭代周期，大家终于找到了节奏。做 demo 的时候人们笑着聊天，那一刻他才感觉，大家终于像一个团队了。
空降管理者跟内部晋升的管理者最大的区别就在这里。内部晋升的至少知道哪些坑是真的坑、哪些只是看起来像坑。空降的没有这个优势，更需要克制推动的冲动，留出团队自己摸底的空
人稳了，交付也找到了节奏，但还有一件事很容易被忽略，那就是运营。
阶段三，运营债务是慢性炸弹
大约两个月后，他终于有时间喘口气，开始看一线支持的情况。团队每周安排一个人负责处理所有进来的工单，他之前一直没管这块，觉得团队已经这么运转了半年，应该不急。
一看吓一跳，一共有21 个未关闭的工单，有的已经开了一个多月。连续三周新开的工单比关掉的多，雪球越滚越大。主要原因是有些维护区域没人熟悉，调试起来特别痛苦，大家都拖到最后才做。
他跟一个工程师一起组织了一次集中修复。包了一间会议室，订了午饭，买了些小奖品，谁完成一个工单就可以抽一次奖。一天下来关掉了 18 个工单，其中很多是修了根因而不仅是打补丁。他自己挑了两个最难的来搞，接下来的几周还亲自参与了一轮值班，自己亲身体验。
从这以后他开始更多地参与一线支持，替人顶班，顺便熟悉产品。
运营债务不会自己消失，而且它有加速效应。新开的比关掉的多，趋势就在恶化。集中清理比慢慢还债有效，因为它既解决了积压，又迫使团队面对那些没人愿意碰的老问题。管理者亲自上手是获取产品认知最直接的方式。
一切重置
四个月过得很快。从关注人，到关注交付，到关注支持，节奏总算稳定了。大家有了说话的对象，知道公司对自己有什么期望，团队有了自己的小传统。
然后两件事同时发生。又一次重组把团队调到一个从零开始的新项目，而他的妻子生下了第二个孩子，他休了一个月的陪产假。
回来之后又开始重新校准。六个月前入职时做的计划是废纸，现在做的计划大概过几周也会变成废纸。这三个阶段不是一次性走完的，每次变化都需要转换注意力，又得从头判断团队缺什么、自己该把精力放哪。他说，唯一有效的方法就是注意观察，纠正偏移，然后在别人告诉你修过头了的时候，听进去。
小结
这篇文章没有万能模板，但它让人看到一个实在的模式。空降管理者的注意力应该跟着团队的实际状态走，团队失管的时候先补人的缺口，团队稳定以后再去碰交付和运营。每个阶段的切换都可能用力过猛，关键是每过几周就回头看看自己的注意力放在哪了，是不是该切换了。