「懂IT的管理者」和「懂管理的IT人」，到底有什麼區別？工作了很多年之後我才體會到，其中的區別很大。
對「懂管理的IT人」來說，管理只是鞏固IT的能力之一，補齊短板所需，他考慮的坐標系仍然是IT，許多從IT出身的領導都是這樣。但是對「懂IT的管理者」而言，IT只是眾多技能中的一項，無甚稀奇，他考慮和決策的標準是生意，是通盤的管理。
這麼說可能仍然有點玄，那麼下面我分幾個方面詳細講述。
身為IT專業人員，我們都清楚技術的重要性，也知道技術的評價標準。什麼樣的技術方案是好的，大家有相當的共識，或者起碼對評價標準有共識。
但是我們接受的教育裡，很少有「技術如何取捨」的部分。時間有限、人力有限、資源有限，這時候該如何決策，到底在哪些方面讓步？是運行效率，還是程序質量，或是架構設計，沒準也是安全性……
如果我是「懂管理的IT人」，無論放棄哪個方面，都讓我感到異常糾結，無比難受，因為它。但如果定位為「懂IT的管理者」，我非常清楚必須放棄某些方面，而且不能猶豫，因為猶豫反而會錯失時機，而時機對生意來說往往是無比重要的。
所以，「懂IT的管理者」平時可以耐心跟大家討論技術方案的優劣，一旦遇到資源有效、目標明確的場合，必須毫不猶豫地放棄自己對技術的執念，迅速定下取捨。近年來，我已經不止一次地告訴程式設計師：對，這樣做確實很醜，但別猶豫，趕緊動手吧。
身為IT專業人員，我們都習慣與機器打交道，因為它是那麼的講規矩、可預見，那麼充滿確定性。相反，我們大多數人都不喜歡跟人打交道，因為人會有各種想法，難以溝通，而且人會有情緒，更難以預見。既然如此，何不早早擺脫與人打交道，潛心編碼，更讓人安心。
不過另一方面，編碼往往是決策的最終環節。一個想法從靈感迸發，到討論打磨，到設計成型，最後才是編碼實現。這就決定了編碼工作也會出現供應鏈中的「牛鞭效應」：負責編碼的人往往是最後得到變化信息的，最初的念頭可能只是差之毫厘，經歷各環節加工之後，到編碼環節已經偏差萬裡。於是也經常引起程式設計師的抱怨：什麼事情都是改來改去，從來不想好再動手……
這樣就陷入了惡性循環：因為大部分的討論和決策都不是依賴程式語言和機器通訊，而是依賴自然語言和面對面溝通。所以越不參與討論，對變化就知覺得越遲，對變化知覺得越遲，就越容易引發誤解和矛盾……
如果換個思路，把自己定位為「懂IT的管理者」，那麼面對面交流、討論就變得相當重要——幾乎所有的管理者課程都強調溝通的重要性。溝通交流的目的，絕不是需要草草敷衍，然後可以讓自己醉心編碼，而是保證自己的信息靈通，協作順暢。這一切都搞定之後才輪到處理具體事務，IT只是諸多「具體事務」中的一項而已。
身為IT專業人員，我們大多數人都無可避免地沾染了IT的慣性，比如各項工作都要很整齊有序，工作安排應當有條不紊，講話應當有理有據，人應當不斷學習提升自己等等。基於IT的極大能力，我們往往也相信，這應當是世界通行，凡事都應當參照的標準。
對圈內人來說，這種想法很正常，也很容易獲得理解。但是對圈外人來說，未必那麼容易獲得理解，甚至可能完全得不到理解。
一個突出的例子是2016年阿里巴巴的「月餅門」事件。當時我也和許多業內同行一樣，認為這純粹是小題大做，專業人員成了政治的犧牲品。但是後來我逐漸發現，事情大概並不像我們想像的那樣。
對這世界上的其它許多人來說，IT是他們承認「非常重要」，同時又自認「永遠也學不會」的技能。所以IT人員對他們來說，就好像掌握著巨大能量但又難以駕馭的工具，如果這種能力不受控，就會產生巨大的不安全、不信任感。
所以圈內人大概覺得，寫幾個無傷大雅的腳本，搶購了幾盒月餅，無非是一時興起，平時絕對能拿捏分寸，不可能做這樣的事情。但對圈外人來說，讓你去負責安全，你卻在做破壞安全的事情，並且擺出一堆道理來為自己辯護，這還了得？
我雖然不知道阿里巴巴當時到底是如何決策的，但以我後來和圈外人聊天的經歷，大多數人都感到「負責安全的人竟然會利用公司的安全漏洞」完全不可思議，而程式設計師給出的理由他們完全聽不懂——圈內人的理由是定量分析，而圈外人只懂得定性分析。雙方溝通，純粹是雞同鴨講，完全不在一個頻率上。所以我們大概能判斷，無論這種事件發生在什麼公司，只要決策者不是技術出身，結果基本不會有什麼變化。
所以我後來時常勸那些認定某些決策「匪夷所思」的同行：你覺得人家奇怪，人家還覺得你奇怪呢。你擺出一二三四五六七，人家未必有那閒心聽下去，或者聽了也跟不上。你動不動搬出權威資料來為自己站臺，人家沒準覺得你這純粹是小題大做，無事生非……
要想明白，絕大多數公司都不是科研機構，而是基於利益的組織。在這種組織裡，整齊有序、邏輯順暢、善於學習等等，作為自己的追求很好，但未必是唯一的工作方式，甚至不是所有人都認可的工作方式。如果公司對統一工作方式沒有嚴格要求（那些口號不算），在溝通協作中就不要執著於自己的工作方式。
比較可取的辦法是先著眼於目的，摸索出各方的最大公約數。然後，在自己能決定的範圍裡踐行自己的工作方式，在這個範圍之外，則以目的優先，絕對不要過多計較工作方式——要知道，在你沒有絕對權力，也沒有絕對話語權優勢的時候，單純強調工作方式多半會碰得頭破血流，尤其是在業務部門面前。
另外，也別執著於凡事都要以系統、流程、規範來做，它們未必是人人認可的工作方式，甚至可能讓人覺得繁瑣和反感。
「懂管理的IT人」，往往在能力上並沒有明顯的短板，但他的工作節奏和思考重心仍然是IT，想著如何把IT做好。這本來沒有錯，可惜的是，不是每家公司都需要那麼好的IT，至少不那麼迫切需要——別信老闆們的鬼話，看看他們的投入就知道了。
我以前的領導曾跟我說過一句話，讓我印象深刻：你們把系統做好，公司當然喜歡，但更重要的是，你們應當從價值鏈的角度出發，找到自己的定位。
什麼意思？IT雖然很強大，可以大大提升效率，但公司是追求利潤的組織，利潤是由各個部門、各個團隊一齊貢獻的，換句話說，大家形成了一條價值鏈。更微妙的是，價值鏈上誰重要誰不重要，誰更燦爛誰更黯淡，往往並沒有客觀的標準，而是根據大家的印象來作出判斷。
所以如果你是「懂IT的管理者」，在懂得IT價值的同時，一定也要能看到整條價值鏈，看到其它團隊的價值所在，不要做僭越自己身份的事情。同時，也需要想辦法影響大家的印象，強調自身的價值。哪怕你很誠實，希望用一套客觀的數據體系去證明自己的價值，起碼也應當先設計出這套數據體系，獲得大家的共同認可，並在工作中持續發出信號。
所謂「價值鏈」，其實也沒有那麼玄乎，一般來說，主要包含兩大因素：人事、財務。無論在哪家公司，這兩大因素基本都是不變的，剩下的只是你如何從這兩個角度展開，看待和證明自己的價值。
所以下一次和圈外人溝通的時候，或許不必強調IT本身如何如何，只從人事和財務出發，反而更容易被人接受。比如業界同類型業務需要多少人團隊，自己帶領了多少人團隊就交付了同樣的功能；又比如上次投入大量開發資源的項目，最終整體收益並不如預期，如果把這些資源投入其它某項目，大概可以帶來多得多的收益……
我把「職業生涯」列在最後，是因為我發現，「懂IT的管理人」的定位可以讓人擺脫技術的焦慮感。
什麼是技術的焦慮感？就是面對層出不窮的新技術，永遠在學習，永遠在追趕，永遠擔心被拉下的憂慮。
為什麼「懂IT的管理人」可以擺脫這種焦慮？因為相比技術的更新速度，生意和組織的更新速度要慢得多。實際上，如果我們把目光從頭部的那幾家「技術弄潮兒」移開，就會發現很難有公司一直引領技術潮流，甚至大部分公司（恰恰是它們解決了大部分IT就業）根本不需要那麼高精尖的技術，它們更需要的是用合適的技術去解決自己生意中的具體問題。
所謂「合適的技術」，並不是把最新技術降幾級就可以直接得到。這個「合適」，需要你懂得取捨，需要你懂得與人交流協作，需要你找到共同認可的工作方式，需要你看得到整條價值鏈，找得到自己的定位。然後就會有越來越多的人願意承認，你是能讓他們放心解決IT問題的人。
一旦具備了這種「提供合適技術」的能力就會發現，錯過幾波技術新浪潮，或許並不那麼讓人擔心，一味追新反倒很可能浪費。另一方面，把這些追新的精力用來提升自己取捨的能力，與人交流協作的能力，打磨工作方式的能力，價值定位的能力，對提升個人價值來說往往反而能起到事半功倍的效果。
最後的最後，「懂管理的IT人」相對容易，只要懂IT的人補齊基本的管理知識，沒有明顯短板就可以，所以競爭也會相對激烈。「懂IT的管理者」相對更難，因為很難想像其它管理者能主動學會IT，所以它只能來源於搞IT的人主動變身，主動越界。
不過，千萬不要被「越界」和「變身」給嚇倒了，以我的經驗，最大的困難來自於你的大腦，只要不時時刻刻繃著「我是（跟其他人不同的）IT人」的那根弦，剩下的都好辦。