PhonePe が次の成長段階に移行する中、私の課題は、エンジニアにプロとしての成長のためのロードマップを提供しながら、私たちの野心的な目標を真っ向から中心に据えるエンジニアリング組織を設計することでした。

PhonePe は、消費者や企業が経済に参加して繁栄するのに役立つさまざまな製品やサービスを提供するエコシステムです — Karte Ja Badhte Ja!

個人的には、PhonePe はさまざまなパートナーとの継続的なコラボレーションを可能にするテクノロジー プラットフォームであると考えています。 私たちは革新的でインテリジェントな製品を作成し、トランザクションの速度、シンプルさ、セキュリティに基づいて、顧客に豊かな体験を提供します.

しかし、このような広いキャンバスに絵を描くということは、近い将来、さまざまなチームが製品の成熟度のさまざまな段階にあることを意味し、エンジニアは、プラットフォームをスケーリングしてハイパーグロースを管理しながら、グロースハックを使用して長期的な能力構築を常にジャグリングしています。 これには、曖昧な問題の解決、あいまいさへの対処、データ駆動型の意思決定、大規模な計画、および多くのコーディングが含まれます。

取り組んでいる製品のライフ ステージに応じて、エンジニアは 1 つのスキルまたは特定の領域で、他のスキルよりも多くの筋肉を鍛える必要がある場合があります。 同時に、会社の野心は、さまざまなレベルのテクノロジーとドメインの専門知識を持つ新しい才能をもたらすことによって、チームを成長させ続けることを要求しています. そこで私は、組織の目標とニーズに焦点を当てながら、時間の経過に伴う学習とスキルの蓄積を通じて、エンジニアの全体的な成長に合わせたフレームワークについて考え始めました。

最初の思考プロセスは、今日のラインに沿って、エンジニアリングのキャリアのはしごをより細かく定義することでした。 私の過去の経験に基づくと、典型的なキャリア ラダーは、役割のスキル レベルの組み合わせを役職に結び付けるコンピテンシー フレームワークで構成されています。 これは、個人の名目上の成長の局所的な最大値を達成することにのみ焦点を当てた行動を促進する傾向があります.

一方、現代のキャリアは（特に消費者のインターネット空間では）はるかに流動的です。 彼らは、企業の価値を最大化するために、どのスキルセットを開発し、どの時点で行使するかを選択する際に、個人にかなりの柔軟性を要求します。

これにより、キャリアラダーの定義を、所有権と責任の範囲の拡大に基づいてエンジニアの成長期待を設定するフレームワークに再考するようになりました. 私の見解では、これは、急速に変化する組織での実際のキャリアの成長によりよく当てはまると思います。そこでは、個人が所有する憲章がより大きく、より広くなるにつれて、個人に対する要求がより多面的になります。

PhonePe でのキャリアのはしごに対する私の見解は、スキル構築に重要な次元を中心としたスライド スケールであり、PhonePe の文化と価値観にうまく対応しています。 1 つのスキルを指して「よくやった! あなたは今、シニア エンジニアまたは SDE3 などです。

組織内でより多くの責任を負う際に、最大の影響を生み出すための最善の運用方法に関するガイドと見なす必要があります。 その過程でスキルと学習を蓄積し、バランスの取れたエンジニアリング リーダーになると同時に、生み出された価値と影響に対して報酬を得ることができます。 それは目標指向ではありませんが、卓越性の追求です。 そのため、 PhonePe での Engineering Journeyという名前が付けられました。

PhonePe エンジニアリングの旅をどのように定義しますか?

PhonePe Engineering Journey は、在職期間や階層ではなく、所有権、影響力、影響力の範囲を通じて、エンジニアリング組織内の個人の成長をマッピングするフレームワークとして定義されています。 これは、次の目的に役立つように設計されています。

• 個々の貢献者が責任を拡大するにつれて、より効果的になるために開発する必要がある特性とスキルについてのガイドとなる
• 貴重な貢献に対して公正かつ一貫して報われることを保証しながら、約束を示しながら、マネージャーがチーム内の個人の責任を拡大するためのガイドとなる
• エンジニアリング組織は、仕事での学習と影響を与えるために同じことを適用する環境を作成することに専念し続け、キャリアの成長はこのプロセスの自然な結果です。

エンジニアリング ジャーニーの詳細について考えを深めるにつれて、エンジニアリング組織としての価値観と、真の意味でのエンジニアリングの成長を表すものについての信念を反映した一連のコア テネットに収束しました。 今後の役割と責任の定義に影響を与えるため、これらを詳細に説明することが重要です。

コアテネット

「範囲と影響」に基づき、「成長の側面」に導かれる成長

PhonePe エンジニアリング ジャーニーの「範囲と影響」では、役割における責任の幅と深さが増し、チームや組織がそこから得られる価値について説明します。 役割の成長は、範囲と影響の増加のレンズを通してのみ測定する必要があります— エンジニアが専門家として成長するにつれて、その範囲 (および対応する影響) も、チーム内の小さなタスクと機能を所有して提供する (監督下で) から移動します。 、機能とサービスをエンドツーエンドで所有し、大規模なプラットフォームと製品をエンドツーエンドで所有します。

「成長の次元」とは、組織としての私たちに固有の技術的スキルと行動特性、およびエンジニアが PhonePe で成功するための要素を指します。 これは、私たちの組織の種類 (多様な製品、決済および金融サービス ドメイン、データ駆動型の意思決定を強化するオープンな大規模プラットフォーム) と、エンジニアに教え込みたい文化 (高い所有権と情熱、対処能力) の機能です。あいまいさ、継続的な学習による成長、およびプラスの影響によるリーダーシップ）。

「成長の側面」はガイドとしてのみ機能し、責任範囲の拡大を準備し、目指すためのチェックリストではありません。 たとえば、エンジニア (バックエンド エンジニアであろうとアプリ開発者であろうと) は、より幅広い責任を求めているため、特に、設計と開発のスキル、および周囲のシステムの理解を向上させる必要があります。

あなたにおすすめ:

資力

RBI のアカウント アグリゲーター フレームワークがインドのフィンテックを変革するためにどのように設定されているか

アミット・ダス

2022 年 7 月 31 日

ニュース

起業家は、「Jugaad」を通じて持続可能でスケーラブルなスタートアップを作成することはできません: Cit...

ジャスプリート K.

2022 年 7 月 31 日

資力

メタバースがインドの自動車産業をどのように変革するか

バイバブ S.

2022 年 7 月 31 日

資力

反営利条項はインドのスタートアップ企業にとって何を意味するのか?

チャラニャ L.

2022 年 7 月 31 日

資力

Edtech スタートアップがインドの労働力のスキルアップと将来への準備をどのように支援しているか...

アンクシュ S.

2022 年 7 月 31 日

ニュース

今週の新時代のテック株：Zomatoのトラブルは続き、EaseMyTripはスト...

タパンジャナ R.

2022 年 7 月 31 日

同時に、ますます複雑化するプロジェクトを遂行するために、より良い計画と優先順位付けに投資する必要もあります。 ただし、これらに加えて、エンジニアは、他の人を指導する能力、(階層構造に支えられてそうするのではなく) 影響範囲を介して変化に影響を与える能力、および自分自身とそのチームの変化とあいまいさを管理する能力も成長させる必要があります。成功するために。

「成長の次元」は、継続的な改善のガイドとして機能することで、エンジニアが長期的にエンジニアとしての全体的な成長を確保しながら、チームが必要とするものに基づいて開発のさまざまな分野への投資を自己管理できるようにします。

成長への型にはまったアプローチを避ける

所有権の範囲とエンジニアが組織に与える影響は、エンジニアが成長のさまざまな次元でどの位置にいるかだけでなく、彼/彼女が所属するビジネスとチームの要求の機能でもあります。 エンジニアは、他の次元の成長を犠牲にして、ビジネスに必要な特定の次元に焦点を当てて過剰にインデックスを作成することがあります。

したがって、ある時点で、社内で同様のレベルの責任を負うすべてのエンジニアが、さまざまな側面で同じレベルの成長を遂げるとは期待できません。 同様に、責任範囲および/または報酬の範囲の拡大は、すべての次元での改善の計画的な実証に常に左右されるべきではありません。 ただし、組織と個人は、構造化されたローテーション、職場での学習、およびメンターシップを通じて、時間の経過とともに次元を超えた成長が達成されるようにする必要があります。

以下は、上記の 2 つの指針となる原則の図です。同様の所有期間と影響への期待を持つ 3 人の個人は、範囲と影響およびディメンションの尺度で異なるマッピングを行います。 同心円は範囲と影響の成長を表し、5 つの軸は成長の次元を表します。

個々のコントリビューターとマネージャーの成長の並行トラック

PhonePe のエンジニアリングには、個人貢献者 (IC) トラックと管理トラックの 2 つの異なる並列キャリア トラックがあります。 エンジニアリング ジャーニーでは、IC トラックでの成長がすべての面でマネジメント トラックでの成長と同等であることを保証する必要があります。また、影響力の創出に関してはガラスの天井がなく、リーダーシップ スキルと報酬を実証する必要があります。 個々の貢献者は、人材管理の中心的な責任に関心がある場合、マネージャーになることができます。 しかし、この変更は昇進ではなく、横方向の動きになります。 これは、間違った理由でトラックを変更するインセンティブを作成しないようにするのに役立ちます。

階層的なタイトルより機能的なタイトル

会社の成長は所有権と影響力の範囲の直接的な代理であることを考えると、役職はその機能範囲を正確に反映するためにのみ必要であり、その中に階層は必要ありません。 私たちは、報酬と責任を増やすことによって範囲および/または影響力を強化する人々に報酬を与え、認識します。

これにより、肩書きが個人の動機ではなくなります。 また、特定のディスカッション フォーラム、エキサイティングな新しいイニシアチブ、または意思決定機能に参加する資格は、役職ではなく、その人の機能的役割とパフォーマンスに基づいています。 これにより、組織階層が人々との日常的なやり取りにおいて果たす役割を持たず、議論が行われ、議論の背後にいる個人ではなく、議論の技術的メリットについて閉鎖される文化が構築されます。

では、PhonePe でのエンジニアリングの役割にとって、これは何を意味するのでしょうか?

前述のように、私たちのエンジニアリングのはしごは、特定された次元に沿ったスライディング スケールであることを考えると、成長のすべての段階で役割を肩書きすることから離れ、肩書きを得るよりも、より多くの責任を獲得することに引き続き重点を置いていることを確認します。 当社の肩書は機能的で、年功序列ではなく役割の適用可能性を示すように設計されています。

個人貢献者トラック

この原則に基づいて、エンジニアリングのソフトウェア開発機能では、IC トラックにソフトウェア エンジニアとソフトウェア アーキテクトという 2 つの役割があります。 ソフトウェア エンジニアの役割の機能的責任は、主に製品チーム、または通常は組織の L1 目標に関連付けられている一連の隣接する POD に割り当てられます。 ソフトウェアアーキテクトの機能的責任はより水平的であり、主に規模、信頼性、パフォーマンス、データセンターのコスト最適化などのテクノロジー組織の目標にマッピングされています。

ソフトウェア エンジニアは、時間の経過とともに製品レベルの深い専門家になりますが、それは彼らがチーム外のより広範なイニシアチブに関与していないという意味ではありません。

同様に、ソフトウェア アーキテクトは、近視眼的に組織のイニシアチブだけに焦点を当てているわけではありません。 彼らはまだチームに属しており、チームのイニシアチブに定期的に貢献していますが、それは彼らの関心の全体的な焦点ではありません。 異なるタイトルを保証するのは、この機能の違いです。 しかし、両方の役割は、学習や報酬の理由で一方から他方へ切り替える必要なく、ずっと平行した成長経路を持ち続けます。

マネージャー トラック

キャリア開発の基礎として、チームと組織のスコープを持つ管理トラックで同様の分岐を採用しました。 初級レベルのエンジニアリング マネージャー、およびチーム スコープを持つ経験豊富なエンジニアリング マネージャーは、エンジニアリング マネージャーの役​​割にマッピングされます。 エンジニアリング管理側の憲章が拡張され、チーム固有ではない組織的責任と P&L 責任の共同所有が含まれるようになると、その役割はエンジニアリング責任者の役割になります。

この場合、エンジニアリング マネージャーとエンジニアリング ヘッドの間のキャリア グラフには一部重複がありますが、エンジニアリング マネージャーの自然なキャリアの進行は、エンジニアリング ヘッドの役割になります。

レベル

両方のトラックで、上記の各役割は人事システムの報酬レベルにマッピングされます。 これは、市場に対して給与を継続的にベンチマークする能力を確保し、システム内に給与の増加と雇用のためのチェックポイントを確保するためです。 ただし、これらのレベルは、機能内のフラットな役割の目的を無効にするため、個人には知られていません。 報酬の決定以外でこれらのレベルを使用すると、機能不全になります。

これはエンジニアリングのすべての分野で一般化できますか?

PhonePe には、バックエンド、モバイル、UI、DevOps、データ サイエンス、品質、セキュリティなど、さまざまなソフトウェア エンジニアリング分野があります。 また、POD として機能横断的に編成された多くのビジネスおよび製品ユニットがあります。 上記の例は主にエンジニアリングのコア開発機能を強調していますが、アプローチと原則は、すべての分野とチームのエンジニアとマネージャーに適用できると思います。

会社全体で一貫した基準を確保することで、流動的な社内異動を可能にし、個人の成長をさらにサポートすることができます。 個人は、幅広い製品や問題に取り組むことで、スキルセットと視野を広げることができるはずです。 それが最終目標です。

参考文献

PhonePe でエンジニアリングの成長フレームワークをどのように構築したいかを考え始めたとき、他の人が同じ問題にどのようにアプローチしたかを調べました。 そして、多くの組織がこれに関する彼らの哲学についてどれほどオープンであるかに驚いた. それらの多くがこれに関する私の考えに影響を与えていることを考えると、フィードバックのために私たちの見解をオープンにし、それに影響を与えたものにクレジットを与えることは正しいことです.