Platform engineering has exploded over the last four years. DORA's 2025 research found that 90% of organizations report using a platform, and 76% have dedicated platform teams. We can see this across our community too. Close to 300,000 people are now calling themselves platform engineers; that’s 300,000 more than just 10 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? And what changes now that agents are platform users too? This article distills learnings from looking at hundreds of platform teams in engineering organizations of all sizes. 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 and operate the platform as a product, serving internal users across the organization. For most teams that starts with an Internal Developer Platform (IDP) for application developers, and it no longer ends there: the next evolution is the Agentic Engineering Platform, where software developers and agents collaborate.
- Platform teams should follow a platform as a product approach, treating their users as customers rather than designing around stakeholder abstractions.
- They should have a strong focus on improving developer experience (DevEx) and removing cognitive load from individual contributors, framed as what users no longer need to know, decide, or figure out.
- 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).
- Paths are discovered from observation, not invented in isolation. Before anything gets built, the team runs discovery interviews and deep dive interviews, maps the value stream, and force-ranks the path candidates that come out of it.
A well-designed IDP:
- Drives standardization across all paths, by design rather than by mandate
- Automates away redundant tasks, e.g., TicketOps
- Has capabilities like deployment management, infra orchestration, RBAC, and ephemeral environments
- Makes the compliant and secure route the easiest one to take across all golden paths, while leaving an escape hatch for the cases the path does not fit
- Provides clear cost management and observability
- Carries the three cross-cutting layers that make a platform enterprise-grade: identity, policy, and state
Two more things hold true regardless of scope:
- A platform team should build the platform starting from the backend. Backends for enterprise-ready IDPs are orchestrators. A portal without one is the nice front door on a non-existent house.
- Successful platform initiatives usually follow a Minimum Viable Platform (MVP) approach (3 path for one persona in 3 months) 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 it 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 who champions the platform initiative will depend heavily on your org's structure, the composition of a platform team and how it interacts with other stakeholders can be generalized to a decent degree.
How to assemble the team: the 3x3 method
We’ve written extensively about this in part 3 of our book Thinking in Platforms that covers the Platform Engineering Playbook. There, we mention the 3x3 method which is the assembly pattern we keep seeing work: a small team, a narrow scope, and a short horizon, rather than a full org design signed off before anyone talks to a user. It pairs naturally with the MVP approach and you are staffing to deliver 3 paths for one persona, not to cover the estate.
.png)
Sizing follows from the same logic. The developer-to-platform-engineer ratio is the number to watch as you scale, not headcount in absolute terms.
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 the platform's measurement model. 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 — adoption is earned through demonstrated value, not mandated from above.
On measurement specifically: use DORA metrics for delivery outcomes, SPACE metrics for the developer-experience dimension, and Platform NPS for whether your users actually want what you built. Generic KPIs and OKRs sit on top of those, not in place of them.
Platform product manager (PPM): Leads product strategy, roadmap, and path prioritization. A PPM also leads user research — discovery interviews, deep dives, and path validation interviews before a path is rolled out more widely — 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 vs. portal like Backstage) and can vary across different teams depending on skills and backgrounds. The interface is where intent crosses the boundary into the platform — it is not the platform itself.
Infrastructure platform engineers: Delegates of the I&O teams. They make sure the platform 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).
As the mandate expands, this two-way split tends to specialize further. We increasingly see security, FinOps, observability, and reliability treated as platform capabilities with named ownership inside the platform team rather than as neighbouring departments to negotiate with.
What changes when agents become users
The roles above were defined when every platform user was a human. That assumption no longer holds, and it is the single biggest change to platform team composition since 2024.
Agents need what developers need: an identity, a defined scope of access, a governed lifecycle, and an audit trail. Which means the platform team's surface area grows to include Agent Infrastructure and with it the harness that turns a model's intelligence into work, the governance that makes it safe across a fleet, and the models being consumed. That work does not belong to the security team or the AI team. It belongs to the only function that already holds identity, policy, path design, and the operating model for serving a user base as one practice.
How much of it you need depends on where you sit across the four levels of agentic software development. At Level 1, human in the loop, agents assist inside the IDE and humans catch errors, so the demand on the platform is modest. From Level 2, human on the loop, agents produce work in parallel and validation stops being a one-pass gate and becomes a validation loop and at which point identity, sandboxing, and evaluation are not best practice but preconditions.
.png)
One caution worth stating plainly, because it decides whether any of this pays off: agents multiply whatever already exists. In an artisanal or hero-based production system they multiply chaos. In a platform-based one they multiply throughput. Adding agents to an organization that has not done the platform work does not skip the platform work, otherwise you burn tokens and get no results.
Other stakeholders
Who owns what across these groups is a shared responsibility model, and writing it down is platform work: the platform team owns the paths, control functions own the rules, infrastructure teams own the environment.
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. Policy belongs embedded in the path, not bolted on as an approval step afterwards.
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 platform.
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 platforms 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 TicketOps. With a platform 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 platform 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 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 makes the secure and compliant golden path the path of least resistance.
Data and AI teams, and business teams building with AI: Newer user groups with the same underlying need. They want the self-service infrastructure guarantees application developers already have, and in the case of business teams, they want enterprise systems to be consumable by the AI they are building with. Both arrive at the platform team's door.
Agents: A user group that does not file tickets, cannot read between the lines of a misconfigured gate, and will run a path a thousand times a day. Everything ambiguous in your platform becomes a defect at that volume.
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. The frame that lands here is the cost of chaos: what the current production system costs across delivery velocity, outcome predictability, operational resiliency, maintenance overhead, organizational learning, and structural incentives.
While platform initiatives touch many different stakeholders within the organization, application developers remain the largest user group for most platform teams today. 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 platform.
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 the MVP as we presented it in our book Thinking in Platforms can be instrumental in the success of your platform initiative. The team you build in the next twelve months will be judged on something the 2024 version of this article could not have asked of it: whether the platform holds when the users are not only human. And of course, you can also join the Platform Engineering Slack to share your story and discuss trends and best practices with industry leaders.
This article was first published in May 2024 and last updated on 28 September 2026.
