How to Lead a Team

本章概覽#

沒有任何團隊能在缺乏領導者的情況下順利運作。在 Google，工程開發幾乎完全是團隊協作，因此領導力至關重要。一艘沒有船長的船只是一間漂浮的候機室——除非有人抓住舵、發動引擎，否則只會隨波逐流。軟體專案也是如此：如果沒有人駕駛，你只會剩下一群工程師空轉，等著事情發生。

本章探討如何從個人貢獻者（Individual Contributor）轉型為領導者，以及如何運用僕人式領導（Servant Leadership）的原則——謙遜（Humility）、尊重（Respect）、信任（Trust）——來帶領團隊走向成功。

即使你是個人貢獻者而非管理者，本章仍然值得一讀，因為它能幫助你更好地理解你的領導者。

管理者與技術負責人#

Google 區分兩種不同的領導角色，各自需要截然不同的人際技能。有時是資深管理者空降帶團隊，有時是個人貢獻者被拔擢到領導職位（通常是較小的團隊）。

Engineering Manager（工程管理者）#

負責團隊中每個人的績效、生產力與幸福感，同時確保產品滿足業務需求
許多公司會請完全不懂軟體工程的專業管理者來帶工程團隊，但 Google 很早就決定：工程管理者必須具備工程背景——要麼是轉任管理的資深工程師，要麼是受過管理訓練的工程師
業務需求與個人需求不一定一致，管理者經常要在兩者之間取得平衡，這使得這個角色充滿挑戰

Tech Lead（技術負責人，TL）#

負責產品的技術面向：技術決策、架構、優先順序、開發速度與專案管理
通常向 Engineering Manager 匯報，與其密切合作以確保團隊人力配置合理、工程師的任務與技能匹配
大多數 TL 同時也是個人貢獻者，因此經常面臨抉擇：自己快速完成，還是委派給團隊成員（較慢但有助於團隊成長）
隨著團隊規模和能力的擴展，選擇委派通常是更正確的決定

Tech Lead Manager（TLM）#

在小型或新成立的團隊中，一個人同時扮演管理者和技術負責人的雙重角色
通常由原本的個人貢獻者擔任，而非資深管理者
需要平衡個人工作、委派任務和人員管理三者，難度極高
Google 建議新任 TLM 參加公司提供的相關課程，並尋找資深 mentor 定期指導
在較大且成熟的團隊中，Google 傾向讓 TL 和 Engineering Manager 分工合作——理論是同時做好兩個角色極為困難，與其一個人勉強兼顧，不如兩位專家各自全力發揮

案例：無權威的影響力（Influence Without Authority）
讓你管轄範圍內的人完成工作相對容易，但要讓組織外部的人配合你，則需要「無權威的影響力」——這是最強大的領導特質之一。
Jeff Dean 在 Google 內部只直接管理一小部分工程團隊，但他對整個工程組織的技術決策和方向有著深遠的影響力（也透過寫作和演講影響了公司外部）。
Data Liberation Front 團隊不到六名工程師，卻成功推動超過 50 個 Google 產品透過 Google Takeout 匯出資料——當時高層並沒有正式要求所有產品加入 Takeout。他們的做法是：辨識公司的策略需求、將其連結到公司使命與既有優先事項、開發一個讓其他團隊能快速輕鬆整合的工具。

從個人貢獻者到領導者的轉變#

無論是否正式被任命，總得有人坐上駕駛座。你可能從未打算成為「領導者」，但不知不覺中開始幫團隊化解衝突、做決策、協調人力——有人把這稱為「管理炎」（manageritis）。

為什麼人們抗拒成為管理者#

寫程式的時間大幅減少——身為工程師，每天結束時你能指著程式碼說「這是我今天的成果」；但管理工作的產出難以量化，就像你從數蘋果的工作換到種香蕉的工作，每天結束時卻對自己說「我今天一顆蘋果都沒摘」，完全忽略了旁邊茂盛的香蕉樹。管理工作的回報週期通常更長，不要用數蘋果的方式來衡量種香蕉的成效。
彼得原理（Peter Principle）——「在階層體制中，每個人都會晉升到自己無法勝任的層級。」多數人都曾遇過不稱職的管理者，如果你整個職涯只遇過差勁的管理者，自然不會想成為其中之一。Google 的對策是要求一個人在晉升前，先在較高層級的崗位上表現出色一段時間（即在當前層級「超越期望」）。
糟糕管理者的陰影——如果你只被差勁的管理者帶過，為什麼會想被晉升到一個你覺得自己做不好的角色？

為什麼仍值得考慮#

規模化自己的影響力：再厲害的工程師也有個人產出的上限，但想像一下一整個優秀工程團隊在你的領導下能產出多少
你可能天生擅長：很多人在被推進領導真空後才發現自己有出色的領導天賦——擅長提供指引、幫助和為團隊撐起保護傘
有人必須領導，為什麼不能是你？

如果你想要為專案掌舵而非隨波逐流，你需要知道如何航行，否則你會把自己（和專案）擱淺在沙洲上。

僕人式領導（Servant Leadership）#

有一種「疾病」似乎會侵襲新任管理者——他們忘了自己的管理者對他們做過的那些糟糕事情，然後開始對自己的下屬做同樣的事。症狀包括但不限於：微管理、忽視低績效者、僱用唯命是從的人。不及時治療，這種病可以殺死整個團隊。

Google 工程總監 Steve Vinter 對新任管理者的忠告：「最重要的是——抵抗那種想要管理的衝動。」 新任管理者最大的衝動就是積極地去「管理」員工，因為那是管理者該做的事，對吧？這通常會帶來災難性的後果。

僕人式領導的核心理念是：領導者最重要的工作是服務團隊，就像管家照顧一個家庭的健康和福祉一樣。具體做法包括：

移除團隊成員無法自行排除的官僚障礙
協助團隊達成共識
在團隊加班時買晚餐
填補團隊的裂縫、必要時提供建議，但不怕親自動手做髒活

僕人式領導同時管理團隊的技術健康和社交健康。雖然專注於技術面很誘人，但社交健康同樣重要，而且通常更難管理。

管理者的角色演變#

「Manager」是個四字髒話#

現今「manager」這個頭銜的概念部分承襲自軍事階層，後來被工業革命採用。工廠需要主管來監督（通常非技術性的）工人，因為這些工人容易被取代，管理者幾乎沒有動力善待他們。管理者用「胡蘿蔔加棍子」（carrot and stick）的方式對待員工，就像趕車的人對待騾子一樣。

這種方式從工廠存續到現代辦公室，至今仍存在於某些需要創造力的產業中——儘管大量研究顯示，這種過時的方法對創意工作者的生產力不僅無效且有害。裝配線上的工人幾天就能訓練好並隨時替換，但在大型程式碼庫上工作的軟體工程師可能需要數月才能融入新團隊。這些人需要培育、時間和思考創造的空間。

現代工程管理者#

「Manager」這個頭銜本身就容易鼓勵新任管理者去「管理」他們的下屬。管理者可能不自覺地像父母一樣行事，員工也會相應地表現得像小孩。

本章最重要的一句話：
傳統管理者擔心的是如何完成事情（how to get things done）；而優秀的管理者擔心的是完成什麼事情（what things get done），並信任團隊自己找出方法。

書中以新工程師 Jerry 的故事為例：Jerry 的前任主管堅持他每天 9 點到 5 點必須坐在座位上，如果不在就等於沒在工作。Jerry 到新團隊的第一天，下午 4:40 結巴地道歉說他必須提前 15 分鐘離開去赴約。新主管（作者）直接告訴他：「只要你把工作完成，我不在乎你幾點離開辦公室。」

Jerry 被當成成年人對待，一直表現出色，從不需要保姆。如果員工需要傳統管理者式的監督才願意工作，那才是真正需要解決的問題。

失敗是一種選項（Failure Is an Option）#

催化團隊的另一種方式是建立心理安全感（Psychological Safety），讓團隊成員感覺可以做自己，不怕來自你或隊友的負面反應，從而願意承擔更大的風險。

大多數人不擅長評估風險，大多數公司也盡可能避免風險
Google 的信念：嘗試不可能的目標，即使失敗，通常也比只追求你知道能達成的目標走得更遠
培養接受冒險的文化，首先要讓團隊知道：失敗是可以的

不同類型的失敗有不同的學習價值：

快速失敗（Fail Fast）：代價低，因為投入的還不多
緩慢失敗：更痛苦，因為風險和損失（通常是工程時間）更大
影響客戶的失敗：最不理想，但 Google 有最完善的結構來從中學習——每次重大生產故障都會執行 Postmortem，記錄導致故障的事件、制定防止復發的步驟，重點不是指責而是聚焦於問題核心並徹底修復

個人成功可以在團隊面前公開表揚；個人失敗應該私下給予建設性回饋。公開批評不僅無效（讓人防禦），而且幾乎都是多餘且殘忍的。以團隊為單位面對失敗，並運用謙遜、尊重和信任從中學習。

反模式（Antipatterns）#

反模式一：僱用唯命是從的人（Hire Pushovers）#

如果你在管理角色中缺乏安全感，一種確保沒人質疑你或威脅你地位的方式就是僱用你能推著走的人——不如你聰明、不如你有野心、或比你更沒安全感的人。這雖然能鞏固你的地位，但代價是：

團隊沒有你就動不了
你休假時生產力歸零
你要做更多工作來帶領他們

正確做法：僱用比你聰明、能取代你的人。他們會經常挑戰你（也會在你犯錯時告訴你），但他們也會持續做出令你驚豔的成果。他們能更大程度地自主工作，有些人甚至渴望領導團隊。不要把這看作對你權力的篡奪——這是你去帶領另一個團隊、探索新機會、甚至放心去度假的機會。被比你聰明的人包圍，也是拓展自己專業知識的好方式。

反模式二：忽視低績效者（Ignore Low Performers）#

作者在 Google 剛當管理者時，發獎金信時開心地說「我愛當管理者！」他的主管（資深業界老手）立刻回道：「有時你是牙仙，有時你得當牙醫。」

Google SRE 團隊的座右銘：「希望不是策略。」（Hope is not a strategy.）在處理低績效者這件事上，「希望」被濫用得最厲害
大多數領導者咬緊牙關、別過頭去，希望低績效者奇蹟般地改善或自行離開——但這極少發生
當領導者在「希望」、低績效者沒有改善時，高績效者正在浪費寶貴時間拖著低績效者前進，團隊士氣不斷流失
團隊成員絕對知道誰是低績效者（即使你假裝沒看到），因為他們必須扛這些人的份
忽視低績效者不僅阻止新的高績效者加入，也促使現有高績效者離開，最終團隊只剩下無法自行離開的低績效者
你也沒有在幫低績效者的忙——他們在你的團隊表現不好，但在別處可能大有發揮

正確做法——輔導低績效者：

想像你在幫一個跛腳的人重新學走路、慢跑、然後跟上團隊的步伐
設定明確的時間框架（例如兩個月）和具體、漸進式、可衡量的小目標，製造大量小成功的機會
每週面談追蹤進度，設定非常明確的里程碑期望，讓成功或失敗一目瞭然
如果跟不上，雙方都會很快看到，當事人通常會自行承認問題並決定離開；或者鬥志被激發，表現達到期望
關鍵在於盡早處理——等太久會讓關係惡化到你已經太沮喪而無法幫助他們

反模式三：忽視人際問題（Ignore Human Issues）#

管理者有兩大關注面向：社交面與技術面。Google 的管理者多從技術崗位晉升，在學生時代所有課程都是學技術，容易只關注技術面而忽略人的因素。

書中以 Jake 和 Pablo 的故事為例：Jake 剛有新生兒，與同事 Katie 在家遠端工作多年且生產力不減，Katie 也完全能接受。但在另一間辦公室的管理者 Pablo 發現後很不滿，堅持 Jake 必須進辦公室，Jake 嘗試解釋但 Pablo 的回應是：「老兄，大家都在生小孩，你需要進辦公室。」Jake 因此對 Pablo 失去了大量尊重。

Pablo 有很多更好的處理方式：如果 Jake 的生產力和團隊沒有受影響，就讓他繼續在家工作一陣子；或協商每週進辦公室一兩天。一點點同理心就能讓結果截然不同。

反模式四：當所有人的好朋友（Be Everyone’s Friend）#

大多數人第一次進入領導角色是成為原本所在團隊的管理者或 TL。很多人不想失去與團隊培養的友誼，因此格外努力維持。這可能導致災難和大量友誼破裂。

不要混淆友誼和溫和的領導風格——當你握有影響他人職涯的權力時，對方可能會被迫回應友善的姿態
可以在不成為密友或嚴厲暴君的情況下帶領團隊、建立共識
一起吃午餐是維持社交連結的好方式——在非正式環境中進行非正式對話，而不讓人感到不自在
如果你要管理原本的好朋友，且對方不善於自我管理或不是努力工作的人，情況會對所有人都很有壓力。盡量避免這種狀況，若無法避免，要格外注意這段關係

反模式五：降低招聘標準（Compromise the Hiring Bar）#

Steve Jobs 曾說：「A 級人才僱用 A 級人才；B 級人才僱用 C 級人才。」

一個常見的做法是：團隊需要招 5 位工程師，面試了 40-50 人，然後挑最好的 5 個——不管他們是否達到招聘標準。這是打造平庸團隊的最快途徑。

找到對的人的成本（招聘人員費用、廣告費、人脈介紹）遠低於處理不適任員工的成本——後者包括：

團隊生產力損失
團隊壓力
花時間輔導或開除的行政負擔
以上還是假設你嘗試處理的情況；如果只是放著不管，成本更高

如果你無法控制招聘決策卻對品質不滿意，要據理力爭。如果仍然被塞進不合格的工程師，也許該考慮換個地方了。沒有好的原料，就無法打造好的團隊。

反模式六：把團隊當小孩（Treat Your Team Like Children）#

展示你不信任團隊的最好方式就是把他們當小孩或囚犯對待——人們傾向於以你對待他們的方式行事。微管理或不尊重他們的能力，不給他們為自己的工作負責的機會，他們就會表現得像小孩。

如果你僱用了值得信任的人並展現信任，他們通常會不負所望。如果永遠需要微管理，那是招聘上的失敗。

Google 的例子：辦公室文具和各種用品自由取用，IT 部門設有 Tech Stop（自助式電子配件區），充滿電源線、滑鼠、USB 隨身碟等，員工自行借用。很多傳統企業聽到這個都大驚失色，認為一定有人「偷竊」。也許吧，但讓整個員工隊伍表現得像小孩、或浪費寶貴時間走正式流程申請幾支筆和 USB 線的成本，肯定更高。

正面模式（Positive Patterns）#

放下自我（Lose the Ego）#

這個模式常被誤解為鼓勵人當門墊，讓別人踩著走，但完全不是。謙遜不等於缺乏自信——你可以有自信和見解而不自大。謙遜和被人佔便宜之間有一條細線，但兩者並不相同。

大的個人自我在任何團隊都難以處理，尤其是在團隊的領導者身上。應該培養強大的團隊集體認同和自我意識
放下自我的一部分是信任：尊重團隊成員的能力和過去的成就，即使他們是新加入的
一線工作的人通常比你更了解細節。你負責驅動團隊走向共識、設定方向，但具體如何實現目標應由實際建構產品的人來決定。這不僅給他們更大的擁有感，也讓他們對成功（或失敗）承擔更大的責任感
不要假裝什麼都知道、什麼都對——你不可能，而且如果你裝出這樣的姿態，很快就會失去團隊的尊重
歡迎質疑：有人質疑你的決定時，他們通常只是想更好地理解你。鼓勵質疑能讓你得到建設性批評，而能給你好的建設性回饋的人非常稀有，更何況是「為你工作」的人
犯錯時誠心道歉：你一定會犯錯，不管你承不承認，團隊都看得到。道歉不花錢，也不會讓你變得脆弱——相反地，人們對願意在犯錯時道歉的領導者有巨大的尊重

成為禪師（Be a Zen Master）#

身為工程師，你可能培養了出色的懷疑和憤世嫉俗能力，但這在帶領團隊時可能成為負債。你不需要天真地樂觀，但應該少一些明顯的懷疑，同時讓團隊知道你了解工作中的複雜性和障礙。

你的反應會被團隊放大。 想像組織圖是一串齒輪：個人貢獻者是最小的齒輪，每一級管理者是更大的齒輪，CEO 是最大的。當你的「管理者齒輪」轉一圈，下面「個人齒輪」可能轉兩三圈。CEO 的一個小動作，可以讓末端六七層齒輪下的員工瘋狂旋轉。

領導者永遠在舞台上。 不只是在開會或演講時——即使你坐在桌前回信，同事也在觀察你的肢體語言、閒聊時的反應、吃午餐時發出的訊號。他們在你身上讀到的是信心還是恐懼？作為領導者，激勵是全年無休的工作。

Google 早期管理者之一、工程副總裁 Bill Coughran 真正掌握了在任何時候保持冷靜的能力。無論什麼爆炸、什麼瘋狂的事發生、多大的風暴，Bill 永遠不會慌張。他通常會把一隻手臂橫在胸前、用手托著下巴，然後對通常已經完全恐慌的工程師提問。這能讓他們冷靜下來、專注於解決問題。有人開玩笑說，如果有人進來告訴 Bill 公司 19 間辦公室被外星人攻擊了，Bill 的回應會是：「知道為什麼沒湊成整整 20 間嗎？」

用提問代替直接給答案。 當團隊成員尋求建議時，你通常會興奮地跳進「解決方案模式」——這是你擔任領導職之前多年來一直在做的事。但這是你最不應該去的地方。尋求建議的人通常不是要你替他們解決問題，而是要你幫他們自己解決。最簡單的方式就是提問，幫助他們細化和探索問題。這通常會引導員工自己找到答案——而且那是他們的答案，這又回到了先前討論的擁有感和責任感。無論你是否知道答案，這個技巧幾乎總會讓員工覺得你確實幫了忙。蘇格拉底會為你感到驕傲的。

成為催化劑（Be a Catalyst）#

在化學中，催化劑加速反應但本身不被消耗。催化劑（如酶）的一種運作方式是讓反應物靠近彼此——與其在溶液中隨機碰撞，不如催化劑幫它們靠近以增加有利互動的機率。身為領導者，你經常需要扮演這樣的角色。

建立共識（Build Consensus）是最核心的催化手段——你可以從頭到尾驅動整個過程，也可以只是在正確的方向上輕推一把
建立共識是一種無需正式權威就能領導的方式，因此常被非正式領導者使用
如果你有權威，可以直接指揮和下令，但這遠不如建立共識有效
當團隊需要快速行動時，有時會自願將權威讓渡給一兩位 TL。雖然看起來像獨裁或寡頭，但如果是出於自願，本身就是一種共識
注意：追求 100% 共識也可能有害，你需要在不是所有人都同意或仍有不確定性時也能推進

移除路障（Remove Roadblocks）#

有時團隊已經有共識知道該做什麼，但撞上了技術或組織上的路障而卡住。有些對團隊成員幾乎無法跨越的障礙，對你來說可能輕而易舉。讓團隊知道你願意且能夠幫忙處理這些路障是很有價值的。

書中舉了三個例子：

一個團隊花了數週試圖與法務部門溝通，管理者介入後不到兩小時就解決了——因為他認識該聯繫的人
一個團隊需要伺服器資源卻無法取得，管理者透過與其他團隊的關係，當天下午就搞定了
一位工程師卡在一段深奧的 Java 程式碼上，管理者雖非 Java 專家，但能把他引薦給懂的人

你不需要知道所有答案，但通常需要知道誰知道答案。在很多情況下，認識對的人比知道對的答案更有價值。

成為老師與導師（Be a Teacher and a Mentor）#

身為 TL，最困難的事之一是看著資淺成員花 3 小時做你 20 分鐘能完成的事。給人學習的機會一開始很痛苦，但這是有效領導的重要組成部分——尤其對新成員而言，他們不僅在學習技術和程式碼庫，也在學習團隊文化和適當的責任水準。好的 mentor 必須在 mentee 的學習時間和貢獻時間之間取得平衡。

好的 mentor 需要三件事：

對團隊流程和系統的經驗
向他人解釋事物的能力
判斷 mentee 需要多少幫助的能力——這可能是最重要的。給予足夠的資訊是你該做的，但如果過度解釋或滔滔不絕，mentee 可能會直接關機而非禮貌地告訴你他們已經懂了

設定清晰目標（Set Clear Goals）#

這聽起來理所當然，卻被大量領導者忽略。把產品想像成一輛大卡車，每個團隊成員手中都有一條繩子綁在車頭。如果你希望卡車盡快往北走，就不能讓成員各拉各的方向——你要他們全部往北拉。

為團隊建立簡潔的使命宣言（Mission Statement）
設定清晰的優先順序，幫助團隊在需要取捨時做出決策
目標清晰後，你可以退後一步給予更多自主權，定期檢查方向即可
這不僅解放你的時間去處理其他領導任務，也大幅提升團隊效率
團隊可以在沒有清晰目標的情況下成功，但通常會浪費大量能量在各自拉扯方向上

保持誠實（Be Honest）#

你不可避免地會遇到無法告訴團隊某些事、或必須說出他們不想聽的話的時刻。

可以說**「我知道但不方便透露」或「我不知道」**——承認不知道不代表軟弱或脫節，只代表你是人
很多管理者覺得如果不知道答案就證明自己不稱職，但事實上唯一證明的是他們是人

給予嚴厲的回饋很難。 大多數管理教科書建議使用「讚美三明治」（Compliment Sandwich）來軟化打擊：

讚美三明治的例子：
「你是團隊的中堅、最聰明的工程師之一。不過你的程式碼太複雜，其他人幾乎看不懂。但你很有潛力，而且 T-shirt 收藏超酷。」
大多數人走出會議只會想：「太棒了，我的 T-shirt 很酷！」——關鍵訊息完全被忽略。

作者強烈建議不要用讚美三明治——不是因為你應該殘忍，而是因為大多數人不會聽到需要改變的核心訊息。可以在傳遞建設性批評時保持善意和同理心，而不訴諸讚美三明治。善意和同理心是確保接收者聽到批評而非立刻防禦的關鍵。

書中以兩個案例說明直接回饋的效果：

Tim：前任主管用讚美三明治，Tim 從未改善。新主管直接清楚說明「你與團隊的互動方式正在疏遠和激怒他們，如果你想有效工作，需要改進溝通技巧，我們致力於幫你」。幾週內 Tim 表現大幅進步——他只是需要非常清晰的回饋和方向
Dean：對一切都要爭論。管理者 Ben 用了「火車」的比喻：每 15 分鐘一班火車經過，如果你每班都擋，不僅浪費精力，最終有人會直接輾過你——挑選真正重要的火車去擋就好。這個比喻注入了幽默，也讓 Dean 和 Ben 更容易討論問題

追蹤幸福感（Track Happiness）#

讓團隊更有生產力（且更不容易離開）的長期方法之一，是花時間了解他們的幸福感。最好的領導者都是業餘心理學家。

具體做法：

列出所有枯燥、無人感謝的任務，確保這些任務在團隊中公平分配
注意工時，用補休和有趣的團隊活動避免 burnout
在一對一會議中先處理技術問題以破冰，然後確認工程師是否擁有完成工作所需的一切
在每次一對一結束時問：「你需要什麼？」——這個簡單的問題能確保每個人有足夠的資源。持續問下去，團隊成員最終會主動帶著需求清單來找你
讓 reports 用 1 到 10 分評價自己的幸福感，以此開啟關於工作內外幸福感的對話

注意不要假設人們工作以外沒有生活。對工作時間有不切實際的期望會讓人失去對你的尊重，或更糟——導致 burnout。在團隊成員個人困難時期給予一點額外彈性，他們在團隊趕期限時會更願意付出。

追蹤職涯發展也是追蹤幸福感的重要一環。如果你問團隊成員五年後想做什麼，多數人只會聳肩。但通常每個人都有一些隱含的期望：晉升、學新東西、上線重要產品、與聰明人共事。身為有效的領導者，你應該：

思考如何幫助這些事情發生，並讓團隊知道你在想這些
把這些隱含目標變為明確目標，作為職涯建議和評估機會的依據

追蹤幸福感歸結為：不只監控職涯發展，也要給團隊成員自我提升的機會、對工作的認可，以及途中的一點樂趣。

其他技巧#

委派但也親自動手（Delegate, but get your hands dirty）：新任領導者要學會委派，即使對方做得比你慢。資深領導者接手新團隊時，主動承接沒人想做的苦差事是贏得尊重的最快方式——再長的成就清單也比不上捲起袖子親手做
尋找接班人（Seek to replace yourself）：除非你想一輩子做同樣的工作。僱用能取代你的人，給他們機會承擔更多責任。記住有些人就是喜歡當高績效的個人貢獻者，這沒問題。不要把優秀工程師硬推到他們不想要的管理職——這只會讓團隊少一個好工程師、多一個差勁的管理者
該掀起波瀾時就掀（Know when to make waves）：面對問題不要拖延，告訴自己「等一下就會好」或「問題會自己解決」。它們極少自行解決，越晚處理傷害越大。立刻行動
為團隊遮風擋雨（Shield your team from chaos）：進入領導角色後你會發現團隊外面是一個充滿混亂和不確定性的世界——它一直都在，只是你的前任管理者幫你擋住了
給予空中掩護（Give your team air cover）：分享你能分享的資訊，但不要讓不太可能影響團隊的組織亂象和瑣碎要求干擾他們
及時表揚（Let your team know when they’re doing well）：不要只在犯錯時才給回饋，做得好時也要讓他們（和團隊其他人）知道
容易撤銷的事就說「好」（It’s easy to say “yes” to something that’s easy to undo）：團隊成員想花一兩天試驗新工具？沒問題。要上線一個需要維護十年的產品？那就需要更慎重考慮。好的領導者善於判斷什麼可以撤銷——而可撤銷的事比你想像的多（技術和非技術決策皆然）

人如植物（People Are Like Plants）#

作者的岳母養育了六個截然不同的孩子，她的智慧是：孩子就像植物——有些像仙人掌，需要少量水但大量陽光；有些像非洲紫羅蘭，需要散射光和濕潤土壤；有些像番茄，給一點肥料就會大放異彩。如果六個孩子都給等量的水、光、肥料，他們會得到平等的待遇，但很可能沒有一個得到真正需要的。

團隊成員也是如此——他們需要不同比例的動力（Motivation）和方向（Direction）：

有些人陷入低潮，需要動力
有些人分心或不確定該做什麼，需要方向
有些人「漂泊不定」，同時需要動力和方向
有些人不需要任何額外的動力或方向——強行給予只會惹惱他們

提供方向相對直接——需要基本的組織能力和將工作拆分為可管理任務的協調能力。動力則更複雜。

內在動機 vs 外在動機（Intrinsic vs Extrinsic Motivation）#

根據 Dan Pink 在《Drive》中的理論，要讓人最快樂且最有生產力，關鍵不是外在動機（如金錢），而是提升內在動機。方法是給予三樣東西：

自主權（Autonomy）：讓人有能力自主行動而不被微管理。給予大方向但讓他們決定如何達成，不僅因為他們通常比你更了解如何建構產品，也因為這給了他們更大的擁有感——他們在產品成功中的利害關係越大，看到它成功的興趣就越大
精通（Mastery）：給予提升現有技能和學習新技能的機會。員工的技能如同刀刃——花大價錢找到最鋒利的刀，但用了多年不磨就會變鈍、低效甚至無用。Google 提供充足的學習機會來維持工程師的銳利、高效和有效
目的（Purpose）：自主權和精通再多，如果工作毫無意義也無法激勵人。很多人的產品其實影響深遠，但他們被隔離在正面效果之外。即使產品影響力較小，找出工作背後的原因並讓團隊看見，就能大幅提升動力。書中提到一位管理者會把客戶感謝信轉發給工程團隊——這不僅激勵士氣，也經常啟發團隊思考如何讓產品更好

以上三點的前提是：團隊成員的薪資已經足夠，收入不是壓力來源。

結論#

帶領團隊與寫程式是截然不同的任務。優秀的軟體工程師不一定是好的管理者——這沒問題。有效的組織會為個人貢獻者和管理者都提供有生產力的職涯路徑。

Google 的經驗表明，軟體工程背景對管理者極為寶貴，但最重要的技能其實是社交能力。好的管理者透過以下方式賦能團隊：

幫助團隊順暢運作
讓他們聚焦在正確的目標上
隔離外部問題的干擾
始終遵循謙遜、信任、尊重三大支柱

TL;DRs#

不要用傳統方式「管理」；專注於領導、影響力和服務團隊
盡可能委派；不要凡事自己來（Do It Yourself）
特別關注團隊的聚焦度、方向和速度