船長偶爾划槳: 工程主管該不該寫 Code?
工程主管還需要寫 Code 嗎？關鍵不在產出，而是維持技術體感。本文探討從執行者轉型領導者的心法，分析 AI 時代下何時該親自下場、何時該放手。透過「船長偶爾劃槳」的哲學，運用乘法思維校準方向，放大團隊最大價值。
領導的價值不在於做了什麼，而在於能讓團隊做什麼。
1. 從執行者到領導者的陣痛
2. 加法與乘法: 兩種截然不同的思維
3. 理解的邊界: 看 code 與寫 code 的鴻溝
4. 體感: 對不可預期的掌握度
5. AI 時代: 追求問題而非解法
6. 判斷準則: 何時該下場,何時該放手
7. 船長偶爾劃槳歡迎回到《非正式寫作》理解複雜世界，前往那尚未被命名的自己。
最近讀到 Will Larson 的一篇文章 [1]，他提到自己加入 Imprint 擔任 CTO 後的六個月裡，合併了 104 個 pull requests，比過去十年加起來還多。他的論點很直接：AI 工具降低了寫 code 的時間成本，所以主管可以更多地參與編碼工作。
這讓我開始思考：工程主管到底該不該寫 code？
表面上看，這是個「該不該」的問題。但深入下去，我發現真正的問題其實是：為了什麼而寫？何時寫能產生乘法效益？何時不寫反而是更負責任的選擇？
《非正式寫作》探索並理解當代世界的多面向特質。
週一更新。馬上訂閱，與 1600+ 位讀者一同升級 ⬆️
① 從執行者到領導者的陣痛
能夠成為主管的人，必然曾是優秀的執行者。我們習慣用「交付」來感知進度、用「產出」來衡量價值。當這樣的人升遷到管理職，角色的轉換並非一蹴而就 — 要求一個戰力滿點的 IC 馬上轉換成乘法心態，是不太可能的。
我想每個從 IC 升上來的主管都有體會。也許都要經過一些團隊動盪，才能醒悟自己更大的責任其實是掌舵，而不是奮力劃槳。
以很快的速度前往錯誤的地方，會讓以速度引以為豪的執行者醒悟到掌舵者的重要性。
※
② 加法與乘法: 兩種截然不同的思維
最容易混淆的動機，我認為是誤以為寫 code 才算產出，忽略了領導是乘法不是加法。
加法思維就是看到一件事就想著如何解決，一是一、說一是一。看起來很有執行力，實際上事倍功半。
乘法思維會拋出更多為什麼，找到更多槓桿點：如果一件事能不做，那為什麼要做？如果一定得做，能不能一魚多吃，做一件事少十件事？如果值得做，怎麼讓它順勢而生，而不會持續被那些所謂很急的任務排擠？
加法的危險在於：你以為自己在幫忙，實際上可能只是在滿足「我今天有產出」的安全感。乘法的挑戰則在於：如何將自己的貢獻可視化，建立一套回饋閉環，不斷優化自己的方向校準和力量放大是否真正奏效。
什麼時候主管要綜觀全域，什麼時候要親身實踐？取決於團隊的能力和規模。
規模越大，劃槳的一致性就越難對齊，掌舵者需要花更多心力協調；能力越強，每個人主動性都很高，能夠自發性地迭代校準，掌舵者就能省下心力，也參與到劃槳的行列。
※
③ 理解的邊界: 看 code 與寫 code 的鴻溝
那麼，主管真的需要寫 code 嗎?
我的答案是：不一定需要，但需要理解。
通過 code review，我可以理解業務邏輯如何透過軟體的抽象對應出來。理解這個關係，就能做出正確的技術決策，掌握時程，進一步幫助團隊排定正確的優先序。
AI 工具在這方面幫了大忙。現在的上下文視窗已經可以容納下常規應用的整個代碼庫，你可以像調整焦距一樣，以各種不同尺度來理解一份複雜的程式邏輯：從整體架構到模組職責，再到具體的某段 code。擁有一個伸縮自如的透鏡，可以更快在腦中形成理解的結構。
相比以前從零開始 code review，像瞎子摸象或拼圖一樣，前期花費大量時間東拼西湊才能慢慢構築起結構，現在的效率提升是顯著的。
但看 code 與實際執行，始終有一段落差。
系統不會獨立存在，必定是與許多其他系統整合的結果。真正下去實作，遇到那些實際的困難：API 不穩定、資料格式衝突、時序問題，才能真的瞭解。簡單來說，看是一回事；做又是一回事。實際做的時候可能會有各種突發狀況、不在預期內的挑戰。
這些或許可以透過經驗提前預知，不過就是這種不可預測性，才讓軟體開發這樣的創造性活動充滿趣味。
※
④ 體感: 對不可預期的掌握度
設計階段有許多假設，很多假設都要等到實作時才能被驗證。
這就是為什麼主管偶爾需要寫 code！不是為了產出，而是為了保持對「不可預期的掌握度」的體感。
這個體感是什麼？就是當你經常接觸時，這個 sense 能越準確地預測；當你太久沒有接觸，那麼這個 sense 就會偏離。
一個體感準確的主管，在聽到團隊說「這個兩週能做完」時，能夠綜合考量開發者的能力做出準確反應。一個體感失準的主管，可能會被團隊唬弄、或者激怒團隊 — 質疑「為什麼需要那麼久」。
在時程管理上，相依性高的系統通常要抓更多緩衝時間，正是因為這些「設計時的假設」需要在實作中驗證。主管如果沒有實作經驗，很容易低估這個驗證過程的不確定性。
偶爾實作，能夠讓你保有這種體感。頻率取決於團隊面對的開發緊湊程度：越緊湊的開發進度，就需要越頻繁的體感校準。我認為通常每個月需要碰一碰。
主管寫 code 的價值不在於產出，而在於校準對執行現實的感知，從而做出更準確的判斷。
※
⑤ AI 時代: 追求問題而非解法
AI 時代帶來了新的變數。
Larson 認為 AI 降低了寫 code 的時間成本，所以主管可以更多參與。這個觀察是對的，但我認為更重要的變化是：技術迭代加速了 假設-現實 的漂移。
像現在許多 AI 技術出現，大幅縮短了某些任務所需的時間。主管如果對這個技術沒有掌握，就無法做出正確的風險判斷。如果沒有親手用過 AI coding tools，當工程師說「這個用 AI 三天就能做完」時，你無法判斷是真的可行，還是過度樂觀。
體感偏離：可能過度樂觀(以為什麼都能加速)；也可能過度保守(不相信 AI 真的有用)。
但這不代表主管要追著每個新工具跑。工具太多了，與其去瞭解功能本身，不如去探究問題的本質。唯有把問題的本質看清楚了，才能不被炒作過多的工具迷惑。
當新工具出現時，追求解法的主管會想「哪個工具最好」；追求問題的主管會想「產生了什麼新問題，更適合這個工具」。
問題與工具是一體兩面的：問題催生了解決方案(工具)，新的解決方案可能催生新的問題。主管需要親手驗證某個新工具，不只是為了學會用它，而是為了理解它解決了什麼問題，發現它帶來了什麼新問題，判斷這些新問題是否值得承受。
只有親手用過，才能感受到 trade-off 的真實性。
只要是一個有所「追求」的技術專家，肯定會有追不上的焦慮。但回到那個答案：不要追求解法，而是追求問題。理解「問題本質不變，只是解法在迭代」可以減緩焦慮！
※
⑥ 判斷準則: 何時該下場,何時該放手
那麼，什麼時候主管該寫 code？什麼時候不該？
首先要理解：技術工作不只是寫 code。需求確認、規格訂製、架構設計、維運考量，這些都是環繞寫 code 的技術工作。主管應該觀察團隊在哪個環節是短板，引入自己的經驗來起到身先士卒 (自己做一次，然後剩下的請成員按照同樣思路執行) 的效果。在日常的團隊技術會議中就可以觀察出來。
主管該寫 code 的時機：
當新技術或工具會顯著改變時程基礎假設時。特別是那些能帶來乘法效益、不會用在緊急任務、具有前瞻性但短期不一定產生效益的技術。這類技術通常團隊太忙無暇探索，主管有時間可以先行驗證。
當需要理解「新工具帶來的新問題」時。不只是學會用，而是感受 trade-off，避免盲目引入技術債。
當你發現自己的判斷持續與執行結果偏離時。這是體感失準的信號，需要重新校準。
當團隊對某個技術方案評估分歧很大時。需要主管用實作來破除爭議，做出有根據的決策。
主管不該寫 code 的時機:
當任務緊急且時間敏感時。你的介入會打亂團隊節奏，保護團隊的執行效率更重要。
當任務只有加法效益時。如果你投入時間與產生效益是 1:1，就要仔細考慮是不是應該委派出去。事前要評估，事後也要回顧，從落差中習得經驗，之後判斷就會越來越準。
當團隊能力足夠、只是需要時間時。你的介入會剝奪成長機會，養成依賴，長遠來說反而不好。自己跳下來做可能快一時，需要調適，需要耐心。
當你只是為了「感覺有產出」時。這是最關鍵的動機檢查：你是為了團隊，還是為了自己?
最重要的三條準則:
不要為了感覺有產出而寫 code，主管最大的價值在於放大團隊的優點與效益。
也不要完全不碰 code，久了會失去對時程的 sense。
專注在乘法效益，如果今天主管投入時間和產生效益是 1:1，那就該委派。
※
⑦ 船長偶爾劃槳
回到根本的問題：主管的價值到底是什麼?
我認為最重要的就兩點：校準方向(掌舵) 與 賦能團隊(放大眾人劃槳之力)。
加法思維的危險在於事倍功半。乘法思維的挑戰在於，如何將自己的貢獻可視化，如何建立回饋閉環，驗證方向校準和力量放大是否真正奏效。參考：《別再測量錯誤的事: 績效指標設定指南》
掌舵者會記得怎麼劃槳，但會失去劃槳的 sense。失去 sense 後，無法準確判斷劃多久會累、水流阻力多大、劃槳節奏如何。偶爾劃槳，就是為了保持這個 sense。
判斷的準確性如何放大團隊效能？時程估得更準、團隊壓力更小；技術選型更準、少走彎路；風險預判更準、少踩坑。這些看似微小的改善，累積起來就是巨大的乘法效應。
身份認同也在這個過程中轉變。個人貢獻者的時候，身份認同在於做事又快又省又好。到了管理者，身份認同在於團隊朝一致認同的方向前進。一個人走得快，一群人走得遠，到達一個人無法到達的目標。
比如要把原本的報表系統引入新的 agent 探索互動方式，這種會涉及不同系統整合和團隊合作的長遠目標，很難靠一個人完成。主管在這種任務上的角色，就是拆解複雜的問題、協同不同角色的分工、管理前進的風險。
工程主管該不該寫 code？這不是該不該的問題，而是:
為了什麼而寫？
何時寫能產生乘法效益？
何時不寫是更負責任的選擇？
AI 時代降低了寫 code 的時間成本，但更重要的變化是技術迭代加速了假設-現實的漂移。主管需要更頻繁地校準 sense，但校準的目的不是保持技術能力，而是保持判斷準確性。
船長偶爾劃槳，不是為了推動船，而是為了更好地指引正確的方向。
🔍 工人智慧猜你也喜歡
我用熱情為燃料進行寫作，您的鼓勵使我不至於 burn out：
請我喝杯咖啡 ☕
將其轉發給可能也會欣賞它的同伴。
留言告訴我什麼讓你印象深刻，分享你的想法，或只是打個招呼。
💡 歡迎約 coffee chat 閒聊。如果您想探討合作方式，請透過我的社群媒體聯絡我，或回覆此郵件。
❏ 本週好讀 🛋️
🔗 References 🔗
[1] Coding at work (after a decade away) - https://lethain.com/coding-at-work/