從個人貢獻者到管理者：關於領導的反思
某個下雪天，我拖著病體，組裝一套供使用者簡報之用的破爛系統，莎朗進來發現我在操控台前勉強支撐，她便離開了，幾分鐘後，她端著一鍋湯回來，為我倒了一杯，我的精神為之一振。我問她要做的管理工作那麼多，怎麼會有空做這種事，她向我展露她的招牌微笑，說：「湯姆，這就是管理。」
－《Peopleware: Productive Projects and Teams》
有次跟一名職涯顧問聊天。我提到：「我希望透過打造產品來替別人創造價值，如果有很棒的團隊，我相信自己能辦到。」她問：「團隊是必須的嗎？」我愣住了，隨口說：「因為打造產品需要很多不同的職能……還需要可持續性的運作，對，我想團隊是必要的。」事後回想，她的問題很有趣，現代社會好像把「團隊」和「領導」當成是成功的標配，人力市場也一堆團隊主管的職缺，這是一則現代神話嗎？還是某種工業革命時代的遺產？
身為個人貢獻者的管理者
不是說團隊不重要，只是在現代，你會用不同的角度審視完成目標需要的條件。你想想，如果你是個開發者，自己架網站、賣東西，網路上工具一堆，你會想說：「嗯，我要加入 WordPress 或 Gumroad，跟他們變成一家人」嗎？應該不會吧。那如果是做產品呢？嗯，可能要花點心思，但你還是能用「個人貢獻者」（Individual Contributor）的角度出發，跟別人合作，找朋友幫忙設計、找行銷公司幫忙推廣，只要你在圈子裡打滾夠久，自然就知道怎麼找到對的人幫忙。你可能會覺得這樣很花錢花時間，但組建和運作一個團隊，也同樣要時間和金錢，搞不好還更多。
既然如此，我們會什麼還需要團隊？在我看來，團隊本質是長期而緊密的合作關係，你請個建築師幫你設計新家，房子蓋好了，你們的關係就結束了，乾脆俐落。團隊不同，它沒有一個結束日，只要你不辭職或被開除，每天都得跟同一批人一起工作。它會讓你覺得更有依靠，也會讓你更有信心面對未來的挑戰，至少出事能立刻找到熟悉的人商量。Lawrence Block 在書中提到：
我最不想要的就是搭檔，但這類提議有種莫名的魅力，會讓人想接受。你會以為這麼一來你就不寂寞了，很多有欠考慮的夥伴關係就是如此開始的，而同樣模式的失敗婚姻也很多。
我前主管說他理想的工作模式像爵士樂，我聽了心有戚戚焉。爵士樂是一種「個人貢獻者的交集」，意思是，跟你一起工作的人對目標有共識，專業能力又能互補，而且每個人都知道自己該怎麼貢獻，不用樂團指揮下指令－－能想像在找吉他手時，還需要先教他怎麼按和弦嗎？在這種模式下，每個人都是獨立的貢獻者，就像在開源專案裡貢獻一樣，你不會說某個貢獻者就是你「團隊」的人，但你知道他做了什麼，而且真心感謝他的付出。
工作一段時間後，有天執行長找我聊天，他說團隊需要有人領導，問我有沒有意願接手。如果個人貢獻者的模式可行，那為什麼還需要有人來管團隊？難道團隊不能自己搞定一切嗎？出自於類似的觀點，Google 曾進行去組織化的實驗，他們把所有工程部門的中階主管都取消了，工程師直接對工程資深副總報告（翻譯一下，就是不用報告了）。這項實驗的結果是，Google 的導師 Bill Campbell 說服 Larry Page 跟 Sergey Brin 重新設立主管：
比爾、布林與佩吉於是在公司裡走來走去，找了兩名正在工作的軟體工程師，問他們想不想要有個主管？
「想啊！」那名工程師說。
「為什麼？」
「我想要有個可以學習的對象，以及有個負責拍板定案的人。」
那天晚上，他們又問了好幾位軟體工程師，幾乎每個人的反應都一樣。只要這個經理人有值得學習之處，又可以協助做決策，這些工程師其實喜歡被管理。
比爾證明了他的論點，但要說服布林與佩吉這兩位年輕的公司創辦人，還是費了一番工夫。谷歌工程部門的去組織化模式實行了一年多才終於落幕，在 2002 年底公司再度設立管理職。
跟 Google 類似，我接受管理職務的存在。我接下這份任務，因為我希望支持其他人成長，還有推動願景早日完成。我曾經有個主管說，他的動力來自「集眾智以成事」，我會用低調一點的語氣表達同樣的意思：如果團隊需要有個人來搞定一些基礎建設，讓其他人可以專心把事情做好，那我可以做點貢獻。而且從長遠來看，這也不違反「個人貢獻者的交集」這個原則，只要團隊成員能繼續成長，我有一天還是能當個單純的個人貢獻者。有次跟其他主管開玩笑：「哪天老闆願意找個人來接替我的位置，我一定第一個舉手贊成！」
我該怎麼開始
我的目標是維持團隊成員的自由，又能讓他們保持專注。在開始負責團隊時，我們的工作模式是全遠端，這是個不錯的基礎。我可以在工作群組的頻道上看到每位成員的現況，不用時時刻刻詢問進度。很快的，我就發現一些問題，例如其他團隊需要幫忙時，他們不知道該找誰；又或者工作項目擬定後，不知道該由誰執行；以及當成員意見不同時，我們應該選擇什麼方案。我可以直接指派工作，但我曾經在一名缺乏經驗的主管底下工作過，知道什麼是讓人挫折的被管理體驗。每位肩負管理責任的人都會面對類似的挑戰，你現在要用團隊的角度來思考，這跟從個人角度出發的思考相當不同，你需要一套原則來幫助你。
透明
我的第一項原則是「透明」，我們前面提過，團隊的本質是長期的合作關係，因此團隊成員的信賴是所有事情的基礎，要讓「個人貢獻者」能彼此協作，信任是不可或缺的。我還記得自己在做保險電商產品時，有位主管說過：「我們販售的不是金融產品，而是信任。」只有當別人信任你，他才有可能開始跟你建立關係。在常見的管理模式中，管理者有其他成員沒有的權力，這份權力不是榮譽，而是詛咒，它是貼身攜帶的槍械，還明晃晃掛在衣服外頭，每個人都看得到，而且傾向跟它保持距離。要贏得他人的信任，你只能在別無選擇的危急時刻才能動用，同時一旦使用，你就必須面對信任受損的後果。
「透明」是用來消除團隊成員的疑慮，讓他們相信你總是把團隊的利益放在個人利益前面，要公開透明到什麼程度呢？這是個好問題。最低要求是，所有團隊成員應該知道的事情，你都要讓他們知道。我曾經執行過一些關鍵專案，執行長希望基於資安原則，只有負責人員知道這件事，我當時提出要求，這項專案必須在我的團隊內部公開，因為只有這樣我才能維持團隊內的溝通。
聽起來好像很容易吧？其實不是。因為你必須讓所有消息，不管好的壞的，都在第一時間讓團隊成員知道，每次傳達壞消息總是讓人非常痛苦，舉例來說，公司要裁員，但還沒有確定，這時你應該讓團隊成員知道嗎？還是應該等狀態更明確才告訴成員呢？你收到一份市場的薪資調查報告，你應該要分享給團隊成員嗎？他們如果拿這份報告來跟你要求加薪，你就會很麻煩，可是不分享，你就是在利用資訊不對等占人便宜。公司有人要離職，但還沒透漏，你用了其他管道得知，你應該違背當事人意願，提前透漏消息嗎？這個月營收狀況不佳，有個大客戶突然轉單，你要跟團隊說前幾個月的努力都變成泡影嗎？等等等等。Google 對於透明應該要做到什麼程度有個簡單易懂的指引：
「分享所有資訊」，並非指「分享萬一洩漏出去時不會難看，以及不會令任何人難過的所有資訊」，而是指「分享除了法規禁止的極少數東西之外的所有資訊」
原則可以幫助你下判斷，每次感到困難時，問問自己原則是什麼，以及這項原則的底線畫在哪裡。我每次都會問自己說，如果今天我是團隊成員，我會希望領導者告訴我這項消息嗎？這項消息如果公開，會傷害到誰嗎？沒有人可以徹底透明（原則不是讓你從無序走向極端），透明不是要你透漏所有資訊，而是要你盡可能把別人放到自己前面，你不能只是分享訊息，你還要用正確的方式傳達訊息，確保每個人能真正理解訊息的意涵：
取部分事實編造謊言，是領導者耗損信任最常見的方式，我要再次清楚強調：千萬別這麼做。你的人不是笨蛋。你用花言巧語唬弄他們，他們是看得出來的，你在他們眼中只會淪為騙子。有話直說，不要嘗試把不好的局面說成好的，員工聽得出你有沒有說實話。
如果不確定透明的意思，問問自己幾個問題
- 我是否能在最晚一天的時間差內，讓團隊成員知道訊息，無論訊息是好是壞？
- 我是否將團隊利益置於我的個人利益之上，並且能夠公開說明我的考量？
- 團隊成員是否願意主動向我求助？如果沒有，我還少做了什麼？
- 當我察覺到訊息落差時，是否願意主動分享訊息，即使團隊成員沒有要求？
- 團隊成員是否清楚團隊目前的業績狀況與目標差距？我們對這個差距的看法是否有共識？
助推
第二項原則我稱為「助推」，這是行為經濟學的名詞。Daniel Kahneman 在《快思慢想》中說人類有兩套思維系統。其中一套慢，以深度與思索為導向；另一套快，依靠本能與直覺。多數時間內，我們都是有限理性人，儘管我們知道應該仔細思索，但認知負載有限，我們還是仰賴第二套系統來進行判斷。人的理性「有限」，意味著我們可以透過「改變環境」來改變別人的行為，對人的引導不是直接說明，而是用改變環境來呈現。芝加哥大學教授 Richard H. Thaler 跟哈佛法學院教授 Cass R. Sunstein 曾如此解說「助推」：
不禁止任何選項，也不大幅改變經濟激勵措施，卻促使人們在選擇時期朝可預見的方向發展，這種力量就是助推……純粹的助推中，必須能夠不費力氣地避免干預。助推並非強制性的。將新鮮水果擺放在與人們視線平齊的櫃檯上算是助推。而以法律形式禁止食用垃圾食品則不是。
Google 的工作環境很有名，他們會在茶水間與休息區擺滿零食，讓員工自取，無限量供應，這是 Google 極客文化的體現。隨著對員工健康的日漸重視，Google 啟動「優化你的生活」專案，他們發現日常飲食在美國是影響健康與壽命最可控的因素，因此他們決定幫助員工做出更好的食物選擇。在一番研究後，Google 重新規劃了零食供應政策，將含糖飲料和巧克力等不健康的食物移至冰箱下層，並在顯眼處擺放礦泉水和蘇打餅乾。這項調整成功讓工程師選擇更健康的食物，進而改善了整體飲食習慣。
你可能會覺得這是在操縱別人的行為，因而抗拒這樣做。別這麼想，「助推」是在告訴團隊成員怎麼做比較好，同時也尊重他們的個人意志，如果團隊成員願意付出心力深思，他們可以保有自己的行動與判斷，而如果他們不認為這件事值得付出心力，你是在節省他們的時間與認知負擔，讓他們把注意力放到真正能創造價值的地方。重要的是，不管你怎麼看，始終會有個預設選項，既然如此，為什麼不好好規劃它？
「助推」是引導獨立個體朝共同目標前進的方式，當你尊重成員意願，又願意給他們選擇，事情就會變簡單。在徵詢團隊成員的看法前，我花了點時間跟團隊講解雲原生在現代軟體工程的意義，接著我問團隊成員說，我們目前有這些工作，有沒有哪項是你們感興趣想做的？如果有，就交給你，如果沒有，就由我來決定。這項原則後來帶來意料外的效果，例如我只是提出希望改善日誌監控設計，有同事端出 CloudWatch Logs Insights，讓我們可以精確追蹤到出問題的程式碼；又或者當產品需要使用者驗證的解決方案時，同事提出使用 Cloudflare Turnstile，降低了三成左右的無效登入。這都是雲原生的解決方案，而且都不是由我提出。
當然，我的意見跟成員不見得總是相同，如果成員在某件事情上有明確的意願，偏偏他的想法跟我不同，那要怎麼辦？Netscape 的 James Barksdale 曾說：「如果我們有數據可以證明怎麼樣有用，我們就看數據，但如果我們有的只有意見，那就採用我的。」我大致同意，但最後一句應該改成「如果我們有的只有意見，那就採用你的。」管理者要先證明自己，才能要求別人，如果你鼓勵成員有自己意見，卻又在最後一刻拿走他的主導權，你就是對他開了那把不信任的槍，傷害自己辛苦累積的信賴感。有時候迫於無奈，你無法承擔決策錯誤的後果，為了保護團隊，你需要親自主導，但即使在這種情況下，也應該盡量取得對方諒解。
如果不確定助推的意思，問問自己幾個問題
- 我是否總是有一套備案，在團隊成員沒有意見時，可以幫助他們更快行動？
- 我是否有意識去降低模糊空間，讓團隊更容易做出選擇？
- 當面對選擇時，我是否會透過調整環境來引導團隊走向更好的結果，而不是直接禁止或要求？
- 我是否以團隊成員的意願為主，並在可能的情況下讓他們自主選擇，即使他們的解決方案與我的不同？
- 當成員的方案取得成果，我是否會表達自己的讚賞，並鼓勵他繼續前進？
工藝
第三項原則是「工藝」，這可以從我喜歡的一個故事講起。
相傳王獻之學習書法，到了十四五歲，他的書法已經很出色了。這時他對自己的作品有點得意，覺得水準父親差不多，就在紙上寫了個「大」字，拿給父親王羲之看。王羲之看後微微一笑，提筆在「大」字下加了一個點，變成一個「太」字，囑咐他拿去給母親看。王獻之拿給母親。母親接過字看了一眼，問說：「這是你寫的字嗎？」王獻之點頭，母親說：「你有進步了，特別是這個『太』字的點，很有你父親的功力。」
這個寓言故事告訴我們，每個領域都有它各自的深度，儘管外觀看起來可能非常類似。在「個人貢獻者的交集」模式中，你是一名管理者也是一名個人貢獻者，你應該像一名書法家重視自己書法一樣重視自己的技術能力，那是你看待世界的角度，有濃淡有層次，是能真正做出貢獻的領域。有次，我問起成員怎麼看未來方向，得到的回答是：「希望公司的職等更明確。」職階代表方向與肯定，你做對事情，有更高的頭銜，然後可以跟自己說我進步了。可是我在意的是，我們能不能更深入自己從事的領域，有沒有用正確的方式做事，打出正確的球賽。當你看到層次，你會知道該如何區分標準，這時職階不再重要，因為你會知道自己有沒有符合自己設定的職階。
管理者需要面對來自各方的壓力。你可能會被問起，如果能動的程式碼跟漂亮的程式碼讓你選擇，你要怎麼選？對我來說，這是個假問題，我會兩個都選，既能動又漂亮。舉例來說，寫測試案例要花時間，於是你問產品負責人如果不寫測試，可以更快交付，想知道他是否同意。不要問這種問題，你怎麼會覺得產品負責人比你更懂程式呢？你應該把他當成是產品的專家，知道如何增長，知道如何回應客戶的需求，但不該讓他教你寫程式。爵士樂隊的吉他手不會去問薩克斯風手如何彈奏吉他，他問的是別的面向：我們何不在這裡多加一段演出，讓音樂變得更迷人？
是的，有時候工藝需要在各種因素間取得平衡，這是工藝被稱為藝術的原因，我可以用記憶體空間換取 CPU 的運算時間，或者在傳送前壓縮資料，讓 I/O 更有效率。但通常你遇到的問題不到這個層級，你只是工藝有待改進而已。如果一直在追求取捨，團隊會原地踏步，團隊成員會覺得自己得不到成長，最後紛紛離去。他們會跟你講：「我有其他想做的事」，意思是現在的工作對他們沒有吸引力。
追求工藝能維持技術上的一致性、提升決策品質，並建立團隊間的信任。不要讓管理責任分散你對技術的關注，正如 Agoda 技術長 Idan Zalzberg 講的：「你的職業仍然是工程師。如果你不了解團隊正在做什麼，怎麼能指導他們或評估取捨？」你仍然應該持續追求技術深度，並且，嘗試將它們落實到組織的願景中。保持技術領先可以讓你不會迷失方向，給予你堅持下去的能量，並幫助你建立自信與榮譽，DHH 說：
That doesn't mean AI doesn't have a role to play when writing Ruby. I'm conversing and collaborating with LLMs all day long — looking up APIs, clarifying concepts, and asking stupid questions. AI is a superb pair programmer, but I'd retire before permanently handing it the keyboard to drive the code.
這並不代表 AI 在寫 Ruby 時沒有角色。我整天都在與 LLMs 對話和合作——查找 API、釐清概念，還有問一些愚蠢的問題。AI 是個出色的搭檔程式設計師，但我寧願退休也不會永久把鍵盤交給它來主導程式碼。
如果不確定工藝的意思，問問自己幾個問題
- 我是否在妥協前，都會有意識尋找能兼得的方案？
- 我是否鼓勵團隊成員追求更好的設計，而不是要求他們跟現狀妥協？
- 我是否知道一段程式碼好在哪差在哪，並能跟我的成員說明清楚？
- 我自己是否有一套標準，知道如何判斷技術能力的層次？
- 我是否能理解自己領域的技術前沿，並知道如何應用在工作中？
在工作中，你會遇到的事
僅有原則無法讓你成功，《雪球》作者 Schroeder 提出一個很棒的問題：為什麼沒人能複製 Buffett 的成就？
在這段時間裡，儘管華倫．巴菲特進行了無數的教學、指導和解釋，卻從未有人能夠複製他的成就——通過組建一家綜合企業或投資，並以他購買價值投資的速度進行複利增長，創造出一家價值 3000 億美元的公司。這就引出了一個問題。如果這看起來如此簡單明瞭，而且他能夠解釋清楚，那麼為什麼沒有其他人做到呢？
...
他向我解釋地毯的個別角色與風格、成本多少、售價為何、每週賣出多少碼，以及利潤率是多少。就在那一刻，我開始真正明白這絕非尋常之人。因為這只是波克夏．海瑟威旗下眾多事業中的一項。
我相信，對於熱愛管理的人（沒有反諷的意思）來說，工作中的挑戰會讓他們躍躍欲試，他們可以利用這些機會來打磨自己的假設，檢視是否需要修正，或是發現另一項更有效的原則。當看到某個技術觀點指出我沒想過的方向時，我就是這種心情。在管理實務中，我們會遇到非常多沒想過的狀況，我建議盡可能將它們視為技術問題，而非原則問題。找出細節上的差異，精進你的管理技能，你會知道該如何處理它們。
資源衝突
我曾以工程師的身分加入某個團隊，有次，團隊主管在會議中被問起專案規劃，他不斷重複：「我們沒有資源。」「我們真的沒有資源。」「有資源我們才能進行。」我記得當時會議一片沉默，沒人知道該如何進行下去。
資源衝突是工作中最常遇到的問題。如果你曾經開發過「即時」性質的產品，你應該知道「即時」只是個相對的用語。傳輸延遲 1000ms 在電視轉播稱不上問題，它還是即時轉播，但放在車用系統，200ms 的延遲可能會是巨大的安全隱患。缺乏資源的正確說法是缺乏「多少」資源，只要再補一位新手工程師，還是需要兩位資深工程師？如果請外包人員協助，是不是能解決問題？
更重要的是，我們應該要先看優先順序，再來看資源。如果沒有優先順序，資源永遠都不夠。OpenTelemetry 要實現「高品質、隨插即用的遙測」，它當然需要大量的資源，可是這些資源要用在哪呢？什麼是當前可觀測性最大的障礙呢？OpenTelemetry 有一份 Roadmap，維護它們的優先順序：
P0：我們必須在指定的時間範圍內完成（如果有的話），否則專案將會失敗
P1：這是我們最重要的主要計畫之一，將對專案產生重大影響
P2：這項工作足夠重要，值得追蹤和優先處理，且比不在此清單上的項目更重要，但目前其緊急性或關鍵性低於 P0 和 P1 項目
如果你遇到資源衝突，找出 Roadmap，想想什麼是你的核心任務，不要分散資源在無關成敗的地方。
接受回饋
我曾參加過一個專案，因為架構設計問題，導致後續維護成本極高。那次經驗讓我打定主意，如果後續有架構設計的環節，我一定會盡全力把關。可是在換到新工作後，同時要忙的事情太多了，我沒辦法在短時間內完成所有架構審查，結果整個團隊都在等我。讓我非常焦慮。
那時有位同事建議我：「我覺得你可以多讓其他人負責。」這有點違反「工藝」原則，我掙扎一陣才跟他講我會想想。現在回頭看，問題原因是我信心不夠，我害怕重蹈覆轍，沒有信任同事的能力，幸好有人適時提醒我，讓我重新思考拿捏的尺度。而結果證明，其他人做得非常好，甚至超乎預期。
將任何願意給你回饋的人當成上天的禮物，即使那有違你的認知。我不是說要照單全收，你應該要有能力辨識出哪些回饋是替你著想，哪些回饋只是想發表自己的意見。試著用 ORID 的方式問自己，這段回饋中有哪些是客觀事實？你聽到之後的感受是什麼？為什麼會這樣感受？又該做出什麼行動？珍惜願意站在你的角度給建議的人，那會是成長的重要動力。
為政策辯護
當你的意見跟主管意見不同，卻又要將他的意見傳遞給你的團隊成員，你應該怎麼辦？Kim Scott 建議你應該秉持著坦率的態度，告訴主管不同意他的想法，這能讓你在面對團隊成員時更容易站住腳：
當同仁問：「為什麼我們要做這件事？我們認為這毫無意義，你沒有爭辯嗎？」那你就可以回答：「我懂你的觀點。沒錯，我確實有機會爭辯。我當時是這麼說的，而就我了解，我們是因為以下理由才去做這件事。」如果他們堅持要你表態是否支持，你可以很坦白地說，你的主管聽到你的觀點，你曾有機會挑戰這些決策，但現在該全心投入不同的行動方針，即便那不是你支持的主張也一樣。
把你的主管當成是另一個領域的專家，他正用他的方式替願景做出貢獻，即使不同意他的看法，你也應該開誠布公與他討論，然後支持他。這不是因為他是你主管，而是因為你相信他的專業能力。時間會證實他的方式是否管用，如果對了，你可以學到一課，如果錯了，像給予其他人犯錯空間一樣給他機會。要是他一再濫用你的信任，我建議你另謀高就。
因為將信任放在核心，你會更容易接受他的動機，也更容易挺身而出替他辯護。有次，我主管提議某項新功能，團隊成員認為那是錯誤的專案，不但沒解決問題，還容易造成使用者誤會。我得說自己也不同意那個案子，但還是從使用者的角度說明開案動機，並建議與其在這裡爭辯，我們應該讓數據來說話。有意思的是，案子的結果說不上成功（也說不上失敗），而我卻因為替案子辯護，學到新的知識。
如果重來，我會加強哪些點
我得說自己在工作中做錯許多事。即使你有一套清晰的原則，也熟悉實務技巧，你仍然不可能永遠正確。網球手 Roger Federer 回顧他的網球生涯時說：
在我職業生涯 1,526 場單打比賽中，我贏了其中將近 80% 的比賽，但你們知道在這些比賽中，我贏得的分數的百分比是多少嗎？只有 54%。
換句話說，儘管是最頂尖的選手，平均也只能贏得比一半多一點的比分。因此，每當你平均每兩分就會輸一分時，你要學會不要停留在某一分。這只是一分，不管是雙發失誤、上網被穿越，即使是反拍扣殺，或是十大好球，這都也只是一分。
當你在打每一分時，要把它當作是最重要的一分。但當它結束了，它就過去了。負面思考是浪費能量，你要成為克服困難時刻的大師。對我來說，冠軍，是儘管知道自己會一再的失敗，並從中學會如何處理它，學會繼續前進，更加努力，更有智慧的成長。
那麼，有哪些困難是我應該克服，學著繼續前進的呢？我認為有幾點
建立願景
首先是「建立願景」的能力。領導者跟管理者最大的差別，在於領導者能建立願景。這聽起來很抽象，好像離我們很遙遠，但它的影響力卻是再具體不過。有朋友曾跟我分享，他選擇工業控制領域的原因，是因為工業控制是基礎建設的產品，產品生命週期五年起跳，需要在嚴苛的環境中運作，而且支撐著我們這個社會。如果說人的選擇中存在某種方向性，最後指向之處就是一個人的願景。願景會吸引人們，讓人想像自己是其中一份子。
我知道怎麼把事情做對，但當要從組織願景中找到個人願景，並轉換成團隊成員每天的工作時，我得承認自己遇到很大挑戰。我安排定期一對一會議，詢問團隊成員他們想要什麼，請他們尋找自己的楷模，觀察他們熱情所在。但即使做了這些事，我仍然不知道該怎麼建立願景。最根本的原因，可能是我的信念不夠，人生像是微積分，任何事情都由細小的偶然堆積起來，工作也是一樣，領導者需要在細節中找出吸引人的力量，才有辦法讓別人相信他們的貢獻都有意義。
願景的力量就像 Peter Senge 講的：「有真正願景時，人們追求卓越並且學習，不是因為他們被要求如此，而是他們想要如此。」
面對衝突
再來是「面對衝突」，這幾乎是領導者的標配能力，有時我會納悶，為什麼要把事情做對，必須得先衝突一番。衝突發生在各處，不僅僅是資源，還有觀點、意願、期待。曾有位主管希望我到美國駐點，帶領當地團隊解決客戶問題，我卻對此興趣缺缺；或者使用者突然無法登入系統，我認為原因不明，應該要先確認現況，但其他人卻認為問題出在登入機制的設計。我直到讀了《雪球》，才發現 Buffett 跟我有同樣的困擾：
巴菲特害怕衝突，閃躲是他的本能，如果有人像他母親那樣對他發作，他會像貓一樣溜走。但他也學會面對衝突時封閉自己的感情，他的祕訣是，針對那件事在你四周造一個殼，只是殼不要延伸到事件外，以免變成冷酷的人。
每個人有自己面對衝突的方式，我的選擇類似 Buffett，他不會直接批評經理人，而是控管相關資源，引導局勢發展－－我相信 Buffett 會同意「助推」觀點。這種方式有其極限，當團隊是由「個人貢獻者的集合」（或波克夏由信任織成的商業模式），它可以運作得很好，可是當需要你披掛上陣，發出強而有力的號令時，它就顯得左支右絀。
我需要有人協助我面對衝突，特別是當衝突需要被呈現、被處理的時候。Munger 願意為 Buffett 挺身而出，我相信 Buffett 非常感謝他。
授權
最後是「授權」。授權不是簡單的事，Intel 傳奇執行長 Andy Grove 說過：「通常我們都把自己看成很會溝通或很能授權的人，但部屬卻常常不以為然。」授權的困難點在於它不是有跟沒有的關係，而是個灰色地帶，你需要精確掌握授權的尺度，這代表你要了解團隊成員的能力，還要給予清晰的目標。如果連自己都不知道該如何進行的事，還能授權嗎？這就是微妙之處，有時你會顯得不負責任，有時你會顯得管控太嚴。
我有位主管曾經採用一種方式，他會在開會時，站在旁邊觀察會議進行，或者在會議結束後詢問討論過程。這是種授權技巧，用意是監督決策過程好確保成效。只是這種模式沒有維持太久，因為他很快發現，會議結論跟他想要的有段差距，他開始在會議中提醒應該要注意的點，或者當團隊成員已經有結論後，他又回來修改結論。你現在知道授權困難在哪了，那位主管沒有做錯事，可是在花費團隊許多時間後，他還是要自己做決定。
我前面分享過團隊在等待架構審查，我卻沒有充分授權，導致事情都卡在我身上。有部分的原因，是我當時沒把握架構設計的方向，也沒有建立好團隊的工作準則，這時貿然授權，更像是為一時方便而違反「工藝」原則。我後來看到 Jessamy Hibberd 的《冒牌者症候群》後，才發現問題所在：「自我要求很高卻又不相信自己的人通常也無法相信他人。你可能會盯著大家的一舉一動，任何小事都要照你的意思做，很難授權給別人。」
小結
最開始談這題目，是因為公司前陣子徵才，不少人問到我的管理風格，我可以談幾個原則，只是原則要如何落實在日常工作中？這些原則間有沒有一致性？還有與其他管理風格比起來，我的原則立足點在哪？限制在哪？這些問題沒辦法用兩三句話講清楚。我知道自己求職時會在意這些事，所以想，好吧，我應該要整理一篇長文，給求職者也給自己看，在這意義上，它更接近一種備忘錄。
文章開頭強調的「個人貢獻者的集合」，是整個論述的基礎。Netflix 在談論不同產業的管理風格時說過：
如果你的重點是消除錯誤，管控就是最好的辦法。埃克森美孚所在的市場以安全為重。工程地點需要數百條安全流程，將人員受傷的風險降到最低。當你經營高風險事業，意外事故愈少才愈有利的話，管控機制絕對不可或缺。
明顯的，「助推」在要求品質控管的產業行不通，你可以看到 Andy Grove 談論如何授權，但他不會使用「助推」原則，Grove 的書名「唯偏執狂得以倖存」（Only the Paranoid Survive）說明控制對他有多重要。我講的原則只能用在一個非常限定的範圍，也就是團隊成員要互相信任，每個人要有各自的專業性，管理成本要盡可能低－－有時候，連「團隊」這樣的用詞都顯得過於正式。在某些情況下，這套原則對我行得通，但在另一些情況中，我也需要做出調整。
我記得有次跟技術顧問聊到公司的優勢，技術顧問說：「你們的優勢是人員組成穩定，現在這個開發團隊，已經兩年沒人離職了對吧。」很有意思，面對同樣的話題，我主管的想法是：「我認為我們的優勢是適應的文化，不管市場怎麼變，我們都能面對挑戰。」他們的觀點都有各自的道理，觀察每個人的思考脈絡，想想他們背後有哪些動力，你會慢慢能建立起自己的觀點，知道別人這麼講的原因。
Reference
- My life as a CTO — 信任領導
- 徹底坦率：一種有溫度而真誠的領導. Kim Scott
- Peopleware. Tom DeMarco & Tim Lister
- The Practice of Management. Peter Drucker
- Trillion Dollar Coach. Eric Schmidt, Jonathan Rosenberg & Alan Eagle
- How Google Works. Eric Schmidt & Jonathan Rosenberg
- David Hutchens’ Learning Fables. David Hutchens
- The Snowball. Alice Schroeder
- High Output Management. Andy Grove
- The Imposter Cure. Jessamy Hibberd
- No Rules Rules. Reed Hastings & Erin Meyer
- Coding should be a vibe!
- Agoda’s CTO on Why Managers Should Code, Running On-Prem, and Adopting Generative AI
