領導需要比下屬更懂技術嗎？

　　領導必須更懂技術嗎？這是個問題。做了領導以後，因為工作的關係，許多人都不那麼熟悉基礎的技術了，結果自己心裡沒底，更怕遇到問題時在下屬面前丟臉。所以，有些人選擇了雙管齊下——既不放棄領導的工作，又不放棄原有的技能，結果疲憊不堪。還有人乾脆選擇不當領導了，因為有手藝，才有安全感。

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

　　在我剛工作的時候，業界使用的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 說的：

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

　　我自己在工作中也會定期組織學習分享會，講解新鮮技術和工作心得。對這種活動，領匯出面主講的效果不如由大家輪流主講，領導只負責把關話題和質量就好了。這樣既有助於提高整個團隊的水平和見識，又節省了大家的時間，更能促進團隊成員的全面成長（要知道，許多程式設計師不是不善於表達，只是一直沒有機會鍛鍊表達）。最關鍵的是，領導再不用擔心某項技術自己懂得不夠多了：“你是專家，來，請你來講一講，幫助大家共同學習吧。”