這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 工程技藝。兩條線的失敗互相看不見，因此分開。另有一條線 財務與投資 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。

書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。

完全不熟悉這個領域時先讀這一本

Accelerate 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。

它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。

依當下的位置選書

位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：交不出來的時候，誰會被問。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 依位置選書 的五篇裡。

起點書的完整描述與購書連結在對應的主題篇：前三本在 角色轉換與職涯路徑，Peopleware 在 留任、動機與工作環境，Team Topologies 在 組織結構與團隊設計。

有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 依位置選書 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。

想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 角色轉換與職涯路徑：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 留任、動機與工作環境 與 組織文化與心理安全感——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 困難對話與無權限影響力 與 組織結構與團隊設計，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。

依主題選書

十一個主題與各自的首選書在 主題書單目錄。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。

經典套書怎麼買

各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。

Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 問題定義與系統思考，第 2 卷第一級評量在 持續交付與交付效能，第 3 卷關照全局的管理作為在 困難對話與無權限影響力，第 4 卷擁抱變革在 組織結構與團隊設計。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在博客來。

Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 留任、動機與工作環境，《Waltzing with Bears》（繁中《與熊共舞》）在 估算、承諾與決策偏誤。兩本沒有合購版本，分開買。

相關的實作內容

書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 CI/CD 教學，服務探活、容量規劃與高可用看 運行期維運，事故分級、指揮角色與復盤制度看 事故處理與復盤，客戶端遙測的四類事件與收集鏈路看 Monitoring 監控體系，交付生命週期全景看 DevOps 全景。既有團隊的結構評估協議看 發射管制隊視角：評估工作團隊設計。

Backlog

改組織圖而沒有改任何人的實際約束，是這個位置代價最高的失敗。畫新的框、宣布新的分工，隔天每個人面對的優先序、被誰打斷、被誰評分都沒有變。三個月後一切照舊，信任被消耗掉一次。與它相鄰的是把每一個跨團隊問題都當成溝通問題處理——那個解釋的吸引力在於它不必動結構。

對組織結構負責時，成文制度與否的差別

制度成文的大組織裡，這個位置的動作要穿過既有制度，於是變更成本高到讓錯誤結構被保留。具體長這樣：某個服務跨在兩個團隊的邊界上，每改一次都要兩邊各自排期，通常差兩到三週；提議把它併進其中一邊，就要動另一邊的 headcount，而 headcount 綁在年度預算裡、還要說服兩位主管跟他們共同的上級；於是這件事每季被提一次，每次都合理地被延後。這裡需要的是判斷哪些結構債值得付這個代價去修，哪些改用介面設計繞過——把跨團隊的協作改成一方提供穩定介面、另一方自助使用，不動組織圖也能減少排期依賴。

制度還沒定型、但層級已經出現的公司（人數常落在五十到兩百之間，但決定性的是制度而非人數）問題相反：改組織幾乎沒有成本，於是改得太頻繁。每次重組都重置一次團隊的默契與領域知識；那個成本不會出現在任何報表上。這裡需要的是知道重組的代價在哪裡、以及什麼訊號才真的構成重組的理由。

這個位置該讀什麼

Team Topologies（Skelton & Pais）是這個位置的主要書。它在這個位置的用途是把切分決定寫成別人可以反駁的形式——這條路線的決定會被上下兩層檢視，而「我覺得這樣切比較好」擋不住任何一次質疑。書的完整描述在主題篇。

An Elegant Puzzle（Will Larson）處理的是這裡的日常：團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。它的團隊狀態模型在這個位置的用途是分配資源時的共同語言：這裡的判斷單位是團隊之間的介面，而爭資源的場合需要一個雙方都認的分類，否則討論會退回誰的嗓門大。模型本身的四種狀態與各自的介入方式在主題篇。

How Big Things Get Done（Flyvbjerg & Gardner）處理的是這個位置躲不掉的承諾問題。它區分的兩個失準來源對這條路線特別重要，因為到這裡的所有估算都經過至少兩層轉述，每一層都有調整它的誘因——分不出手上這個數字失真在哪一層，加再多緩衝也押錯地方。兩個來源各是什麼、為什麼其中一個靠方法修不了，在主題篇。

The Fearless Organization 在這個位置讀出來的東西，跟直接帶人的人讀到的不同。這裡的問題是壞消息在兩層轉述中會不會被磨平——每一層都做了合理的摘要，而合理的摘要累積起來就是失真；自己的團隊敢不敢講是 對人負責 那一篇的題目。

Quality Software Management, Vol. 4（Gerald Weinberg，繁中譯名《溫伯格的軟體管理學：擁抱變革》，四卷各自獨立、不必從第 1 卷讀起）處理推動組織轉變時的人的阻力，是這條路線上唯一一本把抗拒當資訊而不是當障礙的書。完整的性質判定與讀的時機在主題篇。

想往哪裡走

進到這個位置的方式通常是組織長大，而不是換了工作內容——原本帶的一個團隊裂成兩個，人就在這裡了。準備好的訊號是兩個團隊之間的事已經在處理：協調誰做哪一段、決定介面長什麼樣、被找去仲裁優先序。沒有這些累積就直接接下多團隊，最常見的結果是把時間全部花在其中一個團隊上，因為那是唯一熟悉的工作。

這個位置往上走，書能提供的比重快速下降。位置越高，同一個職稱在不同公司對應的實際工作差異越大，決定成敗的是這個組織的規模、產業與治理結構，而那些沒有通用解。

比較有用的方向是往深處而非往上：Wiring the Winning Organization 嘗試解釋為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單，適合手上已經有一批彼此不相干的做法、想找共同解釋的人。Software Engineering at Google 提供的是規模與時間如何反轉工程判斷的具體案例，可以拿來校準自己組織的規模對應到哪些問題。

要把結構決定落到實際的評估動作，發射管制隊視角：評估工作團隊設計 提供的是把這類框架用在既有團隊上的判讀步驟。

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

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

起點是 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》以更廣的跨公司觀察覆蓋，後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它：換一間制度不同的公司，這條建議會怎麼變。答不出來的是敘事而非分析。

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

這個主題接到哪裡

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

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