「Empowered engineers are the single most important thing that you can have in a company.」
「賦能型的工程師，是公司能擁有的最重要的單一要素。」
——比爾・坎貝爾（Bill Campbell）
若全書你只能帶走一個概念#
在你通往賦能團隊的旅程中，若作者只能挑一個希望你銘記於心的概念，會是「賦能型工程師」。
當然這不是全部——非凡產品來自產品團隊。但作者相信這是最重要的單一成分。
作者本可以圍繞這個概念寫整本書#
| 概念 | 為何與「賦能工程師」連動 |
|---|---|
| 創新最佳源頭 | 工程師每天都在用基礎技術——他們最了解「現在做得到什麼」 |
| 產品願景 | 用來吸引並激勵工程師 |
| 產品策略 | 確保工程師在解決最重要的問題 |
| 團隊目標 | 給工程師清楚的問題與要追求的結果 |
| PM 與設計師 | 提供商業可行性與顧客體驗的關鍵限制 |
| 使用者研究與資料科學 | 提供關鍵洞察 |
「賦能」不是什麼#
「讓工程師決定怎麼寫程式碼」不是賦能。當然要他們決定怎麼實作。
「讓工程師決定架構」也不是賦能。當然要他們決定架構。
真正的賦能：給工程師問題與策略脈絡，讓他們用技術找出對問題的最佳解法。
簡單的測試#
若你的工程師第一次看到產品點子是 sprint planning——你毫無疑問是功能團隊，工程師沒被賦能。
若你只用工程師「寫 code」，你只拿到他們一半的價值。
不要外包工程師#
強的科技驅動產品公司外包工程師的可能性，與外包 CEO 一樣低。
最佳科技公司：
- 有 dual-track career ladder（雙軌職涯階梯）是有原因的
- 頂尖工程師的薪酬通常達副總（VP）等級
工程師是判斷一家公司是「傳教士團隊」還是「傭兵團隊」最簡單的方法。
不是把工程師捧上神壇#
工程師是普通人，跟我們所有人一樣。但請把他們當成「他們所在的產品團隊的一級成員」。
想想你每天用且喜愛的突破性創新——它們很可能源自一位賦能工程師、在賦能團隊中工作的成果。
常見阻力：「我的工程師只想寫程式」#
太多 PM 會抗拒，說：「我的工程師對什麼都沒興趣，只想寫程式。」
這是「不理解賦能團隊」的人最常見的藉口——作者在問「為何工程師不參與探索」時無數次聽到。
真相通常是#
當作者堅持直接和工程師談時，他發現：
工程師最常抱怨的是「太晚被拉進來、被迫處理後果」。
真正發生的是：PM 不希望工程師被納入，因為她寧可工程師花時間寫程式。
這是「過度熱心的 PM——比起 PM 更像 PM 經理」只聽自己想聽的、或根本不在乎要問。
真的有「只想寫程式」的工程師#
偶爾工程師也真的這樣告訴作者——「我們偏好寫程式，建什麼都行」。
此時作者會問：他們上次和顧客見面是什麼時候？
答案通常介於「很久以前」到「從來沒有」。
但若真的沒有任何一位工程師對 coding 以外的事感興趣——
作者會把對話轉到工程主管：「你有的是傭兵，不是傳教士；你必須拉高雇用工程師的標準。」
每個產品團隊至少要有一位真正的 tech lead——產品探索是 tech lead 的重要責任之一。
結語#
若你身為產品領導者，這件事就算其他什麼都沒做——也意味著你已在「使用技術」、「走向賦能團隊」、「給自己持續創新的真實機會」上有了實質前進。