Platform vs. DevEx teams: A breakdown
They overlap, but Platform teams have a wider scope.
Platform Engineering and Developer Experience (DevEx) are two roles generating significant attention and growth in today’s engineering landscape. But what exactly distinguishes these teams, and do their names imply different scopes of work?
To answer these questions, we interviewed leaders from 14 Platform and DevEx teams across various companies, exploring their responsibilities and unique approaches. Here’s what we found:
The table above highlights the range of responsibilities typically owned by Platform and DevEx teams. Both types of teams cover an extensive array of functions—from source code management and monitoring to developer training and education. Local development emerged as a priority, with most teams deploying cloud development environments. Nearly every team also handles continuous integration (CI), source code management, compute runtime, incident management, and productivity metrics.
It’s no surprise that CI, local development, and compute runtime are key areas of focus. These tasks are foundational to the development lifecycle and essential for the efficiency of writing, testing, and deploying code. Incident management and productivity metrics also appeared frequently, suggesting that many teams prioritize reliability and use data-driven approaches to guide their work.
Interestingly, we didn’t see a correlation between organization size and the breadth of responsibility. Teams at larger companies, such as Booking, Adyen, and Monzo, often managed narrower scopes, while others of similar size encompassed a wider range of responsibilities. This variety reflects each company’s decision on what a centralized team should own versus what product engineering teams should self-manage. For example, at OVO, individual teams retain autonomy over certain technologies. As Samantha Betts of OVO’s DevEx team described: “We are there to facilitate and unblock access to resources, but how teams use them is managed internally. We’ve built and maintained most of the automation around access, and we hold the knowledge of how these services interconnect.”
Does the name matter? To investigate, we separated team responsibilities by naming conventions, and a pattern emerged: Platform teams tend to own more infrastructure maintenance and incident management responsibilities, while DevEx teams focus on enablement and training. This aligns with each team’s framing—Platform teams typically lean towards tooling, while DevEx teams emphasize developer enablement.
We also asked leaders to share why they chose the names Platform or Developer Experience for their teams. Twilio’s Jesse Adametz shared, “We named the team Developer Platform because we’re building multiple teams focused on Platform Engineering. It’s inclusive of several critical areas within the developer ecosystem, with a rigor distinct from a sole focus on Developer Experience.” At Booking.com, Leo Kraan noted, “We use the name Developer Experience because it is more customer-focused, while our Platform Engineering team oversees data centers, compute platforms, and networking.”
OVO’s Samantha Betts provided another perspective: “I have always referred to my team as ‘DevEx’ because the term resonates well in the software community, though it can vary by company. Lately, I prefer to think of DevEx as a concept rather than a team name. Any team—Platform, SRE, Infrastructure—that reduces cognitive load for tech teams is practicing DevEx.”
At Yelp, Mitali Parthasarathy described how their Engineering Effectiveness teams focus on enhancing developer experience and productivity, managing build and release pipelines, and automating large-scale code migrations. “Our platform engineering teams, however, concentrate on scalable, reliable infrastructure across networking, data, and security,” she explained.
Teams are also taking on names like Developer Productivity, Engineering Productivity, or Developer Acceleration. Monzo Bank’s DevEx team, for instance, is called Developer Velocity. As Fabien Deshayes explained, “Our Platform group at Monzo built the foundational infrastructure, enabling us to scale globally. Developer Velocity focuses on removing bottlenecks, which can overlap with Platform but has a distinct mission.”
In other cases, Engineering Productivity encompasses both Platform and DevEx functions. At Ocado Technology, Mariusz Łuciów shared that they use “Engineering Productivity” to capture the goal of enhancing engineer productivity through both platform and enablement.
In an upcoming issue, we’ll dive into the structures and toolsets that support these teams.
Acknowledgments: Many thanks to everyone who shared insights and feedback for this article, including Samantha Betts, Leo Kraan, Fabien Deshayes, Mariusz Łuciów, David Betts, Mitali Parthasarathy, Matthew Schrepel, Mateusz Grabowski, Russ Nealis, Erika Rice Scherpelz, Sam Gorial, Sergey Chernov, Mitali Parthasarathy, Jesse Adametz, and those who contributed anonymously.