軟體工程師的修煉與成長 (7) — 如何突破資深工程師的天花板
Manager or Individual Contributor?
前面的文章提過，L5資深工程師是大部分公司的「終端等級」。在這個等級以後，即使年資一直增加，也不會自動就往上升，如果沒有超過這個等級的impact，就會一直停在這。這個等級是公司產出的主力部隊，人數通常最多，年資的範圍也最廣。現在在矽谷平均大概5年就能到資深，但也有很多在這個等級的人年資是超過10年甚至20年的。
不繼續升職並不是什麼罪惡，畢竟這個等級工作有一定的自主性，研究技術可深可廣，薪資待遇也很不錯了。這兩年不少資深工程師在一線公司一年可以拿到400k左右的offer（跟美國總統一樣了），即使在矽谷這個生活成本極高的地方也可以過得挺舒適的。我覺得如果是喜歡寫程式或鑽研技術的人，待在這個等級其實是最適合的，因為再往上升寫程式的時間只會變少，而其他的責任則會大大增加。
那如果真的想突破L5繼續往上升，到底該做些什麼呢？
第一件事，就是先決定「想當manager還是想繼續當IC (Individual Contributor)？」
矽谷公司的工程師職涯是在L5開始分岔的，在這個點可以轉職成Engineering Manager (EM) 開始走manager track，或是待在IC track往上升變成Staff Engineer。這兩個track是平行的，在大公司都可以一路往上升到跟VP同等級(L10)。（如果等級不夠了你又是Jeff Dean，公司甚至還可以幫你定義出新的等級!）
在很多公司裡，不管是哪個track，同一個等級所需要負責的scope是一樣的，所以薪水範圍也是一樣的。也就是說，不管你是L6的EM或是L6的IC，待遇並不會有什麼不同。這點可能是矽谷外的人最常誤會的事，從IC變成manager不是升職，而是在同一個等級平行的轉職，薪水也不會因此就變高。（只有升到下一級會讓薪水跳到下一級的範圍內，但那跟IC或manager無關。）也因此，在矽谷有很多人可以一輩子做IC而不用為了薪水轉職成manager做不喜歡的工作。
至於要走哪一個track比較好？這完全是個人選擇和偏好，沒有一定的答案。
Manager與Leader
以前我還是學生時，對台灣公司的結構有個刻板印象：工程師是底層員工，只能聽命行事；而升職就一定要變成manager，不然就職涯或薪水都不會成長。（但我沒有在台灣做過正職工作，不確定現在還是不是這樣就是了。歡迎讀者分享你們的經驗！）
那為什麼矽谷的公司不是這樣運作的呢？為什麼可以有同等級的EM和IC同時存在拿一樣的薪水呢？
我覺得最大的關鍵是，在矽谷的公司裡，manager和leader是兩個分開的概念。Manager指的是people manager，負責「管人」，在工程團隊中就是EM扮演這個角色。而leader則是於幫團隊指引出方向，帶著團隊往那個方向前進的人，工程團隊中大多是Tech Lead (TL) 在扮演這個角色。如果是很小的團隊可以是TLM (Tech Lead Manager)同時扮演EM和TL的角色，但通常TLM不是一個會持續很久的工作，所以比較適合看成一種例外。
一但把manager和leader分開，IC就可以在不管人的情況下當一個leader，進而擁有更同等級的manager一樣大的scope和impact。
舉例來說，在一個工程團隊裡，常會有個L6的EM加上一個L6的TL，兩個人合作分攤管理「人事」、「預算」、「專案」、「流程」、「技術」五個大領域。其中「人事」 (hiring, firing, performance, career growth) 和「預算」（團隊的錢要用在哪）主是EM在管的，而「技術」方面 (technical direction, strategy, vision) 主要就是TL負責的。剩下的兩個領域「流程」(定義OKR, sprint, oncall rotation等讓團隊日常運作的流程) 和「專案」（追蹤每個專案執行的進度和排除障礙)就是執行層面的事，不一定會怎麼分配，完全看兩個人的專長和興趣自己協調。
當我在L5面臨EM vs IC的選擇時，我很快就決定要待在IC這條路上。我想當個leader，但不想當manager。因為我知道，要做一個好EM，一定要有一個覺悟是「放棄自己寫程式」，甚至把技術方面的決定都交給TL才能做好people manager的工作。也就是說，如果我要走上EM這條路，以後我就沒什麼機會深入研究技術細節，也沒什麼機會在工作中寫程式了。這對我來說會是一個很痛苦的事，畢竟寫程式是我在工作中最能放鬆和充電的時候。如果不能寫程式，那工作就會變成整天開會，不斷消耗我精力和時間，我一定持續不了太久的。
當manager的人通常有相反困擾。他們不見得喜歡寫程式這件事，但喜歡幫助團隊成長，甚至可以在成天跟別人開會中找到了樂趣和成就感。就像內向的人需要獨處來充電、外向的人藉由社交來充電一樣，當IC和當manager也有不同的充電方式。
但客觀上來說，如果是想要在大公司一直往上爬到VP或CXO的人，走manager track的機會是比較多的。manager和IC很不一樣的一點是，manager能管的人數不論在哪一層都差不多，頂多10~15個人就會需要多一個manager。隨著公司人數增加，IC變多後，manager也一定要跟著變多。第一線的manager變多後，就一定要有第二層的manager來管一線的manager。等到第二層的manager也太多後，就要有第三層、第四層、第五層…如此不斷增加下去。
相反的，在IC track上，高等級的IC相對於高等級的manager是稀少很多的。例如說，L8的manager是Director，大約要管50–100人的大團隊，如果對應到IC track就是Principal Engineer。IC要能到這個等級，也一樣需要能夠展現出領導50–100個工程師的影響力。但問題是，很少公司有這樣的機會和需求能讓一個人展現出這樣規模的影響力，所以如果公司不夠大，很容易就會發現高等級的IC人數是寥寥可數的。（我們公司雖然有定義L9的工程師，但只有一個人曾經升到這個等級過。甚至連L8的工程師也不到10人。）
Leadership: 找出前進的方向
不管是走IC或Manager，L6的scope都需要能帶領一個6–10人的團隊。如果說L5的主要任務是「解決一個已經定義好的問題」，L6就需要幫團隊「找出什麼才是值得解決的問題」。簡單來說，L6是在一團未知和混沌中幫整個團隊指引出方向的人，除了定義大方向（願景）外，也要把整個願景拆解成數個有清楚定義的問題，讓團隊裡的其他人能夠拿去研究和提出解決方案。
也因此，L6的IC也常會是整個團隊的TL，負責定義願景和把願景轉化為roadmap，並帶領團隊按照計劃執行。（除了TL外，其實也有不同種類的L6工程師，以後的文章我們再來詳細說說。）而L6的manager一樣是要為整個團隊負責，但在有個強力的TL的前提下，manager可以放更多重心在幫助團隊中每個人的職涯成長，還有找新的機會讓團隊擁有的scope可以更大，人數可以成長。
到了L6，不管是IC或是manager，在公司內都是被視為一個leader，對外要代表自己的團隊跟其他團隊協調、溝通，對內要說服團隊往一個共通的願景和方向前進並幫團隊排除中間的障礙。也因此，軟實力 (soft skill) 也是到達L6不可或缺的能力。
工程師需要的軟實力
很多人以為工程師只要會面對電腦寫程式就行了，但有句話說 “Hard skills get you in. Soft skills get you far.”。
寫程式以及對技術的深入理解是硬實力 (hard skill)，如果不會寫程式的確沒辦法通過面試成為工程師。但能單打獨鬥寫好程式只能讓一個L3工程師成長到L4，連L5都會很難達到。要到L6以上，「軟實力」就會變成新的門檻，硬實力反而不一定會有太大差別。也因為要到L6需要有完全不同種類的能力，造成了L5變成大部分工程師職涯的頂點，如果不刻意轉換心態還有找到合適的機會是很難升上去的。
軟實力包含了什麼？對於軟體工程師來說，最基本的有「溝通」、「專案管理」、「跨團隊合作」。
「溝通」包含了「輸入」和「輸出」。輸入（也就是閱讀和聽別人說話）大多數人沒什麼問題，但輸出（寫和說）就是很多工程師的罩門。輸出最基本的就是跟別人解釋自己的想法，可以是給一個演講，或是寫設計文件跟別人解釋自己的系統設計，寫願景文件跟團隊解釋自己的願景是什麼，寫新計畫的提案跟更上層的管理團隊要資源、甚至是在績效考核時寫自己的表現或是對別人的回饋。
不管是說或寫，都是一件需要持續練習的能力才會進步的事，尤其在美國得用英文來溝通對於身為台灣人的我更是加倍困難。幸運的是，我的英文寫作在念博士期間寫論文得到大量的練習和進步，所以寫作對我來說已經不是一個障礙了。
溝通做得好，就能產生 “influence”，讓別人改變原本的計畫來跟著自己想要的方向走。influence對於IC來說特別重要也特別困難，因為IC不像manager有直接的下屬，可以直接指派任務給他們。L6以上的IC就得靠溝通能力來說服和領導別人一起往同個方向前進。
「專案管理」則是把該做的事情清楚的拆分開來，準確的估計每一步驟需要的時間，定好每件事的優先順序和相依性，決定什麼事該在什麼時間點由誰做。有些團隊會有專門的專案經理 (project manager) 做這些事，但工程師做的事通常只有自己能相對準確估計時間和瞭解背後複雜的相依性，所以自己或多或少也是得做一些。管理好自己（甚至是別人的）專案是一件很重要的事，對於manager來說，一個人的表現很大程度取決於他有多可靠，也就是能多穩定多準時的做完他說要做到的事情。
「跨團隊合作」則是把「溝通」的範圍延伸到自己團隊以外的地方，可能是自己團隊的上層（使用者）或是下層（底層服務的提供者），或是平行的其他團隊（做不同的專案，但最後要整合在一起）。跨團隊溝通和協調是需要花很多時間和力氣的事，畢竟每個團隊的目標都不同，執行過程中很多事情會一直改變，這個合作的過程就是一直不斷地align彼此的目標，一起找到對於大家都最有利的最佳解。L6以上的工程師大部分時間可能都是花在這邊。
仔細想想這些軟實力，就會發現他們其實都有個共通的目的：「減少不確定性」。把一件複雜且模糊兩可的事情梳理清楚，變得對所有人都簡單且沒有歧義，在一個組織裡是非常有價值的。公司裡的職位要分層或不同等級也是同樣道理，層級越高的人處理的問題是範圍越大並且越模糊的。而每個層級的人在做的事其實就是把他們拿到的問題稍微弄清楚一點，切割開來，分配給下一個層的人去接手。這樣一層一層下去，每一層的結果都能完成上一層的一部分目標，就像一個大拼圖一樣一區一區拼起來，最後完成整個公司的大目標。
升上L6
相較於在L4的我其實根本沒搞清楚自己應該做什麼才能產生最大的貢獻，我在機器平台團隊時已經成熟很多了。這時的我已經了解我應該要花時間在能對公司產生最大價值的地方，雖然我喜歡寫程式，但我不應該把所有時間都花在寫程式上。同一個公司的工程師程式能力都有一定水準，一但確定了要解決什麼問題後，誰來把這個想法轉成程式碼其實沒有太大差別。而對這個團隊來說，更重要的是讓大家同意「到底要讓程式做什麼事情？」這時我覺得我可以把這件事梳理清楚並講清楚，但團隊裡大部分的人是做不到的。
雖然這個團隊已經有個L7的TL了，但我很快就發現他的專長主要是在建立大規模的分散式系統來提供服務，他其實並不是很了解ML工程師日常的workflow和會遇到的問題。但我剛好相反，我自己有做過ML，比較有興趣的也是提升工程師的生產力，可以很好的補足他不熟悉的部分。我就從ML workflow這點下手，開始一步一步思考和設計可以幫ML工程師更快做完整個ML迭代的工具。
但回到現實面，現在我在這個團隊只是個L5的工程師，我要怎麼說服團隊的其他人接受我的願景呢？
如果把我們想打造的平台當成一個產品來看，想這種「產品願景」(product vision) 剛好是我挺擅長而且喜歡做的事。在無窮的可能性中，找到一條合理可行的道路，然後做出一個prototype證明這個想法真正可以運作。我很幸運的是，我從高中做科展，一直到在MIT念博士，都不斷在練習這個做research和ideation的能力。
我花了點時間研究了業界所有的ML平台，雖然大家做的產品都不一樣，但他們想要解決的問題是大同小異的。對其他人的解法稍微有概念後，就是從我們自身的痛點出發，開始一步步建構能夠解決我們問題的最小系統，再慢慢把他們擴大和連接起來變成一個可以服務整個end-to-end流程的系統。一但我把該做什麼事搞清楚後，剩下的就只是把這個想法跟團隊溝通了，取得其他人的支持。
這個溝通是一個有來有往的過程，不是寫個文件分享給別人就沒事了。
對於一個會影響到整個團隊的idea，我都會先在跟manager和TL的1:1中讓他們知道我正在做這件事，然後有一些具體想法時就先讓他們知道，取得early feedback。同樣的，對於未來要用這個系統的團隊來說，先跟他們的TL在1:1裡取得共識也是一樣重要。這個過程也會得到一些feedback，可以幫助我把想法去蕪存菁，並排出優先順序。
重複做個幾次後，這個願景就會變得很清楚了，這就是該把完整的想法寫成一個 “vision doc” 的時候了。vision doc很重要的是清楚描述這個想像中的願景長什麼樣子，包括「為什麼要做這件事」(why) 還有「具體上可以解決什麼問題以及不可以解決什麼問題」(what)。這樣可以幫助別人了解問題的邊界在哪、範圍有多大、還有如果解決的話可以帶來什麼樣的價值。
vision最主要的功用是指出一個”north star”，告訴團隊終極的目標在哪，還有中間大致上要用什麼策略才能走到目標。寫這種high-level的文件時，要避免的是講太多細節，像是系統要怎麼設計，甚至程式的架構之類的都是太底層的細節。
一個簡單的原則是，想像自己身為L4/L5的工程師，如果是自己會寫在design doc裡的東西，就不應該出現在vision doc裡。vision只要能把系統的範圍和要解決的問題定義清楚，讓一個L5或是L4看完可以開始工作設計系統解決這個問題，那這樣的level of details就夠了。這麼做有很多好處，除了可以讓vision doc的讀者聚焦在最高層次的目標上外，也可以讓實作系統的工程師有完整的ownership，他們才不會覺得系統都已經被別人設計完了，自己只是coding monkey而已。
有了vision和strategy，就可以把大目標分解成一個個比較小的系統和專案，最後變成一個大略的roadmap，讓整個團隊來執行和實作。
開始大量的寫這種文件後，我突然發現透過寫文件來溝通是我的強項，比起用講的我用寫的可以更快讓更多人了解我的願景和想法，要取得別人的buy in也容易很多。除此之外，寫文件也是一種幫助我自己把問題想清楚最好的方式，很多時候我提出的願景都是一邊寫一邊才變得清晰起來的。
就這樣，一但我成功說服團隊和manager我提出的願景後，這個願景就幫團隊打開了一個新的領域。一個新的小團隊就這樣分支出來，我也理所當然成為這個小團隊的TL，跟著manager把這個團隊建立起來。很快的，這個小團隊慢慢變大，我的願景也慢慢被實現出來。有了這樣的impact後，我也很順利升上L6。
（待續）
