[Day04] 空降主管的战地生存术

在一场由执行长主持的月会上，HR 念了一个同事提出的疑问：「公司对工程师的面试标准这麽高，却对管理职的面试这麽草率，让不合格的人进来带人。」在场包括我在内的空降主管们，个个面色凝重，浑身不自在。换位思考，如果我是早期员工，当公司进入成长轨道，却是由一群外来血统的人占居管理位，换作是我也会不服气。一位总经理级的职场前辈曾提点过我：要让老板信任你，放手让你干，先累积一定的信誉 (Credit) 再说。因此新任主管的首要任务，我认为是建立与团队的默契与互信，调整团队体质，团队绩效的提升，就是主管的 Credit。本篇就来聊聊，我的五个空降求生心得。

用欣赏代替批判

一个组织，会向外寻找主管的主要原因不外乎两个：

1. 有急须解决的问题
2. 老板认为内部成员还未准备好

虽然是事实，但如果初上任，就心急的把原本团队的流程、方法、习惯进行改动，无异於跳伞却忘记开伞。任何一个团队，都是一个独特演化成型的系统，实务面上，团队的程序架构、代码风格、程序码管理、发布流程、CI/CD 都极大的可能与先前的经验不同，空降主管首先要努力的，就是去习惯眼前的系统。

可以采用的策略是「原子习惯」里面提到的：身份认同。提醒自己是一个会欣赏多元性，不轻易根据表相来批判团队的主管。抱持着学习的心态，开始理解每一项设计背後的原因，赞赏其聪明之处，佩服团队在有限的资源(时间与资金)下，可以完成交付。让团队成员可以在心理安全的状况下，分享设计概念，加速自己掌握产品的输廓，同时，对於系统中的存在的问题，也可以建立初步的理解。

建立待解问题清单 (Backlog)

曾经共事过一位实务经验丰富的主管，在上任前就颇被高阶主管看好，上任後雷厉风行，几乎每周都能推出一项新的工作规则，并且密集地指导团队成员最佳实践方法。但甫过一个月，他开始埋怨团队没有照指示运作，团队认为他没有搞清楚前因後果就调整工作流程，导至产出下滑。在与他的访谈中，我发现他的确看到了很多问题，为了证明自我价值与勤奋，也积极的在处理每个问题。但问题就出在这，他处理「每一个」眼前遇到的问题。而大约一季，这位主管就被转任到其他部门担任工程师。

用 Scrum 开发来类比，把团队当成一个产品，主管就是 Product Owner。团队的问题就是产品需求，主管应该先将需求放入产品的待办清单 (Backlog)中，进行价值排序，然後挑最重要的问题，进行精链 (Refine)，设法识别出问题的根本原因，最後才是进行解决问题的冲刺 (Sprint)。 然後重复进行跌代。

至於价值排序，我建议的原则，跟公司营收相关的问题，重要性最高。例如商品购买流程的测试计画可能有漏洞，就要优先处理。其次是与团队效率相关的问题。至於其他只是自己不习惯，看不顺眼，不改不会死的问题，就尽量往後放。禅机未到，虽点不中；机缘到了，一点即中。

辨识团队张力

人，是团队系统的组成要素。在开发团队中，成员间的连结与协作，会透过工作流程来定义。而只要有人际间的互动，就会产生「张力」(详细请参考「最小阻力之路」)。举一个简单的例子：QA 需要在某个时间点拿到 RD 的产出进行验证，而 PM 依赖 QA 的验证结果，确保发布品质，而只要其中有一个环境的时间延误，或是发生预期外的状况，就会导至 PO/PM 产生发布可能会失败的压力，然後 PO/PM 不得不开始紧迫盯人，追踪进度，减缓自己对不确定性的忧虑，但又造成了 RD / QA 端的压力，准备要找地方释放。这像极了两方中间有一个弹簧，当一方走进，另一方就被压缩，而产生的回弹的力道。这些彼此间的不适与压力，就是张力。

团队的冲突与效率低落是表相，张力才是问题的根源。所以纾解张力，就是解决问题。张力的纾解，没有想像中的轻松，因为张力是来自於既有的结构；团队的既有结构力是很强的，它会不知不觉地带着团队成员又回到习惯的做事方法。因此，真正的纾解之道，是在创造新的结构，新的系统。这也是我观察很多优秀的经理人，一直在组织中做的事情。

被呛不还口

我曾经被团队成员给过以下的建议与评论：

A 同事：「为什麽要逼我估点，我时间到就会交出成品」

B 同事：「我们的团队就不敏捷啊，我看不出有什麽你的修正会有什麽效果」

C 同事：「你是我遇过最烂的主管!」(在我 FB 贴文)

一旦当了主管，我想上面这种直球对决的戏码一定闪躲不了。张力也会存在於主管与成员中间，当张力的纾缓很常会透过言语释放出来。「生命的十二法则」的第九项法则提醒我们：深入的对话不容易发生，因为很容易陷入竞争与二元对立。新主管与原有团队成员的沟通，很容易发生双方结构的碰撞，而导至僵局。

我的原则很简单：被呛不要还口。跟团队成员的争论，主管永远是占上风的；竞争就有输赢与对错，但这种情境下只会双输。承认成员面临的张力是重要的，重新去了解对方的张力来源，想办法化解它，才能让双方向前走。

上述的 A 同事，带着他理解了估点用意与对团队的帮助後，他创造了一个拆分任务与估点的实践方法，一年後被我推荐升等成功。B 同事，在恳谈後，我发现他对敏捷开发有极高的热情，在清楚的解释我的开发系统与目标後，接替我承担了 Scrum Master 工作，并且协助开发了敏捷管理工具。 C 同事，因违反工作伦理，与其他团队存在着无法改善的张力问题，在 PIP 流程中主动离职，即便他在我的脸书上公然的留言辱骂，我也没有还口。

设计系统

坏的结构，会让团队表现在其中一直摆荡；好的结构，可以让团队持续成长突破。在了解了团队的历史与张力，建立了与成员的互信後，就可以开始设计或修正开发系统。在一个开发团队中，系统的目标是产出，而主管的任务，就是降低系统的内部张力，维护系统健康，提高产出效能。

避免重造轮子，不要随意创新开发流程；引导团队认识业界已经认证有效，且广为采用的框架，想办法让这个框架在团队落地，并产生价值。

主管的日常充满了责任与挑战，也迫使自己不断的阅读、学习、交流与成长。套一句从「人生实用商学院」学到的话：要嘛忍，要嘛狠，要嘛滚。职场的舞台不上则下，继续奋战！