A Series A VP of Engineering posted a job description for a "Platform Engineer" and got 80 applications. Some looked like traditional DevOps engineers: strong on Kubernetes, Terraform, CI/CD, incident response. Others looked like developer tooling engineers: internal developer portals, golden path templates, self-service scaffolding, reducing cognitive load for product teams. Both groups called themselves platform engineers. Neither group was wrong.
The VP hired the first candidate who impressed them in the interview. Three months later, the hire was spending most of their time on-call, managing access requests, and debugging pipeline failures. Not because they were underqualified — they were excellent. But the company had hired for operational DevOps and called it platform engineering, and the mismatch between the job title and the actual work created frustration on both sides.
The distinction matters, and it changes not just what you hire for but when.
What "DevOps" actually means in practice
DevOps — the actual work, not the philosophy — is the set of practices and infrastructure that makes software delivery fast and reliable. In most organizations, the DevOps function owns:
- CI/CD pipelines: the build, test, and deploy automation that gets code from a developer's branch into production
- Infrastructure: the cloud resources, Kubernetes clusters, databases, and networking that the applications run on
- Reliability and on-call: incident response, alerting, runbooks, postmortems, SLO tracking
- Security and access: IAM, secrets management, compliance controls, audit logging
- Cost management: right-sizing, reserved capacity, waste elimination
The work is operational by nature. A lot of it is reactive — incidents, access requests, pipeline failures. Even the proactive work (improving monitoring, automating a manual step) is in service of keeping existing systems running well.
What platform engineering actually means
Platform engineering is a product discipline applied to internal infrastructure. A platform team's customers are the company's own developers, and their product is the tools, templates, and abstractions that let those developers ship code faster and more independently.
In practice, platform engineering owns:
- The "golden path" — the standard way to deploy a new service (a Helm chart template, a CI/CD scaffold, a Terraform module) so developers don't start from scratch or copy-paste from an old service
- Internal developer portal — a single place where developers can see their services, provision new ones, manage dependencies, and run standard operations without filing a ticket
- Developer experience tooling — local development environments, fast feedback loops, test infrastructure that mirrors production without requiring an ops ticket to provision
- Platform SLOs — committing to internal service levels: "the CI pipeline runs in under 8 minutes for 95% of builds," "a new environment can be provisioned in under 10 minutes"
Platform engineers are building a product, which means they do user research (talking to developers about their pain points), prioritize a roadmap, and measure adoption of the things they build. They are not the people you page at 2am when the database goes down.
Why the confusion exists
The overlap is real. Platform engineers need to understand Kubernetes deeply. DevOps engineers build things developers use. Both roles care about CI/CD. The lines blur further because companies use the titles interchangeably, and many engineers move between the two types of work throughout their careers.
The confusion also comes from aspiration. Many companies that need DevOps tell themselves they need platform engineering because "platform" sounds more strategic. Hiring a platform engineer when you have an operational DevOps gap is like hiring a product manager when you need a project manager — the skillsets overlap but the jobs don't, and neither person is set up to succeed.
The stage that determines which you need
Under 20 engineers: DevOps practices, not a dedicated person
At this stage, your infrastructure should be simple enough that developers can handle most of it themselves with the right tooling. Automated deployments, tested backups, basic monitoring, secrets not hardcoded anywhere. You do not need a dedicated platform team, an internal developer portal, or golden path templates for a service count you can count on two hands.
This is the stage where fractional DevOps coverage makes the most economic sense — you get the operational expertise and on-call coverage without the overhead of a full-time hire who would spend most of their time waiting for something to break.
20–50 engineers: when one DevOps hire starts to make sense
The signal that you need an in-house DevOps engineer isn't headcount — it's toil. When developers are spending 10%+ of their time dealing with infrastructure friction (slow pipelines, unclear deployment processes, inconsistent environments), that compounds as the team grows. A DevOps hire at this stage pays back in reclaimed developer productivity within 3–6 months.
This hire is still primarily operational: keeping the infrastructure running, improving the pipelines, managing the on-call rotation. Not building a developer portal. They shouldn't be.
30–60 engineers: when platform investments start paying off
At this stage, you have enough product teams that inconsistency between how different teams deploy and operate their services causes real problems. A new engineer joining Team A gets a completely different setup experience than one joining Team B. Services are configured differently. CI pipelines are copy-pasted with small variations nobody understands anymore.
This is when a Platform Engineer — not a platform team, one person — starts delivering value. Their job is to create standard patterns that reduce inconsistency: a service scaffold, a standard CI configuration, a documented deployment workflow. The output is documentation and tooling that lives beyond any one person.
60+ engineers: dedicated platform team
At this scale, the platform team is a full product team: multiple engineers, a clear roadmap, an internal SLA, adoption metrics for the tools they ship. The "product manager for the platform" role emerges — someone whose job is to translate developer pain into platform priorities, the same way a PM translates customer feedback into product work.
The hiring implication
If you're hiring in the first or second stage, be honest: you need operational DevOps, not platform engineering. The interview questions that matter are about incident response, Kubernetes debugging, Terraform module design, and CI/CD optimization — not about developer portals or golden paths.
If you're in the third stage and hiring your first Platform Engineer, the profile is different: strong product thinking, a history of building internal tools that developers adopted, comfort with being measured on adoption metrics rather than on whether production is up. The Kubernetes depth matters less; the ability to run developer interviews and prioritize a backlog matters more.
A good DevOps engineer hired into a platform role will default to operational work because that's where their instincts are. A good Platform Engineer hired into a DevOps role will try to build systems when you need someone responding to incidents. Neither person is doing anything wrong — the job description created the misalignment.
"We had two 'platform engineers' whose days were 90% operational. Good engineers, completely wrong role. When we finally hired a true Platform Engineer, the first thing they did was talk to developers for two weeks before writing a line of code. Different animal entirely."
Where fractional DevOps fits into this model
The fractional model covers the operational DevOps layer — infrastructure, on-call, CI/CD, security — while your in-house engineers focus on product and platform work. For most companies under 50 engineers, this is the right division of labor: the operational work gets consistent expert coverage without full-time headcount, and the engineers you do hire are focused on platform leverage, not ticket triage.
When a company is genuinely ready to hire its first Platform Engineer, we'll say so — and at that point, our role shifts to making sure the platform engineer inherits something well-documented and well-structured enough to actually build on.