本文並非批評任何人，而是嘗試從組織運作與職位差異的角度出發：在拿到 Senior Title 後我對於辦公室政治與決策議題更有興趣了，而這篇文就是紀錄我目前觀察到中層技術主管們在企業內如何建立影響力。
畢竟每個職級、每個部門都有其任務與立場，我認為這都沒有對錯，只是台灣中大型企業日常運作的一部分。

首先定義什麼是「三明治」，這裡的三明治是泛指在台灣公司體制「 CXX」某某長之下、基層員工之上的所有夾在其中具管理職的員工。

中層主管如何在企業內建立存在感與影響力？

對於身處公司「三明治」的中層技術主管而言，上有高層期待績效與可見成果，下有工程團隊承擔技術落地與維運負擔，要在這樣的夾縫中求生存，最常見的做法之一，就是主動解決跨部門的「痛點」問題。

這類專案看起來像是流程改善、內部工具開發，甚至某種戰略功能的 MVP，其實本質是向平行部門經營關係、向高層展示價值的一種方式：透過這些專案提升部門能見度，也讓中層主管在公司中建立了影響力。

然而這些更高層主管「看得見」的成果，往往會帶來「看不見」的技術債。中層主管們或許心知肚明，但在績效與人事評估的現實考量下，這些隱藏成本多半被選擇性忽略（反正技術債不是當下馬上就爆炸），而且日後也是指派團隊成員慢慢收拾。從管理層的角度來看，這樣的「先交差、後還債」策略，反而是一種合理的資源交換。

並且若從公司整體利益的角度來談，中層主管確實也可以理直氣壯地說：「我是在解決公司、跨部門合作長期以來的痛點」，這句話往往也無可反駁，因為確實如此。

軟體維護的隱性成本難以說清？

那如果主管決定反其道而行，花上一整個月重構系統和架構，這些為了長期維運而做的事情是否會得到認同？答案通常是否定的。

原因很簡單，太難被更高層主管看見。當他無法在主管周會或是月會上列出新功能，其他部門與高層只會看到：「你們這週沒產出」。

至於資訊研發團隊的開發體驗最佳化，這些都只是技術部門的語言，翻譯不成公司高層懂的 KPI。結果就是如果今天有人想做正確的事，需要說動很多人；想做顯眼的事，只要投其所好。

唔這種邏輯很像台灣政治，大家只記得剪綵當天的掌聲...。

影響力與技術債之間的平衡思考

這是我覺得最難的，即使我現在想玩寫完還是得回去 code 裡面打滾..。被迫當個思想巨人、行動的侏儒 :/

對於中層主管而言，想要在不犧牲團隊技術品質的情況下，仍然建立影響力與能見度，確實不是件容易的事。但這也不代表只能二選一，而是需要在組織語言與技術語言之間，找到翻譯的能力。

由於我還不是真正管理職，所以這邊我的平衡思考後面都加上個「..?」
別忘記這篇標題是「之我見」，所以內容會是我觀察公司、諮詢其他公司職場前輩或是社群朋友得到的心得。

必須想辦法讓償債也能被「看得見」..？

不要單純說「我們在重構」，而是用對方聽得懂的語言去說，例如：「為了讓未來新功能能夠在一週內交付，我們這個月的重構會把開發速度提升兩倍。」工程師不只是維護技術品質，而是在為未來爭取可預期的產出能力。

把技術債「攤」出去..？

跨部門專案一定會帶來負擔，但可以選擇做出 MVP 版本，讓其他部門先看見效果，接著和對方談接手維運、共同資源、或轉移維護責任，而不是默默地變成免費維運組。技術部門不是超人，資源應該對等。

另外有點很重要：MVP 不是 Phase 1、AB Testing 結束後要有真正選擇 A、B 的能力，如果這些 MVP 或 AB Testing 弄完還是注定要上正式環境，那就別用什麼 MVP 或 AB Testing 術語來包裹了：老闆可能分不出來，但其他人都不是傻子。

培養團隊內部共識與抵抗力..？

必須直接讓下層工程師知道，這些專案不僅對上有其價值，也會反過來能替團隊爭取什麼樣的空間與資源，也就是要建立技術決策的對話，而非讓大家單向接受。

但是台灣往往很多中層不會告訴下層這件事情：解釋完成這些（可能對公司來說也不賺錢的）專案對部門究竟有哪些幫助，能夠做到這點其實就能減緩下層工程師、團隊的情緒了。

舉個情境例子：老闆要這某核心功能 Q2 上線，中層主管聽完回部門和下屬說：這東西四月要上線，所以往前推 QA 測試時間兩週，所以我們只剩幾週可以開發..。事實上對老闆來說四月、五月、六月上都沒差，總之你 Q2 給我生出一個穩定的功能上線就好。

如果不培養團隊的共識，久了只會被團隊看破手腳，因為員工肯定會和其他部門交流的，一但打聽到老闆其實沒說具體要幾月上，只說 Q2 上，而四月居然是我們自己人喊出來的，那麼就會產生這種想法：

「這 Deadline 時間只是你自己承諾其他部門再回頭壓下面成員的，我就算晚個一週兩週做完，對公司季度戰略目標也不受影響」

完蛋了，當團隊成員有這種想法出現，那就會很難管理與對其大家的期望值。

倒不如直接說明，這個時程是為了爭取更多團隊能見度與主導權的戰略選擇。例如：「老闆雖然說 Q2 上線即可，但如果我們能在四月中就提早交付，不但能讓我們主導更多後續正式上線後的測試時間，也可以在跨部門會議上展現我們的積極性與執行力，爭取後續專案的資源與優先權。」

這種說法，比單純以「老闆說要」來壓時程，來得具說服力，也能讓團隊理解為什麼要這樣做，並產生合理的認同。

看到這邊你肯能會想：太理想了吧？怎麼可能這樣講？Simon 你是不是沒工作過？

當然是可以這樣講的，只是場合就放到部門聚餐裡這種相對 chill 的氛圍裡解釋就好。不然你以為部門聚餐是幹嘛用的？真的默默吃飯喔？

更進一步，中層主管應該主動共享「這個專案如果做得好，能換來什麼」，包括能否減少技術債、是否能申請額外人力、是否能嘗試新技術、或者在部門內建立更高可信度。這些都可以是團隊實際能感受到的非物質性報酬，而不是空泛的公司好、大家才會好。

當團隊知道這些壓力與承諾並非憑空而來，而是中層透過協商、談判、妥協後的產物，那麼對壓力的接受程度就會不同。中層主管的溝通也不再只是轉達訊息，而是建立共識，而這才是最能抵抗失衡與情緒崩潰的關鍵。

不要擦別的部門屁股擦上癮..？

很多中層主管做到後來都是消防隊，哪邊著火就往哪邊衝，跨部門出狀況也習慣第一個跳下去解決。短期來看確實會讓人覺得你可靠、有肩膀、有責任感，甚至高層會因此對你多點信任。

久了之後，這就會變成你的主業，甚至變成跨部門不主動解決問題的理由：反正你都會幫我收尾、幫我補洞，那我幹嘛提前處理？

別忘了，每一次幫別的部門擦屁股，其實都在默默耗損自己的團隊能量與資源，還可能埋下下一波技術債，或導致團隊成員產生「為什麼我們總是在收別人的爛攤子」的情緒。

等到團隊出現倦怠與流動時，可能也不會有人記得你曾經為了別人幾度衝鋒陷陣，因為那些都不是可衡量的績效，只是你剛好會的隱性義務。

最直接的例子就是 IT 或研發部門幫其他部門擦屁股：某些文書處理是這些部門該做的事情，有個情境是他們會在 Excel 或是 Google Sheet 上填寫資料，而這些資料透過某些管道、爬蟲還是什麼的最終會輸出成 json 檔案給 Backend 或 Frontend 用。

但是他們常常某個欄位漏填資料，然後產品出現不和他們預期行為就跑去詢問 PM 或 RD 排查。這些人工處理的資料漏寫，某些正常情境是沒填資料 API 就不會回傳值，結果他們又跑來盧 PM 或 RD 幫忙排查。

這裡不對勁。

文書處理這塊是文職部門應做的工作

文書軟體內是這些部門負責的事情、而輸出成資料的格式、預設值或預設畫面則是 IT 或 RD 部門負責的事情。

而這些部門大可以在 Excel 或是 Google Sheet 透過一些內置其中的表格欄位驗證功能，做到填寫資料的必填防範。

但是他們沒做，而 PM、中層主管們都想當好人。結果就是主管會議被電的永遠是產品 RD 這邊，這個職責轉嫁真的是莫名其妙，而最源頭就是中間層想當好人到處擦屁股。

最理想的情況，應該是：願意擦，但擦得有條件、有週期、有底線，並且設法讓下次能換別人處理，或共同處理。不是不幫，而是要讓每次「幫」都能帶來團隊的價值回報與能見度成長，而不是只留下內耗與疲乏。

要的是戰略合作，而不是長期奴役。偶爾還是讓該失火的地方，燒一燒給人看。

結語

寫這篇不是為了指責誰，而是想釐清自己在職涯這個階段，我看見了什麼、困惑了什麼，也想記錄一下：那些在體制中努力讓事情「變好」的人，他們究竟是怎麼被困住的。

這些觀察與思考，絕對還不夠全面。但也正因如此，我更能從下層的角度、旁觀者的距離，看見中層技術主管在組織內的掙扎與選擇。