角色轉換與職涯路徑
這個主題的書按角色而非按問題組織,在管理線裡只有這一篇這樣切。其他主題篇問「這個問題該讀什麼」,這一篇問「這個位置的人整天在做什麼」。之所以需要這個落點,是因為有一整類書本身就按角色寫成,內容橫跨多個主題而不屬於其中任何一個——把它們拆進各主題會失去「這個位置的全貌」,而全貌正是要換位置的人需要的東西。
這類書的價值有兩種用法:在自己的位置上用來確認哪些事該做而自己沒在做,以及在轉換之前用來預習。後者尤其重要,因為多數位置轉換的失敗來自不知道新位置的成功長什麼樣,而不是能力不足。
預習有一個時間差要注意。位置轉換前讀這些書,能讀到的是地圖;真正的判準要等到承擔了責任才長出來。因此比較有效的用法是轉換前讀一次建立預期,等到自己獨立走完一輪那個位置的完整循環(帶完一次績效週期、獨立處理過一次人的問題、或主導完一次跨團隊的交付)之後再讀一次,兩次讀到的東西不同。
起點是 The Manager’s Path
Camille Fournier 的《The Manager’s Path》一本鋪完整條路徑,涵蓋面在本篇最廣。它從「怎麼被管理」開始,接著是 mentor、tech lead、管理個人、管理團隊、管理多個團隊、管理管理者,最後到資深領導。每章結構相似:這個角色實際在做什麼、常見的失敗模式、怎麼判斷自己準備好進下一層。
它最實用的部分是把模糊的角色講具體。tech lead 與 manager 的差別、什麼時候該停止自己寫程式、一對一該由誰決定議程、績效不佳的人該怎麼處理,這些問題書裡有明確立場而非兩面兼顧的說法。
證據來源是單一路徑的個人經驗(作者在 Rent the Runway 擔任 CTO 及先前的任職)。例子多來自中型組織,對多數團隊的規模比大廠案例貼近。處境相容性上,那道階梯預設組織大到每一層都有專人——tech lead、EM、總監各自是一個人的工作。三十人以下的公司這幾層會壓在同一個人身上,那時它的用途是預覽下一階,而不是對照當下。時效上,書中的職級與晉升描述反映 2010 年代中期的美國科技業,遠距團隊的管理不在討論範圍;各層角色的職責劃分與一對一的用法不依賴那個時空。它的前提是位置而非經驗:正處在書中某一層、或即將進入下一層——建議只讀自己這一層加上一層,整本讀完的人通常記不住用不到的部分,升層時還是要回頭重讀。
還在個人貢獻者階段時讀 The Software Engineer’s Guidebook
Gergely Orosz 的《The Software Engineer’s Guidebook》涵蓋從入門工程師到 principal 以上的各個級別,並且針對每個級別分別處理軟體工程、協作、把事情做完這幾組能力。
它對只對自己產出負責的位置特別有用,因為它明確回答了一個在那個位置上最難自己看清的問題:下一級別的人跟我的差別具體在哪。多數公司的職級描述寫得抽象(影響範圍、獨立性、複雜度),這本書把它翻成可觀察的行為。
證據來源是單一路徑的個人經驗(作者在 Uber、Skyscanner、Microsoft、Skype 的任職),加上長期經營的產業電子報累積的跨公司觀察,後者讓它比純粹的單一路徑多一層廣度。處境上,整本書的骨架是職級制度:能力被翻成級別、級別對應可觀察的行為。沒有職級的組織——新創、接案、共同創辦人之間——讀它拿得到那份能力清單,拿不到把清單排序的那根軸,而排序正是它最有用的部分。時效上是本篇最新的一本,對現在的大廠職級制度與遠距工作型態有直接處理。它的內容綁在職級制度上,那套制度改版時這本書會跟著失準,目前還沒有。讀得出價值的前提幾乎沒有——它是本篇門檻最低的一本,剛入行就可以讀,只是後半的高階級別章節要等到用得上時再回頭看。繁體中文版由碁峰資訊出版,沈佩誼譯,譯名《軟體工程師的晉升之路》。
要走技術路線而非管理路線時讀 Staff 工程師的兩本
Tanya Reilly 的《The Staff Engineer’s Path》處理的是不帶人但要對技術品質負責的位置。它把這個角色拆成三根支柱:用寬廣的視角看自己的工作、把專案實際推成功的戰術、以及決定在自己的組織裡「好的工程」是什麼意思。第三根支柱是這本書在這條線上少有其他書處理的部分——沒有職權的人如何設定標準。
Will Larson 的《Staff Engineer》(Tanya Reilly 作序)是另一種形式:它包含 Larson 的框架加上多位 staff 工程師的訪談,因此提供的是多條路徑的樣本而非單一敘事。想知道這個位置在不同公司長什麼樣的人,訪談的部分價值較高。
兩本與這個主題的其他書承擔同一個角色(技術路線的位置說明),彼此的差別在形式而非層級:Reilly 那本提供系統性的能力拆解,Larson 那本提供路徑的多樣性。只讀一本的話讀 Reilly 那本,因為它的三支柱結構可以拿來自我對照,而訪談讀起來是別人的故事。
證據來源都是單一路徑的個人經驗,Larson 那本另加訪談樣本。時效上,兩本都出版於 2021-2022 年,描述的職級階梯與現在的大廠制度接近,沒有明顯過時的部分。讀得出價值的前提是:已經是資深工程師、且開始被要求處理跨團隊的技術問題——工作範圍還限在自己的模組裡時讀,三支柱會讀成空話。Reilly 那本有繁體中文版,譯名《Staff 工程師之路》;Larson 那本沒有正式出版的中譯本,網路上有社群自譯的版本。
- Amazon(The Staff Engineer’s Path: A Guide for Individual Contributors)
- 博客來(Staff 工程師之路:獻給個人貢獻者成長與改變的導航指南)
- Amazon(Staff Engineer: Leadership beyond the management track)
第一次帶人時讀 The Making of a Manager
Julie Zhuo 的《The Making of a Manager》聚焦在第一年。它處理的是新手管理者實際會遇到的具體場景:第一次一對一該說什麼、面試該問什麼、什麼時候該讓表現不佳的人離開、怎麼在自己也不確定的時候給團隊方向。
它與《The Manager’s Path》的差別是範圍與深度的取捨。Fournier 鋪完整條階梯、每層淺一點;Zhuo 只寫第一段路、但把那段寫得細。第一次帶人的當下,後者的可執行性較高。
證據來源是單一路徑的個人經驗(作者在 Facebook 從第一位實習生做到產品設計副總),且集中在產品設計而非工程管理。時效上,書中的組織規模與遠距前的辦公型態是背景設定;第一年管理者面對的具體場景(第一次一對一、第一次給負評)不依賴那個背景。工程特有的問題(技術決策、輪值、技術債)需要另尋來源。這本有讀它的時間窗:即將帶人或剛開始帶人的那段。已經帶了兩年的人讀它會覺得都知道。繁體中文版由時報出版,譯名《當上主管後,難道只能默默崩潰?》。
想要管理工作的通用定義時讀 High Output Management
Andrew Grove 的《High Output Management》提供的是管理這件事的操作定義而非某個角色的指南。核心是把管理者的產出定義成他所轄組織的產出加上他影響所及組織的產出——這個定義把「我今天很忙」與「我今天有產出」分開,並且讓槓桿變成可以計算的東西。
書中對一對一、決策會議、績效評估、訓練的處理都建立在同一個槓桿邏輯上:這個動作影響多少人的產出、影響多久。這使它跟其他按角色寫的書層級不同——它給的是判斷任何管理動作值不值得做的尺,因此在任何位置都適用。
1983 年的書,書中的製造業類比、當時的辦公型態與人事制度都需要折算;槓桿邏輯與會議的分類處理的是管理動作與產出之間的關係,不依賴那些條件,因此是折算後留下來的部分。證據來源是單一路徑的個人經驗(作者在 Intel 從創始成員做到執行長)。讀得出價值的前提是已經在分配自己以外的時間——只管自己的行程時,槓桿計算沒有可以套用的對象。繁體中文版譯名《葛洛夫給經理人的第一課》。
為什麼只收這幾本
這六本承擔五個角色:整條階梯的地圖(Manager’s Path)、個人貢獻者各級別的能力拆解(SE Guidebook)、技術路線的位置說明(Staff 兩本共同承擔)、第一年帶人的具體場景(Making of a Manager)、管理動作的通用尺(High Output Management)。Staff 兩本合佔一個角色,兩本的差別在形式而非涵蓋範圍。
分佈刻意偏向個人貢獻者與初階管理。理由是位置越高,同一個職稱在不同公司對應的實際工作差異越大,書能提供的通用部分就越少——到了管理管理者這一層,組織的規模、產業與治理結構決定的比書多。
職涯類的書在技術書市成長很快,多數落在兩個已被承擔的角色:重述大廠職級制度的升等指南,以及個人成功敘事。前者被《The Software Engineer’s Guidebook》以更廣的跨公司觀察覆蓋,後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它:換一間制度不同的公司,這條建議會怎麼變。答不出來的是敘事而非分析。
這個主題沒查到可以收的公開課,而成因跟它在哪裡被教有關:組織類題材主要在商學院,而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況,寫在 主題書單 的公開課段。
這個主題接到哪裡
確定了位置之後,各項具體能力回到對應主題:交付效能走 持續交付與交付效能,團隊切分走 組織結構與團隊設計,人留不留得住走 留任、動機與工作環境,該講的話講不出口走 困難對話與無權限影響力。
要判斷自己現在站在哪個位置、以及位置對應的起點書,回到 軟體管理與組織書單 的位置表。
#books #reading #career #engineering-leadership #staff-engineer