I reviewed the org chart for a financial services company last month that had recently created a “Platform Engineering” team. On paper, it looked modern—a dedicated group responsible for developer experience, CI/CD pipelines, and internal tooling. In practice, it was the same six infrastructure engineers doing the same work, just with a new Slack channel and a renamed Jira board.

They weren’t alone. The platform engineering movement has created a wave of rebranding that misses the fundamental shift the concept represents. Get the distinction wrong, and you end up with the worst of both worlds: an infrastructure team told to think like a product team but without the mandate or structure to do so.

What Infrastructure Teams Do

Infrastructure teams manage resources. Servers, networks, storage, cloud accounts, DNS, certificates, firewalls. Their work is defined by the things they operate. Success is measured by uptime, incident resolution speed, and cost efficiency.

This is valuable, necessary work. But it’s inherently reactive and operational. Infrastructure teams respond to requests, resolve incidents, and maintain systems. Their relationship with development teams is typically transactional—developers submit a ticket, infra provisions a resource.

The ITIL framework codifies this model well. But it breaks down when you need rapid iteration, self-service capabilities, or consistent developer experiences across multiple teams.

What Platform Teams Should Do

A genuine platform team operates like an internal product team. Their “customers” are the developers and engineers building business applications. Their “product” is a set of self-service capabilities that make it faster, safer, and easier to ship software.

According to Puppet’s 2025 State of DevOps report, organisations with mature platform teams deploy 4.5 times more frequently than those without, with 60% fewer change failures. That’s not because they’ve hired better people. It’s because they’ve structured the work differently.

A platform team builds golden paths—opinionated, well-supported workflows that handle 80% of common use cases. Need a new microservice? There’s a template that provisions the repo, CI/CD pipeline, monitoring, and deployment target in minutes. Need a database? There’s a self-service catalogue with pre-approved configurations.

The key difference: developers don’t submit tickets and wait. They use the platform directly. Success is measured by adoption rate, developer satisfaction, and time-to-first-deployment—product metrics, not operational metrics.

Where Organisations Get It Wrong

Renaming without restructuring. The most common failure. You can’t create a platform team by changing job titles. Platform engineering requires different skills (product thinking, developer empathy, API design) and different incentive structures (adoption metrics vs uptime metrics).

No product manager. A platform team without a product manager is an infrastructure team with aspirations. Someone needs to own the roadmap and prioritise features based on developer feedback. If the team is just picking tasks from a backlog of infrastructure requests, you’ve changed nothing.

Building everything from scratch. Some organisations try to build a bespoke internal developer platform when commercially available tools would cover 90% of their needs. The goal isn’t to create a software product—it’s to create a curated experience using existing tools.

Ignoring the migration path. You can’t just stand up a platform and expect everyone to adopt it immediately. Existing teams have workflows, scripts, and tribal knowledge built around the old way. A platform team needs a migration strategy that’s gradual and incentive-driven, not mandated from above.

Making the Transition

If you’re serious about moving from infrastructure to platform engineering, here’s what I’ve seen work.

Start small. Pick one capability—say, CI/CD pipeline provisioning—and build a genuinely self-service experience for it. Get three or four development teams to use it. Iterate based on their feedback. Prove the model works before expanding.

Hire or develop a product mindset. Your best infrastructure engineers might not be your best platform engineers. The skills that make someone excellent at managing a Kubernetes cluster don’t automatically translate to building developer-facing products. You need people who enjoy talking to developers and designing solutions around user experience.

I worked through this transition with a company recently, and the approach that an AI consultancy we brought in recommended was revealing: they spent the first two weeks just interviewing developers. Not building anything. Just understanding what slowed people down and what workarounds they’d built. The resulting platform roadmap was completely different from what the infrastructure team would have built on their own assumptions.

Measure differently. If your platform team’s primary metrics are still uptime and ticket resolution time, you’re measuring infrastructure work. Platform teams should track: time from code commit to production deploy, developer onboarding time for new services, percentage of teams using the golden path, and net promoter score from internal developers.

The Honest Assessment

Not every organisation needs a platform team. If you have fewer than five or six development teams, the overhead of building and maintaining an internal platform probably isn’t justified. A well-run infrastructure team with good documentation and reasonable automation will serve you fine.

But if developer productivity is constrained by infrastructure bottlenecks, teams are building one-off deployment pipelines, and onboarding takes weeks because of environment setup—that’s when the platform team model pays off. Just make sure you’re actually building one, not putting a new label on the same old org.