責任引擎:為什麼無用的工作實際上主導著世界

責任引擎:為什麼無用的工作實際上主導著世界
簡而言之:看起來有生產力的工作往往是裝飾性的。看起來裝飾性的工作往往是承重的。在小型自營企業中,每個人都專注於利潤。在有代理人與委託人分離的大型組織中,每個人都專注於不被指責。現代工作的整個機制——委員會、顧問、流程層級、簽核鏈——主要存在的目的是為了分散責任。理解這一點並不會讓你變得憤世嫉俗,而是讓你變得更有效率。
這裡是詹姆斯,水星科技解決方案的首席執行官。 香港 — 2026年7月
一位讀者寫信給我,提出了一個真實的難題。他們在工作中被邊緣化,晉升被忽視,並被同事視為天真的人——在讀者看來,這些同事根本沒有做任何有用的事情。
讀者的抱怨:"這些人創建的報告沒有人閱讀。他們召開的會議沒有產生任何決策。他們建立的流程使一切變得緩慢。這些工作為什麼存在?"
我的回答:因為這個組織並不是想賺錢。它想要不被責怪。
這是兩個完全不同的優化函數。大多數人花了一生的時間在錯誤的優化上。
兩個引擎
每個組織都運行在兩個引擎之一上:
引擎 A:利潤引擎
• 擁有者經營
• 行動與結果之間的直接反饋循環
• 明確的指標:收入、利潤、現金流
• 失敗模式:破產
• 獎勵對齊:完美
引擎 B:問責引擎
• 代理人-委託人分離(經理不擁有公司)
• 行動與結果之間的延遲、嘈雜反饋
• 模糊的指標:"利害關係人對齊"、"風險緩解"、"治理"
• 失敗模式:被解雇,而不是讓公司倒閉
• 獎勵對齊:破裂
角落的燒烤攤?引擎 A。擁有 40,000 名員工的《財富》500 強公司?引擎 B。
在引擎 A 中,如果你提供劣質肉類,你會失去顧客並破產。反饋是立即的。老闆會在錢包中感受到這一點。
在引擎 B 中,如果你做出錯誤的決策,會發生什麼?也許股票在六個月內下跌 2%。也許競爭對手先行推出。也許根本沒有任何明顯的變化。反饋延遲且雜訊太多,以至於你無法從中學習。
那麼,當人類無法從結果中學習時,他們會怎麼做?他們會優化 看起來正確的輸入。他們會優化 過程。
擴散機器
這就是引擎 B 實際運作的方式。核心問題是:如果你做出決策而失敗,你就會暴露在外。如果你做出決策而成功,你可能會獲得一些讚譽——但可能不會像你希望的那樣多。這種不對稱性非常殘酷。
所以理性的做法不是做出更好的決策,而是以一種沒有人可以責怪你的方式做出決策。這創造了三種組織技術:
This creates three organizational technologies:
1. 責任的劃分
做一個簡單的決定。我們應該推出產品 X 嗎?
在引擎 A 中,擁有者決定。如果失敗,他們承擔損失。如果成功,他們保留利潤。乾淨利落。
在引擎 B 中,會發生以下情況:
• 市場研究團隊 進行調查。他們產出了一份 40 頁的報告。
• 策略團隊分析報告。他們產出了一份20頁的備忘錄。
• 財務團隊建模預測。他們產出了一個包含12個情境的電子表格。
• 風險委員會審查情境。他們產出了一份風險評估。
• 這個 執行委員會 會審查上述所有內容。他們做出決定。
現在產品推出了。它失敗了。
誰負責?
• 執行官?「我的決策是基於四個團隊的全面分析。」
• 策略團隊?「我們依賴市場研究數據。」
• 市場研究團隊?「我們抽樣了1,000名消費者。抽樣本身有固有的限制。」
• 財務團隊?「我們的模型方向上是正確的。市場發生了變化。」
• 風險委員會?「我們標示了不確定性。」
沒有人負責。責任已經在五個層級之間擴散。
這不是無能。這是設計。組織已經演變出一種結構,使得責任在建構上變得不可能。
2. 外部防護
內部擴散是不夠的。你還需要外部驗證。
輸入:顧問、審計師、產業分析師、外部審查委員會。
推出產品 X 的決定?這不僅僅是內部審核過的。它經過麥肯錫的審查。由德勤驗證。獲得高德納的支持。
現在當它失敗時:
「我們遵循了最佳實踐。我們聘請了頂尖顧問。甚至專家們也搞錯了。」
外部專家是由代理人(管理層)支付,而不是委託人(股東)。他們的動機是提供掩護,而不是事實。他們是問責機制的一部分,而不是對其的監督。
這就是為什麼顧問公司蓬勃發展的原因。不是因為他們比員工知道得更多。因為他們出售 責任保險。
3. 敘事機器
最後一個組件是故事講述。引擎 B 依賴於將隨機性轉化為策略的敘事。
成功敘事:
• 產品成功了
• 因此過程是正確的
• 因此領導者是有遠見的
• 因此團隊是世界級的
• 撰寫哈佛商學院案例研究
失敗敘事:
• 產品失敗了
• 但過程是嚴謹的
• 市場是「具挑戰性的」
• 團隊「學到了寶貴的教訓」
• 這次失敗是「戰略學費」
• 領導者「承擔了計算過的風險」
注意到不對稱性。成功驗證了個人。失敗驗證了過程。
這就是為什麼你會看到相同的高管向上失敗。他們並沒有成功。他們成功於 敘述 他們以一種分散責任的方式失敗。
是的,部長原則
有一部1980年代的英國情境喜劇叫做 是的,部長. 瑪格麗特·撒切爾喜歡這個節目。這個節目描繪了一位無知的政治家(部長)和一位才華橫溢的公務員(漢弗萊爵士)。
部長想要「做事情」。漢弗萊爵士想要「確保事情正確地完成」。
每一集都遵循相同的模式:部長有一個想法。漢弗萊解釋為什麼這不能做、不應該做,或者必須先通過十七個委員會才能做。部長放棄了。漢弗萊獲勝。
觀眾同情部長。他是行動者。漢弗萊是障礙。
但這個節目實際上展示的是:漢弗萊不是障礙。他是承重牆。
沒有漢弗萊,部長會做出決策,有些會失敗,部長會被解雇。政治系統無法容忍這種程度的波動。因此,它演變出了漢弗萊——那些整個功能是減緩進程、增加流程,並確保當失敗發生時,它是緩慢且無可指責的。
寫信給我的讀者?他們是部長。他們的同事是漢弗萊。而讀者認為漢弗萊是無用的,因為他們不理解組織實際上在優化什麼。
軍事平行
這樣想:實際的戰爭是 10% 戰鬥和 90% 物流、情報、協調和政治操作。
衝上山丘的士兵看起來英勇。確保彈藥準時到達的軍需官看起來無聊。但沒有軍需官,衝鋒就會失敗。
在引擎 B 組織中,「漢弗萊」角色——合規、流程、治理、風險、通信——就是軍需官。他們看起來似乎什麼都沒做。但他們卻在支撐整個系統。
讀者看到同事們在寫報告,並想:「這是做無用功。」
那些同事實際上在做的事情:建立敘事基礎設施,使組織能夠在不崩潰的情況下吸收失敗。
當一個項目失敗時,組織不會問「誰決定的?」而是問「我們遵循流程了嗎?」如果答案是肯定的,組織將繼續。如果答案是否定的,則會有人下台。
所以看起來像是官僚主義的實際上是 組織免疫反應。這並不高效,也不優雅。但它讓有機體存活下來。
唐吉訶德問題
讀者真正的錯誤不是他們錯誤地認為同事不生產,而是他們認為生產力是重點。
他們就像唐吉訶德衝向風車。他們看到「工作」就認為這意味著「產出」。在引擎B中,工作意味著「產生 防禦能力。」
寫報告卻沒有人閱讀的同事?他們正在產生審計追蹤。召開不必要會議的同事?他們正在產生共識文件。因流程而拖延決策的同事?他們正在產生責任擴散。
從引擎 A 的角度來看,這一切看起來像是浪費。從引擎 B 的角度來看,這正是整個重點。
這對你的職業生涯意味著什麼
我不是說引擎 B 是好的。我是說它是真實的。如果你在裡面運作,你有三個選擇:
選項 1:離開去引擎 A
加入一家初創公司。創辦自己的事業。在一個小到擁有者和經營者是同一個人的地方工作。反饋迴路緊密。責任是真實的。工作是真正的工作。
取捨:較少的穩定性、某些維度的上限較低、更高的變異性。
選項 2:學會操作引擎 B
如果你待在大型組織中,停止與漢弗瑞抗爭。開始理解他們。
• 在提出任何建議之前,繪製責任鏈。誰會支持你?誰會受到牽連?誰可以因與能力無關的理由否決你?
• 在需要之前建立聯盟。決策通常在會議上 "決定" 之前就已做出。
• 記錄所有事情。不是因為你偏執,而是因為當事情出錯時,敘述成為現實。
• 學會講風險、治理和利益相關者對齊的語言。這不是出賣自己,而是翻譯。
選項 3:成為橋樑
在引擎 B 組織中,最有價值的人是那些能夠說兩種語言的人。他們可以像引擎 A 操作員一樣執行任務,並像引擎 B 生還者一樣敘述故事。
他們建造事物。但他們也建立了 故事,講述事物是如何被建造的。他們創造價值。但他們也創造了 文件記錄,證明價值的創造。
這不是虛偽。這是雙語能力。你正在講述你所處組織的語言。
古老的智慧
孔子在2500年前就明白這一點:「如果名稱不正確,語言就不符合事物的真相。如果語言不符合事物的真相,事情就無法成功進行。」
用現代的說法:在你建立了從事工作的合法性之前,你無法進行工作。
漢弗瑞一家並不是在阻止行動。他們確保當行動被採取時,它具有合法性的名稱。這個過程。這些文件。這個共識。
沒有這個名稱,任何成功都是脆弱的。任何失敗都是致命的。有了這個名稱,成功就被制度化,失敗則是可以生存的。
寫信給我的讀者認為他們的同事「沒有在做真正的工作。」他們忽略了:他們的同事正在做這個基礎的工作。這項工作使所有其他工作成為可能。
不是在建造一些有用的東西。而是在建造一些可辯護的。
最終重塑
這裡有一個不舒服的真相:世界並不是分為「做事的人」和「胡說八道的人」。
這分為了解自己所處引擎的人——並相應地進行優化——和不理解的人。
這些「廢物工作」並不是廢物。它們是防止引擎 B 卡住的潤滑劑。它們是以代理人-委託人分離的方式大規模運營的成本。
這不是對官僚主義的辯護。官僚主義是浪費、使人沮喪,並且往往是邪惡的。但它並不是不理性。它是有原因演變而來的。在你理解這個原因之前,你將繼續與風車作鬥爭,而漢弗萊斯則掌控著世界。
停止詢問為什麼無用的工作存在。開始詢問它們在問責引擎中扮演什麼角色。
然後決定你想要花一生待在哪個引擎中。
水星科技解決方案:加速數位化。
Originally published on MTS Blog & Research