導讀：做技術開發的人的職業規劃通常有兩個方向：一個是持續做技術，成為技術專家、架構師；一個是轉管理，帶領技術團隊做開發。

開發團隊需要管理者，開發出身的工程師做管理也是順理成章的事。看起來不錯，但有那么容易嗎？

作者：李智慧

來源：大數據DT（ID：hzdashuju）

過去十幾年，很多優秀的工程師成功轉為技術管理人員，成功轉崗的比例似乎比成長為技術專家的比例還要高一些。這也給了更多工程師轉管理的信心，似乎技術轉管理是一件相對容易的事。

事實上，過去十幾年，技術人員之所以能夠容易地轉為管理人員，根本原因在于開發行業的快速擴張。隨著互聯網的快速發展，軟件開發的從業人員數量大概增長了幾十倍，開發團隊規模迅速擴張，因此必須要有技術人員成為管理者，以管理越來越龐大的技術團隊。

如果一個人在技術部門只有十來個人的時候加入公司，經過幾年發展，公司技術部門有百余人，需要將其劃分為十多個開發小組，每個小組需要一個技術主管，因此就需要十多個技術管理者，所以在公司早期加入的這些開發人員，如果能夠勝任工作，跟著公司一起成長，大概率會被任命為技術主管。

如果公司繼續發展，技術部門達到千余人，那么，百余人時加入公司的技術人員也有很大概率會被任命為技術主管，如果這個人在管理方面表現得足夠好，則有可能會被繼續提拔，成為經理、總監、CTO，在管理的道路上越來越成功。

看起來，技術轉管理這條路似乎很光明，是軟件技術人員一條不錯的職業發展之路。

但是，這條光明的道路其實隱藏了一個非常重要的前提，那就是技術團隊規模必須呈指數級增長，這樣才能產生足夠數量的管理崗位空缺，才會讓后來的人跟前面加入公司的人一樣有機會成功轉型管理。

事實上，過去十幾年中，整個行業的軟件開發從業人員確實是指數級增長的；而最近幾年，這一增長勢頭已經明顯變慢；未來會怎么樣，相信不用我說你也能做出判斷。

如果整個行業的軟件開發人員數量從現在開始不再增加，那么現在的工程師轉管理的難度將比自己的前輩難一個數量級。

如果你覺得你的主管、經理的管理水平不過如此，你做管理不比他們做的差，這并不足以支持你成功轉型管理。因為從時間上來說他們轉管理的難度要遠低于你現在轉管理的難度，如果你的規劃是將來幾年轉管理，那么局面會更加悲觀。

我并不是在這里給你打退堂鼓，勸你放棄轉管理。我們現在正在進行產業升級，各行各業都需要在科技水平和管理水平上進行升級，以應對更加激烈的全球競爭。這也許就是你的機會。

想要把握住機會，就不能僅僅以你的前輩作為榜樣和基準，而是要進行更科學的管理方面的學習和訓練。這里，我分享幾個關于管理的基本原理和概念。

01 彼得定律

彼得在20世紀70年代研究了美國數千個組織，包括政府部門、學校、企業等，發現在一個成熟有效的組織中，當一個員工在其崗位能夠出色完成工作時就會得到晉升，被提拔到更高一級職位。如果在這個職位，他能夠繼續出色地完成工作，就會繼續得到晉升，直到他晉升到某個職位以后無法出色完成工作為止。

這是職場晉升的一般規則，看起來似乎沒什么，但是彼得在對這些得到晉升的人進行各種觀察以后，得出一個結論：在一個層級組織中，每個員工都會趨向于晉升到他所不能勝任的職位。這就是彼得定律。

事實上，根據晉升的一般規則也能推導出這個定律。利用這個定律做進一步的推導，還能得到一個彼得定律的推論：在一個成熟的組織中，所有的職位都被不能夠勝任它的人承擔著。

這個推論也很好理解，每個人都會晉升到他不能勝任的職位，那么穩定下來以后，所有的職位都會被不能勝任的人承擔。不得不說這個結論實在讓人有點吃驚，但是卻很好地解釋了組織中的各種奇怪現象。

彼得進一步對這些不能勝任自己職位的人進行觀察，發現當一個人位于他不能勝任的職位時，他必須投入全部的精力才能有效完成工作，這個職位也被稱作這個人的彼得高地。一個處于彼得高地的人，精疲力盡于他手頭的工作，無法再進行更進一步的思考和學習，他的個人能力提升和職業進步都將止步于此。

所以，一個人在其職業生涯中能夠晉升的最高職位，能夠在專業技能上進化的最高階段，依賴于他的專業能力和綜合素養，依賴于他擁有的持續學習和專業訓練的條件與環境，這和他晉升的速度無關。

對公司而言，真正有價值的是你為公司解決了多少問題，而不是完成了多少工作，工作本身沒有意義，解決問題才有意義。對于你自己而言，真正有價值的不是你獲得了多快的晉升、多高的加薪，而是你獲得了多少持續高強度訓練的機會。而這兩者本質上是統一的。

所以，對自己的未來有更多期待、更有進取心的工程師，應該將精力更多地放在發現企業的各種問題并致力于解決問題，在這個過程中，你將同步收獲職場晉升和個人能力提升。

02 用目標驅動

在技術管理領域，常見的管理方式有兩種：一種是問題驅動型管理，一種是流程驅動型管理。

問題驅動型管理著眼于問題，每天關注最新的問題是什么，然后解決問題。流程驅動型管理著眼于流程，關注事情的進展是否符合流程規范，是否在有序的規章制度下行事，看起來像監工。

老實說，這兩種都不是高效的管理方法。對于技術管理而言，更高效的管理方式是目標型管理。

目標驅動的管理者關注的是目標。公司的目標是什么？部門的目標是什么？團隊的目標是什么？我的目標是什么？我和我的團隊做這些事情的價值和意義是什么？不斷問自己：我如何做才能為公司、為客戶創造價值？

目標驅動的管理者并不特別關注問題，他更關注解決方案。當系統出現故障的時候，他不會關注是誰導致的Bug，而是更關注誰可以解決這個Bug。當項目進展緩慢的時候，他并不關注是誰導致了拖延，而是更關注我們如何做才能趕上進度。

他不問為什么出現問題，因為他知道，所有的問題最后都是人的問題，而糾結于人的問題只能導致人們彼此推諉。

目標驅動的管理者其實并不是不關注問題，他只是不用問題進行管理，不讓團隊糾結于問題之中，而是著眼于未來和解決方案本身。管理者自身其實對問題非常清楚，但是他把問題轉化為目標，引導團隊前行。

OKR這個詞最近兩年風靡于互聯網企業。OKR其實就是目標（Object）與關鍵結果（Key Result），即通過對團隊和個人制定有挑戰性的目標和可量化的結果標準進行管理，可以說是目標驅動管理的一種落地實踐方案。

通常在一個OKR周期開始的時候，每個團隊和個人都會制定自己的OKR：我的目標是什么？達成目標后產生的關鍵結果是什么？所有的OKR都需要公開，通過閱讀自己合作伙伴和上級部門的OKR，了解自己的目標在組織中的作用，自己工作的結果對組織的價值，從而了解自己在組織中的位置，使自己的工作成為組織戰略的一部分。

在工作過程中，根據目標不斷調整自己的工作方式，期間需要定期進行評審（Review）：到目前為止，我產出的成果有哪些？距離我們的目標是更近了還是更遠了？我們還需要做哪些工作才能達成期望的結果？

需要注意的是，OKR并不是用來考核的，不應該以目標是否達成作為考核的依據，否則每個人都傾向于給自己制定最簡單的結果和目標。

OKR是一種管理手段，通過對目標的制定和對結果的審核，將團隊和員工的奮斗目標與公司的戰略目標統一起來，使每個人都能理解自己工作的目標是什么，在整個公司戰略中的地位如何，進而使每個人成為公司整體中重要的一部分。

03 小結

管理學作為一個學科已經出現了上百年，它有自己的專業工具和方法，也有自己的客觀規律。技術做得好并不能保證管理做得好，想轉管理的技術人應該專門學習一下管理學的基礎知識，而不是僅僅看兩篇公眾號，覺得自己技術不錯還擅長溝通就要轉管理。

關于作者：李智慧，資深架構專家，同程旅行交通首席架構師，曾在NEC、阿里巴巴、Intel等知名企業擔任架構師，也曾在WiFi萬能鑰匙等企業擔任CTO。長期從事大數據、大型網站的架構和研發工作，領導設計過多個日活用戶在千萬級以上的互聯網系統架構，實戰經驗豐富。曾設計、開發過 Web 服務器防火墻、分布式NoSQL 系統、大數據倉庫引擎、反應式編程框架等各種類型的軟件系統。

本文摘編自《架構師的自我修煉：技術、架構和未來》，經出版方授權發布。

延伸閱讀《架構師的自我修煉：技術、架構和未來》

點擊上圖了解及購買

轉載請聯系微信：DoctorData

推薦語：大型網站技術架構作者李智慧新作，通過架構師的4項自我修煉，構建你的架構師知識體系，完整展示架構師修煉之道。

劃重點????

干貨直達????

• 數據中臺、標簽、數據資產相關的15個名詞解釋
  

• 圖靈獎得主都寫過哪些書？
  

• 終于有人把卷積神經網絡（CNN）講明白了
  

• 終于有人把監督學習、強化學習和無監督學習講明白了
  

更多精彩????

在公眾號對話框輸入以下關鍵詞

查看更多優質內容！

PPT?|?讀書?|?書單?|?硬核?|?干貨?|?講明白?|?神操作

大數據?|?云計算?|?數據庫?|?Python?|?爬蟲?|?可視化

AI?|?人工智能?|?機器學習?|?深度學習?|?NLP

5G?|?中臺?|?用戶畫像?|?1024?|?數學?|?算法?|?數字孿生

據統計，99%的大咖都關注了這個公眾號

????

總結

以上是生活随笔為你收集整理的35岁的程序员，真的要转管理吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。