「我,程序員,32歲,距離退休,只剩3年了!」

來自：IT人的職場進階（ID：BestITer）

「我，程序員，32歲，距離退休，只剩3年了！」

這句話用來形容2019年互聯網行業最適合不過了。從18年開始，大大小小的互聯網公司開始了不止一輪的裁人，19年網上開始充斥一類文章，專門寫互聯網公司超過35歲的人，若是到這個年齡，還不是leader，業務又不核心，那麼請焦慮吧。

上次聽羅胖的跨年演講，主題是：基本盤。意思是不要受到人云亦云的情緒影響，而是轉過頭，看手中的資源，基於基本盤看清本身的努力方向，很是感慨和受啓發。中國互聯網通過過去十多年野蠻式的發展，彷佛這2年開始慢下來了，程序員35歲的退休年齡雖然只是販賣焦慮的一種說法，可是整個行業對人的要求愈來愈高是不爭的事實，要求咱們的成長速度必須跟上。2020年開始，但願本身在技術、管理、業務3個維度再作更深層次的學習，體系化我的的認知，作一個有特色的IT人。

下面要寫的主題是關於『工程師如何從技術轉型作管理』，這是我在團隊管理上第一篇系統性的總結。之因此選擇這個主題，一方面，我的以爲轉型作管理是當前環境下大部分程序員會選擇的職業路徑，另外一方面，本身親身經歷了比較漫長的轉型過程，應該能寫出點心得體會。但願下面的內容對於『正在轉型掙扎期』或者『後續有規劃往管理轉型』的同窗，讓大家有所啓發，內容大概分紅如下4個部分：

• 什麼樣的工程師會被提拔作管理？

• 你選擇作管理的初衷是什麼？

• 轉型期你會遇到哪些困惑或者挑戰？

• 轉型期應該具有哪些心智？

什麼樣的工程師會被提拔作管理？

通常來講，知足這3個條件的工程師會被提拔作管理：技術能力強、業務熟練、軟性素質達標。（固然還要看公司是否有管理崗位的空缺以及你我的的意願），下面分別展開說下重點。

技術方面：經常使用技術的深度和寬度缺一不可，架構能力很是關鍵。不然技術方向都把握很差，技術決策也容易出問題。若是技術能力沒達到必定水平，不建議太早轉管理（我的感受能力至少要接近阿里的P7，騰訊的T3-1，百度的T6）。

業務方面：不瞭解業務，技術無法落地，不只要求熟悉業務並且應該具有比較強的業務意識，（若是能從技術維度提出好想法，幫助業務拿到更好的結果，這種leader是很是受歡迎的）。

軟性素質達標：軟性素質這個詞有些泛，我我的以爲最核心的兩點，溝通協調能力和作事靠不靠譜。軟性都是能夠鍛鍊的，可是必定要有意識去提高。著名管理學家陳春花老師說，「一我的被組織提拔，其實不是由於能力，而是由於信任」，聰明的人不少，可是靠譜的人不多，比能力更重要的是工做的投入感和靠譜的態度。

若是你以爲上述3個方面都達到要求了，我以爲只是差一個機會，不然好好提高本身吧。

你選擇作管理的初衷是什麼？

以前有人問過我一個問題，「你以爲我適合作管理嗎？能給我些建議嗎？」，我當時沒有正面回答他，而是反過來問他，「你能先告訴我，作管理對你意味着什麼？它能給你帶來什麼呢？」。固然我不是在質疑他，而是想讓他反思他作管理的初衷。我以爲『最原始的動機』會決定你在管理路上能扛多大的壓力以及能走多遠。關於初衷，我見過最廣泛的說法有這麼幾種：

• 技術不能作一生，不少前輩在能力達到必定水平後都轉管理了，本身也這麼想

• 在技術路線上遇到了晉升瓶頸，想嘗試下管理方向，看本身是否合適

• 公司發展太快了，老闆讓我帶團隊，本身也沒辦法

• 管理者工資高，在別人眼中是優秀的表明

• 指揮作事便可，能夠脫離執行層面，越往上走越輕鬆

上面這幾類都屬於『外部因素』驅動，說實話，都很難在管理路上走得很遠。由於技術管理是極其複雜和瑣碎的工做，它遠沒有你想象中的輕鬆和風光，而在這些外力下，你作出決策後的結果不少時候跟你的預期是不一致的，這個時候你的怨氣和轉型痛苦就會出現，你開始質疑你選擇的這條路是否是錯了？

再來看另一個問題，做爲技術管理者，對於公司、團隊以及你我的，你以爲它的價值分別是什麼？我我的的解讀是這樣的：

• 對於公司：能帶領技術團隊支撐好業務，幫助業務實現公司定的戰略目標。

• 對於團隊：規劃好方向，別讓組員瞎忙，同時能幫助他們成長。

• 對於我的：提高自身的技術和管理能力。

這是對於技術管理崗位的基本認知，你的初衷必須創建在這個認知基礎之上。而後試問你本身：是否定可這個崗位的價值？若是你以爲全是犧牲本身來成就公司和團隊，那你不可能作得開心，也不可能作好。第2個問題，你是否對管理者的工做充滿熱情？而且享受這個過程呢？好比項目協調，好比制定流程並推進落地執行，好比招聘。若是你說我只喜歡作技術相關的工做（好比架構設計、技術評審等），那麼你仍是走技術路線吧。承認技術管理崗位的價值所在，而且能激發你的投入意願。這些就是底層最好的動力，你的成長和回報都是付出後水到渠成的東西。因此這個初衷很重要，三觀必定要正。

轉型期你會遇到哪些困惑或者挑戰？

轉型期會經歷心態、工做方式的轉變，不少事情會刷新你的認知。下面幾點，我認爲是絕大部分人在轉型過程當中會遇到的困惑或者挑戰：

• 時間不夠用：成爲團隊leader後有不少平常事務要處理，要參加各類會議，有時候還須要分出一部分精力在一線coding上，時間徹底被碎片化，根本不夠用。

• 嫌組員效率低：一個你認爲簡單的需求或者技術問題，交給團隊成員後，他們的處理時間遠超出你的預期，當外界施壓時，你忍不住抱怨和責怪，並開始本身動手處理，長此以往，習慣本身衝在一線，以爲這樣效率最高。

• 恨人際關係複雜：對內對外、對上對下，天天須要和不一樣職位、不一樣level的人打交道，有靠譜的，有不靠譜的，某些你認爲很簡單的事情推進起來卻很難，感受情商不夠用。

• 成就感不強：偶爾會收到上級、平級、甚至下級的負面反饋，你開始質疑本身的管理能力，不像作工程師那樣常常被承認，落差感強。

• 不敢放棄一線：擔憂本身不合適作管理，若是脫離一線執行，感受技術能力會停滯不前。不放棄一線，精力又跟不上，這個度把握很差。

上述疑惑是我我的轉型過程當中體會最深的幾點，我在後文中會分別給出本身的見解和建議。

轉型期應該具有哪些心智？

從技術轉型作管理，更多的不是能力的變化，而是思惟方式和行爲的改變。不少剛轉型的leader管理作很差，絕大部分不是由於能力不行，而是出如今了認知上。如下幾點，我認爲是轉型期leader必定要具有的心智：

• 學會從團隊的角度考慮問題

• 注重執行細節

• 學會用人所長，具有包容心

• 重視情商，作好自我情緒控制

• 作好時間管理

學會從團隊角度考慮問題

之前做爲工程師，更可能是從事情自己或者從我的角度出發，成爲leader後，轉變成團隊思惟是最最重要的，由於你的KPI取決於你整個團隊的完成狀況，你要權衡的是團隊總體的利益和效能。

上面4項對比，是我我的認爲比較典型的case，好比上一節提到的一種狀況：leader以爲某個問題很簡單，嫌員工處理效率低，而後本身跳出來三下五除二給解決了，這種就屬於很典型的員工思惟。單從搞定這件事情來看，這也許是很好的處理方式，業務方也會很滿意，可是帶團隊是長遠的事情，上述作法緊急狀況可行，可是變成常態就是很是大的問題。團隊能力不提升，leader永遠不會解放，這是做爲leader應該具有的意識。若是經過這個問題可以提高組員某方面的能力，leader應該扮演好教練的角色，放手讓組員本身去作，你要作的僅僅是觀察、給一些指點、適當給予時間上的支持。此次處理也許效率不高，可是下次碰到相似的問題，團隊是不須要依靠你來解決的，另外組員也有本身的發揮空間，以爲團隊在幫助他成長。

注重執行細節

對於剛轉型作管理的一線leader，切忌被放權式的管理方式洗腦。放權式管理對於對管理者的經驗要求很高，它比較適用於工做流程清晰，團隊骨幹目標認知以及自驅力很強的團隊。

當你我的的管理水平還處於菜鳥期時，必定要從細節抓起，經過手把手帶員工，教會他們如何正確的作事，怎麼才能達到你的要求，以及如何培養出團隊骨幹，搭建出團隊的核心組織架構，全部這些都經歷過了，你在管理上纔會有本身的心得體會，纔會走得更紮實。

經過觀察執行細節，你能很是清楚團隊每一個人的優劣勢，深刻感覺本身的管理方式是否存在問題，而後再輔以leader思惟去思考和解決問題，管理上才能真正得到成長。這個過程，你可能會收到上級、平級、下級的不少反饋，清楚細節後其實你就有了本身的判斷，知道是不是自身的問題，是否要調整，而不是沮喪抓瞎。

學會用人所長，具有包容心

知人善任、人盡其才，是每一個管理者都懂的道理，可是能作到的很少。尤爲在技術管理崗上，我見過有些leader在技術上很是強勢，技術權威不容有任何挑戰，當組員提出更合理的技術方案時，他會用職級強制要求按本身說的執行，根本不作任何解釋。對於新晉leader，團隊對你的信任感還在磨合期，上述作法很容易打擊組員的積極性，消滅他們的創造力，這對你帶團隊來講是很是致命的。若是組員的方案更合理，leader應該倍感欣慰，包容並鼓勵這種行爲，由於組員某方面的專業能力超過你了，你再也不是團隊各方面最強的人，你須要作的是調整本身的心智，學會用人所長。另外，還有一種狀況是：組員和leader的技術方案均可行，我我的傾向將選擇權交給組員，畢竟他們是真正的執行者，應該給他們自由發揮的空間，最後就算出問題對他們來講也是很好的經驗積累。

重視情商，作好自我情緒控制

管理上能作多大事情，真的和情商有很是大的關係。IT界的技術人員因爲工做性質的緣由，廣泛注重技術上的提高，而忽略情商的培養和維護，做爲新晉leader必須從一開始就意識到情商的重要性。管理是一個複合型的崗位，當你的專業技能和處理問題的方法論已經造成後，越往上發展，爲人處事的軟技能佔比會愈來愈重。

天天和不一樣的人打交道，這個是管理者的平常工做，由於你須要調動全部可能的資源去解決團隊的困難。面對不一樣職位、不一樣level、不一樣性格的人，你要反覆琢磨採起何種溝通方式和溝通技巧。上一節提到一種狀況：一件你認爲很簡單的事情，推進起來卻很困難。多是由於你對外的溝通方式太生硬，別人不想配合你，或者別人確實有其餘更重要的事情，可是若是私下關係創建好，你再當面軟磨硬泡，多半也是能夠解決的。人際關係上，不免會有碰壁的時候，不要氣餒，這跟技術同窗寫出1個bug同樣，是屢見不鮮的事情，可是必定要注意積累經驗。線下和關鍵的配合方維護好私人關係，多吃飯喝酒，別人有困難能及時伸出援手等等，套路有不少。

情緒控制，是一個比較難的事情。情緒很容易傳遞，若是leader碰到不爽的事情，把組員當作出氣筒，這是很是傷士氣的，以前創建的信任感很容易消失，受不了的組員也可能就離職了。另外，對外溝通上，若是leader控制很差情緒，不將重點放在解決問題上，只是抱怨或者發火，也很是容易引發配合方的不滿，認爲你不專業，長此以往，你的團隊也會被打上這種標籤。

我的在情商方面目前作得也不好，踩過不少坑。提供3點建議：

• 保持積極樂觀的心態，同時提升本身面對問題時的承受能力，想清楚情緒化是解決不了問題的，只會加大解決問題的難度。

• 可以自我檢討並吸取別人的反饋，作得很差的地方要敢於正視而且持續改進。

• 培養親和力，不要以爲本身是leader就帶着架子，要有一種鞠着的姿態，可以尊重人而且真誠待人。

作好時間管理

時間管理的4象限理論能夠百度一下。重點說下我我的遇到時間管理問題是怎麼解決的，以及技術和管理兩個維度如何分配時間。

第1步，能夠拿過去一週或者一個月的時間跨度爲例，詳細列一下你的時間花在哪些具體事情上了，以及每類事情大概的時間佔比。對於技術leader可能的事情包括：需求評審，資源規劃和項目排期，技術評審，團隊周例會，研發規範制定和落地，項目管理，技術調研，架構設計，coding，緊急任務協調和處理，業務以及新技術充電等等。

第2步，針對第一步列舉的每類事情，考慮下哪些是非必須的，哪些是能夠受權給團隊骨幹去作的，哪些是能夠優化提升效率的。好比一些簡單的需求評審或者技術方案評審讓骨幹把關便可，項目管理制定好流程規範同時培養一些scrum master或者項目經理下放給他們來作。不用凡事都事必躬親，leader應該把時間聚焦在對團隊最關鍵的事情上，學會受權和放權。

對於一線leader，技術和管理兩個維度如何分配時間，我的的建議是：

• 大部分時間leader是不須要親自寫代碼的，可是若是有須要，leader要可以隨時頂上，因此不能長期遠離一線，紙上談兵。久而久之，技術判斷可能容易出現失誤，並且若是管理不合適再轉型回去代價過高。

• 技術維度：能夠將重點放在架構設計、代碼審查、技術調研、以及一些框架性的代碼開發上，這些事情對於維持技術優點是足夠的。
• 若是管理維度的時間佔比超過60%，我的以爲比例是有些失衡的，要麼團隊太大了（好比超過了10人），要麼自身的管理存在問題或者時間管理存在問題，須要關注並考慮作出調整。

2020年，又一個十年的開端，認清基本盤，不忘初心，再接再礪！

寫在最後：

歡迎你們關注我新開通的公衆號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。

以爲寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！

海量面試、架構資料分享