<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Career on Tarragon</title><link>https://tarrragon.github.io/blog/tags/career/</link><description>Recent content in Career on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Wed, 19 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/career/index.xml" rel="self" type="application/rss+xml"/><item><title>依位置選書</title><link>https://tarrragon.github.io/blog/books/software-management/roles/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/</guid><description>&lt;p>位置篇按責任範圍組織，不按職稱。同一個職稱在不同組織對應的責任差很多——三十人公司的「資深工程師」經常同時對別人的產出與技術品質負責，五百人公司的同一個職稱可能只對自己的產出負責。職稱與實際責任一致時兩者等價，不一致時以責任為準；責任軸的代價是它要自我診斷；職稱則是外部給定、查得到的。下一段的判準就是為了讓這個診斷有可操作的做法。&lt;/p>
&lt;p>每篇處理三件事：這個位置一天實際在處理什麼、同一個責任範圍在制度成文與不成文的組織裡問題差在哪、以及往相鄰位置移動前該預習什麼。制度化程度才是那一段的軸，人數只是粗略訊號——三百人的家族企業可能沒有職級帶，八十人的新創可能整套沿用大廠的 ladder。判的方法是逐項確認四樣東西寫不寫得出來：晉升的條件、績效評估的流程、薪資帶的範圍、以及調動要經過誰。四樣都有文件、而且文件跟實際發生的事一致，是成文；四樣都靠個案決定，是不成文；最常見的是中間態——文件存在但實際決定不照它走，那種情況照不成文處理，因為位置篇談的是這個位置真正能用的工具。另外一個訊號在預算側：headcount 綁在年度預算裡、增補要跨部門核准的，制度化程度通常已經很高。&lt;/p>
&lt;p>遠距、跨國、公部門這三種情境會再疊上各自的變形（可見度、單一薪資市場的假設、法定薪級），那些差異這批內容沒有處理——跨時區非同步團隊尤其要先看&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>。書的完整描述都在 &lt;a href="../topics/">主題書單&lt;/a>，這裡只說「哪種處境對應哪本」與為什麼。&lt;/p>
&lt;h2 id="五個位置">五個位置&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>對什麼負責&lt;/th>
 &lt;th>最常見的失敗&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="own-output/">只對自己的產出負責&lt;/a>&lt;/td>
 &lt;td>交出去的東西本身&lt;/td>
 &lt;td>做完了但沒人知道它做完了&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="technical-quality/">對技術品質負責、不帶人&lt;/a>&lt;/td>
 &lt;td>跨越多人的技術決策與標準&lt;/td>
 &lt;td>方案是對的，但推不動&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="others-output/">對別人的產出負責&lt;/a>&lt;/td>
 &lt;td>團隊交出去的東西&lt;/td>
 &lt;td>自己重寫比教會別人快，於是永遠自己重寫&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="people/">對人負責&lt;/a>&lt;/td>
 &lt;td>這些人留不留得住、成不成長&lt;/td>
 &lt;td>把「管理」做成「更大範圍的自己動手」&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="org-structure/">對組織結構負責&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責&lt;/td>
 &lt;td>改組織圖而沒有改任何人的實際約束&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="怎麼判斷自己在哪一格">怎麼判斷自己在哪一格&lt;/h2>
&lt;p>判準是&lt;strong>交不出來的時候，誰會被問&lt;/strong>：&lt;/p>
&lt;ul>
&lt;li>只有自己被問 → &lt;a href="own-output/">只對自己的產出負責&lt;/a>&lt;/li>
&lt;li>沒有人交不出來、但技術決策錯了會問到自己 → &lt;a href="technical-quality/">對技術品質負責&lt;/a>&lt;/li>
&lt;li>別人交不出來而問到自己 → &lt;a href="others-output/">對別人的產出負責&lt;/a>&lt;/li>
&lt;li>人走了會問到自己 → &lt;a href="people/">對人負責&lt;/a>&lt;/li>
&lt;li>團隊之間卡住而沒有人特別該負責時會問到自己 → &lt;a href="org-structure/">對組織結構負責&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>這張清單判不出來的三種處境，答案都在本節後半，依出現順序是：還沒被指派而想先評估下一格（本節第五段）、好幾格同時成立（倒數第二段）、團隊人數不到一個團隊（最後一段）。夾在中間的兩段講的是判準本身在哪些組織會失準，跟這三種處境無關。&lt;/p>
&lt;p>另外有五種組織會讓判準本身失準。前三種是「被問」這件事在組織裡的分佈出了問題：什麼都問同一個人的、集體負責而沒有人被特別問的、以及被問的人不是有槓桿的人。第四種是&lt;strong>沒有人在看&lt;/strong>——沒有人來問不一定表示做得好，也可能是這件事還沒有人在追，這種情況下判準收不到任何訊號。第五種是&lt;strong>問責發生在組織外&lt;/strong>：受主管機關監理的組織，事故後由稽核與監理單位問責，組織內部可能沒有任何人被問，而責任是真實存在的。&lt;/p>
&lt;p>什麼都問同一個人的、集體負責的、以及沒有人在看的這三種，改看&lt;strong>手上能動的槓桿&lt;/strong>——能不能改變別人的優先序、能不能動人事、能不能改變交接面怎麼定，能動到哪一層就讀哪一篇。被問的人沒有槓桿那一種不適用這個處方（它的定義就是槓桿不存在），那種處境照被問的位置選書，同時把 &lt;a href="../topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 排在前面。問責發生在組織外那一種照法定的責任歸屬判，那通常比組織內部的分工更明確。責任大於權限的處境不必因此退出選書：技術品質與別人的產出這兩格的定義本來就是責任大於權限，照被問的位置選書仍然對，只是要先補 &lt;a href="../topics/influence-conversation/">困難對話與無權限影響力&lt;/a>，否則選對了書也推不動。&lt;/p>
&lt;p>這個判準問的是現在。換位置的人需要的卻是下一格。&lt;strong>下一格不是現在這一格的人，照現況判都會落在舊的那一格&lt;/strong>——已經確定要轉換的（下個月開始帶人、下一季接下平台團隊）是一種，還在評估要不要轉換、連機會都還沒出現的是另一種。那不是判錯，只是判準只看得到當下。兩種處境讀兩篇：現在這個位置的「想往哪裡走」段說明該預習什麼，目標那一格的前兩段說明即將接手的問題長什麼樣。還在評估的人另外先看 &lt;a href="../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>——那裡的書逐層寫出每個位置整天實際在處理什麼，而「值不值得走過去」要先看得到那個才答得出來。轉換之後再讀一次目標那篇，讀出來的東西會跟轉換前不同——這是刻意的，判準要等到承擔責任才長得出來。&lt;/p>
&lt;p>這五格是有僱傭關係、責任由組織分配的處境。獨立接案者、開源維護者、DevRel、研究型工程師、技術寫作者的責任來源不同——對客戶、對社群、對外部讀者——那些處境不在這條線的範圍內，套進五格會失真。五格之間也不是階梯：檔案的排序是責任範圍由小到大，不是該走的順序，橫向移動與留在原地都是正常路徑，每篇的「想往哪裡走」段有標出哪些方向存在。&lt;/p>
&lt;p>同時符合兩處時取當下解不掉的那一處——已經在解的那些問題不需要一本書指出怎麼開始。完全對不上的情況也存在——小公司的技術負責人可能同時負責技術品質、別人的產出、人與組織結構，那種處境的建議是照急迫度挑一篇開始，而不是四篇一起讀。&lt;/p>
&lt;p>有一個規模下限要先確認：&lt;a href="org-structure/">對組織結構負責&lt;/a> 那篇的書預設組織裡至少有三個團隊（這個數字的推導在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的約束段）。人數在一個團隊以內時，那些內容是為不存在的問題做設計，先看 &lt;a href="others-output/">對別人的產出負責&lt;/a>。&lt;a href="people/">對人負責&lt;/a> 那一格照樣成立——兩個人的去留一樣決定得了公司能不能活，只是那一格的書預設組織已經有分級、調薪與績效制度可用，沒有制度時讀到的是那些工具背後的判斷，而不是照著把制度建起來。這個規模真正該補的另一半在 &lt;a href="../../craft/">工程技藝&lt;/a>。&lt;/p>
&lt;p>其他會改變答案的約束（人員流動率、協作形態、法規義務、預算）見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「哪些約束會改變答案」段。&lt;/p>
&lt;h2 id="這幾篇跟主題篇的分工">這幾篇跟主題篇的分工&lt;/h2>
&lt;p>主題篇按問題組織，回答「這個問題該讀什麼」；位置篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多個位置的建議裡，用法不同——&lt;a href="../topics/retention-motivation/">Peopleware&lt;/a> 給只對自己產出負責的人的是「原來我的環境是這樣壞掉的」，給對人負責的人的是「我可以動哪些槓桿」。&lt;/p>
&lt;p>書的性質判定（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提）一律在主題篇，位置篇不重複，避免同一本書的多份說明各自漂移。位置篇寫的是「哪種處境對應哪本、在這裡怎麼用」，而同一本書在多個位置各有一句用法時，那幾句也會漂移——防這一層的做法是各句只講該位置獨有的用途，不重述書的主張本身，書是什麼以主題篇為準。同一條規則也適用於主題篇之間：一本書的性質判定住在它的主場那一篇，別篇引用時只指路、不重述。&lt;/p></description><content:encoded><![CDATA[<p>位置篇按責任範圍組織，不按職稱。同一個職稱在不同組織對應的責任差很多——三十人公司的「資深工程師」經常同時對別人的產出與技術品質負責，五百人公司的同一個職稱可能只對自己的產出負責。職稱與實際責任一致時兩者等價，不一致時以責任為準；責任軸的代價是它要自我診斷；職稱則是外部給定、查得到的。下一段的判準就是為了讓這個診斷有可操作的做法。</p>
<p>每篇處理三件事：這個位置一天實際在處理什麼、同一個責任範圍在制度成文與不成文的組織裡問題差在哪、以及往相鄰位置移動前該預習什麼。制度化程度才是那一段的軸，人數只是粗略訊號——三百人的家族企業可能沒有職級帶，八十人的新創可能整套沿用大廠的 ladder。判的方法是逐項確認四樣東西寫不寫得出來：晉升的條件、績效評估的流程、薪資帶的範圍、以及調動要經過誰。四樣都有文件、而且文件跟實際發生的事一致，是成文；四樣都靠個案決定，是不成文；最常見的是中間態——文件存在但實際決定不照它走，那種情況照不成文處理，因為位置篇談的是這個位置真正能用的工具。另外一個訊號在預算側：headcount 綁在年度預算裡、增補要跨部門核准的，制度化程度通常已經很高。</p>
<p>遠距、跨國、公部門這三種情境會再疊上各自的變形（可見度、單一薪資市場的假設、法定薪級），那些差異這批內容沒有處理——跨時區非同步團隊尤其要先看<a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>。書的完整描述都在 <a href="../topics/">主題書單</a>，這裡只說「哪種處境對應哪本」與為什麼。</p>
<h2 id="五個位置">五個位置</h2>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>對什麼負責</th>
          <th>最常見的失敗</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="own-output/">只對自己的產出負責</a></td>
          <td>交出去的東西本身</td>
          <td>做完了但沒人知道它做完了</td>
      </tr>
      <tr>
          <td><a href="technical-quality/">對技術品質負責、不帶人</a></td>
          <td>跨越多人的技術決策與標準</td>
          <td>方案是對的，但推不動</td>
      </tr>
      <tr>
          <td><a href="others-output/">對別人的產出負責</a></td>
          <td>團隊交出去的東西</td>
          <td>自己重寫比教會別人快，於是永遠自己重寫</td>
      </tr>
      <tr>
          <td><a href="people/">對人負責</a></td>
          <td>這些人留不留得住、成不成長</td>
          <td>把「管理」做成「更大範圍的自己動手」</td>
      </tr>
      <tr>
          <td><a href="org-structure/">對組織結構負責</a></td>
          <td>團隊怎麼切、交接面誰負責</td>
          <td>改組織圖而沒有改任何人的實際約束</td>
      </tr>
  </tbody>
</table>
<h2 id="怎麼判斷自己在哪一格">怎麼判斷自己在哪一格</h2>
<p>判準是<strong>交不出來的時候，誰會被問</strong>：</p>
<ul>
<li>只有自己被問 → <a href="own-output/">只對自己的產出負責</a></li>
<li>沒有人交不出來、但技術決策錯了會問到自己 → <a href="technical-quality/">對技術品質負責</a></li>
<li>別人交不出來而問到自己 → <a href="others-output/">對別人的產出負責</a></li>
<li>人走了會問到自己 → <a href="people/">對人負責</a></li>
<li>團隊之間卡住而沒有人特別該負責時會問到自己 → <a href="org-structure/">對組織結構負責</a></li>
</ul>
<p>這張清單判不出來的三種處境，答案都在本節後半，依出現順序是：還沒被指派而想先評估下一格（本節第五段）、好幾格同時成立（倒數第二段）、團隊人數不到一個團隊（最後一段）。夾在中間的兩段講的是判準本身在哪些組織會失準，跟這三種處境無關。</p>
<p>另外有五種組織會讓判準本身失準。前三種是「被問」這件事在組織裡的分佈出了問題：什麼都問同一個人的、集體負責而沒有人被特別問的、以及被問的人不是有槓桿的人。第四種是<strong>沒有人在看</strong>——沒有人來問不一定表示做得好，也可能是這件事還沒有人在追，這種情況下判準收不到任何訊號。第五種是<strong>問責發生在組織外</strong>：受主管機關監理的組織，事故後由稽核與監理單位問責，組織內部可能沒有任何人被問，而責任是真實存在的。</p>
<p>什麼都問同一個人的、集體負責的、以及沒有人在看的這三種，改看<strong>手上能動的槓桿</strong>——能不能改變別人的優先序、能不能動人事、能不能改變交接面怎麼定，能動到哪一層就讀哪一篇。被問的人沒有槓桿那一種不適用這個處方（它的定義就是槓桿不存在），那種處境照被問的位置選書，同時把 <a href="../topics/influence-conversation/">困難對話與無權限影響力</a> 排在前面。問責發生在組織外那一種照法定的責任歸屬判，那通常比組織內部的分工更明確。責任大於權限的處境不必因此退出選書：技術品質與別人的產出這兩格的定義本來就是責任大於權限，照被問的位置選書仍然對，只是要先補 <a href="../topics/influence-conversation/">困難對話與無權限影響力</a>，否則選對了書也推不動。</p>
<p>這個判準問的是現在。換位置的人需要的卻是下一格。<strong>下一格不是現在這一格的人，照現況判都會落在舊的那一格</strong>——已經確定要轉換的（下個月開始帶人、下一季接下平台團隊）是一種，還在評估要不要轉換、連機會都還沒出現的是另一種。那不是判錯，只是判準只看得到當下。兩種處境讀兩篇：現在這個位置的「想往哪裡走」段說明該預習什麼，目標那一格的前兩段說明即將接手的問題長什麼樣。還在評估的人另外先看 <a href="../topics/role-transitions/">角色轉換與職涯路徑</a>——那裡的書逐層寫出每個位置整天實際在處理什麼，而「值不值得走過去」要先看得到那個才答得出來。轉換之後再讀一次目標那篇，讀出來的東西會跟轉換前不同——這是刻意的，判準要等到承擔責任才長得出來。</p>
<p>這五格是有僱傭關係、責任由組織分配的處境。獨立接案者、開源維護者、DevRel、研究型工程師、技術寫作者的責任來源不同——對客戶、對社群、對外部讀者——那些處境不在這條線的範圍內，套進五格會失真。五格之間也不是階梯：檔案的排序是責任範圍由小到大，不是該走的順序，橫向移動與留在原地都是正常路徑，每篇的「想往哪裡走」段有標出哪些方向存在。</p>
<p>同時符合兩處時取當下解不掉的那一處——已經在解的那些問題不需要一本書指出怎麼開始。完全對不上的情況也存在——小公司的技術負責人可能同時負責技術品質、別人的產出、人與組織結構，那種處境的建議是照急迫度挑一篇開始，而不是四篇一起讀。</p>
<p>有一個規模下限要先確認：<a href="org-structure/">對組織結構負責</a> 那篇的書預設組織裡至少有三個團隊（這個數字的推導在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的約束段）。人數在一個團隊以內時，那些內容是為不存在的問題做設計，先看 <a href="others-output/">對別人的產出負責</a>。<a href="people/">對人負責</a> 那一格照樣成立——兩個人的去留一樣決定得了公司能不能活，只是那一格的書預設組織已經有分級、調薪與績效制度可用，沒有制度時讀到的是那些工具背後的判斷，而不是照著把制度建起來。這個規模真正該補的另一半在 <a href="../../craft/">工程技藝</a>。</p>
<p>其他會改變答案的約束（人員流動率、協作形態、法規義務、預算）見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「哪些約束會改變答案」段。</p>
<h2 id="這幾篇跟主題篇的分工">這幾篇跟主題篇的分工</h2>
<p>主題篇按問題組織，回答「這個問題該讀什麼」；位置篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多個位置的建議裡，用法不同——<a href="../topics/retention-motivation/">Peopleware</a> 給只對自己產出負責的人的是「原來我的環境是這樣壞掉的」，給對人負責的人的是「我可以動哪些槓桿」。</p>
<p>書的性質判定（<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提）一律在主題篇，位置篇不重複，避免同一本書的多份說明各自漂移。位置篇寫的是「哪種處境對應哪本、在這裡怎麼用」，而同一本書在多個位置各有一句用法時，那幾句也會漂移——防這一層的做法是各句只講該位置獨有的用途，不重述書的主張本身，書是什麼以主題篇為準。同一條規則也適用於主題篇之間：一本書的性質判定住在它的主場那一篇，別篇引用時只指路、不重述。</p>
]]></content:encoded></item><item><title>只對自己的產出負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/own-output/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/own-output/</guid><description>&lt;p>工作內容是別人切好的、範圍是別人定的、時程通常也是；交不出來的時候，被問的就是做那件事的人自己。責任邊界清楚到這種程度，核心問題就不是「怎麼做完」，而是&lt;strong>怎麼讓別人相信做完的東西是對的&lt;/strong>，以及在沒有人明說的情況下判斷下一步該補什麼。&lt;/p>
&lt;p>兩種失敗在這個位置特別常見。一種是做完了但沒人知道它做完了：工作做得對，卻沒有留下讓別人能檢查、能接手、能信任的痕跡。另一種是把「更難的技術」當成成長方向，而卡住升遷的其實是協作與交付這一側。&lt;/p>
&lt;h2 id="只對自己產出負責時成文制度與否的差別">只對自己產出負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，這個位置的問題是&lt;strong>標準存在但寫得抽象&lt;/strong>。職級描述寫「影響範圍」「獨立性」「複雜度」，這些詞到績效面談時才被主管翻譯成具體行為，翻譯規則不公開。真正的困難是把抽象描述反推回可觀察行為；反推錯了要一整個週期才知道。&lt;/p>
&lt;p>扁平的小公司沒有這個問題，因為它連抽象標準都沒有。這裡的問題是&lt;strong>沒有人定義什麼叫做好&lt;/strong>——做得好不好取決於當下有沒有人抱怨——沒人抱怨可能是因為做得好，也可能是因為沒人看。這種環境裡的成長風險是三年後換工作時，發現自己的經驗無法被外部標準衡量。應對方式是主動引入外部標準當校準點：找一份公開的工程職級框架（大廠的 career ladder 多半公開），對照自己現在做的事落在哪一級、下一級要求什麼。走這個對照的時機不是排一個週期，是每次手上的工作性質明顯換了一種（開始被找去看別人的設計、開始要對一個模組的長期狀態負責）——那種變化才是級別移動的訊號，而它不按月份發生。這件事不需要公司同意，而且換工作時那份對照就是履歷的骨架。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Software Engineer&amp;rsquo;s Guidebook&lt;/a>&lt;/strong> 是這個位置的主要書。它把各級別的差異翻成可觀察的行為，直接處理上面說的「抽象標準反推」問題。有職級的組織可以拿它直接對照級別；沒有職級的組織讀到的是能力清單本身，而把清單排序的那根軸要另外找外部框架當錨——那正是上一段講的做法。剛入行就可以讀，不必先累積管理經驗。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/problem-definition/">Are Your Lights On?&lt;/a>&lt;/strong> 處理的是接到需求時「這到底是什麼問題」。這個位置的人拿到的需求通常已經被別人切過一次；切錯的需求照做出來仍然是錯的——能指出這件事，是這個位置最容易被看見的價值。一百多頁，一個下午讀得完。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Peopleware&lt;/a>&lt;/strong> 的用法在這個位置跟在管理位置不同。這裡讀它讀出來的是「原來我做不完事不全是我的問題」——中斷成本、環境條件、頻繁重組對產出的影響都有具體論證。這件事本身有實用價值（知道哪些是環境問題就不會全部歸咎自己），也是往管理方向預習時最難自然累積的一塊。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/personal-workflow/">Getting Things Done&lt;/a>&lt;/strong> 處理承諾多到記不住之後怎麼辦。它跟上面那本接得起來——Peopleware 指出哪些負擔來自環境，這本處理剩下屬於自己的那些。這個位置特別要知道的邊界是：被指派進共用待辦、在群組頻道裡被喊住的那些工作不經過任何屬於個人的入口，而那正是這一格最常見的來源。那一層由同一篇的 A World Without Email 與 Four Thousand Weeks 處理，方法本身與它的處境限制在主題篇。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>轉換通常由別人啟動——有人離職、團隊變大、專案需要一個窗口，而不是誰主動申請。能控制的只有被想到的機率：可觀察的訊號是別人開始拿設計來問意見、新人的問題自然流過來、自己的估算被拿去當基準。這三件事發生時，開口說「我想試試看帶這個」的成功率比沒發生時高得多。&lt;/p>
&lt;p>&lt;strong>往技術路線&lt;/strong>（&lt;a href="../technical-quality/">對技術品質負責&lt;/a>）：現在該預習的是影響力，不是技術深度。技術深度會隨著工作自然累積，而「沒有職權時怎麼讓別人照著做」在這個位置上完全練不到——這裡的方案被採納，通常是因為它只影響提案的人自己。&lt;a href="../../topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 那條線是這段路的預習。&lt;/p>
&lt;p>&lt;strong>往管理路線&lt;/strong>（&lt;a href="../others-output/">對別人的產出負責&lt;/a>）：現在該預習的是人與環境，同樣不是技術。還在判斷要不要走這條路的話，先看 &lt;a href="../../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>——那裡的書寫出這些位置一天實際在做什麼，看得到那個才決定得了值不值得。決定要走之後，&lt;a href="../../topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="../../topics/culture-safety/">組織文化與心理安全感&lt;/a> 這兩塊在只對自己負責的位置上沒有練習機會，它們卻決定管理做得好不好。&lt;/p>
&lt;p>&lt;strong>留在這裡繼續深化&lt;/strong>也是完整的路線。把一件事做到別人會來問，本身就是一個位置，而不是還沒選路的狀態；資深個人貢獻者是體面的終點，不是往管理路上的中繼站。往這個方向走要補的是技藝本身——怎麼寫出改得動的程式、怎麼安全地改別人的程式、怎麼知道自己沒弄壞，那整條線在 &lt;a href="../../../craft/">工程技藝書單&lt;/a>。&lt;/p>
&lt;p>三條路都不需要現在決定。這個階段值得做的是先讀 Guidebook 弄清楚各條路要什麼，再看哪一邊的問題讓自己比較有興趣。&lt;/p></description><content:encoded><![CDATA[<p>工作內容是別人切好的、範圍是別人定的、時程通常也是；交不出來的時候，被問的就是做那件事的人自己。責任邊界清楚到這種程度，核心問題就不是「怎麼做完」，而是<strong>怎麼讓別人相信做完的東西是對的</strong>，以及在沒有人明說的情況下判斷下一步該補什麼。</p>
<p>兩種失敗在這個位置特別常見。一種是做完了但沒人知道它做完了：工作做得對，卻沒有留下讓別人能檢查、能接手、能信任的痕跡。另一種是把「更難的技術」當成成長方向，而卡住升遷的其實是協作與交付這一側。</p>
<h2 id="只對自己產出負責時成文制度與否的差別">只對自己產出負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，這個位置的問題是<strong>標準存在但寫得抽象</strong>。職級描述寫「影響範圍」「獨立性」「複雜度」，這些詞到績效面談時才被主管翻譯成具體行為，翻譯規則不公開。真正的困難是把抽象描述反推回可觀察行為；反推錯了要一整個週期才知道。</p>
<p>扁平的小公司沒有這個問題，因為它連抽象標準都沒有。這裡的問題是<strong>沒有人定義什麼叫做好</strong>——做得好不好取決於當下有沒有人抱怨——沒人抱怨可能是因為做得好，也可能是因為沒人看。這種環境裡的成長風險是三年後換工作時，發現自己的經驗無法被外部標準衡量。應對方式是主動引入外部標準當校準點：找一份公開的工程職級框架（大廠的 career ladder 多半公開），對照自己現在做的事落在哪一級、下一級要求什麼。走這個對照的時機不是排一個週期，是每次手上的工作性質明顯換了一種（開始被找去看別人的設計、開始要對一個模組的長期狀態負責）——那種變化才是級別移動的訊號，而它不按月份發生。這件事不需要公司同意，而且換工作時那份對照就是履歷的骨架。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/role-transitions/">The Software Engineer&rsquo;s Guidebook</a></strong> 是這個位置的主要書。它把各級別的差異翻成可觀察的行為，直接處理上面說的「抽象標準反推」問題。有職級的組織可以拿它直接對照級別；沒有職級的組織讀到的是能力清單本身，而把清單排序的那根軸要另外找外部框架當錨——那正是上一段講的做法。剛入行就可以讀，不必先累積管理經驗。</p>
<p><strong><a href="../../topics/problem-definition/">Are Your Lights On?</a></strong> 處理的是接到需求時「這到底是什麼問題」。這個位置的人拿到的需求通常已經被別人切過一次；切錯的需求照做出來仍然是錯的——能指出這件事，是這個位置最容易被看見的價值。一百多頁，一個下午讀得完。</p>
<p><strong><a href="../../topics/retention-motivation/">Peopleware</a></strong> 的用法在這個位置跟在管理位置不同。這裡讀它讀出來的是「原來我做不完事不全是我的問題」——中斷成本、環境條件、頻繁重組對產出的影響都有具體論證。這件事本身有實用價值（知道哪些是環境問題就不會全部歸咎自己），也是往管理方向預習時最難自然累積的一塊。</p>
<p><strong><a href="../../topics/personal-workflow/">Getting Things Done</a></strong> 處理承諾多到記不住之後怎麼辦。它跟上面那本接得起來——Peopleware 指出哪些負擔來自環境，這本處理剩下屬於自己的那些。這個位置特別要知道的邊界是：被指派進共用待辦、在群組頻道裡被喊住的那些工作不經過任何屬於個人的入口，而那正是這一格最常見的來源。那一層由同一篇的 A World Without Email 與 Four Thousand Weeks 處理，方法本身與它的處境限制在主題篇。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>轉換通常由別人啟動——有人離職、團隊變大、專案需要一個窗口，而不是誰主動申請。能控制的只有被想到的機率：可觀察的訊號是別人開始拿設計來問意見、新人的問題自然流過來、自己的估算被拿去當基準。這三件事發生時，開口說「我想試試看帶這個」的成功率比沒發生時高得多。</p>
<p><strong>往技術路線</strong>（<a href="../technical-quality/">對技術品質負責</a>）：現在該預習的是影響力，不是技術深度。技術深度會隨著工作自然累積，而「沒有職權時怎麼讓別人照著做」在這個位置上完全練不到——這裡的方案被採納，通常是因為它只影響提案的人自己。<a href="../../topics/influence-conversation/">困難對話與無權限影響力</a> 那條線是這段路的預習。</p>
<p><strong>往管理路線</strong>（<a href="../others-output/">對別人的產出負責</a>）：現在該預習的是人與環境，同樣不是技術。還在判斷要不要走這條路的話，先看 <a href="../../topics/role-transitions/">角色轉換與職涯路徑</a>——那裡的書寫出這些位置一天實際在做什麼，看得到那個才決定得了值不值得。決定要走之後，<a href="../../topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="../../topics/culture-safety/">組織文化與心理安全感</a> 這兩塊在只對自己負責的位置上沒有練習機會，它們卻決定管理做得好不好。</p>
<p><strong>留在這裡繼續深化</strong>也是完整的路線。把一件事做到別人會來問，本身就是一個位置，而不是還沒選路的狀態；資深個人貢獻者是體面的終點，不是往管理路上的中繼站。往這個方向走要補的是技藝本身——怎麼寫出改得動的程式、怎麼安全地改別人的程式、怎麼知道自己沒弄壞，那整條線在 <a href="../../../craft/">工程技藝書單</a>。</p>
<p>三條路都不需要現在決定。這個階段值得做的是先讀 Guidebook 弄清楚各條路要什麼，再看哪一邊的問題讓自己比較有興趣。</p>
]]></content:encoded></item><item><title>軟體管理與組織書單</title><link>https://tarrragon.github.io/blog/books/software-management/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/</guid><description>&lt;p>這條線涵蓋受僱於某個組織、責任範圍從只對自己的產出到對整個組織結構的五種位置。位置決定當下煩惱什麼：初中級工程師煩惱怎麼讓自己的產出被信任，Tech Lead 煩惱怎麼讓別人的產出達標，EM 煩惱人留不留得住，管理管理者煩惱組織切法對不對。這些煩惱各自對應不同的書，但涵蓋的知識領域大量重疊——同一本談心理安全感的書，四個位置都用得到，用法完全不同。&lt;/p>
&lt;p>這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 &lt;a href="../craft/">工程技藝&lt;/a>。兩條線的失敗互相看不見，因此分開。另有一條線 &lt;a href="../finance/">財務與投資&lt;/a> 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。&lt;/p>
&lt;p>書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。&lt;/p>
&lt;h2 id="完全不熟悉這個領域時先讀這一本">完全不熟悉這個領域時先讀這一本&lt;/h2>
&lt;p>&lt;a href="topics/continuous-delivery/">Accelerate&lt;/a> 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。&lt;/p>
&lt;p>它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。&lt;/p>
&lt;h2 id="依當下的位置選書">依當下的位置選書&lt;/h2>
&lt;p>位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：&lt;strong>交不出來的時候，誰會被問&lt;/strong>。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 &lt;a href="roles/">依位置選書&lt;/a> 的五篇裡。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>當下的主要問題&lt;/th>
 &lt;th>起點&lt;/th>
 &lt;th>主要主題&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="roles/own-output/">只對自己的產出負責&lt;/a>&lt;/td>
 &lt;td>怎麼讓產出被信任、怎麼知道自己下一步該補什麼&lt;/td>
 &lt;td>The Software Engineer&amp;rsquo;s Guidebook&lt;/td>
 &lt;td>&lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>、&lt;a href="topics/problem-definition/">問題定義與系統思考&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/technical-quality/">對技術品質負責、不帶人&lt;/a>&lt;/td>
 &lt;td>沒有指揮權時怎麼讓別人照著做、技術決策怎麼被採納&lt;/td>
 &lt;td>The Staff Engineer&amp;rsquo;s Path&lt;/td>
 &lt;td>&lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>、&lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/others-output/">對別人的產出負責（Tech Lead）&lt;/a>&lt;/td>
 &lt;td>怎麼讓團隊的產出達標而不變成自己重寫&lt;/td>
 &lt;td>The Manager&amp;rsquo;s Path&lt;/td>
 &lt;td>&lt;a href="topics/continuous-delivery/">持續交付與交付效能&lt;/a>、&lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/people/">對人負責（EM）&lt;/a>&lt;/td>
 &lt;td>人留不留得住、回饋怎麼給、壞消息為什麼傳不上來&lt;/td>
 &lt;td>Peopleware&lt;/td>
 &lt;td>&lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>、&lt;a href="topics/culture-safety/">組織文化與心理安全感&lt;/a>、&lt;a href="topics/personal-workflow/">個人工作流與工作負荷&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/org-structure/">對組織結構負責（管理管理者）&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責、承諾為什麼總是跳票&lt;/td>
 &lt;td>Team Topologies&lt;/td>
 &lt;td>&lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>、&lt;a href="topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>起點書的完整描述與購書連結在對應的主題篇：前三本在 &lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>，Peopleware 在 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>，Team Topologies 在 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 &lt;a href="roles/">依位置選書&lt;/a> 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。&lt;/p>
&lt;p>想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 &lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="topics/culture-safety/">組織文化與心理安全感&lt;/a>——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 &lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 與 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。&lt;/p>
&lt;h2 id="依主題選書">依主題選書&lt;/h2>
&lt;p>十一個主題與各自的首選書在 &lt;a href="topics/">主題書單目錄&lt;/a>。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。&lt;/p>
&lt;h2 id="經典套書怎麼買">經典套書怎麼買&lt;/h2>
&lt;p>各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。&lt;/p>
&lt;p>Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 &lt;a href="topics/problem-definition/">問題定義與系統思考&lt;/a>，第 2 卷第一級評量在 &lt;a href="topics/continuous-delivery/">持續交付與交付效能&lt;/a>，第 3 卷關照全局的管理作為在 &lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>，第 4 卷擁抱變革在 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在&lt;a href="https://www.books.com.tw/products/0010553999">博客來&lt;/a>。&lt;/p>
&lt;p>Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>，《Waltzing with Bears》（繁中《與熊共舞》）在 &lt;a href="topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>。兩本沒有合購版本，分開買。&lt;/p>
&lt;h2 id="相關的實作內容">相關的實作內容&lt;/h2>
&lt;p>書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 &lt;a href="https://tarrragon.github.io/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學&lt;/a>，服務探活、容量規劃與高可用看 &lt;a href="https://tarrragon.github.io/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運&lt;/a>，事故分級、指揮角色與復盤制度看 &lt;a href="https://tarrragon.github.io/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤&lt;/a>，客戶端遙測的四類事件與收集鏈路看 &lt;a href="https://tarrragon.github.io/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系&lt;/a>，交付生命週期全景看 &lt;a href="https://tarrragon.github.io/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景&lt;/a>。既有團隊的結構評估協議看 &lt;a href="https://tarrragon.github.io/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計&lt;/a>。&lt;/p>
&lt;h2 id="backlog">Backlog&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>項目&lt;/th>
 &lt;th>類型&lt;/th>
 &lt;th>前置條件&lt;/th>
 &lt;th>規模&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>十個主題各跑一次機制式搜尋&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>機制詞候選事前寫死在主題書單的公開課段（研究設計與因果推論 / 承諾可信度 / 訊號傳遞 / 集體決策 / 因果回路與存量流量），產物是十組詞各查到什麼，可重跑&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>沒查到課的十個主題重掃一次&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音；是哪十個主題與各自為什麼空，見 &lt;a href="topics/">主題書單&lt;/a> 的公開課段&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>系統思考這個主題改判&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>MIT 15.871 補上影片，或找到另一門教因果回路與存量流量而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃&lt;/td>
 &lt;td>1 段&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description><content:encoded><![CDATA[<p>這條線涵蓋受僱於某個組織、責任範圍從只對自己的產出到對整個組織結構的五種位置。位置決定當下煩惱什麼：初中級工程師煩惱怎麼讓自己的產出被信任，Tech Lead 煩惱怎麼讓別人的產出達標，EM 煩惱人留不留得住，管理管理者煩惱組織切法對不對。這些煩惱各自對應不同的書，但涵蓋的知識領域大量重疊——同一本談心理安全感的書，四個位置都用得到，用法完全不同。</p>
<p>這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 <a href="../craft/">工程技藝</a>。兩條線的失敗互相看不見，因此分開。另有一條線 <a href="../finance/">財務與投資</a> 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。</p>
<p>書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。</p>
<h2 id="完全不熟悉這個領域時先讀這一本">完全不熟悉這個領域時先讀這一本</h2>
<p><a href="topics/continuous-delivery/">Accelerate</a> 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。</p>
<p>它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。</p>
<h2 id="依當下的位置選書">依當下的位置選書</h2>
<p>位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：<strong>交不出來的時候，誰會被問</strong>。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 <a href="roles/">依位置選書</a> 的五篇裡。</p>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>當下的主要問題</th>
          <th>起點</th>
          <th>主要主題</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="roles/own-output/">只對自己的產出負責</a></td>
          <td>怎麼讓產出被信任、怎麼知道自己下一步該補什麼</td>
          <td>The Software Engineer&rsquo;s Guidebook</td>
          <td><a href="topics/role-transitions/">角色轉換與職涯路徑</a>、<a href="topics/problem-definition/">問題定義與系統思考</a></td>
      </tr>
      <tr>
          <td><a href="roles/technical-quality/">對技術品質負責、不帶人</a></td>
          <td>沒有指揮權時怎麼讓別人照著做、技術決策怎麼被採納</td>
          <td>The Staff Engineer&rsquo;s Path</td>
          <td><a href="topics/influence-conversation/">困難對話與無權限影響力</a>、<a href="topics/team-design/">組織結構與團隊設計</a></td>
      </tr>
      <tr>
          <td><a href="roles/others-output/">對別人的產出負責（Tech Lead）</a></td>
          <td>怎麼讓團隊的產出達標而不變成自己重寫</td>
          <td>The Manager&rsquo;s Path</td>
          <td><a href="topics/continuous-delivery/">持續交付與交付效能</a>、<a href="topics/influence-conversation/">困難對話與無權限影響力</a></td>
      </tr>
      <tr>
          <td><a href="roles/people/">對人負責（EM）</a></td>
          <td>人留不留得住、回饋怎麼給、壞消息為什麼傳不上來</td>
          <td>Peopleware</td>
          <td><a href="topics/retention-motivation/">留任、動機與工作環境</a>、<a href="topics/culture-safety/">組織文化與心理安全感</a>、<a href="topics/personal-workflow/">個人工作流與工作負荷</a></td>
      </tr>
      <tr>
          <td><a href="roles/org-structure/">對組織結構負責（管理管理者）</a></td>
          <td>團隊怎麼切、交接面誰負責、承諾為什麼總是跳票</td>
          <td>Team Topologies</td>
          <td><a href="topics/team-design/">組織結構與團隊設計</a>、<a href="topics/estimation-decision/">估算、承諾與決策偏誤</a></td>
      </tr>
  </tbody>
</table>
<p>起點書的完整描述與購書連結在對應的主題篇：前三本在 <a href="topics/role-transitions/">角色轉換與職涯路徑</a>，Peopleware 在 <a href="topics/retention-motivation/">留任、動機與工作環境</a>，Team Topologies 在 <a href="topics/team-design/">組織結構與團隊設計</a>。</p>
<p>有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 <a href="roles/">依位置選書</a> 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。</p>
<p>想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 <a href="topics/role-transitions/">角色轉換與職涯路徑</a>：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 <a href="topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="topics/culture-safety/">組織文化與心理安全感</a>——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 <a href="topics/influence-conversation/">困難對話與無權限影響力</a> 與 <a href="topics/team-design/">組織結構與團隊設計</a>，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。</p>
<h2 id="依主題選書">依主題選書</h2>
<p>十一個主題與各自的首選書在 <a href="topics/">主題書單目錄</a>。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。</p>
<h2 id="經典套書怎麼買">經典套書怎麼買</h2>
<p>各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。</p>
<p>Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 <a href="topics/problem-definition/">問題定義與系統思考</a>，第 2 卷第一級評量在 <a href="topics/continuous-delivery/">持續交付與交付效能</a>，第 3 卷關照全局的管理作為在 <a href="topics/influence-conversation/">困難對話與無權限影響力</a>，第 4 卷擁抱變革在 <a href="topics/team-design/">組織結構與團隊設計</a>。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在<a href="https://www.books.com.tw/products/0010553999">博客來</a>。</p>
<p>Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 <a href="topics/retention-motivation/">留任、動機與工作環境</a>，《Waltzing with Bears》（繁中《與熊共舞》）在 <a href="topics/estimation-decision/">估算、承諾與決策偏誤</a>。兩本沒有合購版本，分開買。</p>
<h2 id="相關的實作內容">相關的實作內容</h2>
<p>書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 <a href="/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學</a>，服務探活、容量規劃與高可用看 <a href="/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運</a>，事故分級、指揮角色與復盤制度看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>，客戶端遙測的四類事件與收集鏈路看 <a href="/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系</a>，交付生命週期全景看 <a href="/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景</a>。既有團隊的結構評估協議看 <a href="/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計</a>。</p>
<h2 id="backlog">Backlog</h2>
<table>
  <thead>
      <tr>
          <th>項目</th>
          <th>類型</th>
          <th>前置條件</th>
          <th>規模</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>十個主題各跑一次機制式搜尋</td>
          <td>案例</td>
          <td>機制詞候選事前寫死在主題書單的公開課段（研究設計與因果推論 / 承諾可信度 / 訊號傳遞 / 集體決策 / 因果回路與存量流量），產物是十組詞各查到什麼，可重跑</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>沒查到課的十個主題重掃一次</td>
          <td>案例</td>
          <td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音；是哪十個主題與各自為什麼空，見 <a href="topics/">主題書單</a> 的公開課段</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>系統思考這個主題改判</td>
          <td>主章</td>
          <td>MIT 15.871 補上影片，或找到另一門教因果回路與存量流量而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃</td>
          <td>1 段</td>
      </tr>
  </tbody>
</table>
]]></content:encoded></item><item><title>經營者的下一步：把人力資本納入續行與退場決策</title><link>https://tarrragon.github.io/blog/business/financial-analysis/case-studies/operator-human-capital-paths/</link><pubDate>Mon, 20 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/business/financial-analysis/case-studies/operator-human-capital-paths/</guid><description>&lt;p>這篇處理的對象，是一份財務結論已經指向退場、但經營者本人還要繼續謀生的事業。&lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/breakfast-store-comprehensive-case/" data-link-title="綜合案例：用完整分析框架重新評估一間連鎖早餐店" data-link-desc="拿到一份小型事業的報表時，從定位到估值的端到端評估流程實作——用系列全部分析工具串在一起處理同一個案例">早餐店綜合評估&lt;/a>走完七步框架，結論是這間店「結構性無法產生合理的資本報酬」，退場止血、殘餘資金轉被動投資。那套分析把經營者當成資本提供者——算完資本報酬、算完退場成本，人就從畫面裡消失了。&lt;/p>
&lt;p>但經營者不會在退場那天蒸發。他要回職場、換行業，或從店主改為受雇——無論哪條路，都帶著這幾年投入的技能、經驗與市場關係往下走。這篇補上綜合評估缺的維度：把「經營者作為一個持續謀生的主體」放回決策，問的不再是「這間店值不值得續行」，而是「這個人接下來怎麼走，人力資本增值最快、機會成本最低」。&lt;/p>
&lt;h2 id="財務公式為什麼不夠">財務公式為什麼不夠&lt;/h2>
&lt;p>續行 vs 退場的財務公式，把經營者的下一階段當成外生變數。綜合評估用的公式是「月損失 20,000 × 剩餘月數 vs 退場成本 50-100 萬」，這條式子計算的是資本該不該繼續留在這間店。它是對的，但它回答的是「錢該不該留」，不是「人該往哪走」。&lt;/p>
&lt;p>經營者這個主體有一項資產不進這條式子——&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/human-capital/" data-link-title="Human Capital（人力資本）" data-link-desc="評估小型事業續行或退場決策時，把經營者的技能與經驗當成會增值或折舊的資產納入判斷">人力資本&lt;/a>，也就是一個人靠技能、經驗與市場關係換取收入的能力。這項資產會隨時間增值或折舊：學到可遷移的新能力、累積可變現的資歷，人力資本增值；被鎖在一個難以累積新能力、技能只在單一業態管用的位置，人力資本折舊。財務公式看不到這一層，但對經營者來說，這往往是最貴的一項成本。&lt;/p>
&lt;p>一個在財務上打平、甚至小賺的決策，如果讓經營者的人力資本連續數年停滯，真實成本會是「一個人黃金年份的機會成本」，遠高於帳面數字。這正是綜合評估用「勞動報酬而非資本報酬」這個角度時沒有提到的問題——那份勞動報酬，還要扣掉它讓人力資本停滯的隱性代價。&lt;/p>
&lt;h2 id="續行的好處要多軸看">續行的好處要多軸看&lt;/h2>
&lt;p>續行的好處只用資本報酬一條軸去衡量，這間店的答案就只會是趨近於零。綜合評估已經顯示調整後利潤為負、DCF 趨近零，當作純投資去續行沒有理由。但「好處」攤開成多個軸來看，圖像會不一樣。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>好處的軸&lt;/th>
 &lt;th>這間店成不成立&lt;/th>
 &lt;th>判讀&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>資本報酬&lt;/td>
 &lt;td>不成立&lt;/td>
 &lt;td>調整後利潤為負、DCF≈0，純投資角度沒有續行理由&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>勞動報酬&lt;/td>
 &lt;td>有條件成立&lt;/td>
 &lt;td>自營月入 6.8-10.8 萬，但代價是每天凌晨四點開工、全年近乎無休&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>現金流的過渡&lt;/td>
 &lt;td>只在短期成立&lt;/td>
 &lt;td>撐到合約到期前，把店當成邊止血邊準備下一步的場地&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>選擇權價值&lt;/td>
 &lt;td>弱但存在&lt;/td>
 &lt;td>保留店面、營業權、租賃權，就保留了未來轉租、轉讓的選項&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>人力資本累積&lt;/td>
 &lt;td>多數情況為負&lt;/td>
 &lt;td>技能綁死在成熟觸頂的業態、每天勞動擠掉學習時間，能力隨時間折舊&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>前四軸綜合評估已經觸及，第五軸是這篇要補的。續行對人力資本多半是負貢獻：早餐店的營運時段集中在凌晨到中午、勞動強度高，這段時間本身就擠壓了學習與轉換的準備；而學到的技能（這個加盟品牌的出餐流程、這個商圈的客群）綁死在一個已經觸頂、被三面壓縮的業態上，遷移價值低。續行如果延續這個狀態，等於用勞動報酬換人力資本的持續折舊。&lt;/p>
&lt;p>續行真正站得住的情況，不是「這間店值得繼續開」，而是三個條件之一為真：合約快到期、退場成本高過短期累計虧損（綜合評估的「合約剩 1 年以內」那一格）；或經營者願意用那個勞動條件換月入 6.8-10.8 萬；或把這段時間明確定位成通往下一步的過渡。這三個都指向「一邊設計怎麼收、一邊把店用到最後」，不是「就這樣一直開下去」。&lt;/p>
&lt;h2 id="沉沒成本的價值化是殘值轉用">沉沒成本的價值化是殘值轉用&lt;/h2>
&lt;p>想讓投入的沉沒成本「更有價值」，這個念頭照字面走下去就是財務裡最有名的陷阱。綜合評估寫「&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/sunk-cost/" data-link-title="Sunk Cost" data-link-desc="做續行或退場決策時，辨識沉沒成本以避免讓已發生的支出影響未來判斷">沉沒成本&lt;/a>不影響這個計算」，正是為了擋掉這個動機扭曲退場判斷——已經付掉的加盟金與裝潢，是沉掉的成本，用「想把它撈回來」的心態去續行，只會每月再多虧一筆，沉掉的錢一塊都回不來。把沉沒成本放進決策的那一刻，虧損就開始擴大。&lt;/p>
&lt;p>但「讓投入更有價值」有一個健康的版本，關鍵是把問題換個問法：不是「把付掉的錢撈回來」，而是「投入的項目裡還有殘值的那部分，能不能搬到最願意出價的用途上」。投入的 200 萬（這間店的投資額）要拆成「純沉掉的」跟「還有殘值的」兩塊，後者可以最大化。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>投入的要素&lt;/th>
 &lt;th>殘值狀態&lt;/th>
 &lt;th>讓價值最大化的動作&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>設備&lt;/td>
 &lt;td>原價 2-4 折殘值&lt;/td>
 &lt;td>別當廢鐵報廢，賣去中古設備市場或同業，留時間找買家&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>裝潢、加盟金&lt;/td>
 &lt;td>幾乎為零（純沉沒）&lt;/td>
 &lt;td>放掉撈回來的念頭，執著這裡會扭曲判斷&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>租賃權&lt;/td>
 &lt;td>房租條件優於同業&lt;/td>
 &lt;td>轉租、轉讓可變成權利金，地點好的話租賃權本身就是能賣的資產&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>加盟權&lt;/td>
 &lt;td>看合約轉讓條款&lt;/td>
 &lt;td>走「連營業權一起賣給下個加盟者」這條路&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>常客、配方、流程&lt;/td>
 &lt;td>整店頂讓可整包變現&lt;/td>
 &lt;td>一間還在運轉的店，比拆開來收設備賣得高&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>經驗、能力&lt;/td>
 &lt;td>可轉用、不隨退場遞減&lt;/td>
 &lt;td>帶到下個事業或就業都用得上，這是帶著走、不是撈回來&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>前五項是有形與可交易的殘值，最後一項是這篇的重點：經營一間店累積的能力，是這些殘值裡不隨退場而清算的一項——設備會折價、租約會到期，能力跟著人走。設備當廢鐵處理還是整店頂讓，同樣是退場，回收金額差好幾十萬——這是經營者能控制的變數。而「把付掉的錢撈回來」不是變數，是已經固定的損失，把它從目標裡拿掉，判斷才不會被沉沒成本的動機扭曲。&lt;/p>
&lt;h2 id="把人力資本前景做成第三軸">把人力資本前景做成第三軸&lt;/h2>
&lt;p>續行 vs 退場的完整決策，要在原本的資本軸、勞動軸之外，加上人力資本前景這第三軸。財務公式問「錢該不該留」，勞動報酬問「這份工時值不值那個月薪」，第三軸問的是「三到五年後，這條路讓經營者的可變現能力增值還是折舊」。&lt;/p>
&lt;p>三軸並讀，決策可能翻轉。單看財務，這間店該退場；單看勞動報酬，自營月入 6.8-10.8 萬似乎不差；但加上人力資本前景，如果續行讓經營者的能力鎖在成熟觸頂的業態持續折舊，那份勞動報酬的真實價值要再打折。反過來，一條短期收入更低的路——例如退場後回職場——若讓人力資本重新增值，長期反而是正的。&lt;/p>
&lt;p>決策的算式因此從「月損失 × 剩餘月數 vs 退場成本」擴充成一個三項比較：每條路徑評估「這段時間累積的現金與資本，加上期末的人力資本狀態，減去這段時間的機會成本」。人力資本停滯要當成一項實質成本計入，即使它不出現在任何一張報表上——一個粗略的估法是「每月的薪資折價 × 折價持續的月數」，把看不見的折舊換算成可比較的數字。這一軸最容易被漏掉，因為它沒有帳面數字，而沉沒成本謬誤又會把注意力全部吸到「已經投入多少」上——正好是相反的方向。&lt;/p>
&lt;h2 id="四條路徑的判讀">四條路徑的判讀&lt;/h2>
&lt;p>退場或續行的下一步，主要有四條路徑。這四條不共用同一套判準——每條路徑的技能轉移方式、風險型態與適合條件都不同，硬套同一個模板會抹掉各自的關鍵差異。它們也不是互斥的窮舉：受雇可以是回同業、也可以是換到全新領域從基層做起，實際路徑常是這幾條的組合。以下逐條給判讀。&lt;/p>
&lt;h3 id="店主改為受雇">店主改為受雇&lt;/h3>
&lt;p>店主改為受雇，是把「當老闆」拆成「提供勞動」與「承擔資本風險」兩件事，只保留前者。具體有幾種形態：把現店轉讓或轉租出去、自己受雇當店長領薪；收掉店後去同業當受雇的管理者；或原專業已折舊、乾脆到全新領域從基層受雇做起。兩種都去掉了每月的資本虧損與經營風險，換取一份穩定但有上限的勞動報酬。&lt;/p>
&lt;p>判讀的核心是這行的受雇市場行情，跟自營勞動報酬的對比。自營的勞動報酬是月入 6.8-10.8 萬，但代價是每天凌晨四點開工、拆開後的資本報酬只有約 7%（綜合評估的拆分）；受雇店長的市場行情可能是月薪 4-5 萬，穩定、下班就下班、不承擔資本風險。兩者的差額，是「當老闆的溢價」加上「承擔資本風險的補償」。當自營那份勞動報酬扣掉過勞代價與風險折價後，已經逼近受雇薪資的穩定值，改為受雇就划算——用收入的上限，換掉資本風險。適合的條件是這行的技能有現成的受雇市場，讓經營累積的營運能力能直接變現成薪資。&lt;/p>
&lt;h3 id="回原職場">回原職場&lt;/h3>
&lt;p>回原職場適合開店前有一段專業資歷的經營者，決策的關鍵變數是技能折舊與資歷包裝。離開職場的時間越長，原專業的技能折舊越多，尤其是技術迭代快的領域；但獨立經營過一盤生意這件事，在管理職眼中有它的價值——損益負責、現金流管理、跨職能協調，這些是純受雇資歷不容易證明的能力。&lt;/p>
&lt;p>判讀要分兩塊看：原專業的硬技能還剩多少可用、以及開店經驗能不能包裝成向上的資歷而非空窗。風險集中在職涯空窗與中年轉回的門檻——空窗越長、原領域門檻越高，回去的摩擦越大。適合的條件是原專業技能未大幅折舊，或這段經營經歷能被目標職位理解成創業與管理歷練，而不是一段需要解釋的中斷。&lt;/p>
&lt;h3 id="換一個行業">換一個行業&lt;/h3>
&lt;p>換一個行業創業，成敗取決於哪些能力能跟著過去、哪些綁死在早餐店。可轉移的是「經營小生意的營運肌肉」——成本控管、外送平台運營、供應商議價、現金流管理、排班調度，這些在任何一門面對消費者的小生意都通用。綁死的是業態特定知識——這個加盟品牌的 know-how、這個商圈的客群習慣、這條供應鏈的關係，換了行業就歸零。&lt;/p>
&lt;p>盤點這兩堆的比例：如果經營者帶得走的多是通用營運能力，換行業的學習曲線會平緩許多；如果過去的優勢主要來自業態特定知識，那等於重新開始。這條路最大的風險不在財務，在心理——把上一間店的「不甘心」帶進下一個事業，是沉沒成本謬誤的再次發作，容易讓人為了「證明自己沒失敗」而選一個不該選的方向。適合的條件是找到一個能複用可轉移能力、同時避開早餐店結構困局（觸頂、被上下游與平台三面壓縮）的業態，讓過去的營運肌肉用在一個還有成長空間的地方。&lt;/p>
&lt;h3 id="自營續行當過渡">自營續行當過渡&lt;/h3>
&lt;p>自營續行在這裡指有明確期限的過渡，跟綜合評估講的「無限期經營」不同。它跟前三條路徑並存——用續行這段時間，累積下一步需要的現金、技能或資歷，把店當成通往轉換的跳板，而不是終點。&lt;/p>
&lt;p>判讀的關鍵是這段過渡有沒有出口設計。同樣是繼續開店，「撐到合約到期、期間存下轉換的本金並物色下一個方向」跟「先開著再說」是兩回事——前者有終點與用途，後者是拖延。風險正是過渡悄悄變成拖延：每月虧損持續累積，而「再撐一下」的念頭本身就是沉沒成本謬誤。適合的條件是合約剩餘期短、退場成本高於這段期間的短期虧損，且經營者在續行的同時明確地在準備下一步——過渡的正當性來自那個「下一步」是否在推進。&lt;/p>
&lt;h2 id="判讀訊號與重新評估點">判讀訊號與重新評估點&lt;/h2>
&lt;p>這四條路徑收斂到同一個判準：哪條路讓經營者的&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/opportunity-cost/" data-link-title="Opportunity Cost" data-link-desc="評估一項投資或決策時，用機會成本衡量放棄的最佳替代方案的報酬">機會成本&lt;/a>最低、人力資本增值最快。判準是哪條路在三到五年後，把經營者放在一個能力更值錢、選擇更多的位置——短期收入高低是次要的。&lt;/p>
&lt;p>無論選哪條，都要設一個重新評估的觸發點（tripwire），避免決策做完就進入自動駕駛：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>若續行為過渡&lt;/strong>：設定合約到期前的檢視點，並盯人力資本停滯訊號——連續數月學不到任何可遷移的新能力、且轉換的準備沒有推進，就是過渡退化成拖延的信號，該提前收。&lt;/li>
&lt;li>&lt;strong>若轉換身份（受雇、回職場、換行業）&lt;/strong>：設定回撤條件——新路徑在約定的月數內若未出現人力資本增值訊號（新技能、新資歷、更廣的選擇），重新評估是不是走錯方向，而不是靠意志力硬撐。&lt;/li>
&lt;/ul>
&lt;p>對這個案例最誠實的總結是：續行的好處也好、沉沒成本的價值化也好，都只能在「以退場或轉換為前提的設計」裡做到最大。把繼續開店本身當成目的，會同時削掉這兩種價值——每月的虧損擴大財務損失，停滯的人力資本擴大機會成本。真正的槓桿不在這間店的損益表上，在經營者這個人接下來被放到哪個位置。&lt;/p>
&lt;h2 id="相關文章">相關文章&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>主題&lt;/th>
 &lt;th>對應文章&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>這間店的端到端財務評估&lt;/td>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/breakfast-store-comprehensive-case/" data-link-title="綜合案例：用完整分析框架重新評估一間連鎖早餐店" data-link-desc="拿到一份小型事業的報表時，從定位到估值的端到端評估流程實作——用系列全部分析工具串在一起處理同一個案例">早餐店綜合評估&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>續行 vs 退場、資本 vs 勞動報酬&lt;/td>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/franchise-breakfast-pnl/" data-link-title="四層商業分析：損益表識讀、通路決策、投資評估與加盟結構" data-link-desc="拿到一份小型事業或加盟店損益表時，從報表數字、通路組合、投資報酬率、加盟體系結構等維度做系統性評估的判讀方法">損益表四層分析&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>沉沒成本為何不進決策&lt;/td>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/sunk-cost/" data-link-title="Sunk Cost" data-link-desc="做續行或退場決策時，辨識沉沒成本以避免讓已發生的支出影響未來判斷">沉沒成本&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>機會成本判讀&lt;/td>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/opportunity-cost/" data-link-title="Opportunity Cost" data-link-desc="評估一項投資或決策時，用機會成本衡量放棄的最佳替代方案的報酬">機會成本&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description><content:encoded><![CDATA[<p>這篇處理的對象，是一份財務結論已經指向退場、但經營者本人還要繼續謀生的事業。<a href="/blog/business/financial-analysis/breakfast-store-comprehensive-case/" data-link-title="綜合案例：用完整分析框架重新評估一間連鎖早餐店" data-link-desc="拿到一份小型事業的報表時，從定位到估值的端到端評估流程實作——用系列全部分析工具串在一起處理同一個案例">早餐店綜合評估</a>走完七步框架，結論是這間店「結構性無法產生合理的資本報酬」，退場止血、殘餘資金轉被動投資。那套分析把經營者當成資本提供者——算完資本報酬、算完退場成本，人就從畫面裡消失了。</p>
<p>但經營者不會在退場那天蒸發。他要回職場、換行業，或從店主改為受雇——無論哪條路，都帶著這幾年投入的技能、經驗與市場關係往下走。這篇補上綜合評估缺的維度：把「經營者作為一個持續謀生的主體」放回決策，問的不再是「這間店值不值得續行」，而是「這個人接下來怎麼走，人力資本增值最快、機會成本最低」。</p>
<h2 id="財務公式為什麼不夠">財務公式為什麼不夠</h2>
<p>續行 vs 退場的財務公式，把經營者的下一階段當成外生變數。綜合評估用的公式是「月損失 20,000 × 剩餘月數 vs 退場成本 50-100 萬」，這條式子計算的是資本該不該繼續留在這間店。它是對的，但它回答的是「錢該不該留」，不是「人該往哪走」。</p>
<p>經營者這個主體有一項資產不進這條式子——<a href="/blog/business/knowledge-cards/human-capital/" data-link-title="Human Capital（人力資本）" data-link-desc="評估小型事業續行或退場決策時，把經營者的技能與經驗當成會增值或折舊的資產納入判斷">人力資本</a>，也就是一個人靠技能、經驗與市場關係換取收入的能力。這項資產會隨時間增值或折舊：學到可遷移的新能力、累積可變現的資歷，人力資本增值；被鎖在一個難以累積新能力、技能只在單一業態管用的位置，人力資本折舊。財務公式看不到這一層，但對經營者來說，這往往是最貴的一項成本。</p>
<p>一個在財務上打平、甚至小賺的決策，如果讓經營者的人力資本連續數年停滯，真實成本會是「一個人黃金年份的機會成本」，遠高於帳面數字。這正是綜合評估用「勞動報酬而非資本報酬」這個角度時沒有提到的問題——那份勞動報酬，還要扣掉它讓人力資本停滯的隱性代價。</p>
<h2 id="續行的好處要多軸看">續行的好處要多軸看</h2>
<p>續行的好處只用資本報酬一條軸去衡量，這間店的答案就只會是趨近於零。綜合評估已經顯示調整後利潤為負、DCF 趨近零，當作純投資去續行沒有理由。但「好處」攤開成多個軸來看，圖像會不一樣。</p>
<table>
  <thead>
      <tr>
          <th>好處的軸</th>
          <th>這間店成不成立</th>
          <th>判讀</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>資本報酬</td>
          <td>不成立</td>
          <td>調整後利潤為負、DCF≈0，純投資角度沒有續行理由</td>
      </tr>
      <tr>
          <td>勞動報酬</td>
          <td>有條件成立</td>
          <td>自營月入 6.8-10.8 萬，但代價是每天凌晨四點開工、全年近乎無休</td>
      </tr>
      <tr>
          <td>現金流的過渡</td>
          <td>只在短期成立</td>
          <td>撐到合約到期前，把店當成邊止血邊準備下一步的場地</td>
      </tr>
      <tr>
          <td>選擇權價值</td>
          <td>弱但存在</td>
          <td>保留店面、營業權、租賃權，就保留了未來轉租、轉讓的選項</td>
      </tr>
      <tr>
          <td>人力資本累積</td>
          <td>多數情況為負</td>
          <td>技能綁死在成熟觸頂的業態、每天勞動擠掉學習時間，能力隨時間折舊</td>
      </tr>
  </tbody>
</table>
<p>前四軸綜合評估已經觸及，第五軸是這篇要補的。續行對人力資本多半是負貢獻：早餐店的營運時段集中在凌晨到中午、勞動強度高，這段時間本身就擠壓了學習與轉換的準備；而學到的技能（這個加盟品牌的出餐流程、這個商圈的客群）綁死在一個已經觸頂、被三面壓縮的業態上，遷移價值低。續行如果延續這個狀態，等於用勞動報酬換人力資本的持續折舊。</p>
<p>續行真正站得住的情況，不是「這間店值得繼續開」，而是三個條件之一為真：合約快到期、退場成本高過短期累計虧損（綜合評估的「合約剩 1 年以內」那一格）；或經營者願意用那個勞動條件換月入 6.8-10.8 萬；或把這段時間明確定位成通往下一步的過渡。這三個都指向「一邊設計怎麼收、一邊把店用到最後」，不是「就這樣一直開下去」。</p>
<h2 id="沉沒成本的價值化是殘值轉用">沉沒成本的價值化是殘值轉用</h2>
<p>想讓投入的沉沒成本「更有價值」，這個念頭照字面走下去就是財務裡最有名的陷阱。綜合評估寫「<a href="/blog/business/knowledge-cards/sunk-cost/" data-link-title="Sunk Cost" data-link-desc="做續行或退場決策時，辨識沉沒成本以避免讓已發生的支出影響未來判斷">沉沒成本</a>不影響這個計算」，正是為了擋掉這個動機扭曲退場判斷——已經付掉的加盟金與裝潢，是沉掉的成本，用「想把它撈回來」的心態去續行，只會每月再多虧一筆，沉掉的錢一塊都回不來。把沉沒成本放進決策的那一刻，虧損就開始擴大。</p>
<p>但「讓投入更有價值」有一個健康的版本，關鍵是把問題換個問法：不是「把付掉的錢撈回來」，而是「投入的項目裡還有殘值的那部分，能不能搬到最願意出價的用途上」。投入的 200 萬（這間店的投資額）要拆成「純沉掉的」跟「還有殘值的」兩塊，後者可以最大化。</p>
<table>
  <thead>
      <tr>
          <th>投入的要素</th>
          <th>殘值狀態</th>
          <th>讓價值最大化的動作</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>設備</td>
          <td>原價 2-4 折殘值</td>
          <td>別當廢鐵報廢，賣去中古設備市場或同業，留時間找買家</td>
      </tr>
      <tr>
          <td>裝潢、加盟金</td>
          <td>幾乎為零（純沉沒）</td>
          <td>放掉撈回來的念頭，執著這裡會扭曲判斷</td>
      </tr>
      <tr>
          <td>租賃權</td>
          <td>房租條件優於同業</td>
          <td>轉租、轉讓可變成權利金，地點好的話租賃權本身就是能賣的資產</td>
      </tr>
      <tr>
          <td>加盟權</td>
          <td>看合約轉讓條款</td>
          <td>走「連營業權一起賣給下個加盟者」這條路</td>
      </tr>
      <tr>
          <td>常客、配方、流程</td>
          <td>整店頂讓可整包變現</td>
          <td>一間還在運轉的店，比拆開來收設備賣得高</td>
      </tr>
      <tr>
          <td>經驗、能力</td>
          <td>可轉用、不隨退場遞減</td>
          <td>帶到下個事業或就業都用得上，這是帶著走、不是撈回來</td>
      </tr>
  </tbody>
</table>
<p>前五項是有形與可交易的殘值，最後一項是這篇的重點：經營一間店累積的能力，是這些殘值裡不隨退場而清算的一項——設備會折價、租約會到期，能力跟著人走。設備當廢鐵處理還是整店頂讓，同樣是退場，回收金額差好幾十萬——這是經營者能控制的變數。而「把付掉的錢撈回來」不是變數，是已經固定的損失，把它從目標裡拿掉，判斷才不會被沉沒成本的動機扭曲。</p>
<h2 id="把人力資本前景做成第三軸">把人力資本前景做成第三軸</h2>
<p>續行 vs 退場的完整決策，要在原本的資本軸、勞動軸之外，加上人力資本前景這第三軸。財務公式問「錢該不該留」，勞動報酬問「這份工時值不值那個月薪」，第三軸問的是「三到五年後，這條路讓經營者的可變現能力增值還是折舊」。</p>
<p>三軸並讀，決策可能翻轉。單看財務，這間店該退場；單看勞動報酬，自營月入 6.8-10.8 萬似乎不差；但加上人力資本前景，如果續行讓經營者的能力鎖在成熟觸頂的業態持續折舊，那份勞動報酬的真實價值要再打折。反過來，一條短期收入更低的路——例如退場後回職場——若讓人力資本重新增值，長期反而是正的。</p>
<p>決策的算式因此從「月損失 × 剩餘月數 vs 退場成本」擴充成一個三項比較：每條路徑評估「這段時間累積的現金與資本，加上期末的人力資本狀態，減去這段時間的機會成本」。人力資本停滯要當成一項實質成本計入，即使它不出現在任何一張報表上——一個粗略的估法是「每月的薪資折價 × 折價持續的月數」，把看不見的折舊換算成可比較的數字。這一軸最容易被漏掉，因為它沒有帳面數字，而沉沒成本謬誤又會把注意力全部吸到「已經投入多少」上——正好是相反的方向。</p>
<h2 id="四條路徑的判讀">四條路徑的判讀</h2>
<p>退場或續行的下一步，主要有四條路徑。這四條不共用同一套判準——每條路徑的技能轉移方式、風險型態與適合條件都不同，硬套同一個模板會抹掉各自的關鍵差異。它們也不是互斥的窮舉：受雇可以是回同業、也可以是換到全新領域從基層做起，實際路徑常是這幾條的組合。以下逐條給判讀。</p>
<h3 id="店主改為受雇">店主改為受雇</h3>
<p>店主改為受雇，是把「當老闆」拆成「提供勞動」與「承擔資本風險」兩件事，只保留前者。具體有幾種形態：把現店轉讓或轉租出去、自己受雇當店長領薪；收掉店後去同業當受雇的管理者；或原專業已折舊、乾脆到全新領域從基層受雇做起。兩種都去掉了每月的資本虧損與經營風險，換取一份穩定但有上限的勞動報酬。</p>
<p>判讀的核心是這行的受雇市場行情，跟自營勞動報酬的對比。自營的勞動報酬是月入 6.8-10.8 萬，但代價是每天凌晨四點開工、拆開後的資本報酬只有約 7%（綜合評估的拆分）；受雇店長的市場行情可能是月薪 4-5 萬，穩定、下班就下班、不承擔資本風險。兩者的差額，是「當老闆的溢價」加上「承擔資本風險的補償」。當自營那份勞動報酬扣掉過勞代價與風險折價後，已經逼近受雇薪資的穩定值，改為受雇就划算——用收入的上限，換掉資本風險。適合的條件是這行的技能有現成的受雇市場，讓經營累積的營運能力能直接變現成薪資。</p>
<h3 id="回原職場">回原職場</h3>
<p>回原職場適合開店前有一段專業資歷的經營者，決策的關鍵變數是技能折舊與資歷包裝。離開職場的時間越長，原專業的技能折舊越多，尤其是技術迭代快的領域；但獨立經營過一盤生意這件事，在管理職眼中有它的價值——損益負責、現金流管理、跨職能協調，這些是純受雇資歷不容易證明的能力。</p>
<p>判讀要分兩塊看：原專業的硬技能還剩多少可用、以及開店經驗能不能包裝成向上的資歷而非空窗。風險集中在職涯空窗與中年轉回的門檻——空窗越長、原領域門檻越高，回去的摩擦越大。適合的條件是原專業技能未大幅折舊，或這段經營經歷能被目標職位理解成創業與管理歷練，而不是一段需要解釋的中斷。</p>
<h3 id="換一個行業">換一個行業</h3>
<p>換一個行業創業，成敗取決於哪些能力能跟著過去、哪些綁死在早餐店。可轉移的是「經營小生意的營運肌肉」——成本控管、外送平台運營、供應商議價、現金流管理、排班調度，這些在任何一門面對消費者的小生意都通用。綁死的是業態特定知識——這個加盟品牌的 know-how、這個商圈的客群習慣、這條供應鏈的關係，換了行業就歸零。</p>
<p>盤點這兩堆的比例：如果經營者帶得走的多是通用營運能力，換行業的學習曲線會平緩許多；如果過去的優勢主要來自業態特定知識，那等於重新開始。這條路最大的風險不在財務，在心理——把上一間店的「不甘心」帶進下一個事業，是沉沒成本謬誤的再次發作，容易讓人為了「證明自己沒失敗」而選一個不該選的方向。適合的條件是找到一個能複用可轉移能力、同時避開早餐店結構困局（觸頂、被上下游與平台三面壓縮）的業態，讓過去的營運肌肉用在一個還有成長空間的地方。</p>
<h3 id="自營續行當過渡">自營續行當過渡</h3>
<p>自營續行在這裡指有明確期限的過渡，跟綜合評估講的「無限期經營」不同。它跟前三條路徑並存——用續行這段時間，累積下一步需要的現金、技能或資歷，把店當成通往轉換的跳板，而不是終點。</p>
<p>判讀的關鍵是這段過渡有沒有出口設計。同樣是繼續開店，「撐到合約到期、期間存下轉換的本金並物色下一個方向」跟「先開著再說」是兩回事——前者有終點與用途，後者是拖延。風險正是過渡悄悄變成拖延：每月虧損持續累積，而「再撐一下」的念頭本身就是沉沒成本謬誤。適合的條件是合約剩餘期短、退場成本高於這段期間的短期虧損，且經營者在續行的同時明確地在準備下一步——過渡的正當性來自那個「下一步」是否在推進。</p>
<h2 id="判讀訊號與重新評估點">判讀訊號與重新評估點</h2>
<p>這四條路徑收斂到同一個判準：哪條路讓經營者的<a href="/blog/business/knowledge-cards/opportunity-cost/" data-link-title="Opportunity Cost" data-link-desc="評估一項投資或決策時，用機會成本衡量放棄的最佳替代方案的報酬">機會成本</a>最低、人力資本增值最快。判準是哪條路在三到五年後，把經營者放在一個能力更值錢、選擇更多的位置——短期收入高低是次要的。</p>
<p>無論選哪條，都要設一個重新評估的觸發點（tripwire），避免決策做完就進入自動駕駛：</p>
<ul>
<li><strong>若續行為過渡</strong>：設定合約到期前的檢視點，並盯人力資本停滯訊號——連續數月學不到任何可遷移的新能力、且轉換的準備沒有推進，就是過渡退化成拖延的信號，該提前收。</li>
<li><strong>若轉換身份（受雇、回職場、換行業）</strong>：設定回撤條件——新路徑在約定的月數內若未出現人力資本增值訊號（新技能、新資歷、更廣的選擇），重新評估是不是走錯方向，而不是靠意志力硬撐。</li>
</ul>
<p>對這個案例最誠實的總結是：續行的好處也好、沉沒成本的價值化也好，都只能在「以退場或轉換為前提的設計」裡做到最大。把繼續開店本身當成目的，會同時削掉這兩種價值——每月的虧損擴大財務損失，停滯的人力資本擴大機會成本。真正的槓桿不在這間店的損益表上，在經營者這個人接下來被放到哪個位置。</p>
<h2 id="相關文章">相關文章</h2>
<table>
  <thead>
      <tr>
          <th>主題</th>
          <th>對應文章</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>這間店的端到端財務評估</td>
          <td><a href="/blog/business/financial-analysis/breakfast-store-comprehensive-case/" data-link-title="綜合案例：用完整分析框架重新評估一間連鎖早餐店" data-link-desc="拿到一份小型事業的報表時，從定位到估值的端到端評估流程實作——用系列全部分析工具串在一起處理同一個案例">早餐店綜合評估</a></td>
      </tr>
      <tr>
          <td>續行 vs 退場、資本 vs 勞動報酬</td>
          <td><a href="/blog/business/financial-analysis/franchise-breakfast-pnl/" data-link-title="四層商業分析：損益表識讀、通路決策、投資評估與加盟結構" data-link-desc="拿到一份小型事業或加盟店損益表時，從報表數字、通路組合、投資報酬率、加盟體系結構等維度做系統性評估的判讀方法">損益表四層分析</a></td>
      </tr>
      <tr>
          <td>沉沒成本為何不進決策</td>
          <td><a href="/blog/business/knowledge-cards/sunk-cost/" data-link-title="Sunk Cost" data-link-desc="做續行或退場決策時，辨識沉沒成本以避免讓已發生的支出影響未來判斷">沉沒成本</a></td>
      </tr>
      <tr>
          <td>機會成本判讀</td>
          <td><a href="/blog/business/knowledge-cards/opportunity-cost/" data-link-title="Opportunity Cost" data-link-desc="評估一項投資或決策時，用機會成本衡量放棄的最佳替代方案的報酬">機會成本</a></td>
      </tr>
  </tbody>
</table>
]]></content:encoded></item><item><title>對技術品質負責、不帶人</title><link>https://tarrragon.github.io/blog/books/software-management/roles/technical-quality/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/technical-quality/</guid><description>&lt;p>這個位置的特徵是責任範圍超出自己動手的範圍，但權力沒有跟著擴大。技術決策錯了要被問，可是執行那些決策的人不歸這個位置管、排優先序時不必看它的意思、也沒有義務接受它的判斷。Staff 工程師、架構師、平台團隊的技術負責人、SRE 的技術主導都在這個位置。&lt;/p>
&lt;p>方案是對的但推不動，是這個位置的典型失敗；而它的形式通常是&lt;strong>被同意然後沒有發生&lt;/strong>，不是被否決。會議上大家點頭，回去照舊，因為那個方案沒有進到任何人的優先序裡。另一個高頻失敗是把標準寫成文件，就當作標準已經存在。文件不會約束任何人。約束來自 CI 擋不擋、review 過不過、以及不照做的時候會不會有人說話。&lt;/p>
&lt;h2 id="對技術品質負責時成文制度與否的差別">對技術品質負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，這個位置通常有明確的頭銜（Staff、Principal），問題是&lt;strong>影響範圍與可見度的落差&lt;/strong>。做的事情橫跨多個團隊，每個團隊的主管卻只看得到自己那一段。切碎的形狀大致是這樣：花三個月讓四個團隊改用同一套部署流程，年度考評時主管收到的是四段各自兩三句的側面回饋，每一段聽起來都像「有幫忙」，沒有一段看得出那三個月。應對方式偏向留下跨團隊可見的產出（決策紀錄、遷移計畫、被引用的規範），而不是靠主管轉述。&lt;/p>
&lt;p>扁平的小公司通常沒有這個頭銜，這裡的人是「大家都會來問的那個人」。問題出在&lt;strong>邊界&lt;/strong>而非可見度：沒有頭銜也就沒有拒絕的依據，於是所有技術問題都流過來，把設定方向的時間吃成救火。這裡的關鍵能力是判斷什麼該接、什麼該退回。沒有職權時的「說不」通常是把成本攤開讓對方自己排序，而不是直接拒絕——「這件事我可以接，但它會讓遷移那條線延兩週，你要哪一個」比「我沒空」有用，因為前者把決定交回給有權決定的人，後者只是把問題推回去。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Staff Engineer&amp;rsquo;s Path&lt;/a>&lt;/strong> 是這個位置的主要書。它把這個角色拆成三根支柱，其中一根正是上面說的「沒有職權的人如何設定標準」——那一塊在其他書裡少有處理，也是這個位置最難自己摸索出來的。三根支柱各是什麼在主題篇。想看這個位置在不同公司長什麼樣的人，Will Larson 的《Staff Engineer》收了多位 staff 工程師的訪談，兩本都在 &lt;a href="../../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/influence-conversation/">The Secrets of Consulting&lt;/a>&lt;/strong> 直接處理無職權推動改變。多數管理書預設讀者有直接權限，這本的處境設定是「被找來給建議、但決定權在別人手上」，跟這裡的處境幾乎一致——差別在它的作者退得掉，而站在這個位置的人退不掉，讀的時候要把那一段折算。書中處理的主題與證據判定在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">Team Topologies&lt;/a>&lt;/strong> 在這個位置的用法是拿它當語言而不是拿它當方案。四種團隊型態與三種互動模式提供的是把「這兩個團隊該怎麼合作」講清楚的詞彙——站這個位置的人經常看得出問題出在交接面，卻只能說「他們配合度不好」——那句話推不動任何事。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/meeting-facilitation/">Facilitator&amp;rsquo;s Guide to Participatory Decision-Making&lt;/a>&lt;/strong> 對應的是上面那個「被同意然後沒有發生」。那個結果經常來自一場沒有真正收斂過的會議：意見攤開之後氣氛變難受，主持的人提早收攏，於是點頭的每個人各自帶著不同的理解離開。書中的鑽石模型把那段難受標成必經階段，用途是讓人在會議進行中就說得出「我們還沒收斂」，而不是散會兩週後才從執行狀況推回來。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/influence-conversation/">Difficult Conversations&lt;/a>&lt;/strong> 處理的是方案被反對時的那一場對話。三層對話的區分（事實、感受、身分認同）在技術爭論裡特別有用，因為技術爭論卡住的原因常常不在第一層——反對的人是在保護自己的判斷紀錄，而那件事在檯面上不會被說出來。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置的訊號通常是別人先開始把跨團隊的問題丟過來，職稱在那之後很久才追上。準備好的可觀察形式是這些事已經在做、而沒有人指派：主動去問隔壁團隊的計畫、在別人的設計討論裡被引用、寫的東西被當成別人的起點。這些累積夠了之後，要的是一個名分讓拒絕有依據，而不是一個新技能。&lt;/p>
&lt;p>&lt;strong>往更資深的技術路線&lt;/strong>：預習的是組織結構與系統架構這兩塊，而它們其實是同一件事的兩面——一個介面畫在哪裡，決定了哪兩個團隊要天天開會。組織那一面看 &lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a> 的認知負荷段，系統那一面看 &lt;a href="../../../craft/system-architecture/">系統架構&lt;/a>：架構特性互相衝突、必須明確放棄一些，而那個取捨正是這個位置要能講清楚的東西。&lt;/p>
&lt;p>&lt;strong>往管理路線&lt;/strong>（&lt;a href="../people/">對人負責&lt;/a>）：預習的是人的問題，而這條路徑有一個具體的落差要注意——這裡練出來的是「不靠職權說服別人」，而管理位置需要的是「有職權時怎麼不濫用它」。這兩件事不是同一個技能的深淺，&lt;a href="../../topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="../../topics/culture-safety/">組織文化與心理安全感&lt;/a> 是補這一塊的入口。&lt;/p>
&lt;p>&lt;strong>橫向移動回產品開發&lt;/strong>：這個方向不需要預習書單裡的東西，但值得先確認自己想離開的是這個位置還是這間公司的這個位置——兩者的解法不同。&lt;/p></description><content:encoded><![CDATA[<p>這個位置的特徵是責任範圍超出自己動手的範圍，但權力沒有跟著擴大。技術決策錯了要被問，可是執行那些決策的人不歸這個位置管、排優先序時不必看它的意思、也沒有義務接受它的判斷。Staff 工程師、架構師、平台團隊的技術負責人、SRE 的技術主導都在這個位置。</p>
<p>方案是對的但推不動，是這個位置的典型失敗；而它的形式通常是<strong>被同意然後沒有發生</strong>，不是被否決。會議上大家點頭，回去照舊，因為那個方案沒有進到任何人的優先序裡。另一個高頻失敗是把標準寫成文件，就當作標準已經存在。文件不會約束任何人。約束來自 CI 擋不擋、review 過不過、以及不照做的時候會不會有人說話。</p>
<h2 id="對技術品質負責時成文制度與否的差別">對技術品質負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，這個位置通常有明確的頭銜（Staff、Principal），問題是<strong>影響範圍與可見度的落差</strong>。做的事情橫跨多個團隊，每個團隊的主管卻只看得到自己那一段。切碎的形狀大致是這樣：花三個月讓四個團隊改用同一套部署流程，年度考評時主管收到的是四段各自兩三句的側面回饋，每一段聽起來都像「有幫忙」，沒有一段看得出那三個月。應對方式偏向留下跨團隊可見的產出（決策紀錄、遷移計畫、被引用的規範），而不是靠主管轉述。</p>
<p>扁平的小公司通常沒有這個頭銜，這裡的人是「大家都會來問的那個人」。問題出在<strong>邊界</strong>而非可見度：沒有頭銜也就沒有拒絕的依據，於是所有技術問題都流過來，把設定方向的時間吃成救火。這裡的關鍵能力是判斷什麼該接、什麼該退回。沒有職權時的「說不」通常是把成本攤開讓對方自己排序，而不是直接拒絕——「這件事我可以接，但它會讓遷移那條線延兩週，你要哪一個」比「我沒空」有用，因為前者把決定交回給有權決定的人，後者只是把問題推回去。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/role-transitions/">The Staff Engineer&rsquo;s Path</a></strong> 是這個位置的主要書。它把這個角色拆成三根支柱，其中一根正是上面說的「沒有職權的人如何設定標準」——那一塊在其他書裡少有處理，也是這個位置最難自己摸索出來的。三根支柱各是什麼在主題篇。想看這個位置在不同公司長什麼樣的人，Will Larson 的《Staff Engineer》收了多位 staff 工程師的訪談，兩本都在 <a href="../../topics/role-transitions/">角色轉換與職涯路徑</a>。</p>
<p><strong><a href="../../topics/influence-conversation/">The Secrets of Consulting</a></strong> 直接處理無職權推動改變。多數管理書預設讀者有直接權限，這本的處境設定是「被找來給建議、但決定權在別人手上」，跟這裡的處境幾乎一致——差別在它的作者退得掉，而站在這個位置的人退不掉，讀的時候要把那一段折算。書中處理的主題與證據判定在主題篇。</p>
<p><strong><a href="../../topics/team-design/">Team Topologies</a></strong> 在這個位置的用法是拿它當語言而不是拿它當方案。四種團隊型態與三種互動模式提供的是把「這兩個團隊該怎麼合作」講清楚的詞彙——站這個位置的人經常看得出問題出在交接面，卻只能說「他們配合度不好」——那句話推不動任何事。</p>
<p><strong><a href="../../topics/meeting-facilitation/">Facilitator&rsquo;s Guide to Participatory Decision-Making</a></strong> 對應的是上面那個「被同意然後沒有發生」。那個結果經常來自一場沒有真正收斂過的會議：意見攤開之後氣氛變難受，主持的人提早收攏，於是點頭的每個人各自帶著不同的理解離開。書中的鑽石模型把那段難受標成必經階段，用途是讓人在會議進行中就說得出「我們還沒收斂」，而不是散會兩週後才從執行狀況推回來。</p>
<p><strong><a href="../../topics/influence-conversation/">Difficult Conversations</a></strong> 處理的是方案被反對時的那一場對話。三層對話的區分（事實、感受、身分認同）在技術爭論裡特別有用，因為技術爭論卡住的原因常常不在第一層——反對的人是在保護自己的判斷紀錄，而那件事在檯面上不會被說出來。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置的訊號通常是別人先開始把跨團隊的問題丟過來，職稱在那之後很久才追上。準備好的可觀察形式是這些事已經在做、而沒有人指派：主動去問隔壁團隊的計畫、在別人的設計討論裡被引用、寫的東西被當成別人的起點。這些累積夠了之後，要的是一個名分讓拒絕有依據，而不是一個新技能。</p>
<p><strong>往更資深的技術路線</strong>：預習的是組織結構與系統架構這兩塊，而它們其實是同一件事的兩面——一個介面畫在哪裡，決定了哪兩個團隊要天天開會。組織那一面看 <a href="../../topics/team-design/">組織結構與團隊設計</a> 的認知負荷段，系統那一面看 <a href="../../../craft/system-architecture/">系統架構</a>：架構特性互相衝突、必須明確放棄一些，而那個取捨正是這個位置要能講清楚的東西。</p>
<p><strong>往管理路線</strong>（<a href="../people/">對人負責</a>）：預習的是人的問題，而這條路徑有一個具體的落差要注意——這裡練出來的是「不靠職權說服別人」，而管理位置需要的是「有職權時怎麼不濫用它」。這兩件事不是同一個技能的深淺，<a href="../../topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="../../topics/culture-safety/">組織文化與心理安全感</a> 是補這一塊的入口。</p>
<p><strong>橫向移動回產品開發</strong>：這個方向不需要預習書單裡的東西，但值得先確認自己想離開的是這個位置還是這間公司的這個位置——兩者的解法不同。</p>
]]></content:encoded></item><item><title>對別人的產出負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/others-output/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/others-output/</guid><description>&lt;p>這個位置的定義是：團隊交不出來的時候被問的是帶團隊的那個人；薪水、績效評等與誰留下這三件事通常都不在這個位置的權限內。Tech Lead、技術負責人、專案的技術窗口都在這裡。責任跟權力的落差在這裡特別尷尬：只對技術品質負責的人至少可以不接一個案子，這個位置連不接都不行，因為交付本來就是它的責任。&lt;/p>
&lt;p>自己重寫是這個位置最常見的失敗，形成過程不經過任何決定點。團隊成員交出來的東西不夠好時，自己改掉最快、當下也最省事，於是變成常態；三個月後團隊沒有變強，而帶團隊的人變成瓶頸。另一個同樣不必決定就會發生的是把交付壓力轉成加班要求，因為在能動的槓桿裡它最不需要對話。&lt;/p>
&lt;h2 id="對別人產出負責時成文制度與否的差別">對別人產出負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，Tech Lead 通常有對應的 EM 搭配，兩人分擔「事」與「人」。這裡的問題是&lt;strong>邊界模糊&lt;/strong>：績效面談時 EM 會問某個成員做得怎麼樣，於是 Tech Lead 實際上在影響考核，卻沒有處理後果的位置。這個處境要求把觀察講得具體到可以被複核。「他比較資淺」是印象評語，別人無從查證也無從反駁；「這三次 PR 他都漏了同一類邊界條件，第三次我指出來之後就沒再犯」是可複核的觀察，而且它同時說明了那個人在進步。兩句話花的時間差不多，能支持的結論差很多。&lt;/p>
&lt;p>扁平的小公司通常沒有這個分工，Tech Lead 同時是那個人的主管，這個位置與 &lt;a href="../people/">對人負責&lt;/a> 直接合併。這種情況下建議兩篇都讀——&lt;a href="../people/">對人負責&lt;/a> 那篇談分級、調薪與績效的段落預設組織已經有那些工具，沒有的話要讀的是它背後的判斷，不是照著把制度建起來。並且注意一個具體風險：交付壓力大時，人的問題會被無限期延後。它沒有截止日。所以它永遠排得進「下週再說」，而下週永遠有更急的事。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Manager&amp;rsquo;s Path&lt;/a>&lt;/strong> 的 tech lead 那一章是這個位置最直接的對應。它是這條線上少數把「還要寫程式、同時要對別人的產出負責」這個雙重身分當成主題來處理的書。建議只讀那一章加上下一章，整本讀完的部分會記不住；全書的性質判定在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/continuous-delivery/">Accelerate&lt;/a>&lt;/strong> 在這個位置的價值是把「團隊做得好不好」從印象變成數字。這裡的人經常要向上回報進度、向下要求改變，兩邊都需要依據。那四項是部署頻率、變更前置時間、變更失敗率、服務還原時間；它們的好處是難以造假、且指向流程而非個人——用它們談問題，對話不會滑向「誰比較慢」。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/influence-conversation/">Difficult Conversations&lt;/a>&lt;/strong> 處理的是這個位置每週都會遇到的那場對話：某個人交出來的東西不夠好，而這件事得由這個位置去講。三層對話的區分在這裡的用途是辨認自己卡在哪一層——多數這類對話難開口，是因為講的人在第三層（怕自己顯得刻薄或外行），而不是第一層講不清楚。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/meeting-facilitation/">六頂思考帽&lt;/a>&lt;/strong> 在這個位置的用處是設計討論。方案一提出就被挑洞、提案的人轉入防守，是團隊討論的一種典型結束方式，消耗掉的是資淺成員下一次提案的意願。把找風險與找好處排成不同時段、規定同一時段全場只做一件事，這個做法不需要職權就能導入，是這個位置少數自己說了算的槓桿。這套方法背後沒有獨立驗證，完整的證據判定在 &lt;a href="../../topics/meeting-facilitation/">會議引導與群體決策&lt;/a>。它在這裡的位置因此是團隊內部的實驗協議：自己試、自己看收到什麼訊號，而不是拿去當推動更大範圍改變的依據。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Peopleware&lt;/a>&lt;/strong> 在這個位置讀的是中斷成本與團隊凝聚那幾章。能實際動的槓桿有限，但保護團隊不被打斷是其中最有效也最在職權範圍內的一個。有兩種處境要先確認再投入：成員是約聘輪替或專案制編組時，凝聚那幾章的前提不成立；團隊跨時區而每天重疊不到兩小時（見[協作形態](/books/knowledge-cards/collaboration-mode/））時，中斷成本那幾章要自己換算成非同步的形式。兩者的完整說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的約束段。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置多半是被指派的，而指派的依據通常是「這個人交出來的東西最少讓人擔心」。準備好的訊號不是技術最強，是別人願意把有風險的部分交出來——那表示那個判斷已經被信任。剛被指派的人最該做的一件事是問清楚自己能決定什麼、不能決定什麼，因為責任與權力的落差正是這個位置的主要痛點，偏偏那個邊界通常沒有人主動說。&lt;/p>
&lt;p>&lt;strong>往管理路線&lt;/strong>（&lt;a href="../people/">對人負責&lt;/a>）：預習的是人的留任與動機，而不是更多的交付方法。這個位置處理的是「事」，&lt;a href="../people/">對人負責&lt;/a> 處理的是「人」，兩者的失敗模式不同——前者失敗是東西沒交出來，後者失敗是人走了而東西還在交。&lt;a href="../../topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="../../topics/culture-safety/">組織文化與心理安全感&lt;/a> 是入口。&lt;/p>
&lt;p>&lt;strong>往技術路線&lt;/strong>（&lt;a href="../technical-quality/">對技術品質負責&lt;/a>）：這條路是橫向而非退回。這裡練出來的協調能力到那邊仍然有用，要補的是技術決策的廣度與無職權影響力，看 &lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>&lt;strong>留在這個位置繼續深化&lt;/strong>：這是合理的選擇而非停滯。往深處走有兩個方向。一個是估算與承諾——這條路線對外承諾時程，而承諾失準有兩個不同來源需要分開處理，走 &lt;a href="../../topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>。另一個是技藝本身：這個位置要判斷別人交出來的東西夠不夠好，而那需要自己的判準夠硬，走 &lt;a href="../../../craft/">工程技藝書單&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個位置的定義是：團隊交不出來的時候被問的是帶團隊的那個人；薪水、績效評等與誰留下這三件事通常都不在這個位置的權限內。Tech Lead、技術負責人、專案的技術窗口都在這裡。責任跟權力的落差在這裡特別尷尬：只對技術品質負責的人至少可以不接一個案子，這個位置連不接都不行，因為交付本來就是它的責任。</p>
<p>自己重寫是這個位置最常見的失敗，形成過程不經過任何決定點。團隊成員交出來的東西不夠好時，自己改掉最快、當下也最省事，於是變成常態；三個月後團隊沒有變強，而帶團隊的人變成瓶頸。另一個同樣不必決定就會發生的是把交付壓力轉成加班要求，因為在能動的槓桿裡它最不需要對話。</p>
<h2 id="對別人產出負責時成文制度與否的差別">對別人產出負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，Tech Lead 通常有對應的 EM 搭配，兩人分擔「事」與「人」。這裡的問題是<strong>邊界模糊</strong>：績效面談時 EM 會問某個成員做得怎麼樣，於是 Tech Lead 實際上在影響考核，卻沒有處理後果的位置。這個處境要求把觀察講得具體到可以被複核。「他比較資淺」是印象評語，別人無從查證也無從反駁；「這三次 PR 他都漏了同一類邊界條件，第三次我指出來之後就沒再犯」是可複核的觀察，而且它同時說明了那個人在進步。兩句話花的時間差不多，能支持的結論差很多。</p>
<p>扁平的小公司通常沒有這個分工，Tech Lead 同時是那個人的主管，這個位置與 <a href="../people/">對人負責</a> 直接合併。這種情況下建議兩篇都讀——<a href="../people/">對人負責</a> 那篇談分級、調薪與績效的段落預設組織已經有那些工具，沒有的話要讀的是它背後的判斷，不是照著把制度建起來。並且注意一個具體風險：交付壓力大時，人的問題會被無限期延後。它沒有截止日。所以它永遠排得進「下週再說」，而下週永遠有更急的事。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/role-transitions/">The Manager&rsquo;s Path</a></strong> 的 tech lead 那一章是這個位置最直接的對應。它是這條線上少數把「還要寫程式、同時要對別人的產出負責」這個雙重身分當成主題來處理的書。建議只讀那一章加上下一章，整本讀完的部分會記不住；全書的性質判定在主題篇。</p>
<p><strong><a href="../../topics/continuous-delivery/">Accelerate</a></strong> 在這個位置的價值是把「團隊做得好不好」從印象變成數字。這裡的人經常要向上回報進度、向下要求改變，兩邊都需要依據。那四項是部署頻率、變更前置時間、變更失敗率、服務還原時間；它們的好處是難以造假、且指向流程而非個人——用它們談問題，對話不會滑向「誰比較慢」。</p>
<p><strong><a href="../../topics/influence-conversation/">Difficult Conversations</a></strong> 處理的是這個位置每週都會遇到的那場對話：某個人交出來的東西不夠好，而這件事得由這個位置去講。三層對話的區分在這裡的用途是辨認自己卡在哪一層——多數這類對話難開口，是因為講的人在第三層（怕自己顯得刻薄或外行），而不是第一層講不清楚。</p>
<p><strong><a href="../../topics/meeting-facilitation/">六頂思考帽</a></strong> 在這個位置的用處是設計討論。方案一提出就被挑洞、提案的人轉入防守，是團隊討論的一種典型結束方式，消耗掉的是資淺成員下一次提案的意願。把找風險與找好處排成不同時段、規定同一時段全場只做一件事，這個做法不需要職權就能導入，是這個位置少數自己說了算的槓桿。這套方法背後沒有獨立驗證，完整的證據判定在 <a href="../../topics/meeting-facilitation/">會議引導與群體決策</a>。它在這裡的位置因此是團隊內部的實驗協議：自己試、自己看收到什麼訊號，而不是拿去當推動更大範圍改變的依據。</p>
<p><strong><a href="../../topics/retention-motivation/">Peopleware</a></strong> 在這個位置讀的是中斷成本與團隊凝聚那幾章。能實際動的槓桿有限，但保護團隊不被打斷是其中最有效也最在職權範圍內的一個。有兩種處境要先確認再投入：成員是約聘輪替或專案制編組時，凝聚那幾章的前提不成立；團隊跨時區而每天重疊不到兩小時（見[協作形態](/books/knowledge-cards/collaboration-mode/））時，中斷成本那幾章要自己換算成非同步的形式。兩者的完整說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的約束段。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置多半是被指派的，而指派的依據通常是「這個人交出來的東西最少讓人擔心」。準備好的訊號不是技術最強，是別人願意把有風險的部分交出來——那表示那個判斷已經被信任。剛被指派的人最該做的一件事是問清楚自己能決定什麼、不能決定什麼，因為責任與權力的落差正是這個位置的主要痛點，偏偏那個邊界通常沒有人主動說。</p>
<p><strong>往管理路線</strong>（<a href="../people/">對人負責</a>）：預習的是人的留任與動機，而不是更多的交付方法。這個位置處理的是「事」，<a href="../people/">對人負責</a> 處理的是「人」，兩者的失敗模式不同——前者失敗是東西沒交出來，後者失敗是人走了而東西還在交。<a href="../../topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="../../topics/culture-safety/">組織文化與心理安全感</a> 是入口。</p>
<p><strong>往技術路線</strong>（<a href="../technical-quality/">對技術品質負責</a>）：這條路是橫向而非退回。這裡練出來的協調能力到那邊仍然有用，要補的是技術決策的廣度與無職權影響力，看 <a href="../../topics/team-design/">組織結構與團隊設計</a>。</p>
<p><strong>留在這個位置繼續深化</strong>：這是合理的選擇而非停滯。往深處走有兩個方向。一個是估算與承諾——這條路線對外承諾時程，而承諾失準有兩個不同來源需要分開處理，走 <a href="../../topics/estimation-decision/">估算、承諾與決策偏誤</a>。另一個是技藝本身：這個位置要判斷別人交出來的東西夠不夠好，而那需要自己的判準夠硬，走 <a href="../../../craft/">工程技藝書單</a>。</p>
]]></content:encoded></item><item><title>對人負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/people/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/people/</guid><description>&lt;p>交付出問題可以調度資源，人走了不能。這個不對稱決定了這一格的優先序，而它管的正是那件不可調度的事：人留不留得住、成不成長、講不講真話。多數新任管理者把時間花在交付上，因為交付有截止日而人沒有，等到人真的走了才發現那件事的處理時間早就過了。&lt;/p>
&lt;p>把管理做成更大範圍的自己動手，是這裡的主要失敗形式：接手最難的任務、審查每一個 PR、開會時給答案。這些動作短期看起來是負責，累積起來卻把團隊的成長機會收走，並且製造一個離不開的自己。&lt;/p>
&lt;h2 id="對人負責時成文制度與否的差別">對人負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，這個位置的多數工具已經存在——晉升制度、績效流程、薪資帶、調動管道。問題是&lt;strong>在制度裡替人爭取&lt;/strong>：同樣一位工程師，寫得出具體證據的主管能幫他升上去，寫不出來的不能；制度不會告訴主管證據要長什麼樣。它通常要的是三件事——做過什麼、影響到誰、沒有他會怎樣——而日常累積的觀察多半停在「做得不錯」，那三件事要平時就記，年度評等前一週補寫不出來。這裡的技能偏向把日常觀察轉成制度看得懂的語言，以及知道哪些戰場值得打。&lt;/p>
&lt;p>扁平的小公司沒有這些工具。沒有職級就沒有晉升，沒有薪資帶就每次調薪都是個案談判，沒有調動管道就「這個人不適合這個位置」只有離職一個出口。這裡的問題是&lt;strong>要自己造工具，同時還要用它&lt;/strong>——而自己造的制度沒有外部公信力：公布一套三級的工程師分級，隔週就有人問「這個級距是不是為了讓某某升上去才這樣切」——問的人不一定是在質疑動機，而是無從判斷這套標準是不是先射箭再畫靶，而定標準的一方也提不出制定過程以外的依據。應對方式是把外部標準引進來當錨（公開的職級框架、產業薪資調查），而不是自己定義一套。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Peopleware&lt;/a>&lt;/strong>（DeMarco &amp;amp; Lister）是這個位置的主要書。在這個位置讀它的理由是槓桿：環境是這一格能動的東西裡最少人動、而效果最直接的一個，也是少數不必先取得別人同意的。它涵蓋哪些主題、證據有多硬，在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Making of a Manager&lt;/a>&lt;/strong>（Julie Zhuo）聚焦第一年，剛進這條路線的人讀它的可執行性高於讀鋪完整條階梯的書——它給的是這個位置頭幾個月會實際遇到的場合該說什麼。涵蓋哪些場合在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">First, Break All the Rules&lt;/a>&lt;/strong> 在這個位置的用處有兩層：一是知道自己這一格的份量有多重，二是要在制度裡替人爭取時，它的調查規模足以支持拿去當依據——那是這條路線上少數可以引用數字的場合。核心發現與證據規模在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/culture-safety/">The Fearless Organization&lt;/a>&lt;/strong>（Amy Edmondson）處理的是這裡最難自我診斷的問題（概念本身見 &lt;a href="https://tarrragon.github.io/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感&lt;/a>）——團隊不講壞消息時，所有回報看起來都正常。它給的介入手段都落在這一格能做的範圍內，不需要制度配合。書中失敗案例裡「領導者宣稱歡迎壞消息、實際反應卻相反」那一段值得特別對照，那是這個位置最常見的自我誤判。框架本身與證據在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Radical Candor&lt;/a>&lt;/strong>（Kim Scott）處理回饋這一個動作。新任管理者最常卡在「只關心不挑戰」那一格，卡住的代價要幾個月後才結算。這本的用途是讓那個狀態在當下被自己認出來，而不是事後回想。四個象限的定義在主題篇。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置幾乎都是被指派的，而多數人接下來之後才發現它跟原本想像的不同——原本以為是「範圍更大的技術工作」，實際上一天裡技術佔的比例會掉到很低。轉換前值得先確認的是自己對「幫別人做成事」有沒有實際的興趣，而不只是對「不想被別人管」有興趣；後者會在半年內把人推回技術路線，而那個來回對團隊的代價比一開始就不接更高。&lt;/p>
&lt;p>&lt;strong>往管理更大的範圍&lt;/strong>（&lt;a href="../org-structure/">對組織結構負責&lt;/a>）：預習的是結構與承諾。這個位置的判斷單位是人，&lt;a href="../org-structure/">對組織結構負責&lt;/a> 的判斷單位是團隊之間的介面；那裡會遇到一個這裡完全碰不到的問題——組織的承諾為什麼系統性失準。&lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a> 與 &lt;a href="../../topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a> 是入口。&lt;/p>
&lt;p>&lt;strong>留在這個位置&lt;/strong>也是完整的路線，而且是這五格裡最容易被誤讀成停滯的一格——把一組人帶到他們自己會處理問題，本身就是產出。往深處走要補的是結構與制度的視角：同樣的管理動作在不同的團隊規模與組成下效果差很多，&lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a> 的認知負荷段是這個方向的入口。&lt;/p>
&lt;p>&lt;strong>轉回技術路線&lt;/strong>（&lt;a href="../technical-quality/">對技術品質負責&lt;/a>）：這條路走得通，而且這條路線練出來的判斷不會浪費——處理過人的問題之後再回去做技術決策，對「這個方案要靠誰執行、他們願不願意」的判斷會比沒帶過人的時候準。要補的是技術廣度與無職權影響力，看 &lt;a href="../../topics/influence-conversation/">困難對話與無權限影響力&lt;/a>。轉回去之前值得確認自己想離開的是管理工作本身，還是這個組織裡的管理工作。&lt;/p></description><content:encoded><![CDATA[<p>交付出問題可以調度資源，人走了不能。這個不對稱決定了這一格的優先序，而它管的正是那件不可調度的事：人留不留得住、成不成長、講不講真話。多數新任管理者把時間花在交付上，因為交付有截止日而人沒有，等到人真的走了才發現那件事的處理時間早就過了。</p>
<p>把管理做成更大範圍的自己動手，是這裡的主要失敗形式：接手最難的任務、審查每一個 PR、開會時給答案。這些動作短期看起來是負責，累積起來卻把團隊的成長機會收走，並且製造一個離不開的自己。</p>
<h2 id="對人負責時成文制度與否的差別">對人負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，這個位置的多數工具已經存在——晉升制度、績效流程、薪資帶、調動管道。問題是<strong>在制度裡替人爭取</strong>：同樣一位工程師，寫得出具體證據的主管能幫他升上去，寫不出來的不能；制度不會告訴主管證據要長什麼樣。它通常要的是三件事——做過什麼、影響到誰、沒有他會怎樣——而日常累積的觀察多半停在「做得不錯」，那三件事要平時就記，年度評等前一週補寫不出來。這裡的技能偏向把日常觀察轉成制度看得懂的語言，以及知道哪些戰場值得打。</p>
<p>扁平的小公司沒有這些工具。沒有職級就沒有晉升，沒有薪資帶就每次調薪都是個案談判，沒有調動管道就「這個人不適合這個位置」只有離職一個出口。這裡的問題是<strong>要自己造工具，同時還要用它</strong>——而自己造的制度沒有外部公信力：公布一套三級的工程師分級，隔週就有人問「這個級距是不是為了讓某某升上去才這樣切」——問的人不一定是在質疑動機，而是無從判斷這套標準是不是先射箭再畫靶，而定標準的一方也提不出制定過程以外的依據。應對方式是把外部標準引進來當錨（公開的職級框架、產業薪資調查），而不是自己定義一套。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/retention-motivation/">Peopleware</a></strong>（DeMarco &amp; Lister）是這個位置的主要書。在這個位置讀它的理由是槓桿：環境是這一格能動的東西裡最少人動、而效果最直接的一個，也是少數不必先取得別人同意的。它涵蓋哪些主題、證據有多硬，在主題篇。</p>
<p><strong><a href="../../topics/role-transitions/">The Making of a Manager</a></strong>（Julie Zhuo）聚焦第一年，剛進這條路線的人讀它的可執行性高於讀鋪完整條階梯的書——它給的是這個位置頭幾個月會實際遇到的場合該說什麼。涵蓋哪些場合在主題篇。</p>
<p><strong><a href="../../topics/retention-motivation/">First, Break All the Rules</a></strong> 在這個位置的用處有兩層：一是知道自己這一格的份量有多重，二是要在制度裡替人爭取時，它的調查規模足以支持拿去當依據——那是這條路線上少數可以引用數字的場合。核心發現與證據規模在主題篇。</p>
<p><strong><a href="../../topics/culture-safety/">The Fearless Organization</a></strong>（Amy Edmondson）處理的是這裡最難自我診斷的問題（概念本身見 <a href="/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感</a>）——團隊不講壞消息時，所有回報看起來都正常。它給的介入手段都落在這一格能做的範圍內，不需要制度配合。書中失敗案例裡「領導者宣稱歡迎壞消息、實際反應卻相反」那一段值得特別對照，那是這個位置最常見的自我誤判。框架本身與證據在主題篇。</p>
<p><strong><a href="../../topics/retention-motivation/">Radical Candor</a></strong>（Kim Scott）處理回饋這一個動作。新任管理者最常卡在「只關心不挑戰」那一格，卡住的代價要幾個月後才結算。這本的用途是讓那個狀態在當下被自己認出來，而不是事後回想。四個象限的定義在主題篇。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置幾乎都是被指派的，而多數人接下來之後才發現它跟原本想像的不同——原本以為是「範圍更大的技術工作」，實際上一天裡技術佔的比例會掉到很低。轉換前值得先確認的是自己對「幫別人做成事」有沒有實際的興趣，而不只是對「不想被別人管」有興趣；後者會在半年內把人推回技術路線，而那個來回對團隊的代價比一開始就不接更高。</p>
<p><strong>往管理更大的範圍</strong>（<a href="../org-structure/">對組織結構負責</a>）：預習的是結構與承諾。這個位置的判斷單位是人，<a href="../org-structure/">對組織結構負責</a> 的判斷單位是團隊之間的介面；那裡會遇到一個這裡完全碰不到的問題——組織的承諾為什麼系統性失準。<a href="../../topics/team-design/">組織結構與團隊設計</a> 與 <a href="../../topics/estimation-decision/">估算、承諾與決策偏誤</a> 是入口。</p>
<p><strong>留在這個位置</strong>也是完整的路線，而且是這五格裡最容易被誤讀成停滯的一格——把一組人帶到他們自己會處理問題，本身就是產出。往深處走要補的是結構與制度的視角：同樣的管理動作在不同的團隊規模與組成下效果差很多，<a href="../../topics/team-design/">組織結構與團隊設計</a> 的認知負荷段是這個方向的入口。</p>
<p><strong>轉回技術路線</strong>（<a href="../technical-quality/">對技術品質負責</a>）：這條路走得通，而且這條路線練出來的判斷不會浪費——處理過人的問題之後再回去做技術決策，對「這個方案要靠誰執行、他們願不願意」的判斷會比沒帶過人的時候準。要補的是技術廣度與無職權影響力，看 <a href="../../topics/influence-conversation/">困難對話與無權限影響力</a>。轉回去之前值得確認自己想離開的是管理工作本身，還是這個組織裡的管理工作。</p>
]]></content:encoded></item><item><title>對組織結構負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/org-structure/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/org-structure/</guid><description>&lt;p>管的是管人的人，不再是人本身。因此動作與結果之間隔著至少兩層，回饋延遲以季為單位——這一格的判斷幾乎都要在確認得到結果之前就下。要判斷的東西落在團隊與團隊之間：邊界畫在哪、交接面誰負責、哪些事情沒有人特別該負責但一定會出問題。&lt;/p>
&lt;p>改組織圖而沒有改任何人的實際約束，是這個位置代價最高的失敗。畫新的框、宣布新的分工，隔天每個人面對的優先序、被誰打斷、被誰評分都沒有變。三個月後一切照舊，信任被消耗掉一次。與它相鄰的是把每一個跨團隊問題都當成溝通問題處理——那個解釋的吸引力在於它不必動結構。&lt;/p>
&lt;h2 id="對組織結構負責時成文制度與否的差別">對組織結構負責時，成文制度與否的差別&lt;/h2>
&lt;p>制度成文的大組織裡，這個位置的動作要穿過既有制度，於是&lt;strong>變更成本高到讓錯誤結構被保留&lt;/strong>。具體長這樣：某個服務跨在兩個團隊的邊界上，每改一次都要兩邊各自排期，通常差兩到三週；提議把它併進其中一邊，就要動另一邊的 headcount，而 headcount 綁在年度預算裡、還要說服兩位主管跟他們共同的上級；於是這件事每季被提一次，每次都合理地被延後。這裡需要的是判斷哪些結構債值得付這個代價去修，哪些改用介面設計繞過——把跨團隊的協作改成一方提供穩定介面、另一方自助使用，不動組織圖也能減少排期依賴。&lt;/p>
&lt;p>制度還沒定型、但層級已經出現的公司（人數常落在五十到兩百之間，但決定性的是制度而非人數）問題相反：改組織幾乎沒有成本，於是改得太頻繁。每次重組都重置一次團隊的默契與領域知識；那個成本不會出現在任何報表上。這裡需要的是知道重組的代價在哪裡、以及什麼訊號才真的構成重組的理由。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">Team Topologies&lt;/a>&lt;/strong>（Skelton &amp;amp; Pais）是這個位置的主要書。它在這個位置的用途是把切分決定寫成別人可以反駁的形式——這條路線的決定會被上下兩層檢視，而「我覺得這樣切比較好」擋不住任何一次質疑。書的完整描述在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">An Elegant Puzzle&lt;/a>&lt;/strong>（Will Larson）處理的是這裡的日常：團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。它的團隊狀態模型在這個位置的用途是分配資源時的共同語言：這裡的判斷單位是團隊之間的介面，而爭資源的場合需要一個雙方都認的分類，否則討論會退回誰的嗓門大。模型本身的四種狀態與各自的介入方式在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/estimation-decision/">How Big Things Get Done&lt;/a>&lt;/strong>（Flyvbjerg &amp;amp; Gardner）處理的是這個位置躲不掉的承諾問題。它區分的兩個失準來源對這條路線特別重要，因為到這裡的所有估算都經過至少兩層轉述，每一層都有調整它的誘因——分不出手上這個數字失真在哪一層，加再多緩衝也押錯地方。兩個來源各是什麼、為什麼其中一個靠方法修不了，在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/culture-safety/">The Fearless Organization&lt;/a>&lt;/strong> 在這個位置讀出來的東西，跟直接帶人的人讀到的不同。這裡的問題是&lt;strong>壞消息在兩層轉述中會不會被磨平&lt;/strong>——每一層都做了合理的摘要，而合理的摘要累積起來就是失真；自己的團隊敢不敢講是 &lt;a href="../people/">對人負責&lt;/a> 那一篇的題目。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">Quality Software Management, Vol. 4&lt;/a>&lt;/strong>（Gerald Weinberg，繁中譯名《溫伯格的軟體管理學：擁抱變革》，四卷各自獨立、不必從第 1 卷讀起）處理推動組織轉變時的人的阻力，是這條路線上唯一一本把抗拒當資訊而不是當障礙的書。完整的性質判定與讀的時機在主題篇。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置的方式通常是組織長大，而不是換了工作內容——原本帶的一個團隊裂成兩個，人就在這裡了。準備好的訊號是兩個團隊之間的事已經在處理：協調誰做哪一段、決定介面長什麼樣、被找去仲裁優先序。沒有這些累積就直接接下多團隊，最常見的結果是把時間全部花在其中一個團隊上，因為那是唯一熟悉的工作。&lt;/p>
&lt;p>這個位置往上走，書能提供的比重快速下降。位置越高，同一個職稱在不同公司對應的實際工作差異越大，決定成敗的是這個組織的規模、產業與治理結構，而那些沒有通用解。&lt;/p>
&lt;p>比較有用的方向是往深處而非往上：&lt;strong>&lt;a href="../../topics/team-design/">Wiring the Winning Organization&lt;/a>&lt;/strong> 嘗試解釋為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單，適合手上已經有一批彼此不相干的做法、想找共同解釋的人。&lt;strong>&lt;a href="../../topics/team-design/">Software Engineering at Google&lt;/a>&lt;/strong> 提供的是規模與時間如何反轉工程判斷的具體案例，可以拿來校準自己組織的規模對應到哪些問題。&lt;/p>
&lt;p>要把結構決定落到實際的評估動作，&lt;a href="https://tarrragon.github.io/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計&lt;/a> 提供的是把這類框架用在既有團隊上的判讀步驟。&lt;/p></description><content:encoded><![CDATA[<p>管的是管人的人，不再是人本身。因此動作與結果之間隔著至少兩層，回饋延遲以季為單位——這一格的判斷幾乎都要在確認得到結果之前就下。要判斷的東西落在團隊與團隊之間：邊界畫在哪、交接面誰負責、哪些事情沒有人特別該負責但一定會出問題。</p>
<p>改組織圖而沒有改任何人的實際約束，是這個位置代價最高的失敗。畫新的框、宣布新的分工，隔天每個人面對的優先序、被誰打斷、被誰評分都沒有變。三個月後一切照舊，信任被消耗掉一次。與它相鄰的是把每一個跨團隊問題都當成溝通問題處理——那個解釋的吸引力在於它不必動結構。</p>
<h2 id="對組織結構負責時成文制度與否的差別">對組織結構負責時，成文制度與否的差別</h2>
<p>制度成文的大組織裡，這個位置的動作要穿過既有制度，於是<strong>變更成本高到讓錯誤結構被保留</strong>。具體長這樣：某個服務跨在兩個團隊的邊界上，每改一次都要兩邊各自排期，通常差兩到三週；提議把它併進其中一邊，就要動另一邊的 headcount，而 headcount 綁在年度預算裡、還要說服兩位主管跟他們共同的上級；於是這件事每季被提一次，每次都合理地被延後。這裡需要的是判斷哪些結構債值得付這個代價去修，哪些改用介面設計繞過——把跨團隊的協作改成一方提供穩定介面、另一方自助使用，不動組織圖也能減少排期依賴。</p>
<p>制度還沒定型、但層級已經出現的公司（人數常落在五十到兩百之間，但決定性的是制度而非人數）問題相反：改組織幾乎沒有成本，於是改得太頻繁。每次重組都重置一次團隊的默契與領域知識；那個成本不會出現在任何報表上。這裡需要的是知道重組的代價在哪裡、以及什麼訊號才真的構成重組的理由。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/team-design/">Team Topologies</a></strong>（Skelton &amp; Pais）是這個位置的主要書。它在這個位置的用途是把切分決定寫成別人可以反駁的形式——這條路線的決定會被上下兩層檢視，而「我覺得這樣切比較好」擋不住任何一次質疑。書的完整描述在主題篇。</p>
<p><strong><a href="../../topics/team-design/">An Elegant Puzzle</a></strong>（Will Larson）處理的是這裡的日常：團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。它的團隊狀態模型在這個位置的用途是分配資源時的共同語言：這裡的判斷單位是團隊之間的介面，而爭資源的場合需要一個雙方都認的分類，否則討論會退回誰的嗓門大。模型本身的四種狀態與各自的介入方式在主題篇。</p>
<p><strong><a href="../../topics/estimation-decision/">How Big Things Get Done</a></strong>（Flyvbjerg &amp; Gardner）處理的是這個位置躲不掉的承諾問題。它區分的兩個失準來源對這條路線特別重要，因為到這裡的所有估算都經過至少兩層轉述，每一層都有調整它的誘因——分不出手上這個數字失真在哪一層，加再多緩衝也押錯地方。兩個來源各是什麼、為什麼其中一個靠方法修不了，在主題篇。</p>
<p><strong><a href="../../topics/culture-safety/">The Fearless Organization</a></strong> 在這個位置讀出來的東西，跟直接帶人的人讀到的不同。這裡的問題是<strong>壞消息在兩層轉述中會不會被磨平</strong>——每一層都做了合理的摘要，而合理的摘要累積起來就是失真；自己的團隊敢不敢講是 <a href="../people/">對人負責</a> 那一篇的題目。</p>
<p><strong><a href="../../topics/team-design/">Quality Software Management, Vol. 4</a></strong>（Gerald Weinberg，繁中譯名《溫伯格的軟體管理學：擁抱變革》，四卷各自獨立、不必從第 1 卷讀起）處理推動組織轉變時的人的阻力，是這條路線上唯一一本把抗拒當資訊而不是當障礙的書。完整的性質判定與讀的時機在主題篇。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置的方式通常是組織長大，而不是換了工作內容——原本帶的一個團隊裂成兩個，人就在這裡了。準備好的訊號是兩個團隊之間的事已經在處理：協調誰做哪一段、決定介面長什麼樣、被找去仲裁優先序。沒有這些累積就直接接下多團隊，最常見的結果是把時間全部花在其中一個團隊上，因為那是唯一熟悉的工作。</p>
<p>這個位置往上走，書能提供的比重快速下降。位置越高，同一個職稱在不同公司對應的實際工作差異越大，決定成敗的是這個組織的規模、產業與治理結構，而那些沒有通用解。</p>
<p>比較有用的方向是往深處而非往上：<strong><a href="../../topics/team-design/">Wiring the Winning Organization</a></strong> 嘗試解釋為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單，適合手上已經有一批彼此不相干的做法、想找共同解釋的人。<strong><a href="../../topics/team-design/">Software Engineering at Google</a></strong> 提供的是規模與時間如何反轉工程判斷的具體案例，可以拿來校準自己組織的規模對應到哪些問題。</p>
<p>要把結構決定落到實際的評估動作，<a href="/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計</a> 提供的是把這類框架用在既有團隊上的判讀步驟。</p>
]]></content:encoded></item><item><title>採購職場筆記：資訊敏感度、掌握度與平常心</title><link>https://tarrragon.github.io/blog/business/procurement-planning/buyer-career-notes/</link><pubDate>Thu, 09 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/business/procurement-planning/buyer-career-notes/</guid><description>&lt;p>本篇的定位跟模組其他文章不同：其他篇是商業分析，拆的是成本、誘因與機制；這一篇是從業經驗的整理，記的是資深採購的工作習慣與心態。經驗談有它自己的價值——機制告訴你為什麼，習慣告訴你日子實際怎麼過——但兩種知識的性質不同，分開放，各自誠實。&lt;/p>
&lt;h2 id="資訊敏感度是日常習慣">資訊敏感度是日常習慣&lt;/h2>
&lt;p>採購的資訊工作滲在日常裡：三不五時看市場新聞，第一手掌握原料狀況與產業趨勢；地震或颱風過後，隔天上班第一件事是問供應商工廠的產能供貨有沒有受影響；市場一有原料緊縮的風聲，就開始評估要不要提前佈局。這些動作串起來，就是 &lt;a href="https://tarrragon.github.io/blog/business/procurement-planning/planning-as-risk-management/" data-link-title="斷料與呆料的成本結構：planning 為什麼是風險管理" data-link-desc="用停線與呆料兩側的成本結構推導採購 planning 的存在理由與餘裕配置，供判斷一顆料值不值得留餘裕、以及成本不對稱何時反轉時使用">成本結構篇&lt;/a> 說的「異常應對是常態工作」在日常層面的樣子——訊號進得早，佈局的選項才多。&lt;/p>
&lt;h2 id="料件掌握度的養成">料件掌握度的養成&lt;/h2>
&lt;p>資深採購對料件的掌握度可以深到跟研發工程師對話不落下風。養成的路徑很實體：去工廠看製程、跟著研發學電子零件的規格與特性、把自己負責的每顆料真正摸透——它由哪些上游零件構成、哪個環節容易缺、替代方案技術上換不換得動。&lt;/p>
&lt;p>這份掌握度的回報在 &lt;a href="https://tarrragon.github.io/blog/business/procurement-planning/impossible-triangle-rationing/" data-link-title="不可能三角與短缺市場的配給" data-link-desc="用供應側成本結構解釋交期價格品質的取捨為什麼存在、缺貨時供應商按什麼順序配貨、關係投資在配給中的作用，供決定讓哪一角與評估關係價值時使用">配給篇&lt;/a> 分析過：它壓縮你跟供應商之間的資訊不對稱，唬弄你的期望收益變低、跟你說真話的成本變低。從業者的版本更直白——懂料的採購，供應商知道唬弄不了，反而更願意給真實的資訊與實在的條件。信任建立在「這個人內行、說話算話、平時往來實在」之上，應酬堆不出這種信任。&lt;/p>
&lt;h2 id="平常心">平常心&lt;/h2>
&lt;p>這行的異常是常態——&lt;a href="https://tarrragon.github.io/blog/business/procurement-planning/planning-as-risk-management/" data-link-title="斷料與呆料的成本結構：planning 為什麼是風險管理" data-link-desc="用停線與呆料兩側的成本結構推導採購 planning 的存在理由與餘裕配置，供判斷一顆料值不值得留餘裕、以及成本不對稱何時反轉時使用">成本結構篇&lt;/a> 把它當成分析的輸入條件，落到心態上就是：會缺的料就是會缺，會出的狀況就是會出。工作的本分是讓狀況發生時有路可走，而狀況本身攔不住。資深從業者的心態建議是平常心——追料再急，也別讓自己吃不下睡不著、把身體拖垮；公司少了誰都照常運轉，把自己燒掉換不來供貨。平常心還有一個實用面：危機裡保持判斷清晰，而清晰的判斷正是把料追對節點的前提。&lt;/p>
&lt;p>面對外界的評價也一樣。旁人問起、給建議，多半只是剛好遇到問題順口一提，不必放在心上。把採購當成一份靠專業、信任與穩定心態長期累積的工作，比追求每一次都完美，更接近這行的真實樣貌。&lt;/p>
&lt;h2 id="下一步">下一步&lt;/h2>
&lt;p>這些習慣支撐的分析框架在模組其他篇：資訊敏感度餵養的是 &lt;a href="https://tarrragon.github.io/blog/business/procurement-planning/multi-source-supplier-strategy/" data-link-title="第二來源的經濟學：養供應商是買保險" data-link-desc="用保費對期望損失的框架判斷一顆料要不要養第二供應商，以及認證導入週期為什麼讓臨時尋源不成立，供規劃供應商佈局與評估單一來源風險時使用">供應商佈局&lt;/a> 的提前量，掌握度兌現在 &lt;a href="https://tarrragon.github.io/blog/business/procurement-planning/impossible-triangle-rationing/" data-link-title="不可能三角與短缺市場的配給" data-link-desc="用供應側成本結構解釋交期價格品質的取捨為什麼存在、缺貨時供應商按什麼順序配貨、關係投資在配給中的作用，供決定讓哪一角與評估關係價值時使用">配給順位&lt;/a> 與議價品質，平常心守住的是 &lt;a href="https://tarrragon.github.io/blog/business/procurement-planning/expediting-controllable-nodes/" data-link-title="追料是追可控環節" data-link-desc="追料的節點盤點、各介入選項的成本結構與划算判準、偵測提前量對選項數的影響，供料件快斷時決定在哪個環節出手、用什麼代價換時間時使用">追料&lt;/a> 時的判斷力。&lt;/p></description><content:encoded><![CDATA[<p>本篇的定位跟模組其他文章不同：其他篇是商業分析，拆的是成本、誘因與機制；這一篇是從業經驗的整理，記的是資深採購的工作習慣與心態。經驗談有它自己的價值——機制告訴你為什麼，習慣告訴你日子實際怎麼過——但兩種知識的性質不同，分開放，各自誠實。</p>
<h2 id="資訊敏感度是日常習慣">資訊敏感度是日常習慣</h2>
<p>採購的資訊工作滲在日常裡：三不五時看市場新聞，第一手掌握原料狀況與產業趨勢；地震或颱風過後，隔天上班第一件事是問供應商工廠的產能供貨有沒有受影響；市場一有原料緊縮的風聲，就開始評估要不要提前佈局。這些動作串起來，就是 <a href="/blog/business/procurement-planning/planning-as-risk-management/" data-link-title="斷料與呆料的成本結構：planning 為什麼是風險管理" data-link-desc="用停線與呆料兩側的成本結構推導採購 planning 的存在理由與餘裕配置，供判斷一顆料值不值得留餘裕、以及成本不對稱何時反轉時使用">成本結構篇</a> 說的「異常應對是常態工作」在日常層面的樣子——訊號進得早，佈局的選項才多。</p>
<h2 id="料件掌握度的養成">料件掌握度的養成</h2>
<p>資深採購對料件的掌握度可以深到跟研發工程師對話不落下風。養成的路徑很實體：去工廠看製程、跟著研發學電子零件的規格與特性、把自己負責的每顆料真正摸透——它由哪些上游零件構成、哪個環節容易缺、替代方案技術上換不換得動。</p>
<p>這份掌握度的回報在 <a href="/blog/business/procurement-planning/impossible-triangle-rationing/" data-link-title="不可能三角與短缺市場的配給" data-link-desc="用供應側成本結構解釋交期價格品質的取捨為什麼存在、缺貨時供應商按什麼順序配貨、關係投資在配給中的作用，供決定讓哪一角與評估關係價值時使用">配給篇</a> 分析過：它壓縮你跟供應商之間的資訊不對稱，唬弄你的期望收益變低、跟你說真話的成本變低。從業者的版本更直白——懂料的採購，供應商知道唬弄不了，反而更願意給真實的資訊與實在的條件。信任建立在「這個人內行、說話算話、平時往來實在」之上，應酬堆不出這種信任。</p>
<h2 id="平常心">平常心</h2>
<p>這行的異常是常態——<a href="/blog/business/procurement-planning/planning-as-risk-management/" data-link-title="斷料與呆料的成本結構：planning 為什麼是風險管理" data-link-desc="用停線與呆料兩側的成本結構推導採購 planning 的存在理由與餘裕配置，供判斷一顆料值不值得留餘裕、以及成本不對稱何時反轉時使用">成本結構篇</a> 把它當成分析的輸入條件，落到心態上就是：會缺的料就是會缺，會出的狀況就是會出。工作的本分是讓狀況發生時有路可走，而狀況本身攔不住。資深從業者的心態建議是平常心——追料再急，也別讓自己吃不下睡不著、把身體拖垮；公司少了誰都照常運轉，把自己燒掉換不來供貨。平常心還有一個實用面：危機裡保持判斷清晰，而清晰的判斷正是把料追對節點的前提。</p>
<p>面對外界的評價也一樣。旁人問起、給建議，多半只是剛好遇到問題順口一提，不必放在心上。把採購當成一份靠專業、信任與穩定心態長期累積的工作，比追求每一次都完美，更接近這行的真實樣貌。</p>
<h2 id="下一步">下一步</h2>
<p>這些習慣支撐的分析框架在模組其他篇：資訊敏感度餵養的是 <a href="/blog/business/procurement-planning/multi-source-supplier-strategy/" data-link-title="第二來源的經濟學：養供應商是買保險" data-link-desc="用保費對期望損失的框架判斷一顆料要不要養第二供應商，以及認證導入週期為什麼讓臨時尋源不成立，供規劃供應商佈局與評估單一來源風險時使用">供應商佈局</a> 的提前量，掌握度兌現在 <a href="/blog/business/procurement-planning/impossible-triangle-rationing/" data-link-title="不可能三角與短缺市場的配給" data-link-desc="用供應側成本結構解釋交期價格品質的取捨為什麼存在、缺貨時供應商按什麼順序配貨、關係投資在配給中的作用，供決定讓哪一角與評估關係價值時使用">配給順位</a> 與議價品質，平常心守住的是 <a href="/blog/business/procurement-planning/expediting-controllable-nodes/" data-link-title="追料是追可控環節" data-link-desc="追料的節點盤點、各介入選項的成本結構與划算判準、偵測提前量對選項數的影響，供料件快斷時決定在哪個環節出手、用什麼代價換時間時使用">追料</a> 時的判斷力。</p>
]]></content:encoded></item><item><title>角色轉換與職涯路徑</title><link>https://tarrragon.github.io/blog/books/software-management/topics/role-transitions/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/role-transitions/</guid><description>&lt;p>這個主題的書按角色而非按問題組織，在管理線裡只有這一篇這樣切。其他主題篇問「這個問題該讀什麼」，這一篇問「這個位置的人整天在做什麼」。之所以需要這個落點，是因為有一整類書本身就按角色寫成，內容橫跨多個主題而不屬於其中任何一個——把它們拆進各主題會失去「這個位置的全貌」，而全貌正是要換位置的人需要的東西。&lt;/p>
&lt;p>這類書的價值有兩種用法：在自己的位置上用來確認哪些事該做而自己沒在做，以及在轉換之前用來預習。後者尤其重要，因為多數位置轉換的失敗來自不知道新位置的成功長什麼樣，而不是能力不足。&lt;/p>
&lt;p>預習有一個時間差要注意。位置轉換前讀這些書，能讀到的是地圖；真正的判準要等到承擔了責任才長出來。因此比較有效的用法是轉換前讀一次建立預期，等到自己獨立走完一輪那個位置的完整循環（帶完一次績效週期、獨立處理過一次人的問題、或主導完一次跨團隊的交付）之後再讀一次，兩次讀到的東西不同。&lt;/p>
&lt;h2 id="起點是-the-managers-path">起點是 The Manager&amp;rsquo;s Path&lt;/h2>
&lt;p>Camille Fournier 的《The Manager&amp;rsquo;s Path》一本鋪完整條路徑，涵蓋面在本篇最廣。它從「怎麼被管理」開始，接著是 mentor、tech lead、管理個人、管理團隊、管理多個團隊、管理管理者，最後到資深領導。每章結構相似：這個角色實際在做什麼、常見的失敗模式、怎麼判斷自己準備好進下一層。&lt;/p>
&lt;p>它最實用的部分是把模糊的角色講具體。tech lead 與 manager 的差別、什麼時候該停止自己寫程式、一對一該由誰決定議程、績效不佳的人該怎麼處理，這些問題書裡有明確立場而非兩面兼顧的說法。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是單一路徑的個人經驗（作者在 Rent the Runway 擔任 CTO 及先前的任職）。例子多來自中型組織，對多數團隊的規模比大廠案例貼近。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，那道階梯預設組織大到每一層都有專人——tech lead、EM、總監各自是一個人的工作。三十人以下的公司這幾層會壓在同一個人身上，那時它的用途是預覽下一階，而不是對照當下。時效上，書中的職級與晉升描述反映 2010 年代中期的美國科技業，遠距團隊的管理不在討論範圍；各層角色的職責劃分與一對一的用法不依賴那個時空。它的前提是位置而非經驗：正處在書中某一層、或即將進入下一層——建議只讀自己這一層加上一層，整本讀完的人通常記不住用不到的部分，升層時還是要回頭重讀。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897">Amazon（The Manager&amp;rsquo;s Path）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010890612">博客來（經理人之道：技術領袖航向成長與改變的參考指南）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="還在個人貢獻者階段時讀-the-software-engineers-guidebook">還在個人貢獻者階段時讀 The Software Engineer&amp;rsquo;s Guidebook&lt;/h2>
&lt;p>Gergely Orosz 的《The Software Engineer&amp;rsquo;s Guidebook》涵蓋從入門工程師到 principal 以上的各個級別，並且針對每個級別分別處理軟體工程、協作、把事情做完這幾組能力。&lt;/p>
&lt;p>它對只對自己產出負責的位置特別有用，因為它明確回答了一個在那個位置上最難自己看清的問題：下一級別的人跟我的差別具體在哪。多數公司的職級描述寫得抽象（影響範圍、獨立性、複雜度），這本書把它翻成可觀察的行為。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 Uber、Skyscanner、Microsoft、Skype 的任職），加上長期經營的產業電子報累積的跨公司觀察，後者讓它比純粹的單一路徑多一層廣度。處境上，整本書的骨架是職級制度：能力被翻成級別、級別對應可觀察的行為。沒有職級的組織——新創、接案、共同創辦人之間——讀它拿得到那份能力清單，拿不到把清單排序的那根軸，而排序正是它最有用的部分。時效上是本篇最新的一本，對現在的大廠職級制度與遠距工作型態有直接處理。它的內容綁在職級制度上，那套制度改版時這本書會跟著失準，目前還沒有。讀得出價值的前提幾乎沒有——它是本篇門檻最低的一本，剛入行就可以讀，只是後半的高階級別章節要等到用得上時再回頭看。繁體中文版由碁峰資訊出版，沈佩誼譯，譯名《軟體工程師的晉升之路》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Software-Engineers-Guidebook-Navigating-positions/dp/908338182X">Amazon（The Software Engineer&amp;rsquo;s Guidebook）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0011030029">博客來（軟體工程師的晉升之路：全方位升遷攻略）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要走技術路線而非管理路線時讀-staff-工程師的兩本">要走技術路線而非管理路線時讀 Staff 工程師的兩本&lt;/h2>
&lt;p>Tanya Reilly 的《The Staff Engineer&amp;rsquo;s Path》處理的是不帶人但要對技術品質負責的位置。它把這個角色拆成三根支柱：用寬廣的視角看自己的工作、把專案實際推成功的戰術、以及決定在自己的組織裡「好的工程」是什麼意思。第三根支柱是這本書在這條線上少有其他書處理的部分——沒有職權的人如何設定標準。&lt;/p>
&lt;p>Will Larson 的《Staff Engineer》（Tanya Reilly 作序）是另一種形式：它包含 Larson 的框架加上多位 staff 工程師的訪談，因此提供的是多條路徑的樣本而非單一敘事。想知道這個位置在不同公司長什麼樣的人，訪談的部分價值較高。&lt;/p>
&lt;p>兩本與這個主題的其他書承擔同一個角色（技術路線的位置說明），彼此的差別在形式而非層級：Reilly 那本提供系統性的能力拆解，Larson 那本提供路徑的多樣性。只讀一本的話讀 Reilly 那本，因為它的三支柱結構可以拿來自我對照，而訪談讀起來是別人的故事。&lt;/p>
&lt;p>證據來源都是單一路徑的個人經驗，Larson 那本另加訪談樣本。時效上，兩本都出版於 2021-2022 年，描述的職級階梯與現在的大廠制度接近，沒有明顯過時的部分。讀得出價值的前提是：已經是資深工程師、且開始被要求處理跨團隊的技術問題——工作範圍還限在自己的模組裡時讀，三支柱會讀成空話。Reilly 那本有繁體中文版，譯名《Staff 工程師之路》；Larson 那本沒有正式出版的中譯本，網路上有社群自譯的版本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731">Amazon（The Staff Engineer&amp;rsquo;s Path: A Guide for Individual Contributors）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010980200">博客來（Staff 工程師之路：獻給個人貢獻者成長與改變的導航指南）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Staff-Engineer-Leadership-beyond-management/dp/1736417916">Amazon（Staff Engineer: Leadership beyond the management track）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="第一次帶人時讀-the-making-of-a-manager">第一次帶人時讀 The Making of a Manager&lt;/h2>
&lt;p>Julie Zhuo 的《The Making of a Manager》聚焦在第一年。它處理的是新手管理者實際會遇到的具體場景：第一次一對一該說什麼、面試該問什麼、什麼時候該讓表現不佳的人離開、怎麼在自己也不確定的時候給團隊方向。&lt;/p>
&lt;p>它與《The Manager&amp;rsquo;s Path》的差別是範圍與深度的取捨。Fournier 鋪完整條階梯、每層淺一點；Zhuo 只寫第一段路、但把那段寫得細。第一次帶人的當下，後者的可執行性較高。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 Facebook 從第一位實習生做到產品設計副總），且集中在產品設計而非工程管理。時效上，書中的組織規模與遠距前的辦公型態是背景設定；第一年管理者面對的具體場景（第一次一對一、第一次給負評）不依賴那個背景。工程特有的問題（技術決策、輪值、技術債）需要另尋來源。這本有讀它的時間窗：即將帶人或剛開始帶人的那段。已經帶了兩年的人讀它會覺得都知道。繁體中文版由時報出版，譯名《當上主管後，難道只能默默崩潰？》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Making-Manager-What-Everyone-Looks/dp/0735219567">Amazon（The Making of a Manager: What to Do When Everyone Looks to You）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010855700">博客來（當上主管後，難道只能默默崩潰？）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想要管理工作的通用定義時讀-high-output-management">想要管理工作的通用定義時讀 High Output Management&lt;/h2>
&lt;p>Andrew Grove 的《High Output Management》提供的是管理這件事的操作定義而非某個角色的指南。核心是把管理者的產出定義成他所轄組織的產出加上他影響所及組織的產出——這個定義把「我今天很忙」與「我今天有產出」分開，並且讓槓桿變成可以計算的東西。&lt;/p>
&lt;p>書中對一對一、決策會議、績效評估、訓練的處理都建立在同一個槓桿邏輯上：這個動作影響多少人的產出、影響多久。這使它跟其他按角色寫的書層級不同——它給的是判斷任何管理動作值不值得做的尺，因此在任何位置都適用。&lt;/p>
&lt;p>1983 年的書，書中的製造業類比、當時的辦公型態與人事制度都需要折算；槓桿邏輯與會議的分類處理的是管理動作與產出之間的關係，不依賴那些條件，因此是折算後留下來的部分。證據來源是單一路徑的個人經驗（作者在 Intel 從創始成員做到執行長）。讀得出價值的前提是已經在分配自己以外的時間——只管自己的行程時，槓桿計算沒有可以套用的對象。繁體中文版譯名《葛洛夫給經理人的第一課》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884">Amazon（High Output Management）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010816790">博客來（葛洛夫給經理人的第一課：從煮蛋、賣咖啡的早餐店談高效能管理之道，3 版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這六本承擔五個角色：整條階梯的地圖（Manager&amp;rsquo;s Path）、個人貢獻者各級別的能力拆解（SE Guidebook）、技術路線的位置說明（Staff 兩本共同承擔）、第一年帶人的具體場景（Making of a Manager）、管理動作的通用尺（High Output Management）。Staff 兩本合佔一個角色，兩本的差別在形式而非涵蓋範圍。&lt;/p>
&lt;p>分佈刻意偏向個人貢獻者與初階管理。理由是位置越高，同一個職稱在不同公司對應的實際工作差異越大，書能提供的通用部分就越少——到了管理管理者這一層，組織的規模、產業與治理結構決定的比書多。&lt;/p>
&lt;p>職涯類的書在技術書市成長很快，多數落在兩個已被承擔的角色：重述大廠職級制度的升等指南，以及個人成功敘事。前者被《The Software Engineer&amp;rsquo;s Guidebook》以更廣的跨公司觀察覆蓋，後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它：換一間制度不同的公司，這條建議會怎麼變。答不出來的是敘事而非分析。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>確定了位置之後，各項具體能力回到對應主題：交付效能走 &lt;a href="../continuous-delivery/">持續交付與交付效能&lt;/a>，團隊切分走 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>，人留不留得住走 &lt;a href="../retention-motivation/">留任、動機與工作環境&lt;/a>，該講的話講不出口走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>。&lt;/p>
&lt;p>要判斷自己現在站在哪個位置、以及位置對應的起點書，回到 &lt;a href="../../">軟體管理與組織書單&lt;/a> 的位置表。&lt;/p></description><content:encoded><![CDATA[<p>這個主題的書按角色而非按問題組織，在管理線裡只有這一篇這樣切。其他主題篇問「這個問題該讀什麼」，這一篇問「這個位置的人整天在做什麼」。之所以需要這個落點，是因為有一整類書本身就按角色寫成，內容橫跨多個主題而不屬於其中任何一個——把它們拆進各主題會失去「這個位置的全貌」，而全貌正是要換位置的人需要的東西。</p>
<p>這類書的價值有兩種用法：在自己的位置上用來確認哪些事該做而自己沒在做，以及在轉換之前用來預習。後者尤其重要，因為多數位置轉換的失敗來自不知道新位置的成功長什麼樣，而不是能力不足。</p>
<p>預習有一個時間差要注意。位置轉換前讀這些書，能讀到的是地圖；真正的判準要等到承擔了責任才長出來。因此比較有效的用法是轉換前讀一次建立預期，等到自己獨立走完一輪那個位置的完整循環（帶完一次績效週期、獨立處理過一次人的問題、或主導完一次跨團隊的交付）之後再讀一次，兩次讀到的東西不同。</p>
<h2 id="起點是-the-managers-path">起點是 The Manager&rsquo;s Path</h2>
<p>Camille Fournier 的《The Manager&rsquo;s Path》一本鋪完整條路徑，涵蓋面在本篇最廣。它從「怎麼被管理」開始，接著是 mentor、tech lead、管理個人、管理團隊、管理多個團隊、管理管理者，最後到資深領導。每章結構相似：這個角色實際在做什麼、常見的失敗模式、怎麼判斷自己準備好進下一層。</p>
<p>它最實用的部分是把模糊的角色講具體。tech lead 與 manager 的差別、什麼時候該停止自己寫程式、一對一該由誰決定議程、績效不佳的人該怎麼處理，這些問題書裡有明確立場而非兩面兼顧的說法。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是單一路徑的個人經驗（作者在 Rent the Runway 擔任 CTO 及先前的任職）。例子多來自中型組織，對多數團隊的規模比大廠案例貼近。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，那道階梯預設組織大到每一層都有專人——tech lead、EM、總監各自是一個人的工作。三十人以下的公司這幾層會壓在同一個人身上，那時它的用途是預覽下一階，而不是對照當下。時效上，書中的職級與晉升描述反映 2010 年代中期的美國科技業，遠距團隊的管理不在討論範圍；各層角色的職責劃分與一對一的用法不依賴那個時空。它的前提是位置而非經驗：正處在書中某一層、或即將進入下一層——建議只讀自己這一層加上一層，整本讀完的人通常記不住用不到的部分，升層時還是要回頭重讀。</p>
<ul>
<li><a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897">Amazon（The Manager&rsquo;s Path）</a></li>
<li><a href="https://www.books.com.tw/products/0010890612">博客來（經理人之道：技術領袖航向成長與改變的參考指南）</a></li>
</ul>
<h2 id="還在個人貢獻者階段時讀-the-software-engineers-guidebook">還在個人貢獻者階段時讀 The Software Engineer&rsquo;s Guidebook</h2>
<p>Gergely Orosz 的《The Software Engineer&rsquo;s Guidebook》涵蓋從入門工程師到 principal 以上的各個級別，並且針對每個級別分別處理軟體工程、協作、把事情做完這幾組能力。</p>
<p>它對只對自己產出負責的位置特別有用，因為它明確回答了一個在那個位置上最難自己看清的問題：下一級別的人跟我的差別具體在哪。多數公司的職級描述寫得抽象（影響範圍、獨立性、複雜度），這本書把它翻成可觀察的行為。</p>
<p>證據來源是單一路徑的個人經驗（作者在 Uber、Skyscanner、Microsoft、Skype 的任職），加上長期經營的產業電子報累積的跨公司觀察，後者讓它比純粹的單一路徑多一層廣度。處境上，整本書的骨架是職級制度：能力被翻成級別、級別對應可觀察的行為。沒有職級的組織——新創、接案、共同創辦人之間——讀它拿得到那份能力清單，拿不到把清單排序的那根軸，而排序正是它最有用的部分。時效上是本篇最新的一本，對現在的大廠職級制度與遠距工作型態有直接處理。它的內容綁在職級制度上，那套制度改版時這本書會跟著失準，目前還沒有。讀得出價值的前提幾乎沒有——它是本篇門檻最低的一本，剛入行就可以讀，只是後半的高階級別章節要等到用得上時再回頭看。繁體中文版由碁峰資訊出版，沈佩誼譯，譯名《軟體工程師的晉升之路》。</p>
<ul>
<li><a href="https://www.amazon.com/Software-Engineers-Guidebook-Navigating-positions/dp/908338182X">Amazon（The Software Engineer&rsquo;s Guidebook）</a></li>
<li><a href="https://www.books.com.tw/products/0011030029">博客來（軟體工程師的晉升之路：全方位升遷攻略）</a></li>
</ul>
<h2 id="要走技術路線而非管理路線時讀-staff-工程師的兩本">要走技術路線而非管理路線時讀 Staff 工程師的兩本</h2>
<p>Tanya Reilly 的《The Staff Engineer&rsquo;s Path》處理的是不帶人但要對技術品質負責的位置。它把這個角色拆成三根支柱：用寬廣的視角看自己的工作、把專案實際推成功的戰術、以及決定在自己的組織裡「好的工程」是什麼意思。第三根支柱是這本書在這條線上少有其他書處理的部分——沒有職權的人如何設定標準。</p>
<p>Will Larson 的《Staff Engineer》（Tanya Reilly 作序）是另一種形式：它包含 Larson 的框架加上多位 staff 工程師的訪談，因此提供的是多條路徑的樣本而非單一敘事。想知道這個位置在不同公司長什麼樣的人，訪談的部分價值較高。</p>
<p>兩本與這個主題的其他書承擔同一個角色（技術路線的位置說明），彼此的差別在形式而非層級：Reilly 那本提供系統性的能力拆解，Larson 那本提供路徑的多樣性。只讀一本的話讀 Reilly 那本，因為它的三支柱結構可以拿來自我對照，而訪談讀起來是別人的故事。</p>
<p>證據來源都是單一路徑的個人經驗，Larson 那本另加訪談樣本。時效上，兩本都出版於 2021-2022 年，描述的職級階梯與現在的大廠制度接近，沒有明顯過時的部分。讀得出價值的前提是：已經是資深工程師、且開始被要求處理跨團隊的技術問題——工作範圍還限在自己的模組裡時讀，三支柱會讀成空話。Reilly 那本有繁體中文版，譯名《Staff 工程師之路》；Larson 那本沒有正式出版的中譯本，網路上有社群自譯的版本。</p>
<ul>
<li><a href="https://www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731">Amazon（The Staff Engineer&rsquo;s Path: A Guide for Individual Contributors）</a></li>
<li><a href="https://www.books.com.tw/products/0010980200">博客來（Staff 工程師之路：獻給個人貢獻者成長與改變的導航指南）</a></li>
<li><a href="https://www.amazon.com/Staff-Engineer-Leadership-beyond-management/dp/1736417916">Amazon（Staff Engineer: Leadership beyond the management track）</a></li>
</ul>
<h2 id="第一次帶人時讀-the-making-of-a-manager">第一次帶人時讀 The Making of a Manager</h2>
<p>Julie Zhuo 的《The Making of a Manager》聚焦在第一年。它處理的是新手管理者實際會遇到的具體場景：第一次一對一該說什麼、面試該問什麼、什麼時候該讓表現不佳的人離開、怎麼在自己也不確定的時候給團隊方向。</p>
<p>它與《The Manager&rsquo;s Path》的差別是範圍與深度的取捨。Fournier 鋪完整條階梯、每層淺一點；Zhuo 只寫第一段路、但把那段寫得細。第一次帶人的當下，後者的可執行性較高。</p>
<p>證據來源是單一路徑的個人經驗（作者在 Facebook 從第一位實習生做到產品設計副總），且集中在產品設計而非工程管理。時效上，書中的組織規模與遠距前的辦公型態是背景設定；第一年管理者面對的具體場景（第一次一對一、第一次給負評）不依賴那個背景。工程特有的問題（技術決策、輪值、技術債）需要另尋來源。這本有讀它的時間窗：即將帶人或剛開始帶人的那段。已經帶了兩年的人讀它會覺得都知道。繁體中文版由時報出版，譯名《當上主管後，難道只能默默崩潰？》。</p>
<ul>
<li><a href="https://www.amazon.com/Making-Manager-What-Everyone-Looks/dp/0735219567">Amazon（The Making of a Manager: What to Do When Everyone Looks to You）</a></li>
<li><a href="https://www.books.com.tw/products/0010855700">博客來（當上主管後，難道只能默默崩潰？）</a></li>
</ul>
<h2 id="想要管理工作的通用定義時讀-high-output-management">想要管理工作的通用定義時讀 High Output Management</h2>
<p>Andrew Grove 的《High Output Management》提供的是管理這件事的操作定義而非某個角色的指南。核心是把管理者的產出定義成他所轄組織的產出加上他影響所及組織的產出——這個定義把「我今天很忙」與「我今天有產出」分開，並且讓槓桿變成可以計算的東西。</p>
<p>書中對一對一、決策會議、績效評估、訓練的處理都建立在同一個槓桿邏輯上：這個動作影響多少人的產出、影響多久。這使它跟其他按角色寫的書層級不同——它給的是判斷任何管理動作值不值得做的尺，因此在任何位置都適用。</p>
<p>1983 年的書，書中的製造業類比、當時的辦公型態與人事制度都需要折算；槓桿邏輯與會議的分類處理的是管理動作與產出之間的關係，不依賴那些條件，因此是折算後留下來的部分。證據來源是單一路徑的個人經驗（作者在 Intel 從創始成員做到執行長）。讀得出價值的前提是已經在分配自己以外的時間——只管自己的行程時，槓桿計算沒有可以套用的對象。繁體中文版譯名《葛洛夫給經理人的第一課》。</p>
<ul>
<li><a href="https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884">Amazon（High Output Management）</a></li>
<li><a href="https://www.books.com.tw/products/0010816790">博客來（葛洛夫給經理人的第一課：從煮蛋、賣咖啡的早餐店談高效能管理之道，3 版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這六本承擔五個角色：整條階梯的地圖（Manager&rsquo;s Path）、個人貢獻者各級別的能力拆解（SE Guidebook）、技術路線的位置說明（Staff 兩本共同承擔）、第一年帶人的具體場景（Making of a Manager）、管理動作的通用尺（High Output Management）。Staff 兩本合佔一個角色，兩本的差別在形式而非涵蓋範圍。</p>
<p>分佈刻意偏向個人貢獻者與初階管理。理由是位置越高，同一個職稱在不同公司對應的實際工作差異越大，書能提供的通用部分就越少——到了管理管理者這一層，組織的規模、產業與治理結構決定的比書多。</p>
<p>職涯類的書在技術書市成長很快，多數落在兩個已被承擔的角色：重述大廠職級制度的升等指南，以及個人成功敘事。前者被《The Software Engineer&rsquo;s Guidebook》以更廣的跨公司觀察覆蓋，後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它：換一間制度不同的公司，這條建議會怎麼變。答不出來的是敘事而非分析。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>確定了位置之後，各項具體能力回到對應主題：交付效能走 <a href="../continuous-delivery/">持續交付與交付效能</a>，團隊切分走 <a href="../team-design/">組織結構與團隊設計</a>，人留不留得住走 <a href="../retention-motivation/">留任、動機與工作環境</a>，該講的話講不出口走 <a href="../influence-conversation/">困難對話與無權限影響力</a>。</p>
<p>要判斷自己現在站在哪個位置、以及位置對應的起點書，回到 <a href="../../">軟體管理與組織書單</a> 的位置表。</p>
]]></content:encoded></item></channel></rss>