如今，高級軟件開發人員（無論是初創公司還是更多公司風格的公司）自然而然地要從他們目前的技術角色過渡到更具領導力/管理導向的角色。這種進步通常是由公司/團隊/產品的發展所引起的多種需求推動的，需要高級開發人員將時間用於培訓/入職，規劃/路線圖和領導團隊，從而做出更多宏觀決策和指導，同時越來越少地參與日常工程活動。
職務的標題並不總是“經理”。這通常與工程副總裁或Tech / Team / Project Lead相似，儘管您需要進行大量管理活動，但其含義與在職稱中擁有Manager有著不同的含義。
在本文中，我將介紹如何以及為什麼從以技術為導向的角色過渡到以管理為導向的角色，以及它可能帶來的問題。
“嘿，我邀請你參加我們談論的那次會議……”
從技術到管理的躍遷是團隊成長和您在項目中的資歷引起的自然進步。如果團隊需要更多開發人員，那麼您可能會參與招聘過程。然後，當這些人加入團隊時，指導/指導他們是您的工作。如果要做出激烈的設計或體系結構決策，那麼您就是負責做出最終決策的人之一。所有這些任務通常都需要很多時間，無論是花時間審查和批准候選人，回復電子郵件還是準備和舉行會議。
這意味著您將把大部分時間都花在與管理團隊直接相關的活動上，而不是實際開發軟件，對於很多開發人員來說，這可能是一個巨大的負擔。
但是，將重點轉移到更多的面向管理的工作可能是必不可少的。作為高級開發人員，您擁有該項目的技術知識，並且將是能夠告訴新手是否適合該項目的人之一。由於您從一開始就已經參與項目，因此您將在估計任務和計劃工作時非常精確，並且早日做出了設計決定並了解了體系結構。所有這些知識都是非常有價值的，並且在大多數情況下，僱用新人從事需要所有這些先驗知識的工作不是一種選擇。
話雖這麼說，這是開發人員從其技術角色轉到更加註重管理的角色的一些原因。
薪水
實話實說，公司願意花更多的錢用於管理人員上，而不是花在技術上。我知道這是普遍現象，可能並不適用於所有公司，但是您作為軟件開發人員的薪資水平要比管理其他公司的速度快得多。
在我看來，發生這種情況的原因有兩個。
第一個原因是，軟技能通常比硬技能（技術技能）付出更多。
第二個原因是問責制。
軟技能比技術技能更難學習。當然，您可能有一位超級明星工程師，是10倍的開發人員，可以獨自完成自己的工作。但是，如果他只能自己工作，那他和您的團隊真的相關嗎？如果他的溝通能力很差怎麼辦？您是否仍然傾向於將他提升為更加註重教練的職位？他會做得好嗎？
管理人員需要做好工作，但他們還必須具備強大的軟技能，以解決項目建設中的人為因素，例如溝通，同理心，團隊合作精神和解決問題的能力。
問責制意味著您將成為團隊成敗的罪魁禍首。當一切都出錯時，您不會責怪執行該操作的人並且做錯了，而是在責備下達命令的人，而當您是下達該命令的人時，您的頭在砧板上意味著更多的$$。
職業與生活方式
軟件開發是一種工作，您需要不斷學習和升級您的工具包，以保持敏銳的表現並儘可能做到最好。但是生活和其他責任可能會使您遠離深夜從事輔助項目或閱讀典型的博客文章。這對心理的影響比什麼都重要。人們開始覺得自己無法保持最新，熟練的技能，而轉而從事給他們更多空間的工作。
而且，隨著人們的成熟，他們還可以更加清楚地了解生活和人與人之間的互動，因此他們自然會獲得溝通技巧和經驗，這對於管理操作很有價值。
另一方面，有些人進入軟件開發的明確目標是晉升隊伍並成為團隊的經理。
迎接新角色
對於正在考慮跳傘的人們，在進行過渡時需要考慮以下一些關鍵方面。
1）將重點從技術工作轉移到管理工作
有些人真的很害怕管理工作，並竭盡全力堅持他們可以做的任何技術工作。這並不是一件壞事，因為大多數將技術工作與管理工作結合在一起的開發人員通常會成功地做到這一點，這使他們能夠與團隊的需求以及他為消除障礙所做的工作有更多的聯繫。球隊。如果您的上級/公司允許您瀏覽更多的技術工作，那就繼續吧；如果沒有，嘿，總會有一些副業！
但是，如果您仍然是開發人員，那麼請不要走關鍵路線。說真的
現在，您的時間分配在許多活動之間。如果代碼審查或部署取決於您，那麼您將成為團隊的瓶頸，僅是出於自私的目的，並嘗試保持盡可能多的技術工作。如果您發現自己處於這個位置並且不願意放手，那麼您可能不適合擔任管理職位。
2）不要成為團隊的樞紐
工程不是孤立存在的。工程團隊需要與其他專業知識並存，以便為客戶帶來價值。使團隊遠離障礙或乾擾（這是經理的任務）與使團隊遠離外界任何溝通方式不同。
您的開發人員應該能夠與來自不同領域的其他團隊以及公司產品的最終用戶進行交互，以便調整產品的適用性並發現軟件中的缺陷。如果這變得難以管理，請分配一個時間範圍，使團隊可以執行專門用於外部依賴項的工作。
3）僱用權
招聘始終是一個棘手的話題。招聘過程通常會花費很多時間，而高層人士花費的時間越多，他們的花費就越多。如果您的公司的規模超過20人，則應考慮聘請專門的HR人員。
需要考慮的一些關鍵點是：
- 如果您需要質量，請僱用質量。軟件開發人員可能會很昂貴，但他們可以快速賺錢。至少嘗試招募幾名穩定可靠的員工，然後再指導團隊的其他成員。
- 不要陷入推薦陷阱，也不要讓團隊自行招聘。團隊需要多樣性，您不希望每個人都認為/相同的團隊。
- 聘請價值合適的人。強迫不相信TDD的人必須這樣做比讓某人學習一種新語言要困難得多。
作為該主題的最後註解，對於當前針對軟件開發工作的面試/錄用過程被打破，有一些意見。請花一些時間查看公司的當前流程，並相應地提供您的反饋。
4）有目的的入職
在討論團隊生產力和新員工的總體滿意度時，入職培訓是至關重要的主題。
在小公司（<10）上，入職過程通常是自發的。但是，如果您的團隊發展壯大，那麼是時候超越“嘿，這就是您的位置，請和[人員]談談”。
作為團隊經理和領導者，您的工作是為人們提供所需的所有環境並進行指導。您可以將新聘的工程師指向他需要的資源，將他介紹給團隊和團隊的流程，並立即使他開始。人們已經知道他們會在早期階段變得無能為力，所以不要再給他們任何理由來感受這種感覺了。
支持是最有效的（對於成長而言是有幫助的）過程之一。通過分配支持任務，新僱用的成員可以研究其溝通技巧，了解不同的問題和產品的各個部分，並在關閉支持通知單的同時瀏覽項目。這將極大地幫助他或她了解產品，市場以及一切運作方式。在我看來，這也是一種成長經驗，因為作為開發人員，它將從客戶的角度了解產品的問題，這可以導致了解在用戶體驗方面失敗的原因以及可以改進的方面。
5）1對1
這沒有多少科學。您應該與團隊成員進行一對一的對話。在這些討論中，您應該集中精力弄清楚他們的工作方式，他們如何適應團隊和公司以及他們認為將來有什麼潛在問題。您不僅會與他人建立信任關係，而且還會弄清楚在日常運營中可能不會出現的一些潛在問題。
您還應該在這些情況下提供（和接收）反饋。
6）處理技術債務
作為一名由開發人員轉為經理的人，您比誰都知道，最困擾開發人員的事情之一是技術債務。沒有人願意在有缺陷的基礎上蓋房子，因此，只要有可能，就給您的團隊一些重構和重組的空間。
技術債務可能是影響或破壞團隊士氣的因素之一。如果團隊能夠處理技術債務，他們會感到自己的工作受到尊重，並且可以正確解決在計劃期間做出的妥協。相反，永遠無法做一些“內務處理”可能最終導致沮喪，疲倦，並最終導致人們離開團隊。
7）激勵交流與協作
您需要知道人們在做什麼。如果您不知道，那麼您將不知道自己在做什麼。使用您可以使用的工具進行跟踪，不僅可以了解一切是否按預期運行，而且還可以在需要時疏通人員。
另外，定期舉行演示會議。團隊需要能夠向公司其他部門介紹他們所做的工作。這將使每個人都專注於交付正確的事情（可表示），並且還可以作為不參與其中的每個人的狀態更新。
8）定義文化和價值觀
成長是文化的敵人。大多數公司以擁有驚人的文化而感到自豪，只是發現這種文化是C * O信念的迴響。
問問自己，問問隊友-“我們的文化是什麼？”
如果您沒有定義文化聲明，那麼也許是時候通知公司有關此事需要做的事情了，否則每個團隊都會創建自己的文化，通常由最具統治力的人物的意見來定義。即使負責人是正直的，他們的個人價值觀也可能與公司所定義的文化相衝突。文化定義是每個人都應該做出貢獻的一種練習。隨著團隊/公司的成長以及更多的人為此做出貢獻，這個定義會隨著時間的推移而發展。
價值觀既是公司層面的，也是團隊層面的。對於軟件開發團隊來說，值可以強制執行TDD和代碼審查，也可以始終具有明確定義的git流。始終注意那些不遵守團隊價值觀的人。價值衝突導致的倦怠是真實的，這可能是團隊不穩定的原因。
9）獲得反饋
並非每個人都具有經驗管理能力，或者從一開始就可以正確地進行管理。如果需要，進行適當的培訓。這可以是讀書，參加課程或參加研討會。請確保在培訓之後，負責管理公司中不同部門或團隊的每個人都聚在一起，討論在管理方法論上什麼可行，什麼無效。
另外，如果可能，請您的工作由處於相同狀態的其他人審核。同行評審始終可以有效地發現可以改進工作的地方。
10）不要長時間講道
舉個例子，這是您作為指導者和領導者的責任；如果您現在不知道長時間工作的缺點，那麼您應該了解情況。這可能會在您不知情的情況下暗中傷害您的團隊。我發現本文對這個主題很有啟發性。
結論
從開發人員過渡到管理人員並不是一件容易的事，但它可能會引導人們走向更有意義的職業道路。考慮一下您想做什麼以及在什麼情況下您可以管理工程團隊。還請記住，此切換要求您精通團隊工作的許多方面。