Most companies hiring for "platform engineers" right now want someone to manage their CI/CD pipelines, maintain their Kubernetes clusters, write some Terraform, and maybe set up an ArgoCD deployment.
That's DevOps with a rebrand.
They've seen the platform engineering hype cycle, updated the job title, and changed nothing about the role. The job description still reads like an infrastructure operator. The interview still tests tool proficiency. The success criteria is still "keep things running."
Here's the distinction they're missing: a DevOps engineer maintains infrastructure. A platform engineer designs platforms as products.
That difference sounds subtle. It isn't.
What "Platform as Product" Actually Means
A platform engineer doesn't just keep the lights on. They design for outcomes:
- Cognitive load reduction, how many things does a developer need to understand before they can ship?
- Golden path abstraction, what's the pre-paved route that handles 80% of use cases without friction?
- Developer experience as a measurable outcome, not a feeling, a metric. Time to first deploy. Onboarding duration. Governance lookup time.
- Self-service by default, developers declare what they need; the platform reconciles it. No tickets. No waiting.
None of that appears in most "platform engineer" job descriptions. The people writing them don't know it exists yet.
That's not a criticism, it's a signal. Companies posting DevOps-with-a-new-title roles are telling you something: they know they need platform engineering. They just don't know what it looks like in practice. They're defining the role by the tools they already use rather than the outcomes they actually need.
What a Real Platform Team Looks Like
At Conde Nast, I was part of the cloud infrastructure and platform engineering team that delivered and maintained a global platform for Conde Nast International. We managed multiple production-grade Kubernetes clusters serving digital content for brands like Vogue and GQ across Spain, Mexico, Germany, France, the UK, China, India, and the USA.
That wasn't one person doing everything. It was distinct specialists contributing toward a platform engineering outcome. The Kubernetes engineer handled orchestration. The DevOps engineer handled pipelines. The SRE handled reliability and defined platform SLAs and SLOs. The platform was the product of the team's combined capability.
There's a crucial distinction between a platform team that contains Kubernetes engineers, DevOps engineers, and SREs working together under a platform engineering strategy, and a company that renames a single DevOps engineer to "Platform Engineer" and changes nothing else.
The first is platform engineering done properly. The second is a single operator with a new title.
A Kubernetes engineer can work within a platform team. A DevOps engineer can work within a platform team. A CI/CD expert can, and so can an SRE. They're specialists contributing to a platform product. The platform engineer is the one who designs how those specialisms integrate into a coherent system that serves developers.
What the CNCF's Hardest Exam Reveals
The CNCF recently released the Cloud Native Platform Engineer (CNPE) exam. I started digging into it after stumbling across Michal Tomczak's write-up of taking the beta. He described building a complete IDP from scratch in his home lab as preparation, and called it likely the hardest hands-on exam CNCF has ever released.
The exam covers five domains:
- Platform Architecture and Infrastructure (15%)
- GitOps and Continuous Delivery (25%)
- Platform APIs and Self-Service (25%)
- Observability and Operations (20%)
- Security and Policy Enforcement (15%)
That breadth makes it sound like the industry wants a Swiss Army Knife. But look at what it's actually testing.
It's not testing whether you can be a Kubernetes admin, a DevOps engineer, and an SRE simultaneously. It's testing whether you can design and integrate across all of those domains. The exam requires you to think like an architect and implement like an engineer.
A Swiss Army Knife has many tools, but you only use one at a time. A platform engineer understands how all the tools connect into a coherent system.
This maps to a metaphor I've explored before. A tailor doesn't personally weave the fabric, tan the leather, forge the scissors, and mine the ore. But they understand all of those materials well enough to design a garment that uses them correctly. The platform engineer doesn't need to be the best Kubernetes operator, the best CI/CD pipeline builder, or the best security engineer. They need to understand all of those domains well enough to design a platform that integrates them into something that serves developers.
The Industry Is in the Awkward Middle
Platform engineering as a discipline is real and distinct from DevOps. Designing internal developer platforms as products, building golden paths, treating developer experience as a measurable capability, these are not DevOps tasks with aspirational language. They require different thinking, different metrics, and different success criteria.
But most companies haven't internalised what the difference actually means. They know platform engineering is the direction things are moving. They don't know what it looks like when it arrives.
The CNPE exam at $445 is the industry's attempt to codify the distinction. It validates breadth-with-depth, not "can you use all the tools?" but "can you design how they work together?" The CNCF Platforms whitepaper laid the theoretical groundwork. The CNPE is the practical validation.
What This Means
If you're an engineer positioning yourself as a platform engineer: the differentiator isn't knowing more tools. It's designing systems where developers don't need to know the tools at all. The golden path is invisible to the people walking it. That's the job.
Companies hiring one person to do everything need a generalist. Companies building a platform need an architect. The CNPE doesn't test whether you can be a Swiss Army Knife for hire. It tests whether you're the person who designs how the knife is assembled, which tools it needs, and how they work together.
If you're a company hiring a platform engineer: stop writing DevOps job descriptions with a new title. Define the role by outcomes, developer experience, onboarding time, self-service capability, not by tools. If you need someone to maintain Kubernetes and write Terraform, hire a DevOps engineer. That's a legitimate, valuable role. Just call it what it is.
The industry will catch up. The question is whether you're waiting for the job descriptions to change, or building the thing that changes them.