<?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>Engineering-Manager on Tarragon</title><link>https://tarrragon.github.io/blog/tags/engineering-manager/</link><description>Recent content in Engineering-Manager 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/engineering-manager/index.xml" rel="self" type="application/rss+xml"/><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></channel></rss>