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

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

　　在我剛工作的時候，業(yè)界使用的Java（當時不少人還用的J2SE這種“專業(yè)”的說法）的版本是1.4.2，而Java 5.0的版本已經(jīng)推出了，并且Sun做了大量的工作宣傳Java 5.0的各種好處。我作為充滿好奇的職場新人，當然也鸚鵡學舌地“明白”了不少，比如范型，比如改進的for循環(huán)等等。相比之下，實際項目中老版本代碼太多的“陋習”已經(jīng)讓我躍躍欲試，要大修大改一把了。

　　不過要做到這一點，我首先需要獲得項目經(jīng)歷的許可。于是我仔細準備了幾天，湊齊了一些自認為有說服力的資料，然后跑去跟項目經(jīng)理建議，我們應該升級到5.0版本。

　　我永遠都記得他當時的反應：先是一愣，然后說，“但是我們已經(jīng)很熟悉1.4.2了呀，而且這個系統(tǒng)長期以來都是跑在1.4.2上面的，很穩(wěn)定。你建議的這些特性，并沒有太多實際的好處。”

　　聽了這話我想，他雖然做過不少項目，但腦子已經(jīng)不夠更新了，一直停留在1.4.2的時代了，這就是他否定我的建議的根本原因?！安贿^，如果你有興趣，也可以先做一個仔細的調研，然后模擬環(huán)境測試一下，看看5.0到底能不能跑?！奔热凰詈蠼o我留了個希望的口子，我還是奮力去準備爭取，耐著性子盡可能詳細地做了試驗。

　　果然，我發(fā)現(xiàn)直接升級到5.0有問題，有個依賴的第三方庫會產(chǎn)生兼容問題。當然，最終升級方案還是通過了，系統(tǒng)也有驚無險地升級成功。但我回頭想想，卻不得不佩服項目經(jīng)理的保守：如果冒失升級上去，估計生產(chǎn)系統(tǒng)就不轉了。更讓我困惑的是，雖然他熟悉的版本是1.4.2，但他似乎不太關心5.0到底有哪些進步，也沒怎么花時間去了解這些進步。

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

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

　　這些疑問，直到幾年后我和徐易容一起吃了頓飯，聽他講“一定要做自己真正想做的，覺得有意義的事情”時，才真正解開。他當時是這么說的：

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

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

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

　　回到“搜索相關性”的例子，合格的技術領導可以不去做具體的實現(xiàn)，但并不妨礙他在抽象的程度上多行把握任務的難度、工作量、意義，并分配資源和時間，做到了這一點，他就能承受“放棄技術細節(jié)”的代價。這有點像放風箏，地上的人可以不懂高空氣流的微弱變化，但他總可以把握風箏要向哪里飛，什么姿態(tài)是對的。這時候，即便負責具體開發(fā)的程序員可以暫時欺騙領導，卻無法長期蒙蔽他。

　　當然，有時候在更高的層面上思考問題也會遇到難以應付的具體難題，這時不妨大度應對。假設有程序員建議將代碼管理從SVN換成Git，有些領導會因為完全不了解Git而直接否定（當然要找各種理由），因為這類似“讓手工業(yè)時代管理蠟燭生產(chǎn)的領導去負責機械化的手表生產(chǎn)線”，跨度太大。

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

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

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

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

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