Individual Contributor：工程師不當帶人主管的職涯選擇

「我是資深工程師，但我在猶豫要不要當主管（manager）。我真的很喜歡當工程師，但我覺得我只是不斷重複解決同樣的問題。關鍵好像是『人』的問題，我必須要當上主管才能爭取升遷⋯⋯」前 Facebook Production 工程主管 Charity Majors 在提供職涯諮詢時，反覆見證工程師面臨類似這樣的掙扎。

同樣走過這一遭的前輩，還有現任 Stripe 技術負責人的 Keavy McMinn。她 2019 年在邊緣運算服務獨角獸 Fastly 擔任資深首席工程師時接下主管職，嘗試了 73 天後，證實這不是自己的熱忱所在而放棄。雖然多數同輩的同行都是帶人主管，她仍選擇為自己開闢一條新路：以工程師而非主管的角色去鑽研技術和產品問題，並帶領組織的技術和戰略方向。¹

這條路，叫做資深 Individual Contributor——所以她在 Stripe 的職稱雖然是 Tech Lead，但實際上屬於首席工程師或首席架構師的角色。

這篇文章想討論的，就是在台灣比較少見的 Individual Contributor。這是什麼樣的角色？和傳統的職涯發展路徑有何不同？以工程師的職涯來說，Individual Contributor 又會發揮什麼樣的作用？在組織文化中，我們應該如何看待 Individual Contributor 的存在？

Individual Contributor 和帶人主管的升遷路徑並行

Individual Contributor 常被翻為獨立貢獻者或個人貢獻者（後文簡稱 IC），根據全球最大求職平台 Indeed 定義，IC 不負擔管理責任、沒有直屬的下屬；可能是流程或專案的負責人，亦可作為團隊的一份子或單獨完成任務；關鍵差異是比管理者（manager）擁有更多自己運用的時間提升技能，成為領域專家。²

一般來說，矽谷軟體工程師的升遷分為 IC 和管理職兩線並行，在 levels.fyi 可以看到各家公司之間職務能力階梯（career ladder）的對應關係，而軟體工程師和管理職（software engineer manager）就是兩種不同分類。

公司會提供 IC 這樣的選項，初衷是讓工程師不必放棄熱愛的技術工作又可以累積升遷的資本，不過 IC 的發展結構相對扁平，有人認為這在職涯上是一條「死路」，少數例外則是「10 倍工程師」這類大神。³

像人工智慧領域的大神 Jeff Dean 與 Sanjay Ghemawat 在 Google 共事超過 20 年，都是 Level 11 的 Senior Fellows，不過 Sanjay Ghemawat 就正是擔任 IC；Envoy 是許多企業都採用的開源專案，其開發者 Matt Klein 自從 2015 年加入 Lyft 擔任工程師以來都是 IC，他認為自己對技術問題的熱忱能發揮更大的影響力，也無意成為主管，所以 Lyft 考量他對 Envoy 的貢獻和業界的影響力後再次調升他的 IC 職等。

Last week I sat for an internal interview about my career progression to high level IC engineer, with a focus on how I've never felt I needed to become a manager to gain influence. I thought I would share some of my career advice for aspiring IC "lifers." Thread!

— Matt Klein (@mattklein123) May 19, 2019

連續創業家兼技術作家 Patrick McKenzie 目前也在 Stripe 擔任資深 IC，他則強調自己並非主管、產品經理，也不是工程師。

(Worth noting that I'm a senior IC at Stripe and no flavor of manager nor a PM, nor an engineer for that matter, and that "senior IC on X" describes my quirky potpurri of interests a lot better than any of those would.)

— Patrick McKenzie (@patio11) May 29, 2019

不當主管，Individual Contributor 也不一定要犧牲收入

觀察多數對於是否擔任 IC 的考量點，包括了升職較慢、頭銜模糊，以及薪資較不具競爭力——不過你可能會好奇，選擇 IC 勢必得犧牲收入嗎？Microsoft 前首席軟體工程師 John Miller 前後在 Amazon、Google 和 Oracle 輪流待過，當過 IC 達 13 年，還有 13 年帶領 IC 和高階管理職的資歷，他在 Quora 提到自己在 IC 時期的薪酬和同級別的主管是一樣的，甚至更高。⁴

綜合各方討論，薪資差異主要包括幾個因素：一個爛主管比爛 IC 的破壞力更大 ⁵，所以有的主管會因為優秀的領導和組織能力而比 IC 拿到更多報酬；初階 IC 會因產出和技術能力得到實質回饋，資深 IC 則因提供指導和技術力獲得回報，這部份和管理職的技能樹就出現大幅重疊。

John Miller 分析，主管的晉升不用靠強大的技術能力，且比起相同資歷的 IC，能更大程度影響產品和設計。身為主管，任務是創造一個讓 IC 成功產出的環境，包括不讓他們受到老闆的干擾、作為高層和 IC 之間的溝通橋樑、為團隊爭取獎勵、保持團隊運作順暢、建立或優化流程等等。⁶ 總的來說，薪資制度因公司而異，但薪酬較低並不是 IC 的必要代價。

另一個擺在開發者面前的困境則是「中年危機」。雖然 STEM（science、technology、engineering 和 math）領域起薪相對高，但必須保持技能時時更新、和時間賽跑，一開始的高經濟回報在職涯的前十年就下降一半以上。這也使得許多工程師為了能繼續待在這行，接下主管職務似乎也是很自然的決定。對此，資料庫公司 MongoDB 的主管工程師 A. Jesse Jiryu Davis 在 40 歲那年撰文，探討「大齡工程師不會消失，他們只是變成了中階管理者」的現象。⁷

升遷通常意味著權責範圍擴張，然而「帶人」不代表「高人一等」。我們都很熟悉，公司不乏主管其實根本討厭管理或不擅管理，結果讓他們自己和周圍的人都很痛苦，導致有些組織失去資深的工程師和導師（mentor），犧牲了技術的傳承。

管理大師 Lawrence Peter 在 1969 年提出的《彼得原理》就點出，員工最終會升到一個不能勝任的位置，然後被貼上「無能」的標籤。所以，資安專家 Lesley Carhart 苦口婆心的提醒，如果認為主管職務要扛的責任超出負荷值，持續擔任 IC 真的無妨。

It’s okay to always be an individual contributor and never manage humans. In fact, if you are bad at managing humans, hearing about personal issues, dealing with team disputes and poor performers, or reviewing performance effectively, please seek training or do not become one.

— Lesley Carhart (@hacks4pancakes) April 26, 2021

再加上傳統職場的上下級關係，使得當主管才等於升職的框架幾乎深植於社會價值觀，讓人糾結於成為主管就「回不去了」。這也是為什麼 Charity Majors 離開 Facebook 後創業成立 SaaS 公司，以經營者身份不斷提倡「當主管不是升職，回到第一線的實務工作也不是降職」，並提出改變組織文化的路線圖，像是：確保當回 IC 不會被降薪、甚至擁有高於同職級主管的薪資（據她所說 Slack 就是範例 ）；公司應該明確鼓勵主管在兩三年後回到 IC 職位，並支持他們度過更新技能的適應期等等。⁸

我們曾介紹過的最會回答問題的那個男人：Stack Overflow 傳奇人物 Jon Skeet 在 Google 待了 14 年，接過半年的管理職發現並不適合自己，後來 Jon Skeet 就重返 IC 軌道。他對此分享過來人的感受：「我覺得不應該要求工程師在某個階段就得成為管理者，有些人單純做個工程師會快樂很多、效率也更高，但很多公司在升遷制度上還是犯了這個錯。」

職涯的鐘擺：在 Individual Contributor 和管理職之間切換

不論是被公司拔擢、又或是想挑戰自己，當你坐上主管職位幾年後，或許開始懷念起寫 code 解決問題讓大腦產生「快樂激素」多巴胺的感覺；或是發現自己其實很享受獨自一人但格外專注的工作，過往那種純粹的寫程式生活。因此，科技界也出現另一種潮流——如同鐘擺，在 IC 和管理職之間切換。⁹

自認是內向者的 Phillip Su，職涯中就經歷過四次從主管轉換到 IC，其中三次在微軟、一次在 Facebook。他發現擔任主管時覺得整天開會非常損耗精力，而且隨著團隊規模成長，所做決策上升到企業戰略層級，卻也變得模糊，走期也越拉越長，對他來說更難看見成效展現。

另外，工程師的一大痛點則是能否專注的思考和輸出而不被其他外務打斷，這也是 Y Combinator 創辦人 Paul Graham 的經典文章〈Maker’s Schedule, Manager’s Schedule〉的論述核心——創作者通常喜歡至少以半天為單位運用時間，如果知道下午要被困在一場會議裡，那可能早上開始幹勁就先滅了一半。

Shopify 資深網站開發工程師 Carlos Matallín 就精闢的點出兩者的不同：「擔任 IC 和主管真正的差異在於，我的行事曆今天只有一個時段有約，但以前當主管的時候有六個時段，剩下的時間都花在回覆 Slack。」從主管再次投入 IC 的人，對此也都特別有共鳴。

The best days are when I get to write code for several uninterrupted hours. Those are rare nowadays. This is why I'm going to be an IC (Individual Contributor) for life.

— David Fowler 🇧🇧🇺🇸💉💉 (@davidfowl) August 11, 2020

換軌的契機還包括想嘗試全新的領域。Facebook 設計主管 Daniel Eden 前陣子宣布將退出 1 年 3 個月的管理職，從廣告業務部門換到客服部門擔任 IC。他雖然很肯定之後一定還會重返管理層，但也覺得自己能以 IC 的角色提供 mentorship 幫助設計師成長。

I definitely plan on returning to management in the future, but feel I can meaningfully contribute to this space as an IC and continue helping designers grow through mentorship and leading by example.

— Daniel Eden (@_dte) October 21, 2021

不過，鐘擺也是一把雙面刃。最近升遷為 Peloton 資深工程主管的 Gemma Barlow 過去十年輪番擔任 IC 和管理職，列出幾項管理者回歸 IC 前可以先有的心理準備，像是技能跟不上最新發展、太久沒有程式的產出所以可能面臨被降薪、重新學習如何在沒有權力加身的情況下發揮影響力等等。但同時，主管職的歷練也能幫助強化商業思維，以更宏觀的角度處理技術問題。 ¹⁰

You know what I love for me? Being someone who became a manager who went back to being an individual contributor.

Because I didn't lose any of those leadership and management skills, I reframed them.

— Tatiana Mac (@TatianaTMac) October 20, 2021

無意帶人的 IC 和大齡工程師，仍然值得一席之地

無意擔任主管的資深 IC，其職涯路徑可以分成「廣」或「深」的維度。往廣度發展的話，通常需要在一家公司待較長的時間建立人脈和掌握背景知識，透徹了解業務並能協調多個部門，才能在技術面向有足夠的影響力；若向下鑽研朝深度發展，就不一定得在同一家公司累積，透過公司或產業在特定領域的領導地位，進而推動技術發展，並以新的技術成果展現影響力。

Matt Klein 就是選擇往深度面發展，他認為這樣的 IC 職涯除了需要決心或轉職，適當的「機運」也有著關鍵作用，才能站上向世人展現技術實力的舞台而被看見。像 Envoy 專案的進程結合了天時地利人和，正好為他的 IC 生涯打下深厚基礎。¹¹

A. Jesse Jiryu Davis 認為，公司應該為最資深的 IC 創造新的角色，並根據他們過去的表現評估，而非變化快速的技能掌握度，激勵大齡工程師在每個階段迎接挑戰，也能避免他們落入被公司拋棄的焦慮而被迫接下管理職——不適任的下場反而是雙輸。

Dropbox 在 2021 年 7 月公開內部的工程師職務框架，詳細定義自家工程師的職務能力階梯，比如軟體工程師就分成初階的 IC 1 到 IC 7，有各自應具備的能力面向、關鍵行為與影響力。在 Dropbox 任職的台灣資深工程師 vgod 回憶，他剛加入 Dropbox 時只有粗略分成四級，而且沒有清晰定義，所以容易出現「為什麼我好像做了很多事但還是不能升職」的情況。有了這份框架，平時就有具體的參考項目可以和主管討論績效和職涯發展，像是要繼續在 IC 這條階梯往上，或轉換到管理職（Engineering Manager）。¹²

提供人資服務的 SaaS 公司 Gusto 共同創辦人兼 CTO Edward Kim 則分享為了解決現有績效評估的缺陷而重新設計升遷流程的心得。¹³ 他說 IC 在 Gusto 一開始很大程度依賴其直屬主管是否有能力成功「推銷」他們，這導致 IC 會像論文答辯一樣提交自己的豐功偉業再由評審決定，無法客觀衡量員工的影響力。對此，Gusto 的新框架明確訂出主要評估工程師在四個面向的貢獻，包括：

• 專案影響力：IC 主要的工作，包括工程師為新功能或改進現有功能寫的程式碼
• 提升工程團隊品質：改善 code base 或工具以提高整個團隊的生產力，例如優化建構和測試的週期時間或清理技術債
• 對人和團隊的影響力：面試、指導同事、新成員的入職培訓或帶實習生的狀況
• 對組織的貢獻：代表公司參加外部活動或推動 DEI（多元、公平與包容）文化。

不過，未來 IC 還可能面臨疫情帶來的後遺症。帶領 Shopify UX 團隊提供開發者工具的主管 Owen Williams 在這段遠距工作的日子發現，還是 IC 的時候只要有網路都無所謂，但成為主管後，一整天忙著進出不同會議，顯然不再適合自由移動或在咖啡店工作的數位遊牧生活模式了。

slowly realizing 'working remote' is VERY different as a people lead vs individual contributor.

when I was an IC it didn't matter where I was as long as I had internet—but as a manager i'm in meetings all day, so working in coffee shops/moving around is difficult.

— Owen Williams ⚡ (@ow) September 14, 2021

或許最理想的平衡，是組織和員工不要互相傷害。除了企業能尊重每個角色的難處，為每個職等的員工勾勒出清晰的職涯藍圖，並彈性調配新的管理技能和責任比重，讓他們在帶人和技術為主的工作靈活轉換；同時，就像 Matt Klein 的提醒，身為 IC 必須更體認到「你不可能讓所有人都高興」，員工也不要勉強自己去接下主管職，而能辨識對自己和團隊最好的定位所在。

資料來源：
1. What Is an Individual Contributor?
2. A Guide to Making the Move From Manager to Individual Contributor
3. EP2 在矽谷也要打怪練等？軟體工程師的升遷攻略

（文章代表圖：Photo by Esteban Lopez on Unsplash）

本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出