HashiCorp

Why you should run your platform team like a product team

Like a product team, a successful platform team must understand the needs of its "customers" and stakeholders.

I’ve been working in software engineering and DevOps for about a decade. For the last five years I’ve worked on platform teams and with other infrastructure-focused teams that are trying to become platform teams, even if they didn’t realize it at the time. With that in mind, I have a suggestion for how to help ensure platform team success: run them like a product team.

»What is a platform team?

Platform teams focus on building and maintaining core systems and workflows for delivering infrastructure and other services to application teams. Since applications run on the foundation of infrastructure, supporting infrastructure is a big job. Not only does platform engineering encompass what you would traditionally think of as “infrastructure” — virtual machines, compute clusters, and networking — it also includes all of the glue that binds the worlds of applications and infrastructure. These include APIs, monitoring, CI/CD pipelines, credential management, and more. All these things centralized under one umbrella comprise the “platform” in “platform team”.

»Platform teams and modernization

Platform teams address a historical problem with infrastructure provisioning and configuration. Previously, creation, updates, and deletion of infrastructure involved manual processes, such as pointing-and-clicking to create infrastructure or ad hoc scripting. In cloud-based environments, infrastructure is being automated and spun up in a matter of minutes. New features are getting built and deployed to production in a matter of days.

Besides supporting application teams, platform teams also have the responsibility of ensuring that the workflows they build remain compliant with industry and company standards in the face of this acceleration. In the same way that product teams have to gather feedback from their customers and listen to key stakeholders, platform teams need to collaborate with application teams while also meeting requirements from security, compliance, finance, etc.

While this means platform teams need to sometimes keep developer requests from straying outside of those stakeholders’ boundaries, it’s more often the case in my experience, that many organizations will continue to build legacy compliance processes around manual changes to infrastructure that do not align well with modern automation practices.

To modernize, platform teams must challenge the status quo in a way that’s palatable to key teams inside an organization. Platform teams have to talk with these teams to understand why certain policies are in place and figure out how to automate their systems safely. This diplomacy can be an even bigger challenge than a platform team’s technical responsibilities.

»Platform teams are product teams

To meet that challenge, a platform team should be run like a product team.

Product teams understand they serve a customer and that the customer’s constant feedback is crucial. So, who is the platform team’s customer? Application development teams.

»Use product management strategies

With any product, the first step is user research. Platform teams need to establish feedback loops with their users before they start building the platform. They need requirements, scoping, and prioritization. They’ll need to version infrastructure components, perform maintenance, grow awareness, encourage adoption, and communicate news. Platform teams also need to think in terms of “features”. Like any product team, platform teams should have an idea of what features they want to deliver to their customers based on customer feedback and business needs.

For platform teams, the features are often infrastructure-related capabilities for different types of application architectures. For example, a platform team may be working on a containerization capability to enable application teams to push apps to a particular runtime medium and ensure the deployment meets organizational standards. Other common capabilities include serverless, GPU intensive workloads, and frontend apps spanning web and mobile distributions. These capabilities are cloud-agnostic.

Treat the platform-building process like any other software project. Take an iterative approach and never consider the platform “done”. Don’t forget all the battle-tested product management strategies the IT world has refined over the past several decades just because you’re building something internal and not external.

For inspiration, see Elanco's hybrid multi-cloud adoption case study, which shows how they gathered user feedback from architects, developers, and enterprise teams. It also includes their blueprint for progressing through the analysis, design, and automation phases of their platform.

To learn some of the battle-tested product management strategies that have worked for platform teams, watch Non-technical challenges of platform engineering.

»Work with stakeholders and get buy-in

Product teams must also understand the needs of their stakeholders. Stakeholders for the platform team include every other team that is part of the organization's infrastructure delivery pipeline. These teams may go by different names but include networking, traditional IT, security, identity, finance, risk, compliance, and so on. The platform team’s success is inextricably linked to the success of these functional teams, and without them, the funding and support won’t be there when you need it.

The platform team’s main goal is to help developers safely ship software as quickly as possible while meeting the needs of organizational stakeholders. The organization stakeholders are concerned about — secure-by-default infrastructure workflows, compliance guardrails, reduction of tickets and inefficiencies, and the reduction of costs through the elimination of infrastructure sprawl to name a few. Many of these areas are blind spots for development teams but are critical to the “safety” element of shipping software.

The key is to tightly integrate representatives from all stakeholder teams into your ongoing communication cadence and requirements building processes, just as you would in an external product development workflow.

For examples of working with stakeholders, learn from Building a cloud operations mindset in the financial sector: A diary of change. It features two case studies and describes the process of getting every single function around the same table to talk about the platform.

»Should platform teams exist?

Platform teams exist to cope with infrastructure’s generational shift from manual, human-driven processes to automated self-service processes. The skill sets required to manage these new processes are drastically different. Platform teams represent a specialization to address subject-matter differences in infrastructure and application development.

The business need to quickly deliver new products and features to customers has never been higher, which puts ever-more pressure on application teams. This means infrastructure has to adapt just as quickly as software gets updated. Infrastructure operators have to think like software engineers if they wish to rise to the challenge. Platform teams are an essential part of that transition, blending the worlds of infrastructure and software engineering.

This blog was originally posted on The New Stack.


Sign up for the latest HashiCorp news

By submitting this form, you acknowledge and agree that HashiCorp will process your personal information in accordance with the Privacy Policy.