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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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