The Platform Engineer
By: Varun Achar
Tags: DevOps, Platform, Microservices, Software Development, Product Management

Often a lot is spoken about what Platform engineering is, though not much is spoken about what it takes to build a successful Platform team. Since we are on this journey within Razorpay, over the last 2.5 years, our failings have taught us a few things about this very thing. Of course, at the heart of it all are the engineers themselves. This post explores what attributes we believe are necessary for an engineer to be successful in a Platform team.

What is Platform Engineering?

Let’s first start by understanding what Platform engineering is. It’s important to understand this team’s purpose because many engineers assume that Platform engineering is just about building common services that are shared between multiple teams or the team that automates infrastructure delivery.

So what is the purpose of Platform engineering?

Platform teams exist to bring together the best practices of the org and external companies into a neatly built solution. These practices typically start as experiments in different teams across the company. These experiments produce learnings which then turn into capabilities in the platform services.

A platform team operates in a wide variety of areas besides building shared services. Here are some examples of platforms also managed by Platform engineering: developer productivity, language tooling, release engineering, incident management, messaging, observability, experimentation, infrastructure, testing, data storage, etc. Platform teams work on creating long-term leverage for the organization by making it easier for other engineers to build products that create value for both the customers and the company.

One job, five roles

Now that we understand the scope of the Platform teams’ functional areas, let’s look at the challenges faced by them and what the engineers need to do to overcome them. I will give examples from within Razorpay to show you what we did in such situations.

1. Product Management

Platform engineering is usually introduced when a company has reached a certain scale, either in traffic or people. Obviously, teams usually don’t wait for an engineering system to be built before they begin responding to these needs. Most teams start with offline processes or build capabilities for the short term that are later automated or centralised. So you’ll often find many variations of the same thing in different teams.

Platform engineers, therefore, need to play the role of a product manager to understand how have these teams managing the problem, what are their key issues, what do they struggle with, what is working well for them, etc.

Here’s an example:

As a FinTech platform dealing with billions of dollars of transactions a month, we run thousands of automated tests every day. With the current testing infrastructure near its breaking point and causing a huge amount of developer productivity loss, we had to invest in rebuilding it from the ground up.

Therefore, like any PM, the engineers started with customer interviews and gathered information. They went deep into understanding the key pain points of the current way of writing, running, and measuring tests. They then researched the best practices in the industry by speaking to other companies on how they handle testing and spoke to companies that operate in the ephemeral infrastructure space and other secondary research.

Once this is done, the engineers figured out and prioritized the key goals that a testing infrastructure needs to address in the short, mid, and long term. They then wrote a product specification that captures all the learnings and then got a sign-off from other senior engineers/leaders that they are tackling the right problem statement. They defined the right metrics to measure the success of the initiative. All this before writing a technical spec or a single line of code!

Once we have all this groundwork done, defining the right metrics to track progress is key. You’ll often see Platform teams take an adoption goal with ‘Number of services integrated’ as the key metric. Such metrics usually don’t give the right picture. For example, suppose the Observability team defines their objective as the number of services publishing metrics to a shiny new platform. Even though they may achieve their goal, how would they know if the platform is actually being used? Leaders may push the integration through by intense project management skills, but what if nobody is logging into the platform to actually do debugging and operational reviews? What if everyone is so comfortable with the older one that they don’t make the new platform their first choice, even though it is supposed to make their debugging sessions better and faster?

We faced these same questions and hence, having made the mistake, we started asking ‘What if we were an independent startup, what would our metrics look like?’. With this mindset, we were able to create much better metrics. For example, one of the metrics the Observability team tracks is the Monthly Active Users (MAUs) on the platform, and have taken goals on moving this metric upwards. This view gives a much better understanding of what features, services, stakeholders to target while defining our quarter plans and roadmaps.

2. Deep Tech

I understand that the phrase “deep tech” refers to AI and all that jazz, however, I found this to be the most appropriate way to describe the nature of work. Building capabilities require engineers to go deep into the problem space and the tech behind it. Platform engineers typically work in very niche areas and build expertise that goes beyond the standard use of a technology stack.