在上一篇關於大人學《部屬培育與工作教導》課程的反思中，我們聊到了將部屬培育視為一種「使用者體驗設計（UX Design）」。今天，我想進一步從中階主管的實戰視角，來談談系統維護與升級。
身為主管，你是否曾遇過這樣的場景：你交代了一項任務，部屬點頭如搗蒜，結果交出來的成果卻讓你血壓飆升？或是你明明覺得這件事很簡單（因為你以前做過一百次），但部屬卻頻頻卡關，甚至在緊要關頭直接「當機」？
這時候，很多主管的第一反應是：「真的是一代不如一代。」
但如果我們將團隊視為一套正在運行的軟體系統，部屬的當機，很可能不是硬體（人）的問題，而是身為工程師（主管）的你，安裝了錯誤的驅動程式，甚至根本忘了給對方一份最新的「使用說明書」。
管理誤區：別拿 Windows 98 的驅動程式，去跑 Windows 11 的系統
許多中階主管之所以被拔擢，通常是因為他們在擔任「獨立貢獻者（Individual Contributor, IC）」時表現卓越。你是那個隨時能救火的王牌業務，或者是那個寫稿又快又好的資深公關。
因為你夠強，所以公司讓你帶人。然而，新手主管最容易掉進的陷阱，就是「試圖把部屬複製成另一個自己」。
我們習慣用自己過去成功的標準，去要求現在的部屬。我們心裡會有個預設值：「我以前都這樣做，為什麼你不行？」、「為什麼以前我們加班都沒問題，為什麼你有意見？」
這就像是你試圖拿 Windows 98 時代的驅動程式，去強行安裝在現在 Windows 11 的電腦上；或是你明明發給部屬一台只有文書處理功能的輕薄筆電，卻期待他能跑得動 3A 等級的高幀數遊戲。
當你用帶 A 的方式去帶 B，或是用你當年的「耐操」標準要求現在重視「意義感」的年輕人，系統衝突（世代衝突）是必然的。這不是部屬無能，而是出現了嚴重的「相容性錯誤」。
主管的權威，不該建立在「你要跟我一樣」，而是建立在「我能讓你在你的系統規格下，跑出最佳效能」。
建立協定：你的團隊有「README」檔嗎？
在軟體開發中，開發者通常會附上一個 README.md 檔案，告訴使用者如何安裝、如何配置環境。
每當接手一個新團隊，或是新人報到時，你是否給過他們你的 「主管使用說明書」？
很多職場上的摩擦，來自於「通訊協定」的不一致。你以為他知道要回報，他以為你在忙不敢打擾；你以為這是常識，他以為那是選配。
建議新手主管們，明確寫下（或口頭建立）你的團隊協定：
- 通訊偏好： 什麼事可以用 Line？什麼事必須發 Email？急事是打電話還是傳訊息？
- 授權層級： 哪些決策在他權限內？哪些需要先報備？哪些必須一起討論？
- 系統地雷： 什麼是你絕對不能容忍的錯誤？（例如：對客戶說謊、隱匿壞消息、不懂裝懂）
- 期望值： 對於這個職位，你對「成功」的定義是什麼？你如何檢核每個人的表現？
建立這份「README 檔」，不是為了展現官威，而是為了「降低運算雜訊」。當部屬不需要花費 CPU 去猜測主管的心思時，他們才能將所有的認知頻寬用在解決工作上的難題。
除錯機制：當部屬「當機」時，先別急著重開機
當部屬真的出包（當機）了，你的反應是什麼？
傳統的罵人、責備，就像是電腦當機時直接拔插頭強制重開機。當下或許能恢復運作，但導致當機的 Bug 依然存在，下次跑到同一個程序，還是會死機。
成熟的主管會做的是：查看「系統日誌」。
與其問「為什麼搞砸了？」，不如陪他一起回放犯錯的過程（Debug）：
- 是指令碼錯誤？ 是我交辦任務時，目標講得不清楚？
- 是資源不足？ 他的工作量是否已經超過負載？
- 還是作業系統不相容？
這裡的作業系統，指的是部屬的「內在動機」。
你不能期待把一支 iOS 的 App 直接裝在 Android 手機上跑。了解你的部屬是哪種 OS：他是被「金錢」驅動？被「成就感」驅動？還是被「自由度」或「家人的期待」驅動？
如果他重視的是舞台與成就感，你卻只給他加薪但讓他做重複性工作，他的系統運作效率就會低下。唯有辨識出對方的作業系統，你才能安裝對的驅動程式，讓他的效能最大化。
成為他人的伯樂，而不是複製人的加工廠
從「自己做」到「帶人做」，是職場專業工作者最大的轉職挑戰，也是最高的肯定。
這段過程就像是從「單機遊戲」進化到「多人連線戰略遊戲」。你不再是那個只管自己殺敵的英雄，你是負責調度資源、升級隊友裝備的指揮官。
請記得，帶人的目標不是打造出一批「你的複製品」，而是發掘每個人的獨特規格，讓他們在合適的位置上發光。
當你願意花時間更新你的「使用說明書」，願意在部屬當機時耐心地陪他除錯，你會發現，這場「產品迭代」的過程雖然辛苦，但最終你會得到一個運作流暢、且能自我修復的強大系統。
唯有在團隊基礎健全、後勤支援充足的前提下，你才能從繁瑣的日常業務中解放出來，繼續往你與團隊的下一座職涯高峰—更全面的版本更新全速前進！
