前言#

高階管理者的日常工作因公司規模而有極大差異。一位管理 70 人新創工程團隊的主管,與掌管數千人的 Fortune 500 高階管理者,職責截然不同。市面上有大量的通用高階管理書籍,但這本書的對象不是「通用高階主管」,而是從工程師一路成長為管理者的技術領導者

身為技術高階管理者,我們帶來獨特的技能:願意擁抱並推動變革、能質疑現行做法、理解技術快速演進的本質。但光是當一個 change agent 還不夠,我們還必須建立一個能成功執行變革的組織

你的首要工作是成為領導者。公司期望你提供方向指引:做什麼、往哪走、如何行動、如何思考、重視什麼。你設定了互動的基調。人才因為相信你、相信你聘用的人、以及你參與打造的使命而加入公司。

作為高階領導者,你需要具備的能力:

  • 不完美的資訊下做出艱難決策,並願意承擔後果
  • 理解當前的商業環境,並能預見多種可能的未來
  • 掌握組織結構如何影響團隊工作,並安排能強化結構的管理層
  • 有建設性地參與政治運作,與工程以外的同儕合作推動組織與業務
  • 理解如何 disagree and commit——即使不同意決策,仍然全力執行
  • 知道如何追究個人與組織的交付責任

Andy Grove 的四大管理任務#

Andy Grove 在 High Output Management 中,將管理任務歸納為四大類:

任務說明
資訊收集與分享(Information gathering/sharing)參加會議、讀寫 email、一對一交流、收集各方觀點。優秀的高階領導者能快速消化大量資訊、識別關鍵要素,並以對方能理解的方式傳達
輕推(Nudging)透過提問而非下命令來提醒人們的承諾。大型團隊的領導者很難強制引導方向,而是靠輕推讓組織保持在正軌
決策(Decision making)在衝突觀點與不完整資訊中設定方向。如果做決策很容易,就不太需要管理者和領導者了。決策是管理工作中最耗費精力、最高壓的部分
身教(Role modeling)展現公司的價值觀、出席承諾的場合、為團隊樹立最佳榜樣——即使你當下不想這麼做

無論你是 CTO、VP、General Manager 還是 Head of Engineering,你的日常都由這四項任務所塑造。

Ask the CTO:我的工作到底是什麼?(James Turnbull)

James Turnbull 分享了他的經驗:他來自所謂的「非傳統背景」,在與擁有傳統 CS 背景的人互動時,常受 impostor syndrome(冒充者症候群)的困擾。這在領導他認為技術比自己更強的人時尤其困難。

這種背景加上強烈的「想被認為聰明且正確」的渴望,有時導致他在技術方向討論中陷入不具生產力的爭辯——純粹從技術優劣的角度辯論語言或技術的選擇。當這種情況發生時,他就變成了一群工程師中的又一個工程師。

他花了很長時間才理解:他的工作不是當房間裡最聰明的人,也不是要「正確」,而是幫助團隊做出最佳決策,並以可持續且有效率的方式執行。

技術是每一個決策的因素之一,但技術本身不能造就一個高產且快樂的團隊。好的領導者會在技術討論中注入策略目標,並考量技術決策的非技術影響。重點不在於追逐最新的語言或框架,而是建立一個擁有正確工具與特質的團隊,為客戶打造最好的產品

技術高階領導的角色模型#

高階管理的角色定義模糊。CTO、VP of Engineering、CIO——這些職位在不同公司有截然不同的意義。與其逐一涵蓋所有變體,以下列出高階管理可能扮演的幾個常見角色:

角色說明
研發(R&D)聚焦於拓展技術前沿,進行實驗、研究與新技術創造。可能負責技術策略,也可能純粹負責發掘新想法
技術策略/願景家(Technology strategy/visionary)技術策略與產品開發的交匯點。此角色關注如何運用技術來成長業務,並預測技術在公司所屬產業的演進方向
組織(Organization)引導組織的結構與人員配置。負責人力規劃與組織架構,確保專案有適當人力。通常與「執行」角色搭配
執行(Execution)確保事情真正完成。協調路線圖、規劃工作、協調大型工作、排除障礙、解決衝突、做出決策以推動團隊前進
對外技術門面(Face of technology, external)參與客戶銷售週期、在研討會演講推廣產品,或為招聘目的建立工程品牌
基礎設施與技術營運管理(Infrastructure and technical operations)負責所有技術基礎設施與營運。可能聚焦於成本、安全性或可擴展性,取決於公司的發展階段
商業主管(Business executive)首要關注點是業務本身。理解產業、理解其他核心業務功能,在內部開發需求與業務成長需求之間取得平衡

常見的角色組合#

以下是作者觀察到的常見組合方式:

角色組合常見職位
商業主管 + 技術策略 + 組織 + 執行CTO 或 Head of Engineering (VP/SVP)
R&D + 技術策略 + 對外門面CTO、Chief Scientist、Chief Architect,有時是 Chief Product Officer(通常適用於銷售軟體產品的公司)
組織 + 執行 + 商業主管VP of Engineering、General Manager
基礎設施管理 + 組織 + 執行CTO/CIO,或 VP of Technical Operations
技術策略 + 商業主管 + 執行Head of Product 或 Chief Product Officer,有時是 CTO
R&D + 商業主管CTO 或 Chief Scientist(共同創辦人)
組織 + 執行VP of Engineering,有時是 Chief of Staff

組織可以根據業務需求混搭這些角色。CTO 的角色尤其因公司而異變化劇烈,但多數優秀 CTO 都具有某種策略功能——無論是商業導向、技術策略,或兩者兼具。

VP of Engineering 是什麼#

在 CTO 擔任全工程組織的執行管理者、負責策略領導與監督的情境下,VP of Engineering 做什麼?

VP of Engineering 的角色同樣因組織需求而變化很大,但有一個明顯的差異:VP 通常位於工程師管理職涯階梯的頂端,因此被預期是人員、專案、團隊與部門管理的資深經驗者。

核心特質#

核心特質說明
扎實的流程與細節掌控力能同時追蹤多個進行中的計畫,確保它們都順利進行。好的 VP of Engineering 被形容為有出色的 ground game——能夠深入細節、在底層推動事情發生
強大的管理能力將開發路線圖與招聘計畫對齊、規劃團隊如何隨預期成長而演進、與招聘團隊密切合作、擔任工程管理團隊的 coach
組織策略的掌控深度參與幫助團隊設定目標以達成業務交付物,需與產品團隊緊密對齊,確保路線圖務實、商業目標被轉化為技術組織可達成的目標
商業與產品直覺擁有帶領團隊交付大型專案的實績,包括協商交付物的能力

優秀 VP of Engineering 的畫像#

作者認識的優秀 VP of Engineering 具備以下特質:

  • 是有能力的工程師,但深切關心團隊,偏好留在幕後而非聚光燈下
  • 讓人們有效合作的複雜性感興趣
  • 希望團隊快樂,但知道這種快樂必須與成就感綁定
  • 向其他高階領導者反映團隊的健康狀態,並培養健康、協作的文化
  • 非常善於辨識流程缺口,並管理高度複雜、注重細節的工作而不被壓垮

注意: VP of Engineering 是一個既宏觀又注重細節的職位,這也是為什麼它極難招聘。此人必須能快速理解組織現況、贏得信任、展現管理智慧。不幸的是,工程師通常不信任沒有技術信譽的人,但這個層級的管理者多半不願接受高難度的技術面試,卻只為了一個主要聚焦於組織管理的角色。

CTO 是什麼#

在小公司或新創中,「高階管理」往往意味著你的頭銜是 CTO。然而 CTO 是技術世界中定義最模糊的角色之一

CTO 不是什麼#

  • CTO 不是工程角色
  • CTO 不是技術階梯的頂端,也不是工程師應該自然追求的職涯終點
  • CTO 不一定是公司裡最好的工程師
  • 這不是一個大多數熱愛寫程式、架構設計與深度技術設計的人會享受的角色

CTO 的定義#

不同的 CTO 有不同的樣貌:有些是技術共同創辦人、有些是早期優秀工程師、有些關注人員與流程、有些關注技術架構或產品路線圖、有些是公司對外的技術門面、有些沒有直接下屬而有些管理整個工程組織。

重點: CTO 是公司在當前發展階段所需要的策略性技術主管(strategic technical executive)。「策略性」意味著 CTO 著眼長遠,幫助規劃業務的未來;「主管」意味著 CTO 將策略思維化為現實,分解問題並指揮人員執行。

CTO 的核心職責#

首先,CTO 必須關心並理解業務,能夠透過技術的鏡頭塑造商業策略。CTO 是先作為主管,其次才是技術人員(executive first, technologist second)。如果 CTO 沒有在高管桌上佔一席之地、不了解公司面臨的商業挑戰,就無法引導技術去解決這些挑戰。

CTO 可能識別出技術可以為公司創造新的或更大的業務線的領域,或者確保技術持續演進以預期和支持業務與產品路線圖的潛在未來。

重點: 無論如何,CTO 必須了解業務面臨的最大技術機會與風險,並專注於利用它們。如果他聚焦於招聘、留才、流程和人員管理,那是因為這些是當下技術團隊最需要關注的事。這與「CTO 應該只關注純技術議題,當 chief nerd」的觀念形成對比。

管理權力與影響力的陷阱#

強大的 CTO 也有重大的管理責任與影響力。維護你塑造業務方向和商業策略的能力,意味著要安排人手去解決你認為會影響業務的問題。其他高管會對技術有自己的想法和需求,CTO 必須保護技術團隊不會淪為純粹的執行部門(execution arm),同時也要照顧技術團隊自身的需求和想法。

當團隊規模很大,CTO 開始聘用 VP 來管理所有人員時,情況變得棘手。許多 CTO 將所有管理責任都交給 VP,有時甚至讓 VP 不向自己彙報。

注意: 放棄管理責任就等於放棄隨之而來的權力。沒有業務策略的影響力、沒有分配人力到重要任務的能力,你充其量只能仰賴對其他高管的個人影響力,最壞的情況就是成為一個虛位(figurehead)。沒有管理權的 CTO 必須純粹靠影響力來推動事情,如果管理者不願意撥出人力和時間去處理 CTO 認為重要的領域,他就失去了實質的力量。

對有志成為 CTO 的人的建議#

CTO 首先是一份商業策略的工作,其次才是管理工作。如果你不關心公司在做的生意——如果你不願意為一個大型團隊有效攻克業務承擔最終責任——那 CTO 不適合你。

Ask the CTO:我適合哪個角色?

工程領導的各種頭銜確實令人困惑。以下是幾個自我檢視的問題:

你可能適合 CTO 路線,如果你:

  • 考慮過某天共同創辦一間公司
  • 想監督技術架構並設定演進的流程與方針
  • 願意深入了解商業面,讓技術架構紮根於公司成長
  • 願意參加外部活動、演講、客戶銷售、招聘高階管理者和工程師
  • 願意管理和指導資深個人貢獻者

你可能適合 VP of Engineering 路線,如果你:

  • 享受管理人員
  • 享受讓工程流程更有效率
  • 喜歡對團隊工作有廣泛視野並參與排定優先順序
  • 對組織結構著迷
  • 善於與產品經理合作
  • 願意放棄技術細節的深度,換取對整體團隊效能的關注
  • 寧可參加路線圖規劃會議而非架構審查

成為 CTO 的最快途徑是做技術共同創辦人(但這只保證你的職位,前提是你與新創一起成長)。成為 VP of Engineering 的最快途徑是在大型組織獲得管理經驗,然後加入成長中的新創。

作者的 VP of Engineering 曾給她一條建議:「想成為 CTO(或 VP of Engineering)就像想結婚。記住不只是頭銜,公司和人也很重要。」頭銜絕對不是一切。

優先順序的變動#

某天早上,CEO 靈光一現,看到公司開發新產品線以推動業務成長的機會。她勾勒出願景、向高階領導團隊呈現,大家都同意開始行動。但事情不會立即發生:有進行中的專案要處理、有即將完成不忍放棄的工作。這些顧慮讓團隊遲遲未集結到新計畫上,直到突然一個質問降臨:「為什麼你們還沒在做最高優先事項?」

為什麼優先順序變更會出問題#

高層領導者可能忘記團隊有數週或數月前規劃好的長優先順序清單。當他們看到機會或認為組織的優先順序需要改變時,往往期望變化立即發生,而不考慮當前的實際狀態。

你需要自問(也問你的團隊)的幾個關鍵問題:

  • 你知道最高優先事項是什麼嗎?
  • 你的團隊知道嗎?
  • 團隊中的開發人員知道嗎?

有時候答案純粹是溝通問題:你不知道最高優先事項是什麼,或者你沒有清楚且急迫地傳達給管理團隊,而他們也沒有清楚且急迫地傳達給開發團隊。

技巧: 「說某件事是最高優先」和「真正在時間表上做出取捨,讓人們開始行動」是完全不同的兩件事。你需要明確地逐一檢視進行中的項目,並砍掉或延後其他工作來為新的優先事項騰出空間。

如何處理優先順序衝突#

  • 向上溝通現實情況:上層和其他組織的人不了解你的團隊目前在做什麼以及為什麼。當你被質疑沒有聚焦在對的優先事項上,這代表你和 CEO 對現實的理解不一致,需要取得共識
  • 準備好雙向推動:如果你認為大型專案應該完成後再插入新工作,盡可能收集該專案的價值、現狀和預期時程的細節,並且要務實——如果上層已經急迫到願意進行這個對話,你很可能需要妥協
  • 明確傳達影響清單:要求團隊列出變更會影響的專案,這會迫使管理團隊真正思考新計畫並開始規劃
  • 賣出這個變化:不要只是傳達壞消息,試著將變化包裝成正面的方向

溝通的三次法則#

重點: 絕對不要低估一件事需要被說多少次、用多少種方式說,才能真正被吸收。大型組織中的溝通很困難。根據作者的經驗,多數人需要聽到至少三次才會真正理解。你要告訴你的高階管理團隊、開全體會議、可能還需要寄 email 說明細節。向上溝通同樣如此——當你希望老闆採取行動,預期你需要告訴他三次。前兩次問題可能自行解決,但第三次表示需要更大的介入。

組織越大,優先順序的改變就越慢。如果你在一個成長中的新創工作,CEO 是創辦人,這種緩慢會讓他很挫折。你能做的最好事情是主動讓 CEO 了解正在發生什麼以及為什麼,展示你理解他的優先順序,並告訴他你正在採取的具體步驟。

制定策略#

作者在 2014 年夏天擔任 Rent the Runway 的 SVP of Engineering 時,面臨一個重大挑戰:CEO 告訴她,想在下次董事會上提名她升任 CTO,但作為晉升的一部分,她需要向董事會報告技術策略。CEO 退回了她的多次嘗試,直到她最終創建出一份符合標準的策略文件。

這個過程讓她從只有模糊的策略概念,進化到擁有一份具體的、前瞻性的策略,涵蓋技術架構和工程團隊結構的思考方式,最終影響了公司整體的組織策略。

步驟一:大量研究#

團隊、現有技術和公司出發:

  • 詢問工程團隊的痛點在哪裡
  • 詢問各領域高管對未來成長的預期
  • 自問:現在和未來的擴展挑戰在哪裡?
  • 檢視工程團隊的生產力瓶頸
  • 研究技術發展趨勢,思考它們如何適用於公司

步驟二:結合研究與想法#

利用對現有系統、團隊和瓶頸的結論,以及對可以提升效率、擴展功能或改善業務的想法,構思一個可能的未來。花時間獨自在白板前,畫出公司的系統,用不同維度切割系統與團隊——例如面向客戶 vs. 面向內部營運、後端 vs. 前端。

步驟三:擬定策略#

有了資料的映射,就可以規劃出提升營運效率、擴展功能和成長業務的可行方案。考量系統之間資訊共享的擴展或限制、不同的產品和營運屬性如何在資料流中交互使用。所有這些思考都迫使你考量業務結構、客戶需求(內部與外部)和可能的未來演進

步驟四:考量溝通風格#

作者的第一次嘗試被退回了兩次:

  1. 策略不夠成熟:幾乎全是系統和架構細節,缺少超越 6-12 個月的前瞻想法,也沒有嘗試解決驅動團隊成功的商業因素
  2. 投影片風格不對:作者身為講者,習慣製作精簡的投影片。但這個董事會需要資訊密集的投影片——董事會成員通常在會前閱讀投影片,以便會議聚焦於討論細節

技術策略的本質#

重點: 好的技術策略不僅包含技術架構,還包含團隊結構、對業務基礎和方向的理解。對於產品導向公司,技術策略的核心是**「促成業務的多種潛在未來」(enables the many potential futures of the business)。它不是決定產品方向,而是讓更大的路線圖能夠成功實現。它不是只回應當前問題的反應性文件,而是預見並促成未來的成長**。

制定策略最難的部分是開始。第二難的是在高度不完美的資訊下對未來做出猜測。經歷這個過程後,領導方式從被動(面對已知環境做計畫)轉變為前瞻性(有了對架構、團隊和公司需要前往何處的想法),管理也因此在許多方面變得更容易。

挑戰情境:傳達壞消息#

身為管理者,你總會遇到必須傳達壞消息的時刻——裁員、團隊解散、不受歡迎的政策變更、路線圖大幅調整。作為高階領導者,你必須精通向大型團體傳達敏感資訊。

不要做的事#

  • 不要用非個人化的方式群發訊息:透過 email 或 chat 傳達壞消息是最糟糕的方式,尤其是可以留言評論的媒介。第二糟糕的方式是把所有人集中在一個房間裡一次說完——結果仍然不夠個人化,難以觀察每個人的反應,而且一兩個非常不高興的人可以迅速帶動整個團隊的情緒
  • 不要強迫自己傳達你無法認同的訊息:如果你強烈反對某個變更,到了無法在傳達時不洩露立場的程度,可以請另一位高管或 HR 協助,或將訊息傳達給你信任的副手由他來分享

應該做的事#

  • 盡量一對一溝通:思考誰會有最強烈的反應,為他們量身調整訊息。給他們一對一的空間去反應、提問。需要時明確表示這是命令,你需要他們支持變更。如果需要向整個組織傳達,先跟管理者溝通、給他們 talking points,再讓他們向各自團隊分享,最後才召開全體會議
  • 對可能的結果誠實:如果是裁員,承認過程不愉快但每個人都需要公司存活;如果是團隊解散,指出團隊至今的成就和使改變成為正確方向的因素,強調新的學習和成長機會
  • 換位思考:想想你希望別人如何告訴你這類消息。你辭職時怎麼做的?你大概會面對面拉人到旁邊先告知。在某些情況下,可以帶著優雅慶祝這些悲傷的變化
Ask the CTO:我有一個非技術背景的老闆

第一次向非技術主管匯報可能是一場文化衝擊。以下是管理這段關係的最佳實踐:

  • 不要用術語藏匿資訊,注意細節用量:你的新老闆很聰明,但可能沒有耐心聽技術術語,也不太想聽大量細微的技術決策細節。學會區分哪些資訊有價值、哪些不需要溝通
  • 主動準備一對一會議:忙碌的高管很難安排時間,不要浪費你得到的 1-1 時間。永遠帶著準備好的議題來,如果難以確保 1-1 時間被尊重,提前寄出議程提醒老闆你需要他的注意力
  • 帶來解決方案,而非問題:CEO 通常不想聽到事情如何失敗、你與同儕的分歧或管理困難。如果你的 CEO 不想聽太多問題,接受你不會從他那裡得到太多管理方面的指導,去其他地方尋找。但也不要逃避傳達壞消息
  • 請教建議:這看似與「帶來解決方案」矛盾,但沒有什麼比請教建議更能展現尊重。老闆可能不想替你解決問題,但如果你把它包裝成需要建議,他會很樂意提供回饋
  • 不要害怕重複:如果你提出了重要議題卻似乎被遺忘,再提一次。你可能需要重複幾次才能獲得推進力。三次通常是魔法數字
  • 表達支持:總是問還有什麼你能做的來幫忙。盡可能展示你在支持老闆和公司
  • 主動在外部尋找指導與技能發展:你不再有一位 manager,你有的是 boss。第一次擔任高階領導職位時,你可能仍需要技能發展——找一個 coach、申請培訓、在公司外建立同儕群體來支持你

其他職能的高階同儕#

進入高階管理後,最重要的領悟之一是你需要與領導團隊中其他人建立的關係。高階領導者必須積極實踐 first-team focus(首要團隊焦點,在第六章介紹過):首先致力於業務及其成功,其次才是透過部門的成功來貢獻整體業務。

尊重各自的領地#

跨職能同儕合作的基礎:讓他們擁有自己的領域,他們也讓你擁有你的。如果你不同意某位同儕在她專業領域內的管理風格,但這不直接影響你的團隊,就把它當作好朋友交了你不太喜歡的對象一樣——除非她主動請教,否則盡量不要介入,即使選擇討論也要帶著善意。

意見不合的適當場合是一對一或領導團隊會議。這些會議是你們討論策略分歧、公司挑戰和方向設定細節的地方。

建立根本信任#

Patrick Lencioni 在 The Five Dysfunctions of a Team 中指出,缺乏信任是團隊的根本功能障礙。在此,信任意味著相信你的同儕確實在為組織盡力,而不是在操弄局勢、暗中破壞你、或只是想自行其是。

建立這種根本信任非常困難。你很可能會與部分(甚至全部)同儕產生某種程度的文化衝突。常見的衝突包括:

  • 分析驅動型 vs. 創意直覺型之間的衝突
  • 擁抱敏捷與變化(甚至某種程度的混亂)的人 vs. 偏好長期規劃、截止日期和預算的人

注意: 工程師經常在尊重和與多元同儕有效溝通的過渡上掙扎。當前的科技文化告訴我們工程師是房間裡最聰明的人——你那些不以分析思維為主的同儕不是愚蠢的。同時,當我們向不熟悉技術的同儕丟出術語時,反而讓自己顯得愚蠢。我們需要學會用聰明但非技術的同儕能理解的方式溝通工作的複雜性。

沉默之錐(Cone of Silence)#

在領導團隊中的分歧不應該傳到更廣泛的團隊。一旦決策做出,就要承諾執行,在工程團隊和公司其他人面前展現統一戰線。當你無法如願、覺得反對意見沒有被聽見時,放手是困難的。但在這個層級,你必須決定是服從還是離開——公開反對同儕只會讓所有人的情況更糟。

回聲效應(The Echo)#

作為組織中最高階的人,你會被比以往更密切地注視。你的存在讓人們將所有注意力聚焦在你身上。他們尋求你的認可、試圖避免你的批評。

你不再是團隊的一員#

你的 first team 現在是領導/高管層的同儕,你的直屬團隊已成為 second team。如果你成功地轉換了心態,你會在社交上開始與整體組織保持一些距離:

  • Happy hour 只去喝一杯就離開,讓團隊自己社交
  • 不要定期與你的整個組織在工作時間外過度社交

為什麼需要保持距離#

避免被控偏心:如果你與向你匯報的人維持非常強的社交聯繫,你很可能會偏心。這會讓整個團隊不開心,也讓你的工作更困難。

讓你的話語有份量:領導效能需要人們認真對待你的話。一句隨口的評論就可能讓人們改變整個工作重心。如果你試圖維持「好朋友」的形象,下屬會難以區分朋友在想出聲和老闆在下指示。

注意你在場的影響:作為高階領導者,你會吸走房間裡所有的氧氣。你的存在會改變會議的基調和結構。如果你不小心,可能因為在臨時加入的會議中即興想法就改變了一個專案的方向。你不再是那個可以拋出想法讓人評估、可能被否決的團隊成員了。

你是文化的塑造者#

如果你曾與在 Apple 和 Steve Jobs 共事過的人交談,他們很可能會提到「Steve」對他們專案的影響。Apple 的員工會用 Steve 的形象來支持或反對決策,作為組織的道德指南針。你建立和強化的文化也會對公司產生類似的效果:

  • 如果你吼叫,他們就學到吼叫是 OK 的
  • 如果你公開犯錯並道歉,他們就學到犯錯是可以的
  • 如果你總是對專案問同一組問題,人們就開始自己問那些問題
  • 如果你公開重視某些角色勝過其他角色,有企圖心的人就會去爭取那些被重視的職位

保持距離但不失人性#

你不再是「團隊的一員」,但這不代表你應該停止關心團隊中的個人。花時間認識盡可能多的人——問他們的家庭、嗜好、興趣——這能讓他們感受到自己是一個關心他們的群體的一部分。

隨著你與團隊更加疏離,很容易開始去人性化,把人當成齒輪。人們感受得到。當領導者不再關心組織中的個人,他們就更不願意全力以赴、承擔風險、在困難中堅持。

技巧: 即使是表面層次的個人連結,也能強化你確實關心他們的訊號——不只是他們的專案或工作產出,而是知道他們在工作之外也是一個人。你是一個角色模範。你想培養什麼樣的領導者?你想留下什麼樣的遺產?

以恐懼統治 vs. 以信任引導#

作者分享了一個故事:

Camille——技術能力強、有魅力、能做決策也能把事情做好。但她有時脾氣不好,當人們達不到她的期望或事情出錯時,她會明顯惱怒、公開發怒。她沒有意識到這種犀利和急躁正在讓人們害怕她。人們不想冒著被怪罪失敗或被公開批評的風險,所以他們減少承擔風險、隱藏錯誤。Camille 無意間創造了一種恐懼文化。

Michael 同樣是一位好的領導者,但他善於保持冷靜。當事情不順利時,他不是變得緊張和憤怒,而是變得好奇。他的第一直覺是提問,這些問題往往讓團隊自己意識到哪裡出了問題。

這個故事是真的——Camille 就是作者自己。以下是她成為高階領導者後的第一份績效評估摘錄:

來自績效評估的警告: 「即使是在你的團隊中愛你的人,也承認害怕你和你可能的批評。人們不敢在你面前冒險或失敗,因為他們害怕被當眾斥責。你的攻擊造成了一種文化,讓團隊成員不敢接觸你、不敢問你問題、不敢向你尋求回饋——這又導致一個惡性循環:你不信任他們,他們犯更多錯。」

恐懼文化的根源#

恐懼文化可能來自:

  • 高度重視「正確」和「遵守規則」
  • 對基於層級的領導有強烈傾向
  • 來自公開衝突被容忍甚至鼓勵的環境(如金融業、工程文化中的公開辯論)

當你是領導者時,動態改變了——那些在你是個人貢獻者時可能會反擊的人,現在會感到被威脅。

如何矯正恐懼文化#

練習建立關聯(Practice relatedness)

恐懼文化的一個標誌是傾向於非個人化地對待他人。如果你太注重效率,一見面就直奔問題、不花時間閒聊、不把團隊當作人來認識,你就不會與他們建立個人關係。如果你希望團隊能安心地冒險和犯錯,核心要求之一是歸屬感與安全感。花一點時間閒聊、了解他們、讓他們也了解你。

道歉

當你搞砸了,道歉。練習誠實而簡短地道歉:

  • 「我很抱歉,我不應該對你吼叫,我的壞行為沒有藉口。」
  • 「我很抱歉,我沒有聽你說話,我知道我加重了你對這個情況的挫折。」
  • 「我很抱歉,我犯了一個錯誤,忘了告訴你關於 Bob 的事。」

道歉不需要冗長。簡短地為你在造成負面情況中的角色承擔責任就夠了。說太多往往會變成藉口或轉移焦點。道歉是在告訴團隊:犯錯是可以的,但傷害他人時應該道歉。道歉不會讓你更弱——它讓整個團隊更強

變得好奇(Get curious)

當你不同意某件事時,停下來問「為什麼」。不是每個分歧都在動搖你的權威。當你花時間尋求更多資訊,往往會發現你是在對你不真正理解的東西做出反應。當我們攻擊時,很多人會逃避或關閉,學會向我們隱藏資訊以免被攻擊。當你變得好奇,將分歧轉化為誠實的提問,你能學到更多其他觀點,因為團隊會敞開心扉。

學會追究責任而不把人變成壞人

追究責任不是只有「責任」和「後果」。中間還需要其他要素:

  • 你如何衡量成功?
  • 團隊是否具備成功所需的能力?
  • 你是否在過程中提供回饋?

想想你把一個人或團隊定義為「壞的」是因為他們失敗的那些時刻——你是否對自己讓他們能成功負起了責任?當一切都清楚、每個人都盡了力,你會發現追究責任伴隨著遠少於人格評判的感受。

重點: 恐懼文化在科技業相當常見,且在其他方面一切順利時最能生存。如果你被畏懼但受尊重、公司在成長、團隊在做有趣的工作,你可能暫時沒問題。但如果你失去了任何一個元素,預期有更好選擇的人會離開。努力軟化你的粗糙邊緣、練習關心團隊、保持好奇。建立信任文化需要時間,但成果非常值得。

True North(真正的北方)#

高階領導者有一個常被忽略的核心角色:為其職能領域設定卓越的基準。CTO 為技術設定、CFO 為財務設定,以此類推。作者稱之為 True North

什麼是 True North#

True North 代表特定職能角色在執行工作時必須牢記的核心原則

角色True North
產品領導者首先考慮使用者和他們的需求、盡可能測量和實驗、拒絕不符合團隊既定目標的專案
CFO看數字、看工作成本和潛在價值、確保公司不會意外超支、讓團隊知道何時有超出預算的風險
技術領導者確保做好了進入 production 的準備工作——遵守已同意的程式碼審查、營運監控和測試政策。不會將你不相信已準備好讓使用者體驗的東西推上 production。你在創造你引以為傲的軟體和系統

風險分析的視角#

True North 也可以透過風險分析的鏡頭來理解。風險分析不代表我們不承擔風險。某些通常被認為「不好」的事情,在特定情況下可能是可接受的:

  • 存在單點故障(single point of failure)
  • 有已知的 bug 和問題
  • 無法承受高流量
  • 資料遺失
  • 推出測試不足的程式碼
  • 效能緩慢

在某些情境和公司中,這些風險都是可接受的。但 True North 幫助我們理解:這些議題在推上 production 時必須被仔細考量。規則有例外不代表我們忘記規則的存在。

True North 的組織動力學#

每個職能領域的 True North 略有不同,因此組織中自然會有張力。產品經理可能更在乎使用者體驗而較少在乎 production 維運負擔;財務團隊可能更在乎基礎設施成本而較少在乎可用性風險。這種張力是健康的,因為它迫使我們面對所有的風險,而不只是我們特定職能關心的風險。

成為 True North 領導者#

True North 領導者依賴長年累積的智慧,在沒有時間深入所有細節時做出快速決策。要成為這類領導者,你必須在職涯早期花足夠的時間磨練這些直覺:

  • 保持技術能力
  • 將專案、語言或框架深入學習到超越基礎的程度
  • 即使日常不再寫程式碼,也持續學習新事物

推薦閱讀#

作者書名
Arbinger InstituteLeadership and Self-Deception: Getting Out of the Box
Brene BrownDaring Greatly
Peter F. DruckerThe Effective Executive
Marshall Goldsmith & Mark ReiterWhat Got You Here Won’t Get You There
Andrew S. GroveHigh Output Management
L. David MarquetTurn the Ship Around!

自我評估#

  • 你是否有 professional coach(專業教練)?這在此層級是很好的投資,即使公司不買單。coach 能給你指導和直接回饋
  • 你公司外的同儕支持網絡如何?你認識其他公司的高階管理者嗎?同儕群體幫助你了解其他公司的情況,分享經驗和獲得建議
  • 你特別欣賞哪些技術高階管理者?你欣賞他們什麼?你可以做什麼來更像他們?
  • 回想上次你需要為團隊改變優先順序的經驗。進行得如何?什麼做得好、什麼做得不好?你如何向團隊溝通變化?如果重來,你會有什麼不同做法?
  • 你對公司可預見的未來方向有多了解?你理解幫助達成目標的技術策略嗎?團隊需要在哪些關鍵領域(功能速度、效能、技術創新、招聘等)演進?技術演進推動業務向前的瓶頸或機會在哪裡?
  • 你與公司其他高階領導者的關係如何?哪些好、哪些差?你可以做什麼來改善不好的關係?你有多了解這些同儕的優先順序?他們有多了解你的?
  • 如果我問你的團隊,你和哪些高管處得好、討厭哪些,他們能毫不猶豫地告訴我嗎?當 CEO 或領導團隊做出你不同意的決策時,你能否把分歧拋在腦後並向全公司支持這個決策?
  • 你是否在為團隊樹立榜樣?如果你得知人們每天在模仿你的行為,你會高興嗎?
  • 當你參加團隊的會議時,你是在主導對話還是更傾向於聆聽和觀察?
  • 你上次問一個不常交流的人關於他工作以外的生活是什麼時候?上次有人請病假時,你有花一分鐘祝他早日康復嗎?
  • 你希望資深工程師在評估工作和做決策時考量的基本原則是什麼?或者,如果你更聚焦於組織而非技術,你希望管理者在領導團隊時遵循的基本管理原則是什麼?