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