What Is Platform Engineering, and Is It Replacing DevOps?

Most engineering teams have heard of DevOps. Fewer have built a platform engineering function, and even fewer have a clear picture of what that actually means in practice.

This article answers three questions: is platform engineering new or DevOps under another name, does an organisation need a dedicated team for it, and what is an internal developer platform?

The short version: platform engineering is a separate discipline with its own goals and team structure. It builds on DevOps rather than replacing it, and organisations that confuse the two tend to build the wrong thing or hire for the wrong role.

What Platform Engineering Actually Is

Platform engineering is the discipline of designing, building, and operating the shared infrastructure and tooling that developer teams use to build and ship software. The Cloud Native Computing Foundation (CNCF) defines it as "the practice of planning and providing computing platforms to developers and users," encompassing the people, processes, policies, and technologies that make those platforms work. The goal is to reduce cognitive load on product teams, giving them a well-maintained, self-service environment rather than expecting every team to configure its own pipelines, environments, and observability stacks from scratch.

The four pillars of a platform engineering function

Mature platform engineering functions share four ideas: golden paths, self-service interfaces, an internal developer platform, and treating that platform as a product.

Golden paths are opinionated, pre-built routes for the things developers do constantly: spinning up a new service, deploying to staging, running a test suite. The point is not to stop engineers making choices but to make the sensible choice the easy one. Self-service interfaces, such as developer portals, CLIs or internal APIs, let product teams provision what they need without raising a ticket with an ops team and waiting.

Both are delivered through an internal developer platform (IDP), the product the platform team maintains. The fourth idea matters most: platform as a product. An IDP has users, a roadmap and feedback loops, and without the maintenance any product needs, it degrades.

Many internal infrastructure problems are product failures rather than technical ones: tools built without user research, documented once and never updated, or left to drift while the teams they were meant to serve built workarounds.

Platform engineering gives developer experience a dedicated owner. The product mindset is the same one used in custom software development services, even when the users are internal engineers.

The Internal Developer Platform: What it Is and What It Contains

An internal developer platform is the product that a platform engineering team builds and maintains for the rest of the engineering organisation. Think of it as the operating layer between raw infrastructure and the developers who build features on top of it.

Core components of a well-built IDP

A well-built IDP typically includes several layers. The service catalogue sits at the centre: a searchable registry of all internal services with ownership, documentation, and health status. Pre-configured deployment environments let teams provision staging and production setups without manual intervention. Standardised CI/CD pipelines reduce variance between teams and connect to your software testing services layer, so automated quality checks run on every deployment path.

Secrets management stores credentials centrally, so product teams do not maintain their own secret stores. This is where cybersecurity controls get built in rather than retrofitted. Observability tooling, covering logging, metrics, and tracing, is wired in by default rather than bolted on after an incident. Infrastructure provisioning completes the set: self-service creation of cloud resources with tools such as Crossplane or Terraform, on top of a well-structured backend development foundation.

The Backstage example

The most widely adopted open-source framework for building an IDP is Backstage. Spotify built it internally, open-sourced it in March 2020, and donated it to the CNCF later that year. As of 2026, more than 3,000 companies have adopted Backstage as the foundation for their own internal developer platform. It has become the closest thing the industry has to a standard starting point for IDP software.

The breadth of an IDP is one reason organisations struggle to define platform engineering. An IDP is a curated set of capabilities rather than a single tool, maintained by a dedicated team for every engineering team in the organisation.

What sits inside the IDP matters less than how it is maintained. A stale IDP is often worse than no IDP at all, because it creates the impression of a self-service system while quietly forcing teams to work around it. Ongoing IT support and maintenance discipline applies as much to internal platforms as to client-facing products.

Platform Engineering vs DevOps: What Actually Changed

The short answer: DevOps is a way of working, and platform engineering is a team that builds shared tooling so that way of working scales.

What DevOps actually means

DevOps is a cultural and operational philosophy. It removes the barrier between development and operations so that software can be released faster and more reliably. Its core rule: teams that build software are also responsible for running it in production. Building a DevOps services capability is mostly about culture, toolchain integration, and shared accountability.

Where DevOps ends, and platform engineering begins

Platform engineering is a structural response to the cognitive load that DevOps creates at scale.

When every product team is responsible for its own deployments, pipelines, cloud infrastructure, and observability setup, the overhead compounds. A team of five engineers building a payments feature should be thinking about payments, not debugging a Kubernetes RBAC configuration. Platform engineering creates a dedicated function that absorbs that overhead and packages it into reusable, self-service tooling, applying business process automation principles to the engineering workflow itself.

The two disciplines are complementary but aim to produce different things. DevOps aims for faster, more reliable releases through distributed ownership: each team runs what it builds. Platform engineering reduces the cognitive overhead that this model creates at scale. DevOps puts ops accountability on individual product teams; platform engineering creates a dedicated team that owns the shared layer those teams rely on. The output of a good DevOps culture is a set of practices and collaboration patterns. The output of a good platform engineering function is a product.

The foundation for this structure comes from Team Topologies by Matthew Skelton and Manuel Pais (IT Revolution Press, 2019), which formalised platform teams as one of four fundamental team types. The book describes three ways teams interact. A platform team typically works in "X-as-a-Service" mode: it provides a service that stream-aligned teams consume. Facilitation, where one team helps and mentors another, is the usual mode of enabling teams.

A related shift is the rise of GitOps as a delivery model within platform engineering. Tools like ArgoCD and Flux use Git as the single source of truth for infrastructure state, which fits how IDPs enforce consistency. Our breakdown of GitOps vs DevOps covers this in more detail.

The two do not compete: DevOps thinking is what makes a platform team work well. A platform team that ignores developer feedback and ships tooling nobody wants has misunderstood both disciplines.

Why Is This Happening Now?

Platform engineering is not a new idea. What is new is the scale at which organisations are treating it as a strategic priority.

The business case: Gartner's 2024 signal

Gartner named platform engineering one of its Top 10 Strategic Technology Trends for 2024, and separately forecast that 80% of large software engineering organisations would establish platform engineering teams by 2026, up from 45% in 2022. The 2025 DORA report measures something different: 90% of the organisations it surveyed have adopted at least one platform, and platform quality directly affects how much value teams get from AI.

Several forces are driving it. Engineering organisations have grown substantially over the last decade, and what worked with 20 engineers breaks down at 200. Distributed teams, microservice architectures, and multi-cloud deployments have multiplied the number of systems each developer must understand. Without some form of abstraction, that cognitive load becomes hard to sustain.

There is also a developer experience dimension. Competition for engineering talent is intense across the UK, Netherlands, Sweden, and wider Europe. Engineers talk about their tooling. A well-maintained internal developer platform is one of the more concrete ways an organisation can improve developer satisfaction, shorten onboarding time, and reduce attrition.

Platform engineering is therefore partly an infrastructure decision and partly a talent decision. Organisations that treat it as purely technical tend to underinvest in the product and user experience work that decides whether a platform gets adopted.

How a Platform Engineering Team Is Structured

Team structures vary, but the ones that work share a few patterns.

Roles and ratios

Platform teams are usually small relative to the engineering organisation they serve. The right size depends on infrastructure complexity and on how mature the existing tooling is.

The core of the team tends to be platform engineers with solid systems and Kubernetes experience, an SRE whose job is reliability rather than feature work, and a product manager who owns the IDP roadmap and stays close to what developers are struggling with. Some teams also bring in a developer advocate, whose role is less about technology and more about documentation, onboarding, and making sure the platform gets used rather than worked around.

What good looks like in practice

A Series B SaaS company in the Nordics grew its engineering team from 30 to 90 engineers over 18 months. Each squad had built its own deployment scripts and monitoring setup. Knowledge lived in individual heads. Onboarding a new engineer took three weeks of shadowing before they could ship independently. When the company formed a dedicated platform team of four and built a minimal IDP covering a service catalogue, standardised CI/CD, and one-click staging environments, onboarding time dropped to five days. The platform team spent the first six months doing almost no building: they interviewed developers, mapped pain points, and prioritised ruthlessly. (Illustrative scenario, not a real client.)

In that example, the difference came from six months of developer interviews before any real building. A discovery phase applied to internal tooling, where you interview users before writing code, makes it far more likely that the platform gets adopted.

Is It Actually Replacing DevOps?

No, though it is a question worth taking seriously.

Why the confusion exists

The concern tends to come from practitioners who have watched "DevOps engineer" become a job title, and then watched platform engineering arrive and pull many of the same responsibilities into scope. From the outside, it can read as rebranding: a new label attached to work that was already happening under a different name.

DevOps as a philosophy has not changed: teams that build software should feel accountability for how it runs in production. Platform engineering does not undo that idea. It changes the structure around it: who builds and maintains the shared tooling that makes that accountability manageable at scale, instead of a daily burden on every product team.

The roads analogy

A well-run city does not expect every resident to build their own roads. It provides roads, maintained to a standard and available to all, then expects residents to drive responsibly on them. Platform engineering builds the roads. DevOps culture defines how engineering teams drive.

In most organisations, platform engineering grows out of an existing DevOps practice rather than replacing it. Organisations with strong DevOps practices tend to find platform engineering easier to adopt. Organisations that skip straight to platform engineering without the cultural foundations of DevOps tend to build platforms nobody uses.

What This Means for Engineering Leaders

If you are a CTO or Head of Engineering deciding whether to formalise a platform engineering function, the real question is whether your organisation has reached the point where not having one costs more than building and running one.

A few signals usually show that point has arrived. Onboarding takes longer than two weeks because new engineers cannot get up and running without shadowing someone. Different squads solve the same infrastructure problems independently, with no shared memory between attempts. Post-incident reviews keep tracing root causes back to configuration inconsistencies between environments. Senior engineers spend a significant part of their week on infrastructure that is not their core job.

Platform engineering solutions do not have to start large. A small team with a focused mandate, whether that is standardising CI/CD, building a service catalogue, or cutting environment provisioning time, can demonstrate measurable value within a quarter.

Go Wombat works with engineering organisations across the UK, the Netherlands, and wider Europe on DevOps services and platform engineering engagements, from initial scoping through to IDP design and implementation. If your team is at this point, a discovery phase conversation is worth having before the architecture decisions are locked.

What Leaders Should Remember

Platform engineering solves an organisational problem: engineering teams that have grown past the point where every squad can maintain its own infrastructure without crowding out the product work they were hired to do.

It extends DevOps rather than competing with it. Product teams still own what they run; the platform team makes that ownership cheaper in time and attention. The organisations that do this well treat the IDP as a product rather than an internal IT project: they find out what their developers need, iterate, and measure progress by adoption rather than by features shipped.