The engineering journey at PhonePe: A growth framework for engineers and managers

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 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 decision-making, extensive planning, and a lot of coding.

Depending on the life stage of the product, 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 focusing 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. This tends to drive behaviour that is singularly focused on achieving the local maxima of the individual 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 maximise value for the company.

This made me reimagine our definition of a career ladder to a framework that sets the growth expectations of an engineer. In my view, this maps better to real career growth in a fast-moving organisation where the demands on an individual get more multi-dimensional.

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. It is to be viewed as a guide on how to operate best to create a maximum impact as you take on more responsibility in the organisation.

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 the impact created.

ALSO READ

[Product Roadmap] Focus on ease of use helped PhonePe reach 20M daily transactions

How do we define the PhonePe engineering journey?

It is defined as a framework that maps the growth of any individual in the engineering organisation through their scope of ownership, influence and 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 organisation committed to creating an environment that makes learning on the job and application of the same for the impact the primary goal of every individual, with career growth being a natural outcome of this process

Core Tenets

Growth based on “Scope and Impact” and guided by “Dimensions of Growth”

The “Scope and Impact” of the PhonePe engineering journey describes the increasing breadth and depth of responsibility in a role and the value derived by the team/organisation. 

Growth in a role must be measured only through the lens of increasing Scope and 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 organisation, and what makes an engineer successful at PhonePe. It is a function of the kind of organisation we are (open large-scale platforms powering diverse products, payments and financial services domain, and data-driven decision-making), 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 amd 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.

ALSO READ

Future of Work: How to build trust among customers, expand digital payments reach, explains PhonePe’s Rahul Chari

Avoiding the cookie-cutter approach to growth

The scope of ownership and the impact that an engineer has in the organisation 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 the team they are a part of.

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, an increase in the span of responsibility and/or compensation should not always be contingent on premeditated demonstration of improvement across all dimensions.

However, the organisation and individuals should ensure that over time, through structured rotation, on-the-job learning and mentorship, and 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 and 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 and 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 the 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 recognise 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.

This builds a culture where organisational 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.

Individual Contributor track

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 organisation.

The functional responsibilities of the Software Architect are more horizontal and primarily mapped to the technology organisation goals of scale, reliability, performance, data centre cost optimisation etc.

A software architect is not myopically focused on organisational 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.

Manager track

We have adopted a similar bifurcation with the management track with team- and organisational-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 organisational 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.

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.

While the examples above primarily highlight the core development function in engineering, I believe that the approach and the principles apply to engineers and managers across all disciplines and teams.

The end goal is individuals should be able to broaden their skillset and perspectives by working on a wide range of products and problems.