The Engineering Journey At PhonePe: A Growth Framework For Engineers And Engineering Managers

As PhonePe moves to its next phase of growth, my challenge was to design an engineering organization that places our ambitious goal squarely at the center while giving engineers a roadmap for professional growth.

PhonePe is an ecosystem powering a variety of products and services that help consumers and businesses participate and thrive in the economy — Karte Ja Badhte Ja!

I personally see PhonePe as a technology platform enabling continuous collaboration with a wide variety of partners. We create innovative and intelligent products, anchored on transaction speed, simplicity and security, giving an enriching experience to customers.

But painting on such a broad canvas also means that for the foreseeable future different teams will be at different stages of product maturity with the engineers constantly juggling long-term capability building with growth hacks, while scaling the platform to manage hypergrowth. This involves fuzzy problem solving, dealing with ambiguity, data driven decisioning, extensive planning and a lot of coding.

Depending on the life stage of the product they are working on, an engineer may be required to exercise more muscle on one skill or in one area over the others. At the same time, the ambition of the company demands that we continue to grow the team by bringing in new talent with varying levels of technology and domain expertise. So I began to think about a framework that would be aligned to the holistic growth of engineers through learning and skill accumulation over time, while still focussing on the organisation’s goals and needs.

The initial thought process was to simply define a more granular career ladder for engineering along the lines of what we have today. Based on my past experience, a typical career ladder comprises a competency framework that pegs a combination of skill levels in a role to a title. This tends to drive behavior that is singularly focussed on achieving the local maxima of the individuals titular growth.

Modern careers on the other hand (especially in the consumer internet space) are much more fluid. They demand a fair amount of flexibility from individuals in choosing which skill sets to develop and exercise at what point in time to maximize value for the company.

This made me reimagine our definition of a career ladder to a framework that sets growth expectations of an engineer based on increasing spheres of ownership and responsibility. In my view, this maps better to real career growth in a fast moving organization where the demands on an individual get more multi-dimensional as the charter they own grows bigger and broader.

My take on the career ladder at PhonePe is more a sliding scale around dimensions that are important to skill building, and map well to the culture and values of PhonePe. There is no obvious step function where you can point at any one skill and say “Well done! You are now a Senior Engineer or a SDE3” etc.

It is to be viewed as a guide on how to operate best to create maximum impact as you take on more responsibility in the organization. And along the way accumulate skills and learnings that make a person a well-rounded engineering leader while also being rewarded for the value and impact created. It is not goal-oriented, but is more a pursuit of excellence. And hence the name, Engineering Journey at PhonePe.

How Do We Define The PhonePe Engineering Journey?

The PhonePe Engineering Journey is defined as a framework that maps the growth of any individual in the engineering organization through their scope of ownership, influence & impact rather than tenure or hierarchy. It is designed to serve the following purpose:

• Be a guide to individual contributors on traits and skills they need to develop to be more effective as their responsibilities broaden
• Be a guide for managers to grow the responsibilities of individuals in their team as they show promise while ensuring that they are rewarded fairly and consistently for their valuable contributions
• Keep the engineering organization committed to creating an environment that makes learning on the job and application of the same for impact the primary goal of every individual, with career growth being a natural outcome of this process

As we refined our thoughts on detailing the Engineering Journey, we converged on a set of core tenets that reflected our values as an engineering organization and our beliefs on what represents engineering growth in the true sense. It is important to detail these because of the impact it has on the role and responsibility definitions we will have going forward

Core Tenets

Growth Based On “Scope & Impact” And Guided By “Dimensions Of Growth”

The “Scope & Impact” of the PhonePe Engineering Journey describes the increasing breadth and depth of responsibility in a role and the value derived by the team/organization from the same. Growth in a role must be measured only through the lens of increasing Scope & Impact — as an engineer grows as a professional, their Scope (and corresponding Impact) would also move from owning and delivering (under supervision) small tasks and features in their team, to owning features and services end-to-end, to owning large platforms and products end-to-end.

The “Dimensions of Growth” refer to the technical skills and behavioural traits specific to us as an organization, and what makes an engineer successful at PhonePe. It is a function of the kind of organization we are (open large-scale platforms powering diverse products, payments and financial services domain and data driven decisioning) and the culture we want to inculcate in our engineers (high ownership and passion, ability to deal with ambiguity, growth through continuous learning and leadership through positive influence).

The “Dimensions of Growth” serve only as a guide and not a checklist to prepare and aspire for an increased span of responsibility. For example, as an engineer (whether a backend engineer or an app developer) aspires for broader responsibilities, they need to improve on their design & development skills, and their understanding of systems around them, among other things.

At the same time, they also need to invest in better planning and prioritization to deliver on projects of increasing complexity. Along with these, however, an engineer also needs to grow in their ability to mentor others, to affect change via their sphere of influence (as opposed to doing so backed by a hierarchical structure), and manage change and ambiguity for themselves and their teams to be successful.

By serving as a guide for continuous improvement, the “Dimensions of Growth” allow an engineer to self-manage their investment in different areas of development based on what is needed by their team while ensuring holistic growth as an engineer in the long term.

Avoiding Cookie-Cutter Approach To Growth

The scope of ownership and the impact that an engineer has in the organization is not only a function of where the engineer stands in the various dimensions of growth but also of the demands of the business and team he/she is a part of. Sometimes, an engineer may focus and over-index on certain dimensions that is the need of the hour for the business, at the expense of growth along other dimensions.

So it should not be an expectation that at any given point all engineers holding similar levels of responsibilities in the company will be at the same level of growth across the various dimensions. Similarly, the increase in the span of responsibility and/or compensation should not always be contingent on premeditated demonstration of improvement across all dimensions. However, the organization and individuals should ensure that over time through the structured rotation, on-the-job learning and mentorship, growth across dimensions is achieved.

Below is an illustration of the above two guiding principles — three individuals with a similar span of ownership and expectation of impact will map differently on the Scope & Impact and Dimensions scale. The concentric circles represent growth in scope and impact, and the five axes denote the dimensions of growth:

Parallel Tracks Of Growth For Individual Contributors & Managers

We have two distinct and parallel career tracks in engineering at PhonePe — an Individual Contributor (IC) track and a Management track. The Engineering Journey must ensure that growth on the IC track is comparable in all aspects to growth on the Management track, with no glass ceiling when it comes to creating impact, demonstrating leadership skills and compensation. Individual contributors can become managers if they are interested in the core responsibilities of people management. But this change would be a lateral move and not a promotion. This helps ensure we don’t create an incentive to change tracks for the wrong reasons.

Functional Titles Over Hierarchical Ones

Given that growth in the company is a direct proxy of your scope of ownership and impact, titles are only needed to accurately reflect that functional scope without the need for a hierarchy within that. We reward and recognize people stepping up in scope and/or impact by increasing their compensation and their responsibilities, and not by conferring titles that depict seniority in any way.

This ensures that titles are no longer the motivator for individuals. And entitlement to be a part of a particular discussion forum, an exciting new initiative or a decision function is on the merit of one’s functional role and performance rather than title. This builds a culture where organizational hierarchies do not have a role to play in day-to-day interactions with people, and where discussions happen and are closed on the technical merits of the arguments made and not the individuals behind them.

So What Does This All Mean For The Engineering Roles At PhonePe?

As mentioned earlier, given that our engineering ladder is more a sliding scale along identified dimensions, we are moving away from titling a role at every step of growth to ensure that the focus continues to be on earning more responsibilities versus getting a title. Our titles are functional and designed to denote the applicability of a role rather than seniority.

Individual Contributor Track

Based on this principle, in the software development function in engineering, we have two roles in the IC track — Software Engineer and Software Architect. The functional responsibilities of the Software Engineer role are primarily mapped to a product team or a set of adjacent PODs whose goals are typically tied to the L1 goals of the organization. The functional responsibilities of the Software Architect are more horizontal and primarily mapped to the technology organization goals of scale, reliability, performance, data centre cost optimization etc.

The Software Engineer becomes a deep product-level expert over time, however, that doesn’t mean they are not involved in broader initiatives outside the team.

By the same token, a Software Architect is not myopically focused on organizational initiatives alone; they still belong to teams and contribute to team initiatives regularly, but that is not the overarching focus of their attention. It is this functional difference that warrants a different title. But both roles continue to have parallel growth paths all the way, without the need to switch from one to another for either learning or compensation reasons.

Manager Track

We have adopted a similar bifurcation with the management track with the team-and organizational-scopes as the basis for career development. Entry-level engineering managers, as well as more experienced engineering managers with team(s)-scope, are mapped to the role of Engineering Manager. As the charter on the engineering management side expands to include organizational responsibilities that are not team specific along with co-ownership of P&L responsibilities, the role becomes that of Head of Engineering.

In this case, while the career graph between Engineering Manager and Head of Engineering will have some overlap, the natural career progression for an Engineering Manager is into the role of Head of Engineering.

Levels

In both tracks, each of the roles above is mapped to compensation levels in the HR system. This is to ensure that we have the ability to continuously benchmark salaries against the market as well as have checkpoints within the system for salary increments and hiring. However, these levels are not known to individuals because it defeats the purpose of flat roles within a function. Any use of these levels outside of compensation decisions is dysfunctional.

Can This Be Generalized Across All Disciplines In Engineering?

PhonePe has a wide variety of software engineering disciplines, including backend, mobile, UI, DevOps, data sciences, quality and security. We also have many business and product units organized cross-functionally as PODs. While the examples above primarily highlight the core development function in engineering, I believe that the approach and the principles are applicable to engineers and managers across all disciplines and teams.

By ensuring we have consistent standards across the company, we can enable fluid internal mobility and further support individual growth. Individuals should be able to broaden their skillset and perspectives by working on a wide range of products and problems. That is the end goal.

References

When I started thinking about how I wanted to build a growth framework for engineering at PhonePe, I went about looking for how others have approached the same problem. And I was pleasantly surprised by how open a lot of organizations were about their philosophy on this. Given that many of them have inspired my thinking on this, it is only right that we make our views open for feedback while also giving credit to the ones that have influenced it.