技術領導必須更懂技術嗎?

在IT行業,很多人從專業人員升任領導以後,不再有以前那麼多時間熟悉基礎技術了,於是自己心裡沒底,也害怕遇到問題時在下屬面前丟臉。所以有些人選擇了雙管齊下——既不放棄領導的工作,又不放棄原有的技能,結果疲憊不堪。還有人乾脆選擇不當領導了,因為有手藝,才有安全感。

技術領導必須更懂技術嗎?

這個問題也困擾過我,而且始終找不到「合理」的答案,最終還要靠親身的工作經驗來解答。所以在正式回答這個問題之前,讓我先講講自己的親身經歷。

在我剛工作的時候,業界使用的Java(當時不少人還用的J2SE這種「專業」的說法)的版本是1.4.2,而Java 5.0的版本已經推出了,並且Sun做了大量的工作宣傳Java 5.0的各種好處。我作為充滿好奇的職場新人,當然也鸚鵡學舌地「明白」了不少,比如範型,比如改進的for迴圈等等。相比之下,實際專案中老版本程式碼太多的「陋習」已經讓我躍躍欲試,要大修大改一把了。

不過要做到這一點,我首先需要獲得專案經歷的許可。於是我仔細準備了幾天,湊齊了一些自認為有說服力的資料,然後跑去跟專案經理建議,我們應該升級到5.0版本。

我永遠都記得他當時的反應:先是一愣,然後說,「但是我們已經很熟悉1.4.2了呀,而且這個系統長期以來都是跑在1.4.2上面的,很穩定。你建議的這些特性,並沒有太多實際的好處。」

聽了這話我想,他雖然做過不少專案,但腦子已經不夠更新了,一直停留在1.4.2的時代了,這就是他否定我的建議的根本原因。「不過,如果你有興趣,也可以先做一個仔細的調研,然後模擬環境測試一下,看看5.0到底能不能跑。」 既然他最後給我留了個希望的口子,我還是奮力去準備爭取,耐著性子儘可能詳細地做了試驗。

果然,我發現直接升級到5.0有問題,有個依賴的第三方庫會產生相容問題。當然,最終升級方案還是通過了,系統也有驚無險地升級成功。但我回頭想想,卻不得不佩服專案經理的保守:如果冒失升級上去,估計生產系統就不轉了。更讓我困惑的是,雖然他熟悉的版本是1.4.2,但他似乎不太關心5.0到底有哪些進步,也沒怎麼花時間去了解這些進步。

在我的職業生涯中,類似的經歷還有過好幾次,有時候甚至據理力爭,也無法說服領導。於是我得到一個結論:當了領導的人都不太瞭解具體技術了,只是有人因循守舊不願意接受新變化,有人思想開放可以接受新的方案。

可是還有問題,對具體技術不夠了解的領導,他們的安全感來自哪裡呢?他們不怕下屬犯錯誤,甚至矇騙嗎?

這些疑問,直到幾年後我和徐易容一起吃了頓飯,聽他講「一定要做自己真正想做的,覺得有意義的事情」時,才真正解開。他當時是這麼說的:

如果你是一個熱衷技術的人,領導安排你本年度的工作任務是,把某項搜尋的相關性提高五個點。於是你兢兢業業地安排年度計劃,前三個月讀論文,再三個月定方案,然後三個月編碼實現,最後三個月測試並根據反饋並最終部署。真正上線之後,領導發現形勢變化,你的工作不再需要了,然後給你安排下一年的工作。你付出了一年的勞動,也掙了一年的薪水,但是你的工作真的有價值嗎?你會做得開心嗎?

我聽到的時候首先想到的不是「要做真正向做的事情」,而是「原來領導可以不要那麼懂技術,這竟然是完全沒有問題的」。這個領導或許並不懂關於相關性的那麼多細節,也沒有讀過那麼多論文,但是他可以調動資源去實現某個想法,這種工作才更有價值。而且在這種情況下,下面的員工即便去欺騙領導,最終受損失的還是這名員工,因為他浪費了更多的成本卻沒有真正的收穫。

再後來,我在 讀書的時候 真正明白了「抽象」的意義:將具體事物提煉到某個深入的層面,找到它和其它事物相通之處。這樣,就能做到「觸類旁通」。比如你之前很懂蠟燭的生產,現在讓你去負責手錶的生產。雖然兩份工作不同,但如果你思考得足夠深入足夠抽象,就會知道,在合理配備資源、組織工序、最佳化流程、保證質量等方面,兩者是有很多共性的,所以雖然不懂生產手錶的細節,你也不算門外漢,更不妨礙你管理手錶的生產。

回到「搜尋相關性」的例子,合格的技術領導可以不去做具體的實現,但並不妨礙他在抽象的程度上多行把握任務的難度、工作量、意義,並分配資源和時間,做到了這一點,他就能承受「放棄技術細節」的代價。這有點像放風箏,地上的人可以不懂高空氣流的微弱變化,但他總可以把握風箏要向哪裡飛,什麼姿態是對的。這時候,即便負責具體開發的程式設計師可以暫時欺騙領導,卻無法長期矇蔽他。

當然,有時候在更高的層面上思考問題也會遇到難以應付的具體難題,這時不妨大度應對。假設有程式設計師建議將程式碼管理從SVN換成Git,有些領導會因為完全不瞭解Git而直接否定(當然要找各種理由),因為這類似「讓手工業時代管理蠟燭生產的領導去負責機械化的手錶生產線」,跨度太大。

這種擔心可以理解,但好的領導絕對不應該拒絕,因為身處這個行業,任何崗位的人都有義務經常更新自己的知識。不懂Git,大可以去了解一番,然後才是履行日常領導的職責:判斷這種切換會帶來什麼好處,團隊中的大多數人是否能順利切換,過渡的的代價是什麼,可能面臨什麼風險……衡量之後再做決定。

身為領導,在面對這種局面時還有一種特殊的便利,因為他可以很方便地藉助所管理的人員進行高效的學習,就像肉餅鋪子的Robbin說的:

我的做法比較狠,把下屬研發團隊變成我自己學習新技術的延伸大腦,鼓勵他們不斷學習和嘗試,然後講給我聽,我再提出問題讓他們給我解決。這樣我就可以用最少的時間和精力,快速積累最多的知識。

身為領導,享受這種便利的前提是另一種基本素質:謙虛。具體說來,就是承認自己的無知,坦白自己的無知,所以才能勇敢地招募比自己強的人。「領導者一定要努力招募比自己強的人」,這個道理似乎人人都懂,但不是人人都有勇氣去做到,有些時候是領導不懂識人,更多的時候是領導不夠謙虛或者沒有胸懷,於是整個團隊要麼自我陶醉,要麼進入劣化迴圈,終於釀成悲劇。

解決這個問題的辦法也很簡單,經常組織團隊進行學習分享,並且由大家輪流分享,領導只需要負責把關話題和質量。這樣既有助於提高整個團隊的水平和見識,又節省了大家的時間,更能促進團隊成員的全面成長。最關鍵的是,領導也可以坦然應對自己「不夠專業」的尷尬:「我們都知道你是專家,那麼,就請你來給大家講講。」