方案是對的但推不動，是這個位置的典型失敗；而它的形式通常是被同意然後沒有發生，不是被否決。會議上大家點頭，回去照舊，因為那個方案沒有進到任何人的優先序裡。另一個高頻失敗是把標準寫成文件，就當作標準已經存在。文件不會約束任何人。約束來自 CI 擋不擋、review 過不過、以及不照做的時候會不會有人說話。

對技術品質負責時，成文制度與否的差別

有職級階梯的組織裡，這個位置通常有明確的頭銜（Staff、Principal），問題是影響範圍與可見度的落差。做的事情橫跨多個團隊，每個團隊的主管卻只看得到自己那一段。切碎的形狀大致是這樣：花三個月讓四個團隊改用同一套部署流程，年度考評時主管收到的是四段各自兩三句的側面回饋，每一段聽起來都像「有幫忙」，沒有一段看得出那三個月。應對方式偏向留下跨團隊可見的產出（決策紀錄、遷移計畫、被引用的規範），而不是靠主管轉述。

扁平的小公司通常沒有這個頭銜，這裡的人是「大家都會來問的那個人」。問題出在邊界而非可見度：沒有頭銜也就沒有拒絕的依據，於是所有技術問題都流過來，把設定方向的時間吃成救火。這裡的關鍵能力是判斷什麼該接、什麼該退回。沒有職權時的「說不」通常是把成本攤開讓對方自己排序，而不是直接拒絕——「這件事我可以接，但它會讓遷移那條線延兩週，你要哪一個」比「我沒空」有用，因為前者把決定交回給有權決定的人，後者只是把問題推回去。

這個位置該讀什麼

The Staff Engineer’s Path 是這個位置的主要書。它把這個角色拆成三根支柱，其中一根正是上面說的「沒有職權的人如何設定標準」——那一塊在其他書裡少有處理，也是這個位置最難自己摸索出來的。三根支柱各是什麼在主題篇。想看這個位置在不同公司長什麼樣的人，Will Larson 的《Staff Engineer》收了多位 staff 工程師的訪談，兩本都在 角色轉換與職涯路徑。

The Secrets of Consulting 直接處理無職權推動改變。多數管理書預設讀者有直接權限，這本的處境設定是「被找來給建議、但決定權在別人手上」，跟這裡的處境幾乎一致——差別在它的作者退得掉，而站在這個位置的人退不掉，讀的時候要把那一段折算。書中處理的主題與證據判定在主題篇。

Team Topologies 在這個位置的用法是拿它當語言而不是拿它當方案。四種團隊型態與三種互動模式提供的是把「這兩個團隊該怎麼合作」講清楚的詞彙——站這個位置的人經常看得出問題出在交接面，卻只能說「他們配合度不好」——那句話推不動任何事。

Facilitator’s Guide to Participatory Decision-Making 對應的是上面那個「被同意然後沒有發生」。那個結果經常來自一場沒有真正收斂過的會議：意見攤開之後氣氛變難受，主持的人提早收攏，於是點頭的每個人各自帶著不同的理解離開。書中的鑽石模型把那段難受標成必經階段，用途是讓人在會議進行中就說得出「我們還沒收斂」，而不是散會兩週後才從執行狀況推回來。

Difficult Conversations 處理的是方案被反對時的那一場對話。三層對話的區分（事實、感受、身分認同）在技術爭論裡特別有用，因為技術爭論卡住的原因常常不在第一層——反對的人是在保護自己的判斷紀錄，而那件事在檯面上不會被說出來。

想往哪裡走

進到這個位置的訊號通常是別人先開始把跨團隊的問題丟過來，職稱在那之後很久才追上。準備好的可觀察形式是這些事已經在做、而沒有人指派：主動去問隔壁團隊的計畫、在別人的設計討論裡被引用、寫的東西被當成別人的起點。這些累積夠了之後，要的是一個名分讓拒絕有依據，而不是一個新技能。

往更資深的技術路線：預習的是組織結構與系統架構這兩塊，而它們其實是同一件事的兩面——一個介面畫在哪裡，決定了哪兩個團隊要天天開會。組織那一面看 組織結構與團隊設計 的認知負荷段，系統那一面看 系統架構：架構特性互相衝突、必須明確放棄一些，而那個取捨正是這個位置要能講清楚的東西。

往管理路線（對人負責）：預習的是人的問題，而這條路徑有一個具體的落差要注意——這裡練出來的是「不靠職權說服別人」，而管理位置需要的是「有職權時怎麼不濫用它」。這兩件事不是同一個技能的深淺，留任、動機與工作環境 與 組織文化與心理安全感 是補這一塊的入口。

橫向移動回產品開發：這個方向不需要預習書單裡的東西，但值得先確認自己想離開的是這個位置還是這間公司的這個位置——兩者的解法不同。

這類書的價值有兩種用法：在自己的位置上用來確認哪些事該做而自己沒在做，以及在轉換之前用來預習。後者尤其重要，因為多數位置轉換的失敗來自不知道新位置的成功長什麼樣，而不是能力不足。

預習有一個時間差要注意。位置轉換前讀這些書，能讀到的是地圖；真正的判準要等到承擔了責任才長出來。因此比較有效的用法是轉換前讀一次建立預期，等到自己獨立走完一輪那個位置的完整循環（帶完一次績效週期、獨立處理過一次人的問題、或主導完一次跨團隊的交付）之後再讀一次，兩次讀到的東西不同。

起點是 The Manager’s Path

Camille Fournier 的《The Manager’s Path》一本鋪完整條路徑，涵蓋面在本篇最廣。它從「怎麼被管理」開始，接著是 mentor、tech lead、管理個人、管理團隊、管理多個團隊、管理管理者，最後到資深領導。每章結構相似：這個角色實際在做什麼、常見的失敗模式、怎麼判斷自己準備好進下一層。

它最實用的部分是把模糊的角色講具體。tech lead 與 manager 的差別、什麼時候該停止自己寫程式、一對一該由誰決定議程、績效不佳的人該怎麼處理，這些問題書裡有明確立場而非兩面兼顧的說法。

證據來源是單一路徑的個人經驗（作者在 Rent the Runway 擔任 CTO 及先前的任職）。例子多來自中型組織，對多數團隊的規模比大廠案例貼近。處境相容性上，那道階梯預設組織大到每一層都有專人——tech lead、EM、總監各自是一個人的工作。三十人以下的公司這幾層會壓在同一個人身上，那時它的用途是預覽下一階，而不是對照當下。時效上，書中的職級與晉升描述反映 2010 年代中期的美國科技業，遠距團隊的管理不在討論範圍；各層角色的職責劃分與一對一的用法不依賴那個時空。它的前提是位置而非經驗：正處在書中某一層、或即將進入下一層——建議只讀自己這一層加上一層，整本讀完的人通常記不住用不到的部分，升層時還是要回頭重讀。

• Amazon（The Manager’s Path）
• 博客來（經理人之道：技術領袖航向成長與改變的參考指南）

還在個人貢獻者階段時讀 The Software Engineer’s Guidebook

Gergely Orosz 的《The Software Engineer’s Guidebook》涵蓋從入門工程師到 principal 以上的各個級別，並且針對每個級別分別處理軟體工程、協作、把事情做完這幾組能力。

它對只對自己產出負責的位置特別有用，因為它明確回答了一個在那個位置上最難自己看清的問題：下一級別的人跟我的差別具體在哪。多數公司的職級描述寫得抽象（影響範圍、獨立性、複雜度），這本書把它翻成可觀察的行為。

證據來源是單一路徑的個人經驗（作者在 Uber、Skyscanner、Microsoft、Skype 的任職），加上長期經營的產業電子報累積的跨公司觀察，後者讓它比純粹的單一路徑多一層廣度。處境上，整本書的骨架是職級制度：能力被翻成級別、級別對應可觀察的行為。沒有職級的組織——新創、接案、共同創辦人之間——讀它拿得到那份能力清單，拿不到把清單排序的那根軸，而排序正是它最有用的部分。時效上是本篇最新的一本，對現在的大廠職級制度與遠距工作型態有直接處理。它的內容綁在職級制度上，那套制度改版時這本書會跟著失準，目前還沒有。讀得出價值的前提幾乎沒有——它是本篇門檻最低的一本，剛入行就可以讀，只是後半的高階級別章節要等到用得上時再回頭看。繁體中文版由碁峰資訊出版，沈佩誼譯，譯名《軟體工程師的晉升之路》。

• Amazon（The Software Engineer’s Guidebook）
• 博客來（軟體工程師的晉升之路：全方位升遷攻略）

要走技術路線而非管理路線時讀 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 從第一位實習生做到產品設計副總），且集中在產品設計而非工程管理。時效上，書中的組織規模與遠距前的辦公型態是背景設定；第一年管理者面對的具體場景（第一次一對一、第一次給負評）不依賴那個背景。工程特有的問題（技術決策、輪值、技術債）需要另尋來源。這本有讀它的時間窗：即將帶人或剛開始帶人的那段。已經帶了兩年的人讀它會覺得都知道。繁體中文版由時報出版，譯名《當上主管後，難道只能默默崩潰？》。

• Amazon（The Making of a Manager: What to Do When Everyone Looks to You）
• 博客來（當上主管後，難道只能默默崩潰？）

想要管理工作的通用定義時讀 High Output Management

Andrew Grove 的《High Output Management》提供的是管理這件事的操作定義而非某個角色的指南。核心是把管理者的產出定義成他所轄組織的產出加上他影響所及組織的產出——這個定義把「我今天很忙」與「我今天有產出」分開，並且讓槓桿變成可以計算的東西。

書中對一對一、決策會議、績效評估、訓練的處理都建立在同一個槓桿邏輯上：這個動作影響多少人的產出、影響多久。這使它跟其他按角色寫的書層級不同——它給的是判斷任何管理動作值不值得做的尺，因此在任何位置都適用。

1983 年的書，書中的製造業類比、當時的辦公型態與人事制度都需要折算；槓桿邏輯與會議的分類處理的是管理動作與產出之間的關係，不依賴那些條件，因此是折算後留下來的部分。證據來源是單一路徑的個人經驗（作者在 Intel 從創始成員做到執行長）。讀得出價值的前提是已經在分配自己以外的時間——只管自己的行程時，槓桿計算沒有可以套用的對象。繁體中文版譯名《葛洛夫給經理人的第一課》。

• Amazon（High Output Management）
• 博客來（葛洛夫給經理人的第一課：從煮蛋、賣咖啡的早餐店談高效能管理之道，3 版）

為什麼只收這幾本

這六本承擔五個角色：整條階梯的地圖（Manager’s Path）、個人貢獻者各級別的能力拆解（SE Guidebook）、技術路線的位置說明（Staff 兩本共同承擔）、第一年帶人的具體場景（Making of a Manager）、管理動作的通用尺（High Output Management）。Staff 兩本合佔一個角色，兩本的差別在形式而非涵蓋範圍。

分佈刻意偏向個人貢獻者與初階管理。理由是位置越高，同一個職稱在不同公司對應的實際工作差異越大，書能提供的通用部分就越少——到了管理管理者這一層，組織的規模、產業與治理結構決定的比書多。

職涯類的書在技術書市成長很快，多數落在兩個已被承擔的角色：重述大廠職級制度的升等指南，以及個人成功敘事。前者被《The Software Engineer’s Guidebook》以更廣的跨公司觀察覆蓋，後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它：換一間制度不同的公司，這條建議會怎麼變。答不出來的是敘事而非分析。

這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 主題書單 的公開課段。

這個主題接到哪裡

確定了位置之後，各項具體能力回到對應主題：交付效能走 持續交付與交付效能，團隊切分走 組織結構與團隊設計，人留不留得住走 留任、動機與工作環境，該講的話講不出口走 困難對話與無權限影響力。

要判斷自己現在站在哪個位置、以及位置對應的起點書，回到 軟體管理與組織書單 的位置表。