結論先講
Tech Lead 不是「團隊裡技術最好的人」，也不是「Senior 工程師的升級版」。是能用技術判斷力帶領團隊做出好決策，同時讓每個人都成長的人。
如果你當上 Tech Lead 後還是花 80% 的時間寫 code，那你可能只是一個「有 title 的 Senior」。真正的 Tech Lead 的時間分配大概是：30% 寫 code、30% code review 和技術討論、20% 溝通和對齊、20% 規劃和決策。
1. 技術決策：選擇比努力重要
Tech Lead 最重要的工作不是寫 code，是做決策。
技術選型的思考框架：
| 考慮面向 | 問自己的問題 |
|---|---|
| 團隊能力 | 團隊成員會這個技術嗎？學習成本多高？ |
| 社群和生態 | 有足夠的文件和社群支援嗎？五年後還會活著嗎？ |
| 業務需求 | 這個技術能解決我們的具體問題嗎？ |
| 維護成本 | 長期維護需要什麼？upgrade path 清楚嗎？ |
| 招人 | 用這個技術招得到人嗎？ |
Build vs Buy：
| 情境 | Build（自己做） | Buy（用現成的） |
|---|---|---|
| 核心競爭力 | 是你的產品差異化 → Build | 不是核心 → Buy |
| 時間壓力 | 有時間 → 考慮 Build | 趕時間 → Buy |
| 長期維護 | 有團隊維護 → Build | 不想養 → Buy |
| 特殊需求 | 市場上沒有合適的 → Build | 現成的就夠用 → Buy |
真實案例：某團隊花了三個月自己寫 CMS，結果功能不到 Strapi 的 10%，還要持續維護。如果當初花兩週評估和設定 Strapi，省下的時間能多做三個 feature。
做決策的方式：
不是 Tech Lead 一個人說了算，也不是民主投票。好的流程是：
- 定義問題和限制條件
- 列出選項（至少兩個）
- 團隊討論 pros/cons
- Tech Lead 做最終決定，並說明理由
- 記錄下來（ADR - Architecture Decision Record）
寫 ADR 不是官僚，是讓六個月後的你（和新人）知道當初為什麼選這個方案。
2. 帶人：Code Review 是最好的教學場景
Tech Lead 的帶人不是辦讀書會（雖然那也不錯），是在日常工作中讓人成長。
Code Review 的藝術：
| 不好的 review | 好的 review |
|---|---|
| 「這樣不對。」 | 「這邊用 X 會有 Y 問題，考慮用 Z 嗎？因為…」 |
| 只看 coding style | 看設計、可維護性、邊界情況 |
| 每個 PR 都改一堆 | 分清楚 must-fix 和 nice-to-have |
| 把 PR 當成展示自己多厲害 | 把 PR 當成教學機會 |
| 三天後才 review | 一個工作天內回覆 |
怎麼讓 Junior 成長：
- Pair programming：不是你寫他看，是他寫你引導
- 給適當挑戰的任務：太簡單沒成長，太難會挫折
- 允許犯錯：在安全的環境犯錯（staging、feature flag）
- 教方法而不是給答案：「你可以用 X 工具看看是什麼問題」而不是直接告訴他答案
- 定期 1:1：不只是問進度，是了解他卡在哪、想學什麼
Mentoring vs Managing：
| Mentoring | Managing | |
|---|---|---|
| 關注 | 個人成長 | 團隊產出 |
| 方式 | 引導和建議 | 指派和追蹤 |
| 頻率 | 按需 | 固定 |
| Tech Lead 的角色 | 主要是 Mentor | 部分 Manager（看組織） |
3. 溝通：最被低估的技能
Tech Lead 是技術和業務之間的翻譯者。
跟 PM/老闆溝通技術：
不要說：「我們需要重構這個 service，因為現在的架構用了 monolithic pattern，coupling 太高，沒有 proper separation of concerns。」
要說：「如果不整理這段程式碼，接下來每個新功能要多花 2-3 倍的時間開發，而且 bug 會越來越多。我建議花兩週時間整理，之後開發速度會快 30%。」
跟上層溝通的原則：
| 不要做的 | 要做的 |
|---|---|
| 說一堆技術名詞 | 用業務影響來說明 |
| 只說問題 | 帶著解決方案來 |
| 說「不可能」 | 說「可以，但需要 X 資源 / Y 時間」 |
| 等被問才說 | 主動同步風險和進度 |
| 私下抱怨 | 正式提出並推動改善 |
向上管理（Upward Management）：
這不是拍馬屁，是讓你的主管能幫你：
- 定期同步技術風險（不是出事了才說）
- 用數據說話（「這個技術債讓我們每個 sprint 多花 20% 時間修 bug」）
- 提出選項而不是問題（「我建議方案 A，因為…」）
- 知道你的主管在乎什麼（OKR？交付時間？品質？）
4. 取捨判斷：Perfect vs Good Enough
這可能是 Tech Lead 最難的技能。
什麼時候追求完美：
- 安全相關的程式碼（auth、加密、權限）
- API 介面設計（改了會 breaking change）
- 核心架構決策（影響未來一年的開發）
- 資料模型（schema 改了要 migration）
什麼時候 Good Enough 就好：
- 內部管理工具的 UI
- 一次性的 script
- 還在驗證的 feature（可能下週就砍了）
- 非關鍵路徑的最佳化
Technical Debt（技術債）的管理：
| 類型 | 範例 | 處理方式 |
|---|---|---|
| 刻意的 | 「先用 hardcode，下個 sprint 改」 | 記錄下來，排進 backlog |
| 意外的 | 「原來這個 library 有 bug」 | 評估影響，決定優先級 |
| 長期累積的 | 「這段 code 三年沒人動了」 | 碰到再改，不要沒事去重構 |
| 架構級的 | 「我們的 monolith 太大了」 | 需要正式的計畫和資源 |
好的 Tech Lead 不是追求零技術債（那不可能），是知道哪些債可以欠，哪些不能。就像個人財務，房貸可以，信用卡循環利息不行。
5. 架構 Ownership：負責但不獨裁
Tech Lead 是架構的 owner，但不是 gatekeeper。
Owner 和 Gatekeeper 的差別：
| Owner | Gatekeeper |
|---|---|
| 確保架構方向一致 | 所有設計都要我點頭 |
| 授權團隊做決策 | 只有我能做決策 |
| 出了問題一起解決 | 出了問題是你的問題 |
| 教團隊理解架構原則 | 建立只有自己懂的系統 |
| 歡迎挑戰和討論 | 不接受質疑 |
架構文件的最低要求：
你不需要寫 100 頁的架構文件。但至少要有：
- 系統架構圖：各 service 之間的關係（C4 Model 的 Level 2 就夠了）
- ADR（Architecture Decision Record）：重要的技術決策及理由
- Onboarding 文件：新人第一天需要知道的事
- API 文件：OpenAPI/Swagger，或至少 Postman collection
技術方向的守護：
- 定期 review 架構是否還符合需求
- 不要讓每個人用不同的 pattern（今天 MVC，明天 Clean Architecture，後天 DDD）
- 技術棧的變更要有好理由，不是因為「新的比較酷」
- 留意技術趨勢，但不要追每一個
6. 什麼時候該寫 code，什麼時候不該
Tech Lead 還是要寫 code，但不是所有 code 都該你寫。
應該寫的：
| 類型 | 為什麼 |
|---|---|
| Prototype / POC | 快速驗證技術方案是否可行 |
| 核心框架和 infra code | 影響全團隊的基礎設施 |
| 困難的 bug | 展示除錯方法論 |
| Pair programming | 教學目的 |
不應該寫的：
| 類型 | 為什麼 |
|---|---|
| 每個 feature | 你會變成瓶頸 |
| 別人可以做的 | 剝奪團隊成長機會 |
| 緊急的 hotfix（如果有人可以做的話） | 你應該在協調和溝通 |
| 追求「只有我才寫得好」 | 這是 ego，不是 leadership |
一個檢驗方法：
如果你不在的時候，團隊完全無法運作，那你沒有在做 Tech Lead 的工作，你只是在當最忙的工程師。好的 Tech Lead 讓團隊在自己不在時也能正常運作。
Junior 工程師 vs Tech Lead 的思維差異
| 面向 | Junior 思維 | Tech Lead 思維 |
|---|---|---|
| 看到 bug | 怎麼修 | 為什麼會發生？怎麼防止再犯？ |
| 新 feature | 怎麼實作 | 值不值得做？優先級？ |
| 技術選擇 | 什麼最新 | 什麼最適合我們 |
| code review | 有沒有 bug | 設計合不合理？可維護嗎？ |
| 時間壓力 | 加班趕完 | 調整 scope 或 deadline |
| 溝通 | 完成了通知 PM | 主動同步風險和進度 |
| 成功定義 | 我寫的 code 被 merge | 團隊交付了好的產品 |
FAQ
Q1: Tech Lead 和 Engineering Manager 有什麼不同？
Tech Lead 偏技術決策和技術帶人，Engineering Manager 偏人事管理（hiring、performance review、career development）。有些公司兩個角色是同一個人，有些分開。如果你不喜歡處理人事問題，Tech Lead 可能更適合你。
Q2: 當 Tech Lead 薪水比較高嗎？
在台灣，Tech Lead 的薪水通常比 Senior 高 10-20%，但不是大幅跳升。真正的薪水差異在 Engineering Manager 或 Principal Engineer 等級。Tech Lead 的價值在於影響力和成長機會，不純粹是薪水。
Q3: 當了 Tech Lead 技術會退步嗎？
如果你完全不寫 code，會。所以要保持一定比例的 coding（大概 30%）。但你的技術成長方向會改變：從「寫更好的 code」變成「做更好的技術決策」。你會對系統有更全面的理解。
Q4: 不想管人但想繼續走技術，有什麼選擇？
Individual Contributor（IC）路線：Senior → Staff → Principal → Distinguished。這條路線在大公司（Google、Meta、Amazon）很成熟。你不用管人，但影響力要到技術組織層面。在台灣，這條路線的機會相對少。
Q5: 怎麼知道自己適不適合當 Tech Lead？
問自己幾個問題：
- 你願意花時間幫別人解問題，即使自己做更快嗎？
- 你願意在會議中翻譯技術語言嗎？
- 你願意做決策並承擔後果嗎？
- 你能接受「團隊成功」比「個人產出」更重要嗎？
如果大部分答案是 yes，你可能適合。
系列導航
- [01] 好的前端工程師需要什麼能力？
- [02] 好的後端工程師需要什麼能力？
- [03] DevOps 工程師需要什麼能力？
- [04] 好的全端工程師：廣度和深度怎麼平衡？
- [05] 好的 Tech Lead 需要什麼？ ← 你在這裡
- [06] Junior 和 Senior 的真正差距