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