在一場由執行長主持的月會上，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 流程中主動離職，即便他在我的臉書上公然的留言辱罵，我也沒有還口。

設計系統

壞的結構，會讓團隊表現在其中一直擺盪；好的結構，可以讓團隊持續成長突破。在了解了團隊的歷史與張力，建立了與成員的互信後，就可以開始設計或修正開發系統。在一個開發團隊中，系統的目標是產出，而主管的任務，就是降低系統的內部張力，維護系統健康，提高產出效能。

避免重造輪子，不要隨意創新開發流程；引導團隊認識業界已經認證有效，且廣為採用的框架，想辦法讓這個框架在團隊落地，並產生價值。

主管的日常充滿了責任與挑戰，也迫使自己不斷的閱讀、學習、交流與成長。套一句從「人生實用商學院」學到的話：要嘛忍，要嘛狠，要嘛滾。職場的舞台不上則下，繼續奮戰！