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

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

作者：李智慧

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

事實上，過去十幾年，技術人員之所以能夠容易地轉為管理人員，根本原因在於開發行業的快速擴張。

隨著網際網路的快速發展，軟體開發的從業人員數量大概增長了幾十倍，開發團隊規模迅速擴張，因此必須要有技術人員成為管理者，以管理越來越龐大的技術團隊。

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

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

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

但是，這條光明的道路其實隱藏了

一個非常重要的前提，那就是技術團隊規模必須呈指數級增長，這樣才能產生足夠數量的管理崗位空缺

，才會讓後來的人跟前面加入公司的人一樣有機會成功轉型管理。

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

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

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

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

想要把握住機會，就不能僅僅以你的前輩作為榜樣和基準，

而是要進行更科學的管理方面的學習和訓練。

這裡，我分享幾個

關於管理的基本原理和概念。

01 彼得定律

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

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

彼得定律

。

事實上，根據晉升的一般規則也能推匯出這個定律。利用這個定律做進一步的推導，還能得到一個彼得定律的推論：

在一個成熟的組織中，所有的職位都被不能夠勝任它的人承擔著。

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

彼得進一步對這些不能勝任自己職位的人進行觀察，發現當一個人位於他不能勝任的職位時，他必須投入全部的精力才能有效完成工作，這個職位也被稱作這個人的彼得高地。

一個處於彼得高地的人，精疲力盡於他手頭的工作，無法再進行更進一步的思考和學習，他的個人能力提升和職業進步都將止步於此。

所以，一個人在其職業生涯中能夠晉升的最高職位，能夠在專業技能上進化的最高階段，

依賴於他的專業能力和綜合素養，依賴於他擁有的持續學習和專業訓練的條件與環境，這和他晉升的速度無關。

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

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

02 用目標驅動

在技術管理領域，常見的管理方式有兩種：一種是

問題驅動型管理

，一種是

流程驅動型管理

。

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

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

目標型管理

。

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

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

他不問為什麼出現問題，因為他知道，

所有的問題最後都是人的問題，而糾結於人的問題只能導致人們彼此推諉。

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

OKR

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

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

在工作過程中，根據目標不斷調整自己的工作方式，期間需要定期進行

評審

（Review）：到目前為止，我產出的成果有哪些？距離我們的目標是更近了還是更遠了？我們還需要做哪些工作才能達成期望的結果？

需要注意的是，

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

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

03 小結

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

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

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

推薦語：

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