領導力 - 幫助的難題

· tech

#leadership

📑 目錄

幫助的難題

上一篇收在「激勵的起點是先看懂人」。看懂之後呢?最自然冒出來的衝動就是幫——他卡住了,我看得到問題,我出手。這章(Ch12–13)潑的就是這盆冷水:幫助本身就是難題,而且幫得越熱心,越容易踩坑。

Weinberg 對幫助的幾句判詞,一句比一句不留情:

  1. 對方不想要的幫助,永遠不會成功——不管你多聰明、方案多正確。
  2. 有效的幫助,始於雙方對問題的定義一致——你以為在幫他解 A,他覺得問題是 B,你的幫助就只是干擾。
  3. 同意被幫,不是終身契約——這次要,不代表以後都要;開頭要,不代表到尾都要。
  4. 最狠的一句:每個「幫忙」,都同時在幫助幫的人自己——helper 都有自利的成分,而且每個人都覺得自己是例外。

三道閘門

把這幾句判詞疊起來,想幫的衝動要連過三道閘門,才會變成真正的幫助——任何一道沒過,它就會變成別的東西:

① 他要嗎? ② 問題定義一致嗎? ③ 幫他,還是幫我? 想幫的衝動我看到問題了! 真正的幫助對方也這麼覺得 沒過 → 打擾 沒過 → 雞同鴨講 沒過 → 搶戲 幫助是不是幫助,由被幫的人認定——不是由出手的人
想幫的衝動要過三道閘:沒人要的幫助是打擾,問題對不上的幫助是雞同鴨講,餵自己成就感的幫助是搶戲

閘門一擋掉的是沒人要的幫助。出手前先問——真的用嘴問,不是自己覺得「他一定需要」。而且問過一次不算數:同意被幫不是終身契約,幫到一半對方想自己來,就放手。

閘門二擋掉的是對錯問題的幫助。這是沒問題綜合症的幫助版:對方一開口你就覺得「我懂了」,急著給答案,卻沒確認他真正卡的地方。有效的幫助始於雙方對問題的定義一致——先花一分鐘對齊「你要解的到底是什麼」,常常比直接給十分鐘的答案更有用。

閘門三擋掉的是其實在幫自己的幫助。這道最難,因為它要你承認一件不舒服的事:想幫人的衝動裡,混著「證明自己有用」的成分——而每個人都覺得自己是例外。Weinberg 的建議不是消滅這個成分(消滅不了),是看見它:知道這次出手有幾分是為了對方、幾分是為了自己的成就感,幫助才做得乾淨。

工程團隊最常見的撞閘現場

junior 卡關,你走過去看了三十秒就看出問題,手癢:「我幫你弄。」鍵盤接過來,十分鐘解決。

三道閘一次全撞:他沒說要你接手(閘門一);他要的可能是「學會下次自己解」,你解的是「這段 code 快點好」(閘門二);而那十分鐘裡最爽的人是你——流暢地展示了自己有多快(閘門三)。code 是好了,但他下次還是不會,而且多學到一件事:卡住的時候會有人把鍵盤拿走。你以為你在幫助,其實你在沒收他的學習機會。

學著當激勵者:先看懂自己

Ch13 談怎麼練成激勵者,方向卻是往內的:先搞懂自己被什麼驅動、被幫助或被激勵時是什麼感受——因為你對「人為什麼會動起來」的所有直覺,樣本數為一,就是你自己。不先把這個樣本看清楚,你就會把自己的動機模型套到所有人身上——那正是上一篇說的「把人當電腦」的溫柔版:把人當跟你同款的電腦。

反思

我的動機長什麼樣子

先交代自己這個樣本。最近玩 LoL 有個發現:我寧願玩很難操作但有趣的角色輸,也不要玩無聊的角色贏。而且名單很誠實——我不玩石頭人、好運姊、凱莎,我選 Irelia、達瑞文、煞蜜拉。

拆開看,這兩組的差別不是強弱,是表現的天花板長在哪。石頭人是經典的「按 R 就有貢獻」,角色自帶保底;達瑞文要自己接斧頭才有傷害,煞蜜拉的連段系統根本是遊戲在幫你的操作打分數。在零利害的場合——沒有績效、沒有觀眾——我的偏好函數露出原形:連贏都要「可歸因給自己的贏」。玩達瑞文贏了,沒人能說是角色帶飛;玩石頭人贏了,我自己都無法證明那是我的實力。這跟挖願景時的 A3/B9 完全同構:我是 mastery 驅動的,結果只是防偽標籤。

這就是 Ch13 要的第一步:我現在講得出自己被什麼驅動——所以也講得出哪些任務會讓我熄火:照抄就好的、無法歸因的、沒有東西可鑽的。

別逼達瑞文玩石頭人

但看懂自己的下一步,是承認別人可能是另一款。

團隊裡有人玩達瑞文,也有人玩石頭人——有人被「穩定把事情做好、看到明確的贏」驅動,把需要穩定產出的任務交給他,他做得又快又安心;你硬塞一個開放式的鑽研題給他,他只覺得焦慮。反過來,mastery 驅動的人拿到照 SOP 走的任務會直接熄火。派任務其實就是幫每個人選英雄——而最常見的錯誤,是 Leader 照自己的英雄池幫全隊選。

我自己要特別提防的就是這個:因為我是達瑞文型,我會下意識覺得「有挑戰的任務=好任務」,把它當獎勵發——但對石頭人型的成員,那不是獎勵,是懲罰。上一篇說 KPI 是用同一把尺量所有人;用自己的動機當預設值,是用同一支英雄打所有位置——同一種偷懶。

重讀一次「我才是小丑」

最後把 clean architecture 那件事再拿出來照一次——那次我已經認過「沒看懂就判定」的錯,但用這章的閘門再照,它還有另一層:那也是一次沒人要的「幫助」。

沒有人請我把他的架構改掉——我自認在「幫專案守住一致性」(閘門一,撞)。他要解的問題是「讓 domain 邏輯不被 ORM 綁死」,我處理的問題是「跟現有 code 長得不一樣」(閘門二,撞)。而現在誠實地說,那次出手裡混了多少「守門人的自我感覺」?不少(閘門三,撞)。同一件事,btl-7 照出「殺點子」,這裡照出「假幫助」——自以為的幫助,常常就是點子被殺的現場:凶器不是惡意,是熱心。

所以這章我帶走的判準跟上一篇是同一條線:出手幫忙之前,先過三道閘——他要嗎、問題對齊了嗎、這次是幫他還是幫我。想幫是本能,幫得成是修煉;而修煉的第一步,跟這個系列每一課一樣——先看懂,這次是看懂「幫助」這件事本身。