PhonePe 的工程之旅:工程師和工程經理的成長框架
已發表: 2020-07-12PhonePe 的職業階梯更多的是圍繞對技能培養很重要的維度進行滑動,並很好地映射到文化和價值觀
PhonePe 工程之旅的“範圍和影響”描述了角色責任的廣度和深度以及團隊所衍生的價值
基於這個原則,在工程中的軟件開發功能中,PhonePe在IC賽道有兩個角色——軟件工程師和軟件架構師
隨著 PhonePe 進入下一個發展階段,我面臨的挑戰是設計一個工程組織,將我們雄心勃勃的目標放在中心位置,同時為工程師提供專業發展路線圖。
PhonePe 是一個為各種產品和服務提供動力的生態系統,可幫助消費者和企業參與並在經濟中蓬勃發展——Karte Ja Badhte Ja!
我個人認為 PhonePe 是一個技術平台,可以與各種合作夥伴持續協作。 我們創造創新和智能的產品,以交易速度、簡單性和安全性為基礎,為客戶提供豐富的體驗。
但在如此廣闊的畫布上繪畫也意味著在可預見的未來,不同的團隊將處於產品成熟度的不同階段,工程師們不斷地在長期能力建設和增長黑客之間進行權衡,同時擴展平台以管理超增長。 這涉及模糊問題的解決、處理歧義、數據驅動的決策、廣泛的計劃和大量的編碼。
根據他們正在研究的產品的生命階段,工程師可能需要在一項技能或一個領域鍛煉更多肌肉而不是其他技能。 與此同時,公司的雄心壯志要求我們通過引進具有不同技術水平和領域專業知識的新人才來繼續壯大團隊。 因此,我開始考慮一個框架,該框架將通過隨著時間的推移學習和技能積累與工程師的整體成長保持一致,同時仍然關注組織的目標和需求。
最初的思考過程是按照我們今天的方式簡單地定義一個更細化的工程職業階梯。 根據我過去的經驗,典型的職業階梯包含一個能力框架,該框架將角色中技能水平的組合與頭銜掛鉤。 這往往會驅動那些特別關注實現個人名義增長的局部最大值的行為。
另一方面,現代職業(尤其是在消費者互聯網領域)更加流動。 他們要求個人在選擇開發和鍛煉哪些技能組合時具有相當大的靈活性,以便為公司帶來最大價值。
這讓我將我們對職業階梯的定義重新定義為一個框架,該框架基於不斷擴大的所有權和責任範圍設定工程師的成長預期。 在我看來,這更好地映射到快速發展的組織中的實際職業發展,隨著他們擁有的章程變得越來越大,對個人的需求變得更加多維。
我對 PhonePe 的職業階梯的看法更多的是圍繞對技能培養很重要的維度進行調整,並很好地映射到 PhonePe 的文化和價值觀。 沒有明顯的階梯函數,你可以指著任何一項技能說“幹得好! 您現在是高級工程師或 SDE3” 等。
當您在組織中承擔更多責任時,它將被視為如何以最佳方式運作以產生最大影響的指南。 並在此過程中積累技能和學習,使一個人成為全面的工程領導者,同時也因創造的價值和影響而獲得回報。 不以目標為導向,更多的是追求卓越。 因此得名, PhonePe 的工程之旅。
我們如何定義 PhonePe 工程之旅?
PhonePe 工程之旅被定義為一個框架,該框架通過其所有權範圍、影響力和影響力而不是任期或等級來映射工程組織中任何個人的成長。 它旨在服務於以下目的:
- 成為個人貢獻者的指南,了解他們需要發展的特質和技能,以便隨著責任的擴大而變得更加有效
- 成為管理者的指南,讓他們在團隊中表現出有希望的個人承擔起更大的責任,同時確保他們因其寶貴的貢獻而獲得公平和一致的獎勵
- 讓工程組織致力於創造一個環境,使工作中的學習和應用能夠影響每個人的主要目標,職業發展是這一過程的自然結果
隨著我們對詳細說明工程之旅的想法進行改進,我們融合了一系列核心原則,這些原則反映了我們作為工程組織的價值觀以及我們對真正意義上的工程增長的信念。 詳細說明這些很重要,因為它對我們未來的角色和責任定義有影響
核心原則
基於“範圍和影響”並以“增長維度”為導向的增長
PhonePe 工程之旅的“範圍和影響”描述了角色責任的廣度和深度以及團隊/組織從中獲得的價值。 角色的成長必須僅通過擴大範圍和影響的鏡頭來衡量——隨著工程師成長為專業人士,他們的範圍(和相應的影響)也將從擁有和交付(在監督下)團隊中的小任務和功能轉變,到擁有端到端的功能和服務,到擁有端到端的大型平台和產品。
“成長維度”指的是我們作為一個組織所特有的技術技能和行為特徵,以及使工程師在 PhonePe 取得成功的原因。 它是我們組織的一種功能(為各種產品、支付和金融服務領域以及數據驅動的決策提供支持的開放式大型平台)以及我們想要灌輸給我們的工程師的文化(高度的所有權和熱情、交易能力)模棱兩可,通過持續學習實現成長,通過積極影響發揮領導作用)。
“成長的維度”僅用作指南,而不是準備和渴望增加責任範圍的清單。 例如,作為一名工程師(無論是後端工程師還是應用程序開發人員)渴望承擔更廣泛的職責,他們需要提高自己的設計和開發技能,以及對周圍系統的理解等等。
為你推薦:
同時,他們還需要投資於更好的規劃和優先級,以交付越來越複雜的項目。 然而,除此之外,工程師還需要提高他們指導他人的能力,通過他們的影響範圍影響變革(而不是由等級結構支持),並為自己和他們的團隊管理變革和模糊性要成功。
通過作為持續改進的指南,“增長維度”允許工程師根據團隊的需要自我管理他們在不同開發領域的投資,同時確保作為工程師的長期整體成長。
避免千篇一律的增長方式
工程師在組織中的所有權範圍和影響不僅取決於工程師在各個增長維度中所處的位置,還取決於他/她所屬的業務和團隊的需求。 有時,工程師可能會專注於業務所需的特定維度並過度索引,而犧牲其他維度的增長。
因此,不應期望在任何給定時間點,公司中承擔相似職責的所有工程師都將在各個方面處於相同的增長水平。 同樣,責任和/或補償範圍的增加不應總是取決於有預謀地展示所有方面的改進。 但是,組織和個人應確保隨著時間的推移,通過結構化輪換、在職學習和指導,實現跨維度的增長。
以下是上述兩個指導原則的說明——擁有相似所有權範圍和預期影響力的三個人將在範圍和影響力和維度量表上進行不同的映射。 同心圓代表範圍和影響的增長,五個軸代表增長的維度:
個人貢獻者和經理的平行增長軌跡
在 PhonePe,我們在工程方面有兩條截然不同且平行的職業軌道——個人貢獻者 (IC) 軌道和管理軌道。 工程之旅必須確保 IC 軌道的增長在所有方面都與管理軌道的增長相當,在創造影響、展示領導技能和薪酬方面沒有玻璃天花板。 如果個人貢獻者對人員管理的核心職責感興趣,他們可以成為經理。 但這種變化將是橫向移動,而不是提升。 這有助於確保我們不會因為錯誤的原因而產生改變曲目的動機。
功能標題優於分層標題
鑑於公司的增長是您的所有權範圍和影響力的直接代表,因此僅需要標題來準確反映該功能範圍,而無需在其中建立層次結構。 我們通過增加薪酬和責任,而不是授予以任何方式描述資歷的頭銜來獎勵和認可人們在範圍和/或影響力方面的提升。
這確保了頭銜不再是個人的動力。 成為特定討論論壇、激動人心的新舉措或決策職能的一部分的權利取決於一個人的職能角色和績效,而不是頭銜。 這建立了一種文化,在這種文化中,組織層級在與人的日常互動中沒有作用,並且討論的發生並以所提出論點的技術優點而不是背後的個人為基礎。
那麼這對 PhonePe 的工程角色意味著什麼呢?
如前所述,鑑於我們的工程階梯在確定的維度上更像是一個滑動比例,我們正在擺脫在成長的每一步中為角色命名,以確保重點繼續放在獲得更多責任而不是獲得頭銜上。 我們的頭銜是功能性的,旨在表示角色的適用性,而不是資歷。
個人貢獻者追踪
基於這個原則,在工程中的軟件開發職能中,我們在 IC 賽道上有兩個角色——軟件工程師和軟件架構師。 軟件工程師角色的職能職責主要映射到產品團隊或一組相鄰的 POD,其目標通常與組織的 L1 目標相關聯。 軟件架構師的職能職責更加橫向,主要映射到規模、可靠性、性能、數據中心成本優化等技術組織目標。
然而,隨著時間的推移,軟件工程師會成為一名深入的產品級專家,但這並不意味著他們不參與團隊之外的更廣泛的計劃。
出於同樣的原因,軟件架構師並不僅僅短視地專注於組織計劃。 他們仍然屬於團隊並定期為團隊計劃做出貢獻,但這不是他們關注的首要焦點。 正是這種功能差異保證了不同的標題。 但是,這兩個角色一直都有平行的成長路徑,不需要出於學習或薪酬的原因從一個切換到另一個。
經理跟踪
我們採用了與管理軌道類似的分支,以團隊和組織範圍作為職業發展的基礎。 入門級工程經理以及具有團隊範圍的更有經驗的工程經理被映射到工程經理的角色。 隨著工程管理方面的章程擴大到包括非團隊特定的組織責任以及損益責任的共同所有權,該角色變成了工程主管的角色。
在這種情況下,雖然工程經理和工程主管之間的職業生涯圖會有一些重疊,但工程經理的自然職業發展是進入工程主管的角色。
級別
在這兩個軌道中,上述每個角色都映射到 HR 系統中的薪酬級別。 這是為了確保我們有能力根據市場持續對工資進行基準測試,並在系統內設置加薪和招聘檢查點。 然而,這些層級並不為個人所知,因為它違背了在一個函數中設置平面角色的目的。 在薪酬決定之外對這些水平的任何使用都是不正常的。
這可以推廣到工程的所有學科嗎?
PhonePe 擁有廣泛的軟件工程學科,包括後端、移動、UI、DevOps、數據科學、質量和安全性。 我們還有許多業務和產品單元,它們以 POD 的形式進行跨職能組織。 雖然上面的例子主要強調了工程中的核心開發功能,但我相信這些方法和原則適用於所有學科和團隊的工程師和經理。
通過確保我們在整個公司擁有一致的標準,我們可以實現流暢的內部流動性並進一步支持個人成長。 個人應該能夠通過處理廣泛的產品和問題來拓寬他們的技能和視角。 這就是最終目標。
參考
當我開始思考我想如何在 PhonePe 構建一個工程增長框架時,我開始尋找其他人如何解決同樣的問題。 許多組織對他們的理念持開放態度,這讓我感到驚喜。 鑑於他們中的許多人激發了我對此的思考,我們應該公開發表我們的觀點以徵求反饋意見,同時也讚揚那些對其產生影響的人。