前言#

作者多年前成為 Tech Lead。當時她剛升上 Senior Engineer，在一個由多位資深工程師組成的小團隊中工作。出乎意料地，她被拔擢為 Tech Lead，儘管她在職級或年資上都不是團隊中最資深的人。回顧來看，她具備幾項優勢：她不只是一位好工程師，更是一位好的溝通者——能撰寫清晰的文件、能上台做簡報而不崩潰、能跨團隊跨角色地與人溝通。她也擅長排定優先順序，願意主動推進工作並決定下一步該做什麼。最終，她認為是這種務實的急迫感（pragmatic urgency）成為決定性因素。畢竟，Tech Lead 是一個領導職位，即使它不是管理職位。

作者也見過失敗的 Tech Lead。其中一位令人印象深刻的案例是一位技術能力出眾的工程師，程式寫得很好，但討厭與人溝通，經常被技術細節所分心。他不斷鑽進技術的兔子洞，而產品經理趁他不在時，迫使團隊承諾了設計粗糙且時程過於緊迫的功能交付。專案一團糟，而這位 Tech Lead 做了什麼？他又去追下一個重構了，因為他堅信問題全出在程式碼的結構上。這種故事到處都在發生。自動將 Tech Lead 角色指派給最資深的工程師，是一個常見的錯誤認知，連有經驗的管理者都會犯。Tech Lead 不是給那些只想深入鑽研自己程式碼的人做的。

Tech Lead 的定義#

如同軟體工程中的許多頭銜，「Tech Lead」缺乏一個共通的定義。作者在 Rent the Runway 建立工程職涯階梯時，刻意將 Tech Lead 定義為一組特質與職責，而非特定的職級。這是因為隨著團隊的變化與演進，Tech Lead 角色可能由不同階段的工程師擔任，也可能在工程師之間傳遞，而雙方不一定會改變其職級。以下是 Rent the Runway 的定義：

Rent the Runway 對 Tech Lead 的定義： Tech Lead 不是職涯階梯上的一個點，而是任何工程師達到 Senior 等級後可能承擔的一組職責。此角色可能包含也可能不包含人員管理，但若包含，Tech Lead 必須達到以下管理標準：

• 固定的一對一會議：每週與被管理人員進行定期接觸
• 定期給予回饋：涵蓋職涯成長、目標進度、需改進的領域，以及適時的讚賞
• 訂定學習領域：協助成員透過專案工作、外部學習或額外的指導來成長

即使 Tech Lead 沒有直接管理職責，仍然需要為團隊其他成員提供指導與引導。Tech Lead 正在學習成為一位強大的技術專案經理，透過有效的委派工作來擴展自己的影響力，而非事必躬親。他們專注於整個團隊的生產力，致力於提升團隊工作產出的影響力。

擔任 Tech Lead 並非晉升的必要條件，但它是工程師從 Senior Engineer 1 升到 2 最常見的途徑，且從 Senior Engineer 2 升到 Engineering Lead 則是必要的。即使走個別貢獻者路線，在更高階的層級上幾乎不可能不曾擔任過 Tech Lead，因為領導力與責任感在資深層級至關重要。

Patrick Kua 在他的著作 Talking with Tech Leads 中提供了一個更簡潔的定義：

Patrick Kua 的定義： 一位負責（軟體）開發團隊的領導者，且至少花 30% 的時間與團隊一起寫程式。

Tech Lead 的定位是擔任強大的技術專案領導者，運用自身專業在更大的範圍內提升整個團隊的能力。他們可以做出獨立決策，並在與非工程合作夥伴的協調中扮演重要角色。值得注意的是，這個角色的定義中沒有特別強調純技術工作。這是一個資深工程角色，但將 Tech Lead 等同於團隊中最好或最有經驗的工程師是一個錯誤。你無法在不與人互動的情況下領導他人，而我們要求新任 Tech Lead 去拓展的，遠比純技術能力更多的是人際技能。

不過，Tech Lead 會學到一項重要的新技術能力：專案管理。拆解專案的工作與設計系統有很多相似之處，即使對不想管人的工程師來說，這項技能也極具價值。

優秀 Tech Lead 都懂的一個訣竅#

你是 Tech Lead，意味著你懂軟體，而你的經理認為你成熟到可以承擔更大的專案責任。但有技術實力和成熟度還不夠，你必須領悟做好 Tech Lead 的最大訣竅：願意暫時離開程式碼，學會在技術工作與團隊整體需求之間取得平衡。你必須不再完全依賴舊技能，開始學習新的技能。你即將學習平衡的藝術。

從現在開始，無論你的職涯走向何方，平衡很可能都是你的核心挑戰之一。如果你想對工作有自主權，想要自由選擇何時做什麼，你就必須掌控好自己的時間。更困難的是，你經常需要在你已經會做且喜歡做的事情（例如寫程式）和你還不會的事情之間取得平衡。人類天生偏好已經熟練的活動，所以當你必須減少在當前才能上的投入、轉而學習新事物時，會感到相當不適。

在專案管理與監督和親手技術交付之間取得平衡可能很困難。有些日子你處於 Maker’s Schedule（創作者時間表），有些日子你處於 Manager’s Schedule（管理者時間表）。你需要透過反覆嘗試，學會管理自己的時間，為自己安排適當大小的工作區塊。最糟糕的排程錯誤是讓自己被隨意拉入會議——如果每小時都被會議打斷，幾乎不可能進入寫程式的心流。

即使仔細排程，你也不太會有連續好幾天專注在程式問題上的機會。希望你在此之前已經學會了一些技巧，把自己的工作拆分得更小，不需要花好幾天的專注時間才能完成技術任務。同時你也知道，幫團隊安排一個能讓他們長時間專注開發的時間表是很重要的，因為他們確實需要連續好幾天專注在程式問題上。你的領導責任之一，就是幫助其他利害關係人（如你的老闆和產品經理）尊重團隊的專注時間，不要安排讓個別貢獻者不堪負荷的會議行程。

Tech Lead 入門#

假設你正與一位產品經理和四位工程師合作，進行一個多週的大型專案以推出一項新計畫。Tech Lead 在此情境中有許多職責，取決於你在專案生命週期的哪個階段。當然，你需要寫一些程式碼、做一些技術決策，但那只是你扮演的角色之一，甚至可能不是最重要的一個。

Tech Lead 的三大主要角色#

你身為 Tech Lead 的最高優先事項，是以大局觀看待工作，確保專案持續推進。你需要從組織和規劃自己的程式碼，轉變為組織和領導整個專案。

系統架構師與商業分析師

在此角色中，你要辨識出需要變更的關鍵系統與必須打造的關鍵功能，以交付即將到來的專案。目標是為評估工作量和排定工作順序提供結構。你不必完美地辨識出專案的每一個元素，但花時間思考專案相關的外部因素和潛在問題有很大的價值。此角色要求你對系統的整體架構有良好的掌握，並具備設計複雜軟體的扎實能力，同時也需要能理解商業需求並將其轉化為軟體方案。

專案規劃師

專案規劃師將工作拆解為粗略的可交付項目。戴上這頂帽子時，你正在學習用有效率的方式拆分工作，讓團隊能快速推進。其中一個挑戰是盡可能讓更多的工作能平行進行。這可能很難，因為你大概習慣只思考自己的工作，而不是一群人的工作。找到可以套用共識抽象層（agreed-upon abstractions）來實現平行開發的地方是關鍵。例如，如果你有一個消費 JSON 物件的前端與一個 API，API 不需要完全完成前端開發就能開始——只要雙方同意 JSON 格式，就可以用假資料先行開發。

如果你夠幸運，你以前見過這種做法，只需要模式匹配（pattern-matching）過去的經驗。在這個階段，你會想要收集團隊中專家的意見，和深入了解受影響軟體的人討論，讓他們幫忙處理細節。你也會想在這個過程中開始辨識優先順序——哪些部分是關鍵的，哪些是選擇性的？如何在專案早期就著手處理關鍵項目？

軟體開發者與團隊負責人

軟體開發者與團隊負責人寫程式碼、溝通挑戰、並進行委派。隨著專案推進，意料之外的障礙會出現。有時候 Tech Lead 會想英雄式地自己硬撐過去、加班把事情做完。在你作為 Tech Lead 的位置上，你應該繼續寫程式碼，但不要太多。即使你很想自己把兔子從帽子裡變出來，你也必須先溝通這個障礙。你的產品經理應該儘早知道任何可能的挑戰。在需要時尋求工程經理的協助。在一個健康的組織中，儘早提出問題不會帶來任何羞恥或傷害。團隊失敗的原因往往是因為他們在一個產品經理其實願意妥協的功能上過度加班。當大型專案接近交付日期時，功能上一定會有妥協。開始尋找委派工作的機會，特別是你原本預期要自己做但還沒時間處理的部分。

從以上描述可以看出，在擔任 Tech Lead 的過程中，你必須同時扮演軟體開發者、系統架構師、商業分析師和團隊領導者，知道什麼時候該親自動手，什麼時候該委派給他人。幸運的是，你不必同時做所有這些事。一開始可能不太舒服，但隨著時間和練習，你會找到平衡。

管理專案#

作者對複雜專案管理的第一次經驗記憶猶新。她當時是一位初任 Tech Lead，團隊正在處理一項非常複雜的任務：把一個已經擴展到極限的現有系統改為能在多台機器上運行。那是分散式系統的早期時代，大多數軟體開發者對建立分散式系統的最佳實踐所知甚少。但團隊有一群聰明人，而他們有信心能解決這個問題。

他們確實解決了，慢慢地但確實地。他們花了很長時間思考設計，以及如何拆分運算使其在多台機器上運行。然後有一天，她的老闆 Mike 把她叫進辦公室，告訴她需要做一份專案計畫。

那是她最糟糕的經歷之一。她必須把這組極其複雜的任務梳理出哪些依賴哪些：如何讓它在複雜的測試框架中運作？如何部署？什麼時候需要訂購硬體來測試？整合測試需要多久？問題源源不絕。她會走進 Mike 的辦公室，坐在他對面的大木桌前，一起檢視任務描述、日期和拆解。他會幫忙做一部分，然後把需要更多工作的部分交給她。

這不是她享受的事情。它深深烙印在她的記憶中，是一系列令人沮喪又繁瑣的步驟，她必須克服不確定性和害怕遺漏的恐懼。然而，這是她職涯中最重要的學習經驗之一。

敏捷開發不能取代專案管理#

敏捷軟體開發（Agile）是一種很好的工作思維方式，它迫使你將任務拆解成更小的塊，規劃這些更小的塊，並逐步交付價值而非一次全部交付。然而，這並不意味著你不需要理解如何做專案管理。你會遇到某些原因無法在一個 Sprint 甚至兩個短 Sprint 中完成的專案。你需要為管理層估計專案時程，並詳細說明為何你認為需要那麼久。有些專案（通常被描述為基礎設施、平台或系統）需要架構設計或大量的前期規劃，這種有許多未知數且期限相對固定的專案，不太適合標準的敏捷流程。

隨著你在職涯中前進，你需要理解如何拆解超出個人能力範圍的複雜工作。為長期的團隊專案做專案管理，對大多數人來說都不有趣。作者覺得它繁瑣而且有時候令人害怕。但替代方案不是專案更快失敗，而是更慢地失敗。

專案管理也不需要對每項工作都做得鉅細靡遺，在某些組織中它確實被過度使用。作者甚至不喜歡僱用專案經理，因為他們經常成為工程師不去思考未來工作的拐杖，而且他們的存在往往意味著更多瀑布式專案而非敏捷流程。然而，專案管理必須發生，作為 Tech Lead，你應該在需要時去做，尤其是對於深度技術性的專案。

重點： 規劃的價值不在於你完美地執行計畫、事先捕捉到每個細節、或預測未來。價值在於你強迫自己在一頭栽入之前，以一定的深度去思考專案。在那些你可以合理做出預測和計畫的地方進行一定程度的深思熟慮——這才是目標。計畫本身無論最終多準確，都不如花時間在「規劃這個行為」上來得重要。

回到那次經驗——專案是否完美按照計畫執行？當然沒有。有問題、有 bug、有意外延遲、有遺漏的事項。然而，驚人的是，他們仍然大致如期交付了專案，而且不需要熬夜趕工。他們在 40 名其他開發者同時對主分支做修改的情況下，成功完成了這個複雜系統的分散式部署轉換。這一切之所以可能，是因為他們有一支好團隊，而且他們有一個計畫。他們事先想過成功是什麼樣子，並識別出一些可能導致失敗的風險。

專案管理的五大方針#

專案管理是將複雜的終極目標拆分成更小的部分，以大致最有效的順序排列，辨識哪些可以平行進行、哪些必須循序執行，並嘗試理出那些可能讓專案進度放慢或完全失敗的未知因素。你在面對不確定性、尋找未知數，並認知到你在過程中一定會犯錯、一定會遺漏一些未知數。以下是具體方針：

1. 分解工作：拿出試算表、甘特圖或任何對你有用的工具，開始將你的大型交付目標拆解成任務。先從最大的部分開始，然後把大的拆成小的，再把小的拆得更小。你不必全部自己做——如果有你不了解的系統部分，向了解的人求助。把大項目拆解到一定程度後，將注意力轉向工作的排序。哪些可以立即開始？把那些任務交給能將它們轉化為工單大小工作的人。

2. 推進細節與未知要素：專案管理的訣竅在於不要在你感到有點卡住或疲倦時就停下來。它確實令人疲倦又繁瑣。而且這不是你大概擅長做的事。所以，撐過那些煩躁、無聊和痛苦的時刻繼續推進。一位好的主管會坐下來陪你，告訴你哪裡不夠好、提出問題來提示你，甚至和你一起做一些。持續處理未知數，直到你真的覺得再花時間在上面已經沒有更多價值。

3. 執行專案並隨時調整計畫：良好規劃流程的價值在於幫助你了解專案大約走了多遠、距離完成還有多遠。當事情延遲時（而它們總會延遲），讓所有人知道進度。現在，你不再是猜測還剩多遠，而是能清楚地指出已達成的里程碑，並概述預期的剩餘工作。

4. 利用規劃所得的洞察來管理需求變更：你在基於原始需求拆解專案時學到了很多。如果需求在過程中開始改變，將這些洞察應用到變更上。如果變更為專案帶來顯著風險、需要大量新規劃，或只是需要大量額外工作，清楚說明這些變更的成本。如果你正朝著固定的截止日期推進，大致了解所需的工作量能幫你排定優先順序、刪減和簡化工作，以在功能、品質和交付日期之間取得最佳平衡。

5. 臨近完成時重新審視細節：在專案尾聲，繁瑣感又回來了。現在是時候真正關注收尾的細節了。還缺什麼？測試呢？驗證呢？進行一次事前驗屍（premortem），演練在這個大專案上線時所有可能出問題的事情。決定「夠好」（good enough）的標準在哪裡，讓大家達成共識並承諾它。砍掉低於「夠好」標準的工作，讓團隊聚焦在最重要的最終細節。制定上線計畫，制定回滾計畫。最後，別忘了慶祝！

決策時刻：技術職或管理職#

關於要當主管還是留在技術路線，這是一個艱難的決定。它高度取決於脈絡，沒有人能替你決定。然而，作為一個曾經夢想並經歷過這兩條路線的人，作者分享了她對這兩個角色的想像與實際經歷的對比。以下是一些角色的描繪——它們只是粗略的素描，並非鐵板釘釘。

想像中的資深個別貢獻者生活#

你的日子在深度思考、解決智識挑戰但仍有趣和新穎的難題、以及與其他深度思考者合作中度過。雖然是軟體所以你知道會有一些瑣事（yak shaving），但你能做到最有趣的工作，而且你有很多權力選擇做什麼。你熱愛寫程式、修 bug、優化效能、讓電腦做新事情，而你大部分時間都在做這些。

因為你的資歷，管理者在開始開發之前會徵詢你的建議，所以你知道所有正在發生的事，但不需要處理執行人員的細節。你被邀請參加恰好那些做重要決策的會議，但不會多到打斷你的心流。資淺的開發者仰望你，聽你的每一句話，接受你的回饋但不會過多打擾你的深度思考時間。

你的上升軌跡從不放慢，總有新的大問題讓你解決，展現你對組織的價值。你努力工作但很少需要加班或週末工作。當你確實晚了，那是因為你太投入在心流中，迫不及待想完成手上的功能或修復剛發現的 bug。

你能寫書、演講、做開源——如果幸運且堅持，你還能獲得一定的業界知名度。沒人在意你有點笨拙或害羞，也不期望你太多改變溝通風格，因為你說的話太重要了。組織裡每個人都知道你是誰，理解你的工作有多珍貴，對你的意見尊敬有加。

簡而言之，你有完美的平衡：引人入勝的工作、名聲、以及累積的專業讓你不可或缺且備受尊重、高薪又有影響力。

真實的資深個別貢獻者生活#

當你找到對的專案——在對的專案的對的生命週期階段——你的生活很棒。你被挑戰，你學到新東西。你對日常有很多掌控權，肯定比管理者少開很多會議，但你的日子並非總在幸福的心流狀態中度過。每個專案都有你提出想法然後到處推銷的階段，試圖說服別人這是正確的做法。或者你已經實作了系統，但現在需要讓其他團隊開始使用它，所以你花好幾天坐在他們旁邊，展示來龍去脈、解釋為什麼有用，試著說服他們去跟主管爭取時間來採用。

你的上升軌跡不像你希望的那麼快。那些證明你是不可或缺架構師的大專案很難找到。團隊不需要新的程式語言、新的資料庫或新的 Web 框架。你的經理不太會主動交給你能在整個組織展現才華的美差；她期望你自己去告訴她這些機會在哪裡。選錯專案，你可能花數月甚至數年在一個最終被取消的東西上。你有點嫉妒你那些做管理的朋友似乎升遷更快、團隊也越帶越大。

其他開發者參差不齊。你是個好人，所以有些人欽佩你、聽你的意見，但其他人似乎嫉妒你的影響力。新進開發者要嘛想要太多你的時間，要嘛不知為何怕你。同儕之間對於誰能領導大型有趣專案肯定有些競爭。

你的經理有點煩人。她不太支持你想把一個系統開源出去的願望，她建議如果你想演講或寫書也許應該用個人時間。她會徵詢你對技術事務的回饋，但有時忘了告訴你新計畫直到太遲。你懷疑你錯過了關鍵資訊因為你不在正確的會議中，但每次她邀你參加那些會議，你就想起那些會議有多無聊和低效，以及你損失了多少寶貴的專注時間。而且她對你想擺脫回覆郵件、面試或及時做 code review 等瑣事的願望也沒什麼耐心。

不過，你大部分時間還是能建造東西。你可以專注於技術問題、系統設計和工程議題，不用太多與人打交道或開無聊的會。你通常能選擇自己的專案，如果想要新東西可以輕鬆換團隊。而且你剛發現你的薪水比你的經理高！所以，日子也沒那麼糟。

想像中的管理者生活#

你有一個團隊、你有掌控權、你能做決定，你終於能讓別人照你的方式做事了。你的團隊尊重你，樂意在所有事情上服從你的權威。你覺得他們應該多寫測試？你說「寫更多測試」，他們就做了！你想確保每個人無論性別、種族都被公平對待？你確保它發生，並開除任何越界而為其他團隊成員製造不健康環境的人。

因為你關心人，他們知道你即使與他們意見不同，也總是盡力為他們著想。他們給你懷疑的空間，在一對一會議中對你坦率回饋你哪裡搞砸了，也渴望接收你的回饋。處理人的事情有壓力，但他們知道你關心他們，所以也非常有成就感。你能很快看到你的指導所產生的影響。

你的主管給你大量指導但很少干預告訴你該做什麼。你一覺得準備好帶更大的團隊，你的主管就願意給你更多人、擴展你的組織。她給你清晰的目標且很少改變。即使你有很多責任，你仍有時間寫部落格文章和演講，這是被鼓勵的因為它幫助你的團隊招募和提升你在技術業界的地位。

簡而言之，你做決策、你創造文化、你的效能對周遭所有人都顯而易見，讓你的升遷之路快速、職涯刺激又豐厚。

真實的管理者生活#

你有一個團隊。你有一些掌控權，但你很快發現讓人做事比直接告訴他們做難得多。你似乎放棄了對自己日常的所有掌控。你大部分時間都在開會。你知道這會來，但直到親身經歷才真正理解它意味著什麼。當你只有小團隊時還能平衡一下、繼續寫程式，但隨著團隊成長，你跟程式碼漸行漸遠。這像是啃噬你的焦慮——你覺得你應該在寫，但沒有時間。每次你抓到幾個小時想寫程式，你就意識到把它 check in 讓團隊維護是不負責任的，所以頂多偷寫個腳本、除個 bug。有專注力建造大東西的日子已是遙遠的記憶。

你能做決定——嗯，某些決定。實際上，你大概能縮小被決定的事項的範圍。你可以讓團隊聚焦在某些事上，例如寫更好的測試，但他們仍有產品路線圖要實作，也有自己對技術優先事項的想法。所以與其說你自己做決定，不如說你在幫團隊做決定。你的主管給你目標但有時完全改變那些目標，而你得負責向團隊解釋這些變更。

你確實在團隊中設定了文化標準，這有好有壞。好的一面是他們學到了你最好的特質，壞的一面是你發現團隊也在映射你的缺點。

你的團隊不會天然地同意你、尊重你、甚至喜歡你。你意識到權威需要的不只是一個頭銜。你發現自己在艱難時期掙扎著激勵他們——當專案不順利時，或當你必須告訴個別成員他們還沒準備好升遷、今年沒有加薪、沒有獎金。有些人不會告訴你他們不開心；他們就是受夠了然後在你注意到任何問題之前辭職。當公司表現好時，有很多錢可以發、有很多刺激的專案，生活很棒；但壓力大的時候，你看到你讓人開心的能力有多有限。更糟的是，你連開除人都不能不經過瘋狂的 HR 流程！不過，你能看到你的工作對某些人確實重要，他們因為你的指導而更快樂、更成功。這些小小的勝利在艱難時期支撐著你。

其他管理者不見得對你的回饋有興趣。事實上，他們覺得你多管閒事，當他們覺得你侵入他們的地盤時會變得有競爭性。你自己的主管不同意你已經準備好帶更大的團隊，也無法真正解釋為什麼；他的指導能力有待加強。也許他只是擔心你會蓋過他的風頭？他絕對不希望你把所有時間都花在演講上——他對你太常不在辦公室感到不爽，不管團隊可能從中獲得什麼價值。搞清楚如何在不破壞同儕或老闆的情況下做領導，比你預期的更棘手。但如果你能拿到更大的團隊，你知道你就會升遷，所以至少你的路徑是清楚的。當你發現在你底下的 Staff Engineer 薪水比你高的時候，你差點崩潰，所以你最好趕快想辦法拿到更大的團隊。不然這一切壓力和荒謬有什麼意義？

你可以換跑道#

作者最後的建議是記住：你可以隨時換跑道。人們在某個時間點嘗試管理、發現自己不喜歡、然後回到技術路線，是很常見的。這個選擇不必是永久的，但請睜大眼睛走進去。每個角色都有好處和壞處，取決於你去感受什麼最適合自己。

好主管、壞主管：流程大頭目#

流程大頭目（Process Czar）相信存在一種唯一正確的流程，只要正確實施並按設計執行，就能解決團隊所有最大的問題。流程大頭目可能沉迷於 Agile、Kanban、Scrum、Lean，甚至 Waterfall 方法。他們可能對 on-call 如何運作、code review 必須怎麼做、或發布流程必須如何運行有非常精確的想法。他們往往非常有條理、對細節很在行，擅長掌握規則並精確地遵守。

流程大頭目常見於 QA、客服或產品管理團隊中，也常見於顧問公司和其他高度獎勵具體工作進度衡量的地方。他們在專案管理團隊中可以非常有價值，因為他們往往確保沒有任務被遺忘、所有事情都按應有的方式收尾。

流程大頭目的問題在於，他們沒有意識到大多數人不像他們那樣擅長遵循流程。他們傾向將所有問題歸咎於未遵循最佳流程，而不是承認需要靈活性和意外變更的必然性。他們經常聚焦於容易衡量的事物（如辦公室時數），而忽略了聚焦在容易衡量的事物上所遺漏的細微差異。

相信「對的工具做對的事」的工程師，有時在成為 Tech Lead 後會變成流程大頭目，試圖找到正確的工具來解決所有關於規劃、專注、時間管理和優先順序的問題。他們試圖在找到完美流程之前停止所有工作，或不斷把新工具和新流程推給團隊作為人際互動中那些更混亂問題的解方。

流程大頭目的反面不是完全放棄流程的管理者，而是理解流程必須服務於團隊和工作需求的人。諷刺的是，雖然「敏捷」經常被僵化地執行，但敏捷宣言的原則其實是健康流程領導的絕佳總結：

注意： 作為新任 Tech Lead，小心不要依賴流程來解決團隊中因溝通或領導力不足而產生的問題。流程的改變有時有幫助，但它很少是銀子彈，而且沒有兩個優秀的團隊在流程、工具或工作風格上看起來完全一樣。另一個建議是尋找自我調節的流程（self-regulating processes）。如果你發現自己在扮演監工的角色——批評違反規則或不遵循流程的人——看看流程本身是否可以改得更容易遵循。浪費時間當規則警察是不值得的，而自動化通常能讓規則變得更顯而易見。

作為流程大頭目的管理者，應該幫助那個人變得更能接受模糊性。如同許多管理者的陷阱，對流程的執迷可能與害怕失敗和想控制事物以防止意外有關。如果你坦誠且明確表示失敗和不完美是安全的，通常就足以讓你的流程大頭目放鬆一些、容許一些模糊性。非常重要的是，要防止流程大頭目花所有時間尋找完美的工具或流程，尤其要確保他們沒有因為未遵循流程而懲罰團隊。

如何成為優秀的 Tech Lead#

優秀的 Tech Lead 具備許多特質，但以下幾點最為重要。

理解架構#

如果你進入 Tech Lead 角色時覺得自己不完全理解你所支持的架構，花時間去理解它。學習它、感受它、視覺化它。了解它的連接方式、資料存放在哪裡、如何在系統之間流動。了解它如何反映它所支持的產品、這些產品的核心邏輯存放在哪裡。當你不理解你正在改變的架構時，幾乎不可能好好地領導專案。

當一個好的團隊成員#

如果你把所有有趣的工作都自己做了，停下來。去看看那些棘手、無聊或惱人的技術需求，看看你能否解除那些區域的阻塞。在程式碼庫中較不刺激的部分工作，能教你很多關於流程哪裡壞了的事。對於無聊或令人沮喪的專案，如果有經驗的人花時間去看，往往能發現一些明顯可以修復的東西。

如果你只在做最無聊的工作，也停下來。你是一位有才華的資深工程師，接手一些較困難的任務是合理的。你想鼓勵團隊中的其他人學習整個系統，想給他們機會去挑戰自己，但你不必總是在選擇工作時自我犧牲。偶爾給自己一個有趣的任務，只要你確定有時間做好它。

領導技術決策#

你會參與團隊的大多數重大技術決策。但參與不等於獨自做出所有決策。如果你開始在沒有徵詢團隊意見的情況下做所有技術決策，他們會怨恨你，並在事情出錯時怪你。另一方面，如果你不做任何技術決策而把一切交給團隊，本可以快速做出的決定可能會拖延而沒有結論。

判斷哪些決策必須由你做出、哪些應該委派給有更多專業知識的人、哪些需要整個團隊共同解決。在所有情況下，清楚說明討論的事項是什麼，並溝通結果。

溝通#

你的個人產出現在不如整個團隊的產出重要。這往往意味著你要承擔溝通的開銷。你代表團隊出席會議，傳達他們的需求，並將會議資訊帶回團隊，而不是讓每個團隊成員都坐在會議中。

如果有一項通用的才能能將成功的領導者與其他人區分開來，那就是溝通能力。成功的領導者善於寫作、仔細閱讀，並能在眾人面前發言。他們在會議中專注，並不斷測試自己和團隊的知識邊界。現在是練習寫作和演講技能的好時機。撰寫設計文件並從更好的寫手那裡獲得回饋。為你的技術部落格或個人部落格寫文章。在團隊會議中發言，在 meetup 上演講，練習在觀眾面前站起來說話。

不要忘記在所有溝通中傾聽。給別人發言的機會，聽他們說的話。練習將事情重述回去以確保你理解。學習如何聽到別人說的話並用你自己的話重新表達。如果你不擅長做筆記，你可能需要變得擅長。無論你選擇深入技術還是成為管理者——如果你不能溝通、不能傾聽別人在說什麼，從這個時間點開始，你的職涯成長會受到影響。

評估你的個人經驗#

• 你的組織有 Tech Lead 嗎？這個角色有書面的職位描述嗎？如果有，它說了什麼？如果沒有，你會如何在你的組織中定義這個角色？一位 Tech Lead 會如何定義這個角色？
• 如果你正在考慮成為 Tech Lead，你準備好挑戰自己了嗎？你能接受把一些時間花在程式碼之外嗎？你覺得你對程式碼庫夠了解，能在其他人在其中工作時成功地領導他們嗎？
• 你有問過你的主管，他或她對 Tech Lead 有什麼期望嗎？
• 你合作過的最棒的 Tech Lead 是誰？那個人做了哪些事讓他或她成為出色的 Tech Lead？
• 你有和一個令人沮喪的 Tech Lead 共事過嗎？他或她做了什麼讓你感到沮喪？