領導力 - 發想力

發想力

前面談過擋住創新的三道牆,也談過用日記拆掉第一道牆——但牆拆掉之後呢?點子要從哪裡來?

這章給的答案是:發想力(idea power)是一種可以練的技能,不是天分。而且更反直覺的是——Leader 對團隊點子的最大貢獻,往往不是「自己想出點子」。把創新想成「等某個天才靈光一閃」,就會漏看 Leader 真正該做的事:養一條活的點子流——讓點子進得來、被打磨、活得到被看懂的那一刻。

點子不必原創:偷

最直覺的貢獻是自己丟點子——但那只是五分之一。第二種貢獻是偷:創造性的借用改良。別的團隊怎麼解類似的問題?開源專案怎麼設計這一塊?別的領域有沒有現成的模式?拿過來,改到適合自己的環境,就是一個好點子。

工程師其實天天在做這件事——查資料、讀原始碼、抄設計模式——但一到「提案」的場合,很多人又突然覺得點子必須從零長出來才算數。會有這種原創迷思,骨子裡還是相信問題只有一個正解:好像別人已經給過解答,這題就結案了。實際上點子很少憑空長出來——能把別人的解法接到自己的土壤上活起來,本身就是發想力。

加工:比原創更常發生的貢獻

點子剛出生時幾乎都是半成品——連提出的人自己都只看到一半。所以第三種貢獻是幫別人的點子加工:補上一個沒想到的 edge case、接上一個現成的工具、指出可以先做哪一小塊來驗證。

一個點子最後上線的樣子,通常已經是好幾個人加工過的合體——這時候誰是「原創者」早就不重要了。願意把力氣花在別人的點子上,而不是堅持場上留著自己的名字,團隊的點子流才會活。

放下自己的點子

五種貢獻裡最難的一種——因為要跟自己的 ego 打架。

難就難在:「更好」從來不是絕對的。一個點子夠不夠好,是相對於「這個團隊、此刻、養不養得起它」——效能再好,團隊維護不動,在這個團隊裡它就不是好解法。這正是 organic 思維說的:點子的價值長在環境裡,不是掛在點子身上。

所以放下自己的點子,不一定代表「我輸了」——更多時候只是「現在的我們,適合另一個」。這句話我不是從書上讀懂的,是用好幾年的自我懷疑換來的,故事留到反思講。

殺點子的話,和怎麼接

點子最脆弱的時候,就是剛出生的時候——一句話就能殺死它。殺人句長得都很像:用過去或現況,直接否決一個還沒被看懂的未來。

殺人句	換成
「我們以前試過了」	「上次試是什麼情境?現在有什麼不一樣?」
「這行不通」	「要讓它行得通,還缺什麼?」
「全專案都這樣做」	「它想解的問題,我們現在有沒有?」

左邊是句點,右邊是問號——差別只在一句話,但左邊殺掉點子,右邊逼大家先把點子看懂。Leader 的第五種貢獻,就是在點子還站不穩的時候當那把傘:先擋住這些話,讓點子至少活到被看懂的那一刻。看懂之後要淘汰,再淘汰——那是判斷;看都沒看懂就否決,那只是反射。

反思

這章的兩種貢獻——「放下自己的點子」和「不讓點子被殺」——我剛好各有一個刻骨的故事:一次我是被殺的那方,一次我是拿刀的那方。照 上一篇日記的格式寫:事實、感受、教訓。

被殺的一方:訂單統計

事實:多年前我在外送平台,公司辦了一個活動,讓 app team 的人來做做看後端的事:同一個 feature 由幾個人各自設計、各自實作,最後挑一組上線。我拿到的題目是訂單統計。資料庫是 MongoDB,我用 ORM 的 aggregation pipeline 把整個統計在資料庫端一次算完、直接回傳;另一位同事則是分段把資料 query 出來,再用 JS 接續處理。我們有實際測過效能——我的版本比較快,這不是我自己說說而已。最後上線的是另一組:理由是以當時後端 team 的風格,分段 query 的版本比較好維護。

感受:落寞。而且不只是當下——之後好一陣子,我都在反覆懷疑:難道我的做法是錯的嗎?

教訓:多年後懂得比較多了,我才真正釋懷:每個團隊適合的東西,會隨著時空背景與成員組成改變。連實測量出來的效能優勢,都不足以讓一個點子勝出——因為選點子選的從來不是「哪個最好」,而是「這個團隊此刻養得起哪個」。我的做法沒有錯,它只是不適合當時的那個團隊。而當年那個懷疑「我是不是錯了」的我,正是掉進了障礙三:以為一題只有一個正解,所以沒被選上就等於錯。

拿刀的一方:ORM model 當 domain entity

事實:後來換我當 reviewer。一位同事很認真地做 clean architecture——分層清楚、domain entity 獨立。我在 code review 把它擋了下來,逼他改回用 ORM 的 model 直接當 domain entity。理由只有一個:「全專案都這樣做。」

感受:當下毫無感覺,甚至覺得自己在守護專案的一致性。直到後來我真的搞懂 clean architecture 在解什麼問題,才驚覺——原來我才是那個小丑。

教訓:我殺那個點子的時候,根本還沒看懂它。那不是判斷,是 pattern matching:「跟我們現在不一樣」等於「錯」。這就是 沒問題綜合症在 code review 裡的變形——急著套用既有答案,跳過對方真正想解的問題。

分水嶺:殺之前,你看懂了沒

兩個故事擺在一起,有個尷尬的地方:殺點子的理由幾乎一模一樣,都是「跟團隊現況一致」。為什麼訂單統計那次殺得有道理,clean architecture 這次卻是錯殺?

分水嶺在於:殺之前,有沒有先看懂。訂單統計那次,兩個實作都真的做出來、效能實際量過——團隊是在看懂兩個方案之後,才依環境選了養得起的那個。clean architecture 那次,我連它想解什麼問題都講不出來,就拿一致性當武器了。

所以我現在給自己一條硬規則:講不出一個點子的優點之前,我沒有資格淘汰它。環境理由是正當的淘汰依據——但只在看懂點子之後才成立;看不懂就搬出一致性,那不是把關,是殺點子。

還有一件事,是我從被殺的那一方學到、現在身為 Leader 才做得到的:淘汰別人的方案時,把理由明講成環境因素,而不是優劣因素——「你的做法沒有錯,只是不適合現在的我們」。當年沒有人跟我說這句話,我就自我懷疑了好幾年。一句話的成本,換對方好幾年的自我懷疑——這筆帳怎麼算都划算。