工程主管的自我修養

自 2013 年踏入職場開始，我都是從事軟體產品相關的開發工作，在這期間我的職涯經歷了全端工程師（Software Engineer）、後端工程師（Backend Engineer）、產品經理（Product Manager）和工程主管（Engineer Manager）等工作。

在這將近十年的工作經歷中，不論是領導我或是一起合作的工程主管都十分優秀，但有趣的是，他們彼此之間的行事作風非常不一樣。有的平時無為而治、只有在你求救時竭盡所能給予指引，也有呵護備至、但卻時刻緊盯工作狀況的主管。在我有幸擔任主管工作之初，曾經一度很掙扎，究竟自己該採用哪一種類型的管理風格？

在經過我的諮詢、訪問和實際嘗試之後，我才真正了解，沒有最完美的管理風格，只有最適合當下環境的管理方式。但即便如此，仍是有一些訣竅能夠當作檢核表，所以我整理了以下個人認為很關鍵的幾個重點，時刻提醒和檢核自己。不過老實說，真的要完全做到裡面所提的所有內容，難度真的很高，我自己也還有很大進步空間。

---

1. 準備好你的心態

1. 你不必什麼技術、系統都懂，但你必須要知道誰懂，或是指派人 / 自己去研究學習

2. 如果有時間，你應該要去了解整個 Codebase，而且最好從 Backend 開始

3. 避免 micro-management（操偶師），你的使命是了解團隊隊員的工作內容、流程，指出團隊方向，以及幫助大家工作更順利

4. 你必須隨時有意識地去摸索 top-down 和 bottom-up 的平衡點

   top-down：關注隊友工作、身心狀態，協助修正和確認團隊在對的方向。
   bottom-up：提供隊友發揮的舞台，多聆聽隊友的想法，幫忙排除路障和雜事，讓他們發揮潛力。

5. 不要害怕決策錯誤，沒有絕對的正確，只有適合當下的決策，並盡可能快速決策，不要卡超過一天

6. 你會需要面對許多過去不曾經歷的挑戰，用穩定的心態去解決它，你一慌大家就會亂，絕對穩住！

7. 管理是一門學問，但你過去從來沒有接受過訓練，你不會、不懂是非常正常的，趕緊找人討論，你的主管就是最好的學習資源

8. 勇敢地主動尋求負面批評，未來你會感謝這些願意說真話的人

9. 保持正念思考，不需要到事事樂觀，但至少能做到對自己、對他人、對團隊都是立意良善

   用 What if we … 來取代脫口而出的 No!
   但該拒絕的時候還是要拒絕啦！

2. 建立你的團隊和文化

1. 描繪一下你心中理想的團隊和工作方式（畫面感很重要），你無法一個響指就做到，但你能夠逐漸逼近它

2. 訂出明確的團隊框架和 Dos & Don’ts，讓大家有指引可以依循（但規矩別太多）

3. 不論你心中的團隊文化是什麼，但至少應該呼應公司的核心價值和文化

4. 主動去了解你的隊友，例如他們的興趣、職涯規劃、參考標竿、驅動力、強弱項、疑惑、不滿

5. 定期跟隊友溝通你對他們的期待，包含專業能力、團隊合作行為，盡量使用具體案例或可衡量的指標

6. 幫助你的隊友獲得 Spotlight，他們產生的 Impact 同時也會是你的

   比方說隊友發現的 Insights，經過你驗證無誤後，請隊友自己公開分享，同時也能訓練表達能力

7. 養成流暢的雙向回饋習慣，隨時關注隊友工作狀態，及時伸出援手進行協助

8. 你應該要學習如何為團隊招募新血，比如說撰寫 JD、審履歷、規劃面試流程、新人上工規劃等

3. 做好向上管理

1. 絕對不要揣摩上意，透明溝通，確實了解具體期待跟目標，以及背後更大的藍圖

2. 對於主管的期待和目標，不該全盤接收，如果發現有不妥之處，應該提出來討論和調整

3. 審慎設定一個具挑戰性、可行性的團隊目標，預期達成率約在 70-80%，並跟你的主管確實溝通確認

   • 負責特定產品的團隊，可能已經由 Product Manager 設定了團隊目標，Engineer Manager 也應該確認合理性。
   • 團隊目標訂定應該以 70-80% 信心程度為依歸，才具備挑戰性（不該太過輕易達到）。

4. 挑戰、限制、風險等等不確定性因子，需要向上提醒，不要讓危機悄無聲息突然爆發

5. 做好上對下、下對上的溝通橋樑，但不是當傳聲筒，你應該把資訊處理成適合對方吸收的形式

6. 你應該具體表達你需要主管提供什麼樣的支援或行動，以及背後的考量是什麼

4. 與你的同儕們共事

4-1. 與其他 Engineer Managers

1. 你應該要對於不同單位的守備範圍有基本的認識

2. 在某些情況下，單位之間勢必存在些模糊地帶，你要能夠接受這樣的模糊地帶，並漸進式釐清

3. 在不影響自己團隊目標的前提，與其他 Engineer Managers 有良好協作關係，包含但不限於支援部分工作、給予專業上的建議

   多數情況下，各團隊隊友應專注於團隊目標發展，但在少數較為複雜的專案，或是商業上短期衝刺的必要時，應彼此支援來達到公司效益最大化

4. 應該要跟其他 Engineer Managers 一起巡邏產品健康狀態，將新的維護工作進行分發安排

   其他團隊的工作：at 對應 Manager、加到其他團隊看板
   自己團隊的 bug：評估嚴重性，安排隊友現在或未來維修
   自己團隊的 Product Feedback：加到對應看板，並 at PM 等相關人士

5. 當你意識到功能或專案可能會需要其他團隊的支援時，需要儘可能提早知會，讓對方預留資源

6. 建議可以在以下幾個時間點審視是否需要知會其他團隊（越早越好）

   團隊年度、季度規劃進行中或已確定時
   專案準備開始之前，或是專案初期研究階段（你在準備技術解決方案時）
   肯定有些事情是專案進行途中才發現需要支援，請盡可能快速溝通

7. 溝通時必須明確具體表達期待（範圍、時間），並協調出解決方案，因為資源不會一直空在那邊等你

8. 若是其他團隊因為 priority 衝突無法支援，因而影響到自己團隊的規劃，你需要有能力找自己或是對方的主管進行協調，不該讓團隊卡住

9. 若是所負責的團隊有新的功能、技術、洞察頗具效益和發展機會，應主動與其他 Engineer Managers 分享

4-2. 與團隊的 Product Managers or Product Designer Leads

1. 定期和 PM & PD Leads 討論 Product Feedbacks 的工作安排（由 PM 發起），並給予工程技術上的回饋

2. 參與 PM Sync-up，清楚產品發展藍圖，並主動給予專業技術上的建議和看法

3. 在每一年及每一季跟 PM 一起訂定年度、季度目標及發展規劃

4. 主動向 PM & PD 分享由 Engineers 發起的點子或專案，讓事情能夠被團隊安排進去

5. 在產品功能或專案規劃前期就加入討論，主動了解目的、目標，並提出技術解決方案幫助 PD 收斂設計

6. 根據產品需求或設計提出解決方案們，並能夠清楚說明 pros & cons，幫助大家一起（或自己）做決定

7. 具產品需要的相關技術知識，或知道該問哪位關鍵隊友，有意識地將解決方案和規模調整成時程面合理的最佳瘦身狀態（Time is money！）

5. 塑造團隊工作流程

1. 團隊會根據產品發展藍圖，安排大、中、小型規模的專案，你應該與 PM & PD 合作，共同建立並持續優化流暢的合作流程，包含但不限於：會議模式、文件形式、Definition of Done、測試、功能驗收方式和上線後的成效追蹤（成功指標、健康指標）等

2. 你也應該關注工程師內部的合作流程，包含安排系統代理人、固定邀請隊友分享系統設計、指派隊友（或自己）研究新技術及應用場景並內部分享。目的是建立 backup 機制，以及讓團隊專業能力提升。

3. 持續觀察和優化團隊合作流程，以及透過工具、流程改善來提升工程團隊的工作效率

4. 根據 Best Practices 歸納出一套工作 framework，以便人員變動的情況下，新隊友能夠快速進入狀況

   並非一定要是 SOP，也可以是 Guidline 的形式（重點是有可參考的依據）
   請想像：今天有一個或多個新隊友加入團隊，你要怎麼樣讓他們快速進入狀況？

5. 掌控專案開發時程和資源分配，讓工作能夠如期完成，甚至在規劃或開發過程能用更有效率的時間達標

6. 幫助團隊盡可能專心在重要事情上，除了單純的排除掉雜事之外，你應該要能夠權衡「什麼可以不做」（減法很重要），讓投資效益最大。當然有時候還是可以讓他們做雜事轉換心情，但不該太過頻繁

7. 你需要分擔部分的開發工作，甚至不是你專業領域的開發工作，來讓團隊保持專心

8. 當你發現隊友同時間在處理三件（含）以上的任務，並且多數工作將少量時間切割得很破碎，導致有些工作花不到 15% 的時間，就要警覺

   範例：70% 開發專案，30% 在處理二至三件雜事。短期可接受。
   範例：50% 開發專案，50% 在處理五件雜事。注意力太分散。這是個警訊。

9. 透過跟進隊友日常工作狀態，來觀測和評估開發時程是否存在風險，提前知會 PM 並安排應對行動

6. 優化產品開發體驗

1. 你需要透過日常工作或是隊友分享中，了解目前產品開發的痛點是什麼

2. 你應該像是 PM 面對 Product Feedback 的態度去面對這些痛點，為他們排定 priority

3. 能夠彙整收攏這些痛點，跟隊友一同找出可能解決方案，並且有系統地去安排處理

4. 你需要將這些痛點回饋給 PM，讓他們理解並預留空間時間給團隊處理

5. 你可能會需要與其他 Engineer Managers 分享或溝通這些痛點，並且一起合作解決

6. 開發者體驗和快速發布有時是需要權衡利弊的，疊床架屋滿足需求的同時，也需要安排未來回頭優化

7. 開發體驗糟糕並且沒有規劃改善的狀態下，工程師的效率和情緒是會受到影響的，需要放在心上

8. 幫助團隊建立良好的開發習慣，確保團隊產出良好的品質，鞏固產品穩定性

7. 帶領工程團隊創造更大的影響力

1. 能夠加入團隊的隊友絕大多數都是優秀的，你應該盡可能激發他們的潛能，push 他們的創新能力

2. 工作飽和的狀態下，是無法做到創新的，這是需要時間和空間思考，所以你應該有意識地去控制工作量

3. 建議產品功能開發安排在 80% 以內，剩餘 20% 用於改善開發體驗、專業技能成長、創新點子嘗試等

   整理文件至 Wiki、嘗試新的工具或流程、系統設計分享、新技術 / 想法嘗試，屬於 20% 範疇

4. 你要能夠籌備由 Engineers 發起的專案，專案規模可能是只限於 Engineers 自己進行，甚至是整個團隊（含 PM、PD…）一起去做

5. 工程團隊若將自己定位為單方面接受 PM 的想法和規劃，會很可惜，因為通常工程的創新和實作能力也是很棒的。我們應該要跟 PM 做好雙向交流溝通，互相理解來創造最大價值。