In April 2021, we (virtually) met with Galo Navarro, Lead Software Engineer at New Relic, to talk about how he built an internal Platform as a Service (PaaS) in his previous job for 1500 engineers at Adevinta. Galo discussed his teams’ obstacles, why they ultimately decided to build an internal PaaS, and how his team executed and measured their success.
Working as a platform team
Platform teams run into numerous challenges throughout the workday. Various issues are common across many industries, such as needing to support depreciated tools and internal libraries with mutually incompatible versions because each engineer has a preferred method.
If you’re only mitigating the problems for a small company, these issues are relatively easy to handle. But these issues quickly become insurmountable when a platform team is the central support system for twenty sub-companies with their own ecosystems, problems, cultures, and technology cocktails.
This is what Galo faced at Adevinta—he was in charge of assisting twenty companies in managing their online marketplaces. Each marketplace had unique features, and many even had their own platform teams, but they shared common assets that didn’t need to be rebuilt over and over again. As Galo stated, “You don’t need to have twenty different plumbing systems to build a marketplace. You can reuse the same plumbing system.”
The challenge is crafting an internal PaaS that provides proven value to each individual sub-company.
Generating value as a platform team
Every company has profit centers and cost centers. Profit centers, such as sales teams, actively work to make money; cost centers, such as platform teams, eat into the budget to create a better product or user experience.
It’s easy to recognize the value that profit centers bring to the business because their contributions can be measured in revenue. But cost centers have the more challenging task of proving that they’re an extremely valuable component of the company. Since their success can’t be measured in income, platform teams and other cost centers are more closely scrutinized by executives.
Galo explains that it’s “a tough position to be in because in general, the financial department for every company will be looking closely at every cost center and looking to cut it or externalize it.” And with the increasing accessibility of infrastructure services such as AWS, Google Cloud, and Heroku in the modern tech stack, the pressure is on platform teams to demonstrate their value or risk becoming redundant.
Strategies for building a PaaS
Galo’s primary focus in developing Adevinta’s PaaS system wasn’t to create a set of tools to throw at engineers. Instead, he concentrated on crafting a fully realized product that could help engineers throughout the entire development cycle.
He advises other teams, “you’re building a product, this product has a lot of competitors, and that’s a very tough job. Now, you have two options. You can build the car yourself, and that’s fine. But, if you want, we can do the heavy lifting for you, so you don’t need to focus on the wheels, the engine, the gas, etc. You can focus on winning the race against your competitors.”
Therefore, the goal for any PaaS is building a golden path that enables engineers to use the tools they’re familiar with or the best tools for the job on hand without requiring them to assemble those tools every time they need to do something.
The issue is that platform teams can’t expect engineers to follow the same path every time. The system needs “escape hatches” that allow engineers to use the tools that fit into their workflow and add alternatives without employing a new platform.
In this way, the PaaS should act as the glue between the various systems, tools, and components without being too restrictive that engineers can’t deviate from the defined path. And engineers need to feel confident in the strength of the bond no matter what components they need to add or subtract to work in their preferred way.
Demonstrating value qualitatively
Since platform teams cannot demonstrate their value quantitatively like profit centers, they must show their value through impact. Because of the extreme scrutiny platform teams face, Galo emphasizes that demonstrating value qualitatively through impact needs to be done right. “A lot of teams try to do something big and ambitious that will have a lot of impact straight away, but the problem is that it will take seven years. Those seven years will have seven reorganizations on average, and… the team will get cut.”
Galo shared that at Adevinta, his team automated one low-value activity at a time instead of focusing on long-term impact. Eventually, submitting a Pull Request looked like this:
This system enabled the team to show their impact frequently in small, measurable ways. Executives could clearly see that the PaaS wasn’t simply a set of tools but an ecosystem that offered multiple benefits to the DevOps environment.
Implementing feedback loops
As with any internal PaaS, the system will generate more value as it grows through feedback. At Adevinta, Galo’s team created analytics dashboards on the top of the PaaS to oversee the real-world performance and impact the platform had on the DevOps environment.
“What we could explore was, let’s see how many deployments we have, how many builds we have, how long those builds take, etc.,” he explains. “This was super useful when you want to have conversations with teams and influence their behavior. What we did was show them that data and not give them any options.”
These analytics give platform teams the power to discuss data with the teams who will (usually) draw the same conclusion that the platform teams identified.
However, teams must use industry-standard data to measure the effects of their platform accurately and present the data to executives in a way that addresses their interests and concerns.
Zero friction onboarding
One of the most common roadblocks that teams face with internal PaaS software is that onboarding often feels more streamlined with an external competitor. Even if the tool is impeccably crafted, platform teams risk losing to competing products because they’re too frustrating or have too much of a learning curve.
Galo’s team worked to address this issue with Adevinta’s PaaS. “One of the things we invested in was hiring product managers and UX designers—people that know how to design user interfaces and understand how our users are interacting with our tools.”
They eliminated this pain point by developing a one-click onboarding system and a robust help center with documentation. Since they were collaborating with twenty companies rather than thousands, they provided 24/7 on-call support that was more specific to their sub-companies than any external competing services.
As Galo stated, “when you’re in this type of team, you want to make things easy, but at the same time, it’s frustrating because [other] teams have to adapt, and it’s a grueling process.” But platform teams must recognize that although things are difficult for them, they’re often more challenging for other teams attempting to balance their regular workload while learning a new system.
The less friction that users experience during onboarding with your system, the more likely they’ll stick with the PaaS you build.
Wrapping Up
Creating an internal PaaS system is challenging, to say the least, which is why it’s always beneficial to learn from lead engineers like Galo. Charting the course to develop a system that makes everyone happy (from managers to engineers to colleagues to executives) is tricky, but it’s not impossible.
Shifting the narrative to view your internal platform as a product rather than a set of tools enables you to demonstrate value to both your engineers and executives.
We are grateful to Galo Navarro for sharing his time and insights with us. Check out the entire meetup here and listen to Galo’s stories about building a platform that rivals the big-name vendors. And if you want to learn more, sign up for one of our many upcoming meetups.
.webp)
.webp)
