技術管理者的困惑——技術與管理應該如何平衡？

原創不易，求分享、求一鍵三連

前段時間有個粉絲與我討論了一個問題：

小釵，我半年前從技術經理升職到了技術總監，但這段時間的工作很惱火：一大半時間要去開各種產品會，還有一些時間要去處理團隊扯皮，這導致我寫程式碼的時間越來越少，半年下來感覺技術毫無成長，接下來該怎麼辦呢？

該同學的問題十分常見，而這裡真正的問題是：程式設計師轉型管理後，如何平衡技術及管理的精力投入。

然後看最後一句「技術毫無成長，接下來該怎麼辦」，這裡是第二個問題：為什麼技術Leader不寫程式碼會感到焦慮？

這裡圍繞這兩個問題開始展開。

技術大神的路線

「學而優則仕」這句話在技術界也行得通，技術好的人會被尊稱為大神或者大佬，他會受到技術人員天然的尊敬，這種大神光環所帶來的勢能對他後續工作開展有莫大的幫助，即：

1. 技術好可以獲得莫大的個人成就感；
2. 技術好可以獲得極大的勢能，對實際工作有莫大的幫助；

綜上，技術好對個人來說是雙倍快樂！所以大家會對他沉迷不以，一旦沒有成長當然會陷入焦慮。但技術好的背後有兩個重要問題：

• 時間成本

優秀程式設計師誰都喜歡，但技術好這個事情從來都不是那麼簡單，他需要耐得住寂寞。

因為單就基礎知識如作業系統、資料庫、演演算法，一套連招下來很多人三年都搞不明白；到後面工作中的各種疑難雜症，如效能問題、並行問題、複雜架構的維護問題，精通其中任何一個領域，都需要投入長年累月的時間，有些領域光是時間投入還不夠，還必須有對應場景，所以成為一個技術好的程式設計師其實很不容易！

但是技術好並不意味著工作好或者產出好，因為長年累月的跟程式碼打交道，在與人交流方面會有一些小毛病，甚至一些程式設計師會被認為是一朵奇葩；

另一方面因為大量時間投入到了技術研究，對業務的理解會打折扣，甚至一些技術人並不想要關注業務實現，這些都極大的制約了其真實的產出能力。

• 專業壁壘

除了大量時間成本外，技術本身也是分領域的，除了少數大神，程式設計師都是在某一塊專精，比如後端、前端、iOS、Android...

精通後端後能不能也精通前端？當然可以，但再學一個埠的邊際收益太低，比如後端架構師待遇已經很高了，再多獲取一個前端架構師的title收益不大，多數程式設計師並不想做這個事情。

另一方面時間是有限的，你寫後端程式碼的同時沒有辦法寫前端程式碼，所以多數技術人員只會選擇一個領域重點發展，除非那個領域不行了，不得不轉方向。

這也是很多技術Leader面臨的問題，技術體系旁枝錯節，很難全部精通，這就是所謂的專業壁壘，因為收益太低，一般人不會選擇去突破。

• 發展選擇

如上所述，成為技術大神的代價是大量的時間投入，長時間的面對程式碼也會導致思維方式的改變，最終的結果就是對真實世界的認知不夠全面。

另一方面，技術領域本身又會細分，多數人只能精通其中一塊，要想職業生涯更進一步當然就會有取捨，技術專家與技術Leader兩個路線選擇就出現了：

1. 程式設計師到某個階段一些會採取縱向深耕，比如Android方向同學，可以在音視訊領域深耕，這種做得深了會成為領域專家待遇很高，但問題是可能以後的路很窄；
2. 另一方面一些同學會採用橫向的方式擴充套件自己的價值，比如轉技術管理，或者變成業務專家，這個選擇的問題就是技術很難再進一步了；

凡事有利有弊嘛，成年人的世界總是存在取捨，但兩種選擇都是常見的出路。

真假Leader

從賽道來說，是這樣的：

1. 程式設計師->技術組長->技術專家->領域技術專家；
2. 程式設計師->技術組長->技術經理->技術總監->CTO；

技術經理是個很大的分叉口，到這裡多半知道自己適合什麼，一些技術經理在工作一段時間後發現自己不能適應，便會迴歸技術路線，到技術總監後再轉技術專家的還是比較少。

回到粉絲案例：剛從技術經理進階到技術總監，所以他事實上還是技術經理思維，在這個陣痛期沒有感受到總監帶來的好處，更多的是發現自己的核心技術競爭力在丟失，所以感到是否焦慮。這裡就引發了一個問題：

技術經理和技術總監有什麼區別？

技術經理也是我們常說的一線Leader，是第一個真正具有彙報關係的Leader，一般規模在十人左右，這種小組有個特點：技術經理就算技術不是最好，但總體還是能服眾的。

對於程式設計師來說，技術好壞直接關乎待遇，所以大家都願意跟著技術好的Leader學習，技術不好在團隊裡是站不住腳的，技術強弱直接關乎話語權之爭，也是因為如此，技術經理會很注重自身的實力成長。

技術經理的工作比較簡單，多是帶領小團隊處理具體專案，可以是技術專案也可以是業務專案，經理和一線的關係更像是帶著他們一起幹活。

我們一般不認為技術經理是真正的Leader，因為他們是不具有資源分配許可權的。

總監之於經理表面的不同是管理規模變大了，根本的不同是總監開始掌握了團隊資源分配許可權，並且需要處理的問題更加複雜了，所以技術經理與技術總監主要區別有兩點：

1. 總監開始涉及資源分配問題；
2. 總監需要處理的場景更加複雜；

這裡再次回到Leader的能力模型和Leader的五件事：

此圖可以更好的說明區別：

1. 總監需要做團隊接下來的目標設計；經理更多關注下派任務；
2. 總監需要做團隊梯隊建設；經理更多關注自身能力提升；
3. 總監需要向上管理拿資源、分配資源；經理更多關注具體任務資源夠不夠；
4. 總監需要開始嘗試使用機制流程解決全域性問題；經理更多關注具體問題的處理；

從Leader的五件事的設計上，就沒有要求總監一定要寫太多程式碼，而是要有全域性視野，並開始思考降本增效的問題了。

所以，技術經理職位更多的是一個緩衝帶，程式設計師可以在這個時間視窗找到自己到底適合做什麼。

雙線並修

至此，就可以聊聊「技術管理雙線並修」問題了。

如前所述：技術是存在專業壁壘的，你是因為某個技術領域做的出色才被提拔成了總監級Leader，而已經選擇了總監管理路線，自然就不能走領域專家路線，那麼這個場景下你是要並修什麼？

• 後端出身的技術總監，非要去教前端Leader做事，這不合適吧？
• 前端出身的技術總監，幾年沒寫程式碼了，非要去跟前端Leader討論Backbone多麼優雅，這有必要嗎？

這裡想要表達的是什麼呢？這裡想要表達的是大家不要總想去做簡單的事，不要在熟悉的領域逼逼賴賴，那很遭人煩，因為那是降維使用，這個是一個常見現象：很多大Leader看見一線的工作就眼紅：

可以在幾個小專案上打出超預期的戰鬥，或者扶大廈於將傾，在某個「爛尾」專案做兜底，這樣很容易引起大家的注意。

但將簡單的事情做得超出預期，似乎並不是我們應該做的，巴西打國足一個5:0也並不值得驕傲；湘北打敗王者山王后被愛和秒殺，只能說殘血被收割了，並不能說愛和多麼牛逼。況且，簡單的事本是別人的經驗包...

有些leader定位不清晰喜歡搶下面同學活幹，這種行為能帶來「巨大的安全感」，這種安全感甚至是「可觸控的」：

技術總監過於專注技術細節，多半是在尋找安全感，緩解焦慮...

總監的「技術提升」

既然選擇總監這條路，那麼就要做這條路上的「技術突破」，可以使用以終為始的方法，看看技術負責人的能力要求是什麼，就我現在的認知，要求有二：

• 成本中心

技術負責人最重要的工作是讓其他CXO理解、認可並且支援技術部的工作，否則作為成本部門，在公司的地位會很低。

• 技術創新

光是讓其他部門理解還不行，技術還需要創造價值，所以需要做技術創新。

上面的兩個描述不夠具體，走技術總監路線的同學需要不停的反問自己一個送命題：

技術部對於公司的價值是什麼，與外包團隊有何不同；

如果一時間沒有太好的答案，那麼以下問題需要先進行解答：

1. 迭代速度真的不能再快了？
2. 工程、技術重構類專案的價值闡述？
3. 如何降本增效？
4. 如何在高管會上說人話，如何讓其他部門不會認為我們是工具人？
5. 在高管會上，除了這個BUG我下去處理以及資源問題我去想辦法外，還有什麼可以聊的？
6. 可不可以在不寫需求的情況下完成專案？
7. 技術團隊的產出如何量化？
8. 技術部的話語權如何提升？
9. ...

拜託了各位，真的想要技術提升，請解答以上問題，不要老是盯著幾個技術問題秀操作，來咬點硬的！

技術是個成本部門，並沒有自己的產品，也不帶流水！因此，技術部門雖然不可或缺，卻未必非常重要，這也是很多技術總監會面臨的一個問題：

多數時間去寫程式碼了，卻對程式碼要解決什麼領域的問題不夠敏感，很容易淪為工具人。

而高管會議時，你說的效能優化、模組重用、效率提升天老爺才感興趣呢？甚至個別同事連研發和IT都分不清，這還如何玩耍？

做什麼創新？

技術的價值在於場景應用，但創新的底色是足夠的資訊輸入，如果技術總監對業務思考較少，對業務場景化創新完全沒想法，這就很難了！

走出程式碼世界，更多的參與真實世界，多見一見業務的發展和困難，是技術第一梯隊最需要做的事情。

一切能夠被程式碼化和演演算法實現的，我們都應該去關注，任何能被技術解決的問題都應該優先考慮技術，這裡具體的一些場景可以是：

1）我們能不能根據技術手段比如爬蟲，拿到使用者的資料，給不同的使用者打不同的標籤，對幾百萬使用者做一個分層管理，有了這個分層和標籤系統後，產品端再針對不同型別的使用者提供不同的客製化服務，標籤、分類做得好，才可能做出精準的千人千面服務；

2）一些資料打通成本很高，技術上能不能協助打通，比如公安系統與業務系統（酒店系統、銀行系統），我們能通過臉部辨識，精準的知道這個使用者到底是誰，在哪從事什麼工作，再做進一步產品設計；

3）AI化可以替代哪些人工的工作，可以替代這些人工工作到什麼地步，是部分替代增加效率，還是完全替代降低成本，當前每次交易成功都有百分之多少的人工成本，技術能將這個成本降低到什麼程度？

4）...

以上的任務都要求對業務足夠的瞭解，並且具備獨立思考能力。

對於技術部如果所有的需求都是來源於外部團隊，接到需求就做，如果出錯了，再不停打修補程式，沒有自己的思考，不能提前6個月甚至12個月佈局業務所需的技術，這種後置的成本很高。

對於業務，技術這塊到底有什麼核心優勢？這個需要好好的面對。

不能總是去做很多短線操作，比如：做一些技術重構，在穩定性上發發力，然後再招一點人在做下工程建設，搞搞Devops嘛，最後質效資料是好看了，想來好像確實是解決了一些焦慮。但做加法，不面對自己，出來混，終究要還的。

選擇總監路線就要思考技術核心競爭力到底是什麼，在公司的分工和定位到底是什麼，不要去找一些短線操作，以為能夠有捷徑，這個沒有意思，而且長期的看，也確實不會給公司留下什麼有價值的東西。

慢慢的迴歸到日常工作、業務日常，去做那些最艱難但最有意義的事情。無非就是從一個技術，轉型成一個技術產品或者業務技術。每天去跟產品開一次產品會，去幫他們調調需求，就靜下心來去好好做。

真的做了這步，發現路還挺長的，要轉型其實還挺多的。

面對困難，就如張藝謀所說」接受是我最大的哲學，先接受，再談創新改變「

業務架構師就是這個場景下的產物，即⼀個優秀的技術站在業務⻆度思考問題，扮演部分產品、運營⻆⾊，站在⼯程效率⻆度與產品業務⽅⼀起解決實際問題。

說白了就是——結合業務做技術創新...

業務是資訊輸入是底色，技術是創新能力，底色+能力=創新的可能

其實從個人發展來說，也不外如是：

1）更大的認知

比如，之前管50人團隊，現在能管500人團隊。

2）更多的認知

比如，之前做了兩年開發，又去做了兩年產品，再去做了兩年語文老師。

3）1+1>2的認知

比如，兩個相關聯的領域，先做了兩年技術，然後做了兩年產品，最後成為一條業務線負責人。

這裡比較晦澀，舉個不恰當的例子是，學了九陽神功，又學了九陰真經，最後達到了1+1>2的效果，Hybrid就是這類產物。

業務工程師便是要融合業務與技術兩個領域，設計出更好的結果，這裡的輸入是業務及技術知識，產出可以是產品、服務、合作流程、合作機制等。

最後總結一下：既然選擇了技術總監的路線，那就要放棄純粹的程式碼技術，擁抱更復雜的業務技術，創造更多的價值。

好了，今天的分享就到這，喜歡的同學可以四連支援：

想要更多交流可以加我微信：