Platform engineering has exploded in the last two years. Analysts like Gartner keep adding it to the top trends to watch together with AI, every second booth at conferences like KubeCon mentions it, and the community has been growing like wildfire. PlatformCon 2024 for example is expecting over 35k people to join this June, up from 6k just two years ago.
Yet, within the community, there are still many open questions about what a platform engineering team actually looks like. Who works on a platform team? What skills are needed for a successful platform initiative? This article distills learnings from looking at hundreds of platform teams in engineering organizations of all sizes over the last two years. Let’s dive in.
Core tenets of a platform engineering team
Before getting into the specific roles, it’s worth recapping what the key principles and main goals of such a team are:
- A platform team’s job is to build an Internal Developer Platform (IDP).
- Platform teams should follow a platform as a product approach, treating developers as their customers.
- They should have a strong focus on improving developer experience (DevEx) and remove cognitive load from individual contributors.
- This also means there should be at least one person on the platform team with strong product management skills, capable of building tight feedback loops with all key stakeholders (especially app developers).
A well-designed IDP:
- Drives standardization across all configurations and workflows
- Automates away redundant tasks, e.g., ticket ops
- Has features like deployment management, infra orchestration, RBAC, ephemeral environments
- Ensures compliance and security across all golden paths
- Provides clear cost management and observability
- A platform team should build the IDP by starting from the backend
- Backends for enterprise-ready IDPs are Platform Orchestrators
- Successful platform initiatives usually follow a Minimum Viable Platform (MVP) approach to iterate quickly and show value to all key stakeholders
Looking at the above, it becomes clear that platform engineering is an important org transformation that touches many different parts of the engineering organization, as well as its toolchain(s). Another question frequently asked in the community is who should sponsor the platform engineering initiative? Is it the app dev department, given the IDP is built with the goal of improving DevEx? Or is the infrastructure and operations (I&O) team, as the IDP is seen as part of the infrastructure consumed by developers?
There are of course many possible shades of this, depending on the presence of existing DevOps, SRE, or I&O teams, as well as the roles played by security, architects e.g., CCOE, execs, etc. So, while the answer to who champions the platform initiative will heavily depend on the structure of your org, the composition of a platform team and the way they interact with other stakeholders can be generalized to a decent degree.
Roles and skills in a platform team
Head of platform engineering: This is a managing role but can easily be very hands-on depending on team size. The head of platform engineering is responsible for headcount and budget planning, as well as all North Star Metrics (NSMs), KPIs, and OKRs. This role can double up as the product owner and product manager in some cases, though this is not necessarily recommended. They need to be a strong communicator and understand the different (and sometimes contrasting) priorities of all stakeholder groups. They must also be able to speak the language of each group to sell the platform engineering initiative internally.
Platform product manager (PPM): Leads product strategy, roadmap, and feature prioritization. A PPM also leads user research and is responsible for building tight feedback loops with all platform users. They need to be a good listener and, ideally, also a strong communicator and mediator.
DevEx platform engineers: Delegates of the application development teams. They understand and deeply care about developer pain points and general DevEx struggles or bottlenecks. They ensure the app dev perspective is taken into account, for example, when it comes to the choice of interfaces, which should be left to developers (e.g., code-based like Score vs. portal like Backstage) and can vary across different teams depending on skills and backgrounds.
Infrastructure platform engineers: Delegates of the I&O teams. They make sure the IDP acts as an interface that facilitates the consumption of resources and infrastructure by app developers in a compliant and standardized way.
Both DevEx and infra platform engineers work together with the platform product manager to guarantee a clear separation of concerns between the different user groups (application developers, I&O teams).
Other stakeholders
Security teams: Formulate security capabilities incorporated into the platform, preferably by design. They need to approve any security-relevant platform features. In general, they want to make sure they are heard by the platform team in the design phase and ideally, that the platform is used to enforce clear RBAC and security postures.
Compliance and legal teams: Similar to Security teams. They want to make sure their priorities are clear to the platform team and that they can drop their requirements in the way the golden paths are designed and implemented across the IDP.
Architects
- Enterprise architects: The platform should support their long-term strategy by making technology transformations easier to implement, while also reducing the onboarding and training cost by abstracting complexity away from developers.
- Solution architects: The platform should function as an engine that makes basic tech a commodity and standard architectures easily consumable.
In some cases, architects are the main drivers of platform engineering initiatives since well-designed IDPs can play a huge part in achieving their goals of higher compliance and standardization, and eliminating shadow IT and shadow operations.
I&O teams: They no longer have to fight ticket ops. With an IDP in place, they can focus on optimizing current infrastructure performance or adding new tools instead of having to provision yet another instance of the same resource for app devs. If the IDP is built with a Platform Orchestrator, the platform team is responsible for defining those resources. The I&O teams get a consistent interface to optimize their service delivery against. The platform becomes the vending machine where developers can order, and I&O people do the (re)stocking of the inventory. The platform team defines the machine's interface and order process.
Developers: As the platforms' end users, developers can now self-serve what they need to run their workloads without having to wait on I&O teams to support them. Waiting times are gone, and developers can move much faster, with little to no concern about breaking things. The platform ensures they follow secure and compliant golden paths.
Executives: They have the ultimate say on budgets. A well-implemented platform engineering initiative not only considerably cuts time to market but also improves the bottom line by increasing overall efficiency. All the while, this gives a big boost to employer branding and allows any enterprise to position itself as a much more attractive place for engineers to work.
While platform initiatives touch many different stakeholders within the organization, developers remain the main end users of the IDP. Their user feedback will therefore be crucial from a product management perspective to iterate on the platform. However, this doesn’t necessarily mean that app devs are the most important stakeholder or the leading sponsor. Any of the personas and teams listed above can be a sponsor, typically trying to advance their own interests through the platform rollout. A recurring example is I&O teams looking to get their products and services sold via the IDP.
Conclusion
A successful platform engineering initiative requires alignment across multiple stakeholder groups, and there are many moving parts that the platform lead (whether head of or platform product manager) needs to coordinate. It’s essential they are good listeners and communicators, but it’s also important they create a shared language with all users and stakeholders.
That’s why using standards like reference architectures and the MVP framework can be instrumental in the success of your platform initiative. And of course, you can also join the Platform Engineering Slack (19k+ practitioners) to share your story and discuss trends and best practices with industry leaders.
.avif)
.avif)
