Apr 12, 2026 管理洞察

T 型人才在受監管產業，到底行不行得通？

在一般企業推 T 型人才是主流，但在金融/醫療/電信這類受監管產業，職責分離和最小權限是白紙黑字的法規。T 的橫槓該怎麼畫？

最近一直在思考這個問題

為什麼大家都在推 T 型人才

在一般企業，推 T 型人才是主流：讓成員跨領域學習，提升個人競爭力，同時也讓組織更有彈性，不會因為一個人請假就停擺

聽起來怎麼看都是雙贏

管理書上說的/研討會上講的/LinkedIn 上分享的，幾乎都在鼓勵這個方向

但真正在受監管產業帶過團隊的人都知道，事情沒有這麼簡單

在金融/醫療/電信這類受監管的產業，有很多看不見的紅線

職責分離/最小權限/稽核軌跡——有些是白紙黑字的法規，有些是長年累積的產業慣例

當你鼓勵成員多學一點不同領域的技能，制度告訴你：他不應該有那個權限

當你希望團隊能互相補位，稽核告訴你：角色邊界要清楚

這不是你想不想推的問題，是制度讓不讓你推的問題

舉個例子：在電子支付產業，負責開發的人不能碰生產環境的資料庫，負責部署的人不能改程式碼。這是金管會的要求，不是主管的偏好。你再怎麼想讓工程師「全端化」，這條線就是不能跨

就算制度上可以，人的慣性也是一道牆

推動改變的人常常會遇到一種落差——你看到的是機會，對方感受到的是壓力

「學新東西」對主管來說是成長機會，對成員來說可能是額外負擔。特別是當他已經在自己的領域做得很好的時候，你叫他去學另一個領域，他心裡想的是：「我現在的事都忙不完了」

這不是誰對誰錯，而是每個人站的位置和看到的風景不一樣

後來我的思考是：在受監管的環境裡，T 型人才不是不能推，但「T」的橫槓不能跨過合規的紅線

→ 可以跨「知識」，但不一定能跨「權限」
→ 可以理解全局，但不一定能操作全局
→ 重點不是讓每個人都能做所有事，而是讓每個人都能「理解」所有事

什麼意思？

開發的人不能碰生產資料庫，但他可以理解部署流程，知道自己寫的 code 上線之後會經歷什麼。這樣他在開發階段就會考慮到部署的需求，而不是丟過牆就不管了

維運的人不能改程式碼，但他可以理解系統架構，知道哪個元件壞了會影響什麼。這樣他在處理事件時就能更快定位問題，而不是只會重開機

這就是「跨知識不跨權限」的 T 型人才

至於人的那面牆，我的經驗是：不要推著別人跑，先讓他看到走出去之後的風景

與其跟成員說「你應該學 X」，不如讓他看到學了 X 之後能解決什麼問題/能省掉多少溝通成本/能讓他自己的工作變得更順

當他自己想學的時候，你不用推，他自己會跑

我帶團隊這幾年最深的體會是：制度可以靠規劃繞過去，但人的心態繞不過去。如果你只靠制度推動改變，推得動但走不遠。如果你能讓人「想要」改變，制度反而會跟著鬆動

如果要畫一張圖，受監管產業的 T 型人才大概長這樣：

橫槓畫得好，團隊的溝通成本會大幅下降，因為每個人都聽得懂對方在說什麼。橫槓畫過頭，稽核報告上就會出現你的名字

這中間的拿捏，就是受監管產業的技術主管每天在做的事

在受監管產業工作的朋友，你們怎麼看 T 型人才這件事？是努力在框架內找空間，還是覺得在這個環境裡根本不適用？