前些天從灣區(qū)日報上看到美國一家叫 Gusto 的公司 CTO 的文章，他 6 年前開始創(chuàng)業(yè)，一開始他是唯一的工程師，幾乎 100% 時間都在寫代碼；后來 2-10 個工程師的時候，40% 的時間花在招人上；11-50 個工程師的時候，自己若寫代碼就是給團隊添麻煩；51-100個工程師時，60% 時間管人，40% 時間招人。
國內(nèi)也大同小異，管的人越多的時候，寫的代碼就越少，到最后一行代碼都不寫。這是典型的技術(shù)管理路線，當然，還有另一條技術(shù)專家的路線，不在今天說的主題范圍內(nèi)。
那到底技術(shù)管理要管什么呢？開頭那個 CTO 最后的工作變成 60% 管人，40% 招人，招人來還是要管，好像最后技術(shù)管理就等于管人了。真是這樣嗎？
哪怕技術(shù)管理真的就等于管人，那管人又管什么呢，或者說怎么管呢？
無論是春秋戰(zhàn)國時候的丞相，還是三國時候的謀士們，技能大概分成兩種：謀略和理事。謀略重在想辦法，理事重在做事情。但凡有名的丞相謀士至少有一樣特長，兩者兼顧的自然是不世功勛唾手而來。
丞相和謀士就是管理者，并且有別于將軍們，他們是技術(shù)管理者。
現(xiàn)代的技術(shù)管理者需要的核心技能仍然是這兩樣，只不過體現(xiàn)形式有些變化。
謀略：技術(shù)架構(gòu)搭建、新技術(shù)演進選型等，解決該做什么和怎么做的問題。
理事：任務(wù)和人員協(xié)調(diào)、分配等，解決誰來做、哪件事先做的問題。
所有技術(shù)管理，或者管人，都是很抽象的說法，聽著好像對極了，真做的好的屈指可數(shù)，很大程度上是因為很多人根本沒搞清楚技術(shù)管理到底該管什么。
把握好謀略和理事這兩條，技術(shù)管理才能真正落地，團隊戰(zhàn)斗力才能真正體現(xiàn)出來。
這篇文章其實到這里就可以結(jié)束了，點到即止。
但是有兩個典型的問題還是有必要順便探討下。
第一個問題，雖說技術(shù)管理不能直接等價于管人，但實際上管理者大部分時間還是要和人打交道。那怎么處理人的問題呢？
我的經(jīng)驗是，我們的目的應(yīng)該是把事情做好，管人只是一種方式而已。以代碼規(guī)范為例，最好的方式是，通過技術(shù)手段去保證，不按照規(guī)范去做的代碼沒法提交成功；次好的方式是，建立規(guī)范準則，要求大家去遵守；最壞的方式是，質(zhì)問和批評為什么不這么做。
不要輕易嘗試去改變一個人，哪怕你是為他好，哪怕改的是缺點對他也有好處。作為管理者，你沒有權(quán)利也沒有義務(wù)去改變你的組員。當然，你有讓他們進步的義務(wù)。健康的團隊不應(yīng)該過度依賴任何人（包括管理者本身），保持一定的離職率才能有機會引入新鮮血液。從這個角度看，也沒有必要非得去改變誰。當然，重點對象還是可以嘗試多去培養(yǎng)下的。
第二個問題，技術(shù)管理者不寫代碼好心慌。
開頭那個 CTO 的觀點非常有道理，團隊達到一定規(guī)模后，管理者還去寫代碼，就是給團隊添麻煩。長期不練手的你，編程能力已經(jīng)不足以保證你的代碼質(zhì)量了；另一方面，投入精力寫代碼之后，其他需要你做的事情必然會被耽擱下來。
管理者不應(yīng)該是職級層面的上級，而應(yīng)該是分工層面的決策和協(xié)調(diào)者。
覺得不寫代碼會心慌的人，說明你把太多精力花在理事上了，謀略給丟了。實際上，在技術(shù)架構(gòu)滿足不了業(yè)務(wù)增長需求的時候，是需要你（和你的架構(gòu)師一起）去拿出新的架構(gòu)的；組員討論幾個方案拿不定主意的時候，也是需要你去做決策的。這些都是需要你平時花時間去不斷豐富和充實你的技術(shù)的。否則一定是一將無能累死三軍。
你并不應(yīng)該陷入與人溝通和處理雜事的漩渦中，而是應(yīng)該抽時間出來保持自己的技術(shù)敏感度。管理者和普通員工在技術(shù)上的區(qū)別，在于和技術(shù)打交道的方式變了。普通員工是寫代碼，技術(shù)管理者應(yīng)該是學習技術(shù)和思考架構(gòu)。
聯(lián)系客服
