你笑著走出會議室，兩個月後你坐回同一張椅子
做了三年工程師，技術 review 比同事漂亮，年底分紅永遠在隊上前 20%，主管把你叫進去說「下個專案這組由你帶」。你笑著走出來。兩個月後你坐在同一間會議室，看著部屬交出來的 PR，心裡只有一句話：「這如果是我自己寫，三天就完成。」
這個念頭，幾乎是每一個技術人升主管後的第一道關卡。它不是壞心，甚至是一種高標準——但它會讓你輸。
這集 Podcast 介紹的書叫《普通主管才是最強主管》，原書《The First-Time Manager》從 1981 年出到 2025 年第七版，被整整三代主管驗證過。書裡的觀念沒有一個是新的，但都是沒人會主動告訴你、做錯之後才會很痛的常識。我從裡面挑了四個最反工程師本能的原則來聊。
原則一：前 90 天，是部屬在試用你
大多數新主管進入角色的第一個月，腦子裡想的是「我要評估我的團隊」。但其實方向是反的——部屬從你踏進來的第一天起，就已經在評估你了。你怎麼開會、怎麼回 Slack、出了問題第一個反應是追人還是追原因，這些細節全部都在被讀取。
前 90 天你建立的印象，會決定這個團隊往後願意對你透明到什麼程度。信任一旦沒建立起來，你之後說什麼都會被多解讀一層。
原則二：第一週，千萬不要做一對一面談
這個反直覺到很多人第一次聽都會皺眉。一對一不是很好嗎？先了解每個人？
問題是：你還沒有足夠的脈絡。第一週就把人叫進小房間「深談」，對方不知道你要做什麼，會緊張、會表演、或者會把舊帳翻出來希望新主管主持公道。你收到的資訊是雜訊，不是訊號。書裡的建議是先花時間觀察、在自然情境裡互動，等你有了基本的情境理解之後，一對一才會有真正的品質。
原則三：讚美要具體到「那個 commit」的顆粒度
「你這次做得很好」這句話，幾乎等於沒說。對方聽完的感覺是禮貌，不是被看見。
有效的讚美要具體到讓對方知道你真的看過他做的事——具體到某個決策、某個時間點、某個取捨。這不只是讓人感覺好，更重要的是它在傳遞一個訊號：我知道你在做什麼，我認可的是這件具體的事，不是在對你這個人發出泛泛的好感。對工程師來說，這個顆粒度大概就是「那個 commit」、「那個你在 code review 裡提的問題」。
原則四：「我自己做最快」是一個陷阱
這是整本書最核心的轉換，也是最多技術人卡關的地方。以前的工作叫「把事情做好」，新工作叫「讓別人把事情做好」。這兩件事的交集其實不多。
當你搶回來自己做，你短期內確實快了，但你同時做了幾件事：告訴部屬他不被信任、剝奪了他成長的機會、讓自己永遠卡在執行層而不是管理層。主管的產出，是團隊的產出，不是你個人的產出。
AI 時代的額外一層：技術權威正在失效
這集還聊到一個有趣的現象——現在帶的工程師，手上的 AI agent 寫 code 可能比你還快。當技術本身不再是主管的護城河，新一代主管的權威來源就必須建立在別的地方：判斷力、脈絡理解、替團隊排除障礙的能力。這讓「升主管是換工作」這件事又多了一層現實重量。
給還沒升、或剛升上去的你
如果你現在還在工程師的位置，這些原則值得提前想清楚——不是為了表現得像主管，而是讓你未來做決定時有一個校準點。如果你已經是新主管，這本書不會給你新框架，但它會把你已經模糊感覺到的問題說得很清楚。
有時候，你需要的不是新知識，而是有人把你早就知道、但還沒說服自己的事，白紙黑字寫給你看。
📚 同主題的其他單集 / 文章，延伸聽下去：
🎙 這篇文章延伸自 Podcast《操作一下》。想用聽的，完整一集在這裡：