How Platform Engineering Helps Manage Innovation Responsibly
Vilas Veeraraghavan is a little suspicious of the term “platform engineering.”
“Why are we saying that this is the platform?” the senior director of developer experience at Bill.com asked The New Stack.
The “platform,” he pointed out, isn’t something fixed, but rather something that can constantly be changed, replaced and amended.
This is a perspective worth considering as it gets at the challenges — linguistic and technological — that platform engineering poses to the industry today. What is a platform, exactly? Who’s responsible for it? And what, exactly, should we be doing with it?
Unpacking the emergence of platform engineering and the various ways it has been defined is essential if we’re going to make sense of how it is impacting and shaping the way developers work. It will also help us to better understand how organizations are trying — and sometimes struggling — to leverage the accelerating pace of technological change to their advantage.
What Is Platform Engineering?
Despite his issues with the term “platform engineering,” Veeraraghavan (a speaker at the first PlatformCon in June), does provide an elegant description of its purpose.
“Platform engineering’s primary objective is the efficiency of engineering within the organization,” he said. In other words, it is about enabling developers to build and deliver high-quality software more efficiently.
Subbu Allamaraju, vice president of engineering at Bill.com (and recently with the online travel site Expedia), sees it in similar terms. However, he doesn’t limit it to delivery. For him, it’s also about “increasing operability of the software so it falls apart less frequently,” he told The New Stack.
Furthermore, he said, it should “eliminate as much grunt work as possible from developers, operators, and SREs.” Platform engineering, he suggested, will necessarily be concerned with a diverse range of organizations’ technology challenges.
Veeraraghavan echoes this notion, noting that the practice has “become a bit of a behemoth.” Today, he said, it takes all three of what he calls the modes or phases that make up the life of a software engineer: onboarding onto something new, day-to-day work, and refactoring.
A Symptom of Complexity
But if it has become a “behemoth,” we should probably treat its size as symptomatic of something else. No one, after all — least of all software developers — sets out to construct something unwieldy.
Although it’s difficult to pinpoint the emergence of platform engineering to a single thing, we might see it as a response to the tension between the commercial demand for speed and agility and the dizzying range of options available for achieving it.
It’s from this perspective that we can see a point made by Allamaraju, that platform engineering “involves carefully reducing choices to simplify the work needed to realize” organizational goals.
What Is Platform Engineering’s Role?
Platform engineering, then, is a support function. If it enables, it does so by reducing complexity and making it easier for developers and other technical teams to achieve their objectives.
Moreover, one of the advantages of having a platform engineering team is that it can balance competing needs and aims — like, for example, developer experience and security — in a way that ensures engineering capabilities and commercial imperatives are properly aligned.
Calling it a “support function” might not sound particularly sexy, but it nevertheless suggests that organizations are maturing in their approach to software development. It’s no longer the locus of moving fast and breaking things, but instead recognized as something that requires care and stewardship. But this implies responsibility — and that, to invert the old adage, carries considerable power.
This means that platform engineering can become a political beast within organizations. If it can shape the way developers work, it can inevitably play a part in the direction of a whole technology strategy.
This is a tension Veeraraghavan recognized. In an ideal world, he said, platform engineering teams should be relatively lean, focusing primarily on enablement and those elements that are common to all software development functions, it’s also possible for platform teams to evolve into what he described as “mega-monsters.”
“It’s a very slippery slope,” he said. It’s possible, he added, for platform engineering teams’ reach to expand and grow, potentially taking in everything from bare metal to the application layer. Once it becomes too expansive, though, it becomes “non-scalable.”
Such a scenario is almost antithetical to the very ethos of platform engineering. Instead of simplifying processes and tooling, it seeks to assert its authority purely for its own sake.
Platform engineering can become a political beast within organizations. If it can shape the way developers work, it can inevitably play a part in the direction of a whole technology strategy.
The tension is best expressed in the way platform engineering teams have come to form their own functions. In recent years, Veeraraghavan noted, new job titles like “vice president of platform engineering” have emerged, formalizing the role and lending it a certain kind of gravitas.
In the past, he noted, platform teams would “organically come together,” composed of a range of engineers from various teams with complementary skills. This would often occur in response to a specific technical need rather than a deliberate decision.
This isn’t to say that platform engineering can’t be purposeful and deliberate. As Veeraraghavan said, from a chief technology officer’s perspective it can be “an investment for a specific play: how do we differentiate in this market from everyone else?” The challenge for a CTO is ensuring that this remains the focus — and that the platform doesn’t become an end in itself.
While there are certainly challenges when thinking about platform engineering at scale, it can be risky for smaller organizations to “platformize,” too
“An organization needs to go through a few iterations of building software and creating value before introducing platform engineering,” Allamaraju suggested. “You mustn’t prematurely standardize before learning what to standardize and what not to. You should learn enough to know what parts of the software stack need to change fast to drive business value and what artifacts you need to create that fast rate of change.”
Collaboration and Feedback
Platform engineering teams require enough knowledge to be effective, but they also need a certain degree of humility to allow the teams around them to thrive. A key question is precisely how this can be done. It’s a bit of a balancing act.
Answering it, moreover, gets at the crux of one of the central challenges of platform engineering: mediating what developers need with what the organization needs.
When Veeraraghavan worked as director of engineering at Walmart Labs, he recalled, “We used to have a regular roadshow where we would showcase all of the tools.” The work he and his team did very much centered on supporting and interacting with other software development units.
This is important to bear in mind; often the discussion around platform engineering focuses so much on tooling and infrastructure development that it’s easy to neglect the conversations that lay the foundation of that highly technical work. In this respect, platform engineering has much in common with developer relations, or DevRel — the key difference is that these conversations are entirely in-house.
“Platform teams have to be six months to sometimes a year ahead of development teams. If a dev team comes to you and says ‘I need Kubernetes clusters’ and you’re like, Oh crap! I haven’t even thought of this — that’s a fail.”
—Vilas Veeraraghavan, senior director of developer experience, Bill.com
The platform engineering team’s work is “public” — visible across an organization. This helps to build trust with other developers and is crucial in bringing others with you. Indeed, this might even be daunting as it inevitably opens you up to questions and often criticism.
However, this is exactly how things should be. “The one part you cannot run from is the honest feedback you will get. You better be ready for it!” Veeraraghavan said. Ultimately, he noted, it increases trust with developers: “Developers can then see that, if I say something, something happens.”
One way of thinking about it, according to a 2021 InfoQ article, is that platform engineering is a “community service” as much as it is a technical one. In other words, it is as much about managing the needs of software developers — making them more productive and maybe even that little bit happier — as much as it is building a new infrastructure capability.
Is ‘Platform Engineer’ a Real Job?
Given the growth of platform engineering, job opportunities will inevitably increase across the industry. A simple Google search for “platform engineer” will likely deliver a list of job openings in your region.
However, much like the notion of a “DevOps engineer,” the idea that we can think of a platform engineer as a distinct role is problematic.
“I’m not a fan of creating specialized roles like ‘platform engineers,’ Allamaraju says. “People’s skills in a platform engineering team depend on the organization’s software architecture.”
Consequently, any kind of role could prove valuable within a platform engineering team — from frontend developer to machine learning engineer.
However, if platform engineering is ultimately community-driven and dependent on effective communication and feedback, then the so-called soft skills matter most in a platform engineering team.
Both Veeraraghavan and Allamaraju noted the importance of empathy. “It is a great opportunity,” Veeraraghavan said, “for someone who has great empathy within the developer community to come and say, ‘Hey, let me make your life easier. Let me help you sleep better at night.’”
Also critical is a sense of curiosity. True, that’s something that just about anyone working in technology needs, but it’s particularly important in the context of platform engineering. “Platform teams have to be six months to sometimes a year ahead of development teams,” Veeraraghavan argues. “If a dev team comes to you and says ‘I need Kubernetes clusters’ and you’re like, Oh crap! I haven’t even thought of this — that’s a fail.”
Allamaraju also sees this sense of curiosity as important, but he emphasized the ability to balance technical know-how with business awareness. Yes, a platform engineering team needs “responsible innovation to maintain pace with evolving business needs and technology trends,” he acknowledged. But it’s essential to possess a critical or reflective mindset so you don’t just keep tweaking the platform without a goal in mind.
Paving ‘the Path of Modernization Responsibly’
Platform engineering guides innovation. In some organizations, you might even say it governs it.
If it can, as Veeraraghavan claimed, “directly influence the speed of innovation at an organization,” then we need to recognize that it is far more than just a team that drives acceleration. Done effectively, it can manage gear changes, modulating the pace of change in a way that is appropriate and relevant to an organization’s needs.
Given the nature of many of the most discussed trends in the tech industry today — crypto, Web3, the metaverse — having a team that is able to navigate hype and, as Allamaraju put it, lead “the path of modernization responsibly,” will be immensely valuable.
Equally, though, platform engineering itself will have to be nimble. “What’s an enabler today can become an anchor tomorrow,” Allamaraju warned.
Maybe we would do well to remember that the “platform” is always provisional — what matters is that developers can do the work they want to do and do it well.
