在過去的幾年裡，我有幸與很多才華橫溢的工程師共事——其中一些還在我的建議下還走上了管理崗位。
同任何一個投入新工作的人一樣，他們必須要從根本上改變自己每天的做事方式。我在指導他們的過程中可謂竭盡全力，基於這種經歷，我寫了一些感想，探討如何將他們的工程技能最有效地轉變為管理技能。其中一些想法比較具體，適用於管理工程師，但大多數想法都屬於經驗之談，應該適用於任何一家正處於發展中的公司的管理人員。
實用主義
我現在會經常講到這個故事，但是我認為初級工程師和高階工程師之間的主要區別是他們的務實能力。初級工程師在看待問題時故弄玄虛，他們會說，“我知道問題出在哪兒了，”然後著手去解決。高階工程師會以務實的態度看待問題，他們會說，“我不知道問題具體出在哪兒，但我知道從何處下手去弄明白，”然後開始去鑽研資料。
我特別喜歡用的一個比喻是：每個問題或挑戰就像一棵樹，這棵樹的樹幹上有若干樹枝，這些樹枝代表了若干可能性。初級工程師從樹冠開始修剪，每次一根樹枝，從上往下一根根修剪，而高階工程師則是從樹幹開始，每次修剪很多樹枝，這其實就是在一次性消除很多可能性。
作為一個管理人員，你的角色很大程度上就像是老師，你所教授的內容大部分是“實用主義”：如何以最合乎邏輯的方法看待問題和處理問題。很顯然，每個人都有一點不同於他人的風格。作為管理人員的關鍵不是去扼殺這種差異，而是要幫助他們在工作中表現得更好。
體系與規模
在我認識的所有出色的工程師當中，每一個天生就善於系統性思考問題。他們總在思考如何以一種可伸縮的方式來開發產品。
從本質上講，管理人員的工作就是超出人性的一面（我保證以後會談到這一點），去建立一個由人構成的體系。當你帶領一家公司不斷髮展壯大時，必須要考慮如何使這個體系具有伸縮性。具體來說，在這一點上，你需要仔細斟酌你負責的每個決策和每個任務。如果有 20 多人都向你彙報工作，你要思考如何將那些工作做好。換句話說，在你看來，微觀管理就好像是棘手的工程專案，而在你所管理的員工看來，這並不是什麼不好的行為（無論你怎樣絞盡腦汁，你都會更好、更快地解決這個問題的）。
現在，人們的表現顯然與程式碼不同，但這是一個你必須在計算中考慮的可變因素，就像你在思考伺服器的速度或者 Python 相對於 Go 的功能時必須考慮的變數一樣。同樣，我希望你能瞭解你所選擇語言的優劣，應該清楚團隊中每個成員的長處和短處。這是你作為管理人員應該明白的，而不是要你的交流物件理解的。（關於這一點，我會在下面的章節做進一步解釋。）
最後一點關於伸縮性：每次你為公司或者團隊解決了問題之後，你應該思考一下你是如何將那個解決方案融入這個體系的。如果這是一個不斷變化的過程，那麼你不僅需要反思你是如何向現有員工傳達或執行那個過程的，而且還要反思你是如何向潛在員工傳達或者執行那個過程的。這可能像檔案編制那麼簡單，但關鍵是要保證你思考了這個問題。
做事動機
儘管我與工程師們共事時也有所收穫，但做管理人員之後學到了更多的東西。我認為，成為出色的管理人員的關鍵是，要明白用什麼方式來激勵向你彙報工作的員工。
你應該瞭解團隊中每個人的優點和缺點，最重要的是瞭解他們每天來工作的動力是什麼。你需要根據一個人的動力，試著調整跟他的交流方式。工作動力會有許多不同的表現方式：有的人是渴望得到認可，有的人則源於害怕，有的人純粹是為了解決真正的難題。如果你弄清楚是哪種動力（除了上面這些，還有很多）激勵著員工，那麼你的管理工作就會輕鬆許多。
要了解員工的動機，光做分析是不夠的，你還需要真正地去了解這個人。也就是說，在工作之外進行單獨的交流和談話（畢竟，他們的動力可能不是源於發生在辦公室的事情）。每週你都應該 體察下屬，以便更深入地瞭解他們的需要並建立良好的私人關係。
任務分工不明確等於沒分工
這不是做工程時特別要考慮的事情，但我仍然認為如果你要轉型為管理人員，這一點非常有用。一般來說，把任務分配給一群人，那就相當於這項任務會完不成。如果你想要確保事情能及時完成，就需要由專人負責。這是顯而易見的事情，但還是值得提一下。
最後要說的是，無論從哪方面講，從個人貢獻者向管理者的轉變，都是一個艱難的的過程。然而，我以前就說過，工程師們儘管平時沉默寡言，但比起公司的其他人，這個群體實際上更適合做管理工作。這種轉變絕非易事，管理工作當然也不是每個人都能做好的，但我依舊希望以上建議對大家有所幫助。
英文原文：Becoming An Engineering Manager
來自：部落格園
評論(1)