原創不易，求分享、求一鍵三連
前段時間有個粉絲與我討論了一個問題：
小釵，我半年前從技術經理升職到了技術總監，但這段時間的工作很惱火：一大半時間要去開各種產品會，還有一些時間要去處理團隊扯皮，這導致我寫程式碼的時間越來越少，半年下來感覺技術毫無成長，接下來該怎麼辦呢？
該同學的問題十分常見，而這裡真正的問題是：程式設計師轉型管理後，如何平衡技術及管理的精力投入。
然後看最後一句“技術毫無成長，接下來該怎麼辦”，這裡是第二個問題：為什麼技術Leader不寫程式碼會感到焦慮？
這裡圍繞這兩個問題開始展開。
技術大神的路線
“學而優則仕”這句話在技術界也行得通，技術好的人會被尊稱為大神或者大佬，他會受到技術人員天然的尊敬，這種大神光環所帶來的勢能對他後續工作開展有莫大的幫助，即：
- 技術好可以獲得莫大的個人成就感；
- 技術好可以獲得極大的勢能，對實際工作有莫大的幫助；
綜上，技術好對個人來說是雙倍快樂！所以大家會對他沉迷不以，一旦沒有成長當然會陷入焦慮。但技術好的背後有兩個重要問題：
- 時間成本
優秀程式設計師誰都喜歡，但技術好這個事情從來都不是那麼簡單，他需要耐得住寂寞。
因為單就基礎知識如作業系統、資料庫、演算法，一套連招下來很多人三年都搞不明白；到後面工作中的各種疑難雜症，如效能問題、併發問題、複雜架構的維護問題，精通其中任何一個領域，都需要投入長年累月的時間，有些領域光是時間投入還不夠，還必須有對應場景，所以成為一個技術好的程式設計師其實很不容易！
但是技術好並不意味著工作好或者產出好，因為長年累月的跟程式碼打交道，在與人交流方面會有一些小毛病，甚至一些程式設計師會被認為是一朵奇葩；
另一方面因為大量時間投入到了技術研究，對業務的理解會打折扣，甚至一些技術人並不想要關注業務實現，這些都極大的制約了其真實的產出能力。
- 專業壁壘
除了大量時間成本外，技術本身也是分領域的，除了少數大神，程式設計師都是在某一塊專精，比如後端、前端、iOS、Android...
精通後端後能不能也精通前端？當然可以，但再學一個埠的邊際收益太低，比如後端架構師待遇已經很高了，再多獲取一個前端架構師的title收益不大，多數程式設計師並不想做這個事情。
另一方面時間是有限的，你寫後端程式碼的同時沒有辦法寫前端程式碼，所以多數技術人員只會選擇一個領域重點發展，除非那個領域不行了，不得不轉方向。
這也是很多技術Leader面臨的問題，技術體系旁枝錯節，很難全部精通，這就是所謂的專業壁壘，因為收益太低，一般人不會選擇去突破。
- 發展選擇
如上所述，成為技術大神的代價是大量的時間投入，長時間的面對程式碼也會導致思維方式的改變，最終的結果就是對真實世界的認知不夠全面。
另一方面，技術領域本身又會細分，多數人只能精通其中一塊，要想職業生涯更進一步當然就會有取捨，技術專家與技術Leader兩個路線選擇就出現了：
- 程式設計師到某個階段一些會採取縱向深耕，比如Android方向同學，可以在音視訊領域深耕，這種做得深了會成為領域專家待遇很高，但問題是可能以後的路很窄；
- 另一方面一些同學會採用橫向的方式擴充套件自己的價值，比如轉技術管理，或者變成業務專家，這個選擇的問題就是技術很難再進一步了；
凡事有利有弊嘛，成年人的世界總是存在取捨，但兩種選擇都是常見的出路。
真假Leader
從賽道來說，是這樣的：
- 程式設計師->技術組長->技術專家->領域技術專家；
- 程式設計師->技術組長->技術經理->技術總監->CTO；
技術經理是個很大的分叉口，到這裡多半知道自己適合什麼，一些技術經理在工作一段時間後發現自己不能適應，便會迴歸技術路線，到技術總監後再轉技術專家的還是比較少。
回到粉絲案例：剛從技術經理進階到技術總監，所以他事實上還是技術經理思維，在這個陣痛期沒有感受到總監帶來的好處，更多的是發現自己的核心技術競爭力在丟失，所以感到是否焦慮。這裡就引發了一個問題：
技術經理和技術總監有什麼區別？
技術經理也是我們常說的一線Leader，是第一個真正具有彙報關係的Leader，一般規模在十人左右，這種小組有個特點：技術經理就算技術不是最好，但總體還是能服眾的。
對於程式設計師來說，技術好壞直接關乎待遇，所以大家都願意跟著技術好的Leader學習，技術不好在團隊裡是站不住腳的，技術強弱直接關乎話語權之爭，也是因為如此，技術經理會很注重自身的實力成長。
技術經理的工作比較簡單，多是帶領小團隊處理具體專案，可以是技術專案也可以是業務專案，經理和一線的關係更像是帶著他們一起幹活。
我們一般不認為技術經理是真正的Leader，因為他們是不具有資源分配許可權的。
總監之於經理表面的不同是管理規模變大了，根本的不同是總監開始掌握了團隊資源分配許可權，並且需要處理的問題更加複雜了，所以技術經理與技術總監主要區別有兩點：
- 總監開始涉及資源分配問題；
- 總監需要處理的場景更加複雜；
這裡再次回到Leader的能力模型和Leader的五件事：
此圖可以更好的說明區別：
- 總監需要做團隊接下來的目標設計；經理更多關注下派任務；
- 總監需要做團隊梯隊建設；經理更多關注自身能力提升；
- 總監需要向上管理拿資源、分配資源；經理更多關注具體任務資源夠不夠；
- 總監需要開始嘗試使用機制流程解決全域性問題；經理更多關注具體問題的處理；
從Leader的五件事的設計上，就沒有要求總監一定要寫太多程式碼，而是要有全域性視野，並開始思考降本增效的問題了。
所以，技術經理職位更多的是一個緩衝帶，程式設計師可以在這個時間視窗找到自己到底適合做什麼。
雙線並修
至此，就可以聊聊“技術管理雙線並修”問題了。
如前所述：技術是存在專業壁壘的，你是因為某個技術領域做的出色才被提拔成了總監級Leader，而已經選擇了總監管理路線，自然就不能走領域專家路線，那麼這個場景下你是要並修什麼？
- 後端出身的技術總監，非要去教前端Leader做事，這不合適吧？
- 前端出身的技術總監，幾年沒寫程式碼了，非要去跟前端Leader討論Backbone多麼優雅，這有必要嗎？
這裡想要表達的是什麼呢？這裡想要表達的是大家不要總想去做簡單的事，不要在熟悉的領域逼逼賴賴，那很遭人煩，因為那是降維使用，這個是一個常見現象：很多大Leader看見一線的工作就眼紅：
可以在幾個小專案上打出超預期的戰鬥，或者扶大廈於將傾，在某個“爛尾”專案做兜底，這樣很容易引起大家的注意。
但將簡單的事情做得超出預期，似乎並不是我們應該做的，巴西打國足一個5:0也並不值得驕傲；湘北打敗王者山王后被愛和秒殺，只能說殘血被收割了，並不能說愛和多麼牛逼。況且，簡單的事本是別人的經驗包...
有些leader定位不清晰喜歡搶下面同學活幹，這種行為能帶來「巨大的安全感」，這種安全感甚至是「可觸控的」：
技術總監過於專注技術細節，多半是在尋找安全感，緩解焦慮...
總監的“技術提升”
既然選擇總監這條路，那麼就要做這條路上的“技術突破”，可以使用以終為始的方法，看看技術負責人的能力要求是什麼，就我現在的認知，要求有二：
- 成本中心
技術負責人最重要的工作是讓其他CXO理解、認可並且支援技術部的工作，否則作為成本部門，在公司的地位會很低。
- 技術創新
光是讓其他部門理解還不行，技術還需要創造價值，所以需要做技術創新。
上面的兩個描述不夠具體，走技術總監路線的同學需要不停的反問自己一個送命題：
技術部對於公司的價值是什麼，與外包團隊有何不同；
如果一時間沒有太好的答案，那麼以下問題需要先進行解答：
- 迭代速度真的不能再快了？
- 工程、技術重構類專案的價值闡述？
- 如何降本增效？
- 如何在高管會上說人話，如何讓其他部門不會認為我們是工具人？
- 在高管會上，除了這個BUG我下去處理以及資源問題我去想辦法外，還有什麼可以聊的？
- 可不可以在不寫需求的情況下完成專案？
- 技術團隊的產出如何量化？
- 技術部的話語權如何提升？
- ...
拜託了各位，真的想要技術提升，請解答以上問題，不要老是盯著幾個技術問題秀操作，來咬點硬的！
技術是個成本部門，並沒有自己的產品，也不帶流水！因此，技術部門雖然不可或缺，卻未必非常重要，這也是很多技術總監會面臨的一個問題：
多數時間去寫程式碼了，卻對程式碼要解決什麼領域的問題不夠敏感，很容易淪為工具人。
而高管會議時，你說的效能優化、模組重用、效率提升天老爺才感興趣呢？甚至個別同事連研發和IT都分不清，這還如何玩耍？
做什麼創新？
技術的價值在於場景應用，但創新的底色是足夠的資訊輸入，如果技術總監對業務思考較少，對業務場景化創新完全沒想法，這就很難了！
走出程式碼世界，更多的參與真實世界，多見一見業務的發展和困難，是技術第一梯隊最需要做的事情。
一切能夠被程式碼化和演算法實現的，我們都應該去關注，任何能被技術解決的問題都應該優先考慮技術，這裡具體的一些場景可以是：
1）我們能不能根據技術手段比如爬蟲，拿到使用者的資料，給不同的使用者打不同的標籤，對幾百萬使用者做一個分層管理，有了這個分層和標籤系統後，產品端再針對不同型別的使用者提供不同的定製服務，標籤、分類做得好，才可能做出精準的千人千面服務；
2）一些資料打通成本很高，技術上能不能協助打通，比如公安系統與業務系統（酒店系統、銀行系統），我們能通過人臉識別，精準的知道這個使用者到底是誰，在哪從事什麼工作，再做進一步產品設計；
3）AI化可以替代哪些人工的工作，可以替代這些人工工作到什麼地步，是部分替代增加效率，還是完全替代降低成本，當前每次交易成功都有百分之多少的人工成本，技術能將這個成本降低到什麼程度？
4）...
以上的任務都要求對業務足夠的瞭解，並且具備獨立思考能力。
對於技術部如果所有的需求都是來源於外部團隊，接到需求就做，如果出錯了，再不停打補丁，沒有自己的思考，不能提前6個月甚至12個月佈局業務所需的技術，這種後置的成本很高。
對於業務，技術這塊到底有什麼核心優勢？這個需要好好的面對。
不能總是去做很多短線操作，比如：做一些技術重構，在穩定性上發發力，然後再招一點人在做下工程建設，搞搞Devops嘛，最後質效資料是好看了，想來好像確實是解決了一些焦慮。但做加法，不面對自己，出來混，終究要還的。
選擇總監路線就要思考技術核心競爭力到底是什麼，在公司的分工和定位到底是什麼，不要去找一些短線操作，以為能夠有捷徑，這個沒有意思，而且長期的看，也確實不會給公司留下什麼有價值的東西。
慢慢的迴歸到日常工作、業務日常，去做那些最艱難但最有意義的事情。無非就是從一個技術，轉型成一個技術產品或者業務技術。每天去跟產品開一次產品會，去幫他們調調需求，就靜下心來去好好做。
真的做了這步，發現路還挺長的，要轉型其實還挺多的。
面對困難，就如張藝謀所說”接受是我最大的哲學，先接受，再談創新改變“
業務架構師就是這個場景下的產物，即⼀個優秀的技術站在業務⻆度思考問題，扮演部分產品、運營⻆⾊，站在⼯程效率⻆度與產品業務⽅⼀起解決實際問題。
說白了就是——結合業務做技術創新...
業務是資訊輸入是底色，技術是創新能力，底色+能力=創新的可能
其實從個人發展來說，也不外如是：
1）更大的認知
比如，之前管50人團隊，現在能管500人團隊。
2）更多的認知
比如，之前做了兩年開發，又去做了兩年產品，再去做了兩年語文老師。
3）1+1>2的認知
比如，兩個相關聯的領域，先做了兩年技術，然後做了兩年產品，最後成為一條業務線負責人。
這裡比較晦澀，舉個不恰當的例子是，學了九陽神功，又學了九陰真經，最後達到了1+1>2的效果，Hybrid就是這類產物。
業務工程師便是要融合業務與技術兩個領域，設計出更好的結果，這裡的輸入是業務及技術知識，產出可以是產品、服務、合作流程、合作機制等。
最後總結一下：既然選擇了技術總監的路線，那就要放棄純粹的程式碼技術，擁抱更復雜的業務技術，創造更多的價值。
好了，今天的分享就到這，喜歡的同學可以四連支援：
想要更多交流可以加我微信：