為什麼要投資團隊成長#
Yishan Wong（前 Reddit CEO、Facebook 工程主管）的思想實驗： 「想像你有一支魔杖，揮一揮就能讓公司裡每個人都把工作做到 120%。會發生什麼事？ 公司會大成功，而你什麼也不必做，就會被這股成功的浪潮一起捲上去。」
他的結論：個人職涯成功的祕訣，是讓身邊的人成功。
Benchmark Capital 共同創辦人 Andy Rachleff 也在史丹佛課堂上說：「身處成功公司的人，得到的功勞多於自己應得；身處失敗公司的人，得到的功勞少於自己應得。」 你的成功很大程度繫於公司／團隊的成功，而非單純的個人貢獻。
職涯階梯的本質：影響的範圍#
Etsy 與 Stripe 工程副總 Marc Hedlund 對工程職級的精煉描述：
職級名稱 影響範疇 核心價值 資深工程師 (Senior) 個人與任務 能獨立解決複雜問題 主任工程師 (Staff) 整個團隊 讓整個團隊比沒有你時更好 首席工程師 (Principal) 整間公司 讓整間公司比沒有你時更好 傑出工程師 (Distinguished) 整個產業 對整個產業產生改進
職級越高，衡量的不再是個人貢獻，而是「對周圍人的影響力」。 即使你不是主管或資深工程師，仍能透過參與招聘、入職、文化建設來提升團隊強度。
1. 讓招聘成為每個人的責任#
招聘表面上很瑣碎，但若一場面試能多招到一位優秀工程師，他一年能貢獻 2,000+ 小時的產出——這比你花 40 小時面試的回報率遠遠更高。
Dropbox 早期工程師 Albert Ni 在公司 30 人時，從工程轉向專職招聘：標準化面試、籌備校園招募、與每位候選人對話。幾年後 Dropbox 工程團隊成長 5 倍。
面試的兩個目標#
- 篩選（Screen）：找出能在團隊中表現出色的人
- 行銷（Excite）：讓候選人對團隊、使命、文化興奮——即使最後沒錄取，也願意推薦朋友來面試
高訊噪比的策略#
面試官的目標是優化 訊噪比（Signal-to-Noise Ratio）：每分鐘獲得最多有用資訊。
| 面向 | 策略 | 細節 |
|---|---|---|
| 面試設計 | 定義關鍵特質 | 程式能力、溝通技巧、文化契合度由不同面試官覆蓋 |
| 題目準備 | 多層次問題 | 可變更難度的題目，視候選人程度調整變數或限制條件 |
| 流程控管 | 維持節奏 | 適時提示、切換問題，避免離題或卡住 |
| 風險偵測 | 短答快掃 | 用語言特性、核心庫原理等短答題快速確認知識廣度 |
| 團隊校準 | 面試配對（Shadow） | 定期共同面試，互相校準評分標準並交換回饋 |
從白板題到實作題的趨勢#
許多公司已超越傳統白板演算法題，加入動手實作：
- Quora：實作環節讓候選人在筆電上 debug、擴展真實開源 codebase，可使用 Google、Stack Overflow
- Stripe：題目模擬日常工作——設計小型端對端系統、修 Bug、重構糟糕的應用、Pair Programming
- Ooyala：限時實作 Tetris，測管理專案與技術取捨
- Airbnb：至少兩場面試專門評估文化契合
2. 設計優良的入職流程（Onboarding）#
作者在 Ooyala 第一週的入職體驗：CTO 一句「Sink or swim」加兩週 80 小時工時的緊急功能交付，全靠在充滿
qqq、load2命名的程式碼中自我摸索。 雖然順利上手，但這種設計對團隊長期成長毫無幫助。
好的入職投資具高槓桿：
- 新人能更快產出
- 養成正確的文化認知與工程習慣
- 投入導師的人也能釋出較低槓桿的任務給新人，自己做更高槓桿的事
- 一次性建立的教材，後續每一位新人都會受益
Quora 的入職計畫四大目標#
| 面向 | 目標 | 重點 | 預期回報 |
|---|---|---|---|
| 效率提升 | 快速上手（Ramp up） | 短期犧牲導師生產力，加速新人學習曲線 | 越快上手回報越早 |
| 文化傳承 | 傳承文化 | 深入學習並認同團隊共享價值觀 | 建立凝聚力 |
| 技能奠基 | 掌握基礎 | 傳授每位工程師都必須具備的關鍵知識與工具 | 確保交付品質 |
| 網絡建立 | 社交融入 | 儘早建立協作關係，避免新人成為社交孤島 | 強化團隊協作 |
入職計畫的四大支柱#
- Codelabs：以文件解釋每個核心抽象的設計理念，加上實作練習驗證理解（作者親自先寫第一份示範，再讓其他人補上）
- 入職講座（Onboarding Talks）：由資深工程師講解 codebase、架構、開發工具、團隊規範與價值觀
- 導師制度（Mentorship）：一對一指導。建立共識：帶人比寫自己的程式更高優先，導師應毫無壓力地把時間花在 mentee 身上
- 入門任務（Starter Tasks）：第一週就要交付一個小 Bug 修復、小功能或實驗——強迫團隊降低新人開始貢獻的摩擦
3. 共享程式碼所有權（Shared Ownership）#
作者在 Ooyala 度假時被 CTO 簡訊：「Logs processor down.」——只有他懂這個系統。整整一天的時間，他在火山健行卻心懸異常。 度假被破壞、團隊靠他、客戶當天看不到分析報表，沒有人是贏家。
「成為某專案唯一的負責工程師會增加個人價值」是錯誤觀念——這只會讓你成為瓶頸，被綁在維護工作上，無法抽身去做更高槓桿的事。
巴士指數（Bus Factor）#
從公司角度，共享所有權能把巴士指數從 1 拉到更高：「任何一件事都能由多人完成」。 Facebook 工程總監 Nimrod Hoofien 稱之為 工程師的可互換性（Fungibility）——它帶來開發自由度、On-call 彈性，並避免任何一人扛下不愉快的維護重擔。
提升共享所有權的做法#
- 避免單人團隊
- 互相 Review 程式碼與設計
- 輪替不同任務與責任
- 保持程式碼可讀性與品質
- 用內部技術分享講解架構決策
- 撰寫高層設計文件與必要的程式碼註解
- 紀錄複雜工作流程與特殊解法
- 投資時間教學與帶人
4. 透過事後檢討累積集體智慧#
NASA 把每次模擬與任務後的檢討制度化：4 小時模擬後跟 1 小時 debrief；一次太空飛行後可能要 debrief 整整一個月以上。
累積的所有教訓寫進《Flight Rules》——數千個情境的標準作業流程，包含「為什麼」要這樣做。 冷卻系統故障？翻 Flight Rules 一步步處理；燃料電池異常？Flight Rules 告訴你發射要不要延後。
工程上的事後檢討#
每次重大事故、嚴重 Bug、基礎設施問題後，高效團隊都會做 事後檢討（Post-mortem）：
| 要素 | 觀念 | 方法 | 目標 |
|---|---|---|---|
| 核心目的 | 無責備原則（Blameless） | 嚴禁指責特定個人，否則會扼殺透明的技術討論 | 建立安全的檢討文化 |
| 分析方法 | 5 個為什麼（5 Whys） | 採用 Toyota 生產模式方法論，層層挖掘根本原因 | 找出系統性缺陷 |
| 行動導向 | 預防再犯 | 把焦點從「誰犯錯」轉到「系統如何失效」，並定下改進措施 | 提升系統穩健性 |
事後檢討不應只用於故障——成功與失敗的專案也要 debrief。 Amazon 和 Asana 都用「5 Whys」追根究柢；不只看故障，也看「我們花了三個月做的功能，是否真的達到原本的目標？」。
老老實實討論失敗很不舒服，但若一場 1 小時的對話能讓下一個月的專案增加成功機率，那它就是極高槓桿的活動。
5. 建立卓越的工程文化#
作者面試 500+ 候選人時習慣問：「你最喜歡和最不喜歡你前任公司的工程文化哪一點？」 數百次累積下來，他歸納出卓越工程文化的十項特徵——也正好對應這本書其他章節的高槓桿活動：
- 致力於加速迭代（Iteration speed）
- 無情自動化（Automation）
- 建立正確的軟體抽象
- 透過 Code Review 維持高品質
- 維持互相尊重的工作環境
- 共享程式碼所有權
- 投資自動化測試
- 保留實驗時間（20% 時間、Hackathon）
- 培養學習與持續改進的文化
- 招募最好的人
文化並非一蹴可幾，而是隨著早期成員的價值觀，再隨每位加入者的決定與故事共同形塑。 當我們專注於高槓桿活動時，我們就是在為卓越的工程文化奠基。
重點摘要（Key Takeaways）#
- 讓身邊的人成功：高階工程職級獎勵那些讓同事更有效能的人
- 把招聘當作優先要務：守住面試標準，主動參與招募
- 投資入職與導師制：團隊越強，你越有自由選擇高槓桿的事
- 共享程式碼所有權：別讓自己變成瓶頸
- 事後檢討、寫下集體智慧：把失敗與成功都轉化為團隊資產
- 打造卓越工程文化：對招募、留才與決策都帶來複利效應