Platform engineer vs DevOps engineer vs SRE
Below roughly thirty engineers these are the same job with three names, and arguing about which to advertise wastes time you could spend writing an accurate description of the work. The distinction becomes real when there are enough people that one group's output is another group's input. At that point the difference is not skills but who the role serves and what it is measured on, and those two answers are what a candidate is actually deciding between.
Are these actually different jobs?
Not in most companies. In a team of twenty engineers, one infrastructure specialist does pipelines, provisioning, monitoring, on-call design and cost, and the title on the contract reflects fashion at the time of hiring rather than any difference in duties. Insisting on a distinction at that size produces a job ad describing a role that does not exist, and candidates notice.
They diverge when specialisation becomes cheaper than generalism, which happens once the internal tooling has its own users. At that point one group builds things other engineers consume, another keeps production reliable, and the two have different customers, different definitions of done and different reasons to be woken up.
The useful question to settle before writing an ad is therefore not which title is correct, but who the person's customer is: developers who want to ship, or the running system that must not fall over. Almost every disagreement about these titles resolves once that is written down.
What is each role measured on?
Different things, and the differences are sharper than the skill overlap suggests. The table below is the version that survives contact with an actual organisation, including the failure mode each role reliably produces when it goes wrong.
| Role | Primary customer | Measured by | Failure mode |
|---|---|---|---|
| DevOps engineer | The engineering team as a whole | How rarely anyone has to ask them to ship something | Becomes the request queue and never gets to the underlying work |
| Platform engineer | Other engineers, treated as users of an internal product | Adoption of the paved route, and time from new service to first deploy | Builds a platform teams work around because nobody asked what they needed |
| Site reliability engineer | The running system and the people who depend on it | Service objectives met, and incidents that do not recur | Without authority to slow releases, becomes operations with a better title |
| Cloud or infrastructure engineer | The estate itself | Environments that are reproducible, secure and predictably priced | Optimises the estate for its own elegance rather than for delivery |
| Systems administrator | Whoever raised the ticket | Tickets resolved and systems kept available | Knowledge stays in one head because nothing forces it into code |
What is a platform team actually for?
Removing the need to ask. A platform team exists so that a developer can create a service, get a pipeline, a database, credentials, logging and a production route without opening a ticket or learning the cloud provider's console. That is the entire proposition, and it is worth stating plainly because platform teams that lose sight of it start building infrastructure for themselves.
The mechanism that makes it work is treating internal engineers as users rather than as colleagues who should be grateful. That means asking what they currently do by hand, watching them try the new route without help, and accepting that a golden path nobody takes is a failed product regardless of its technical quality. Mandating adoption is the standard substitute for this, and it produces compliance rather than use.
A blunt test: pick an engineer who joined recently, ask them to stand up a new service, and time it without helping. If it takes more than a day or requires messaging a specific person, there is no platform yet, whatever the team is called.
What does SRE add that DevOps does not?
A decision procedure for the trade-off between reliability and speed. That is the substance of the discipline: agreeing an objective for how reliable a service needs to be, measuring against it, and using the remaining margin to decide whether the next risky change goes out now or waits. Everything else attributed to SRE, the automation and the monitoring and the incident practice, is also done by other titles.
This only functions if the objective has teeth. If a service is failing its target and feature work continues unchanged, the objective is a dashboard, not a decision procedure, and the SRE has been given the responsibility without the authority. That arrangement burns people out faster than on-call frequency does, and candidates with real experience will ask about it in the first interview.
So the honest question before advertising an SRE role is whether your organisation would actually pause a release because a reliability target was missed. If the answer is no, hire a DevOps or platform engineer and describe the job accurately. Nobody experienced is fooled, and the ones who are fooled leave within the year.
Which should you hire first?
A generalist, almost always, and the title should be the one that best describes the estate they are inheriting. A first hire into a company with no infrastructure specialist will spend a year doing all three jobs regardless of what the contract says, and hiring a specialist into that situation wastes the specialism.
The sequence that tends to work is a generalist first, a second generalist when the first one becomes a single point of failure, and only then a split. The split usually forms along the customer line rather than the skill line: someone turns towards the developers and the paved route, someone turns towards production and reliability. Letting that emerge from the work produces better fits than deciding it in advance.
Advertise the title that matches the work rather than the one that attracts the most applicants. Platform engineer currently pulls a larger shortlist, which is exactly why using it for a role that is mostly ticket handling produces early departures. The cost of a title that oversells is paid at month four, and it is higher than the cost of a smaller shortlist.
Does the title change what the job costs you?
It changes the shortlist more than it changes the work, and the shortlist changes the price. Titles associated with product-facing internal tooling attract people who want to build things, and roles described as keeping the lights on attract fewer applicants at any level. That is a market fact rather than a judgement about the value of the work.
The distortion to guard against is inflation. Retitling an operations role as SRE to compete for candidates works exactly once per candidate. They arrive expecting objectives, error budgets and the ability to influence release decisions, find a pager and a ticket queue, and start looking again. The recruitment cost of that cycle exceeds whatever the honest ad would have cost in extra weeks of searching.
The reverse error is cheaper but still real. Advertising a genuine platform product role as a DevOps engineer position, because that is what the last one was called, buries what makes the job interesting and produces a shortlist of people who will be surprised to be building an internal product. Write the ad from the six months of work you actually have queued, and then pick whichever title lies least.
Common questions
- What is the difference between a DevOps engineer and an SRE?
- The customer and the measure. A DevOps engineer serves the engineering team and is measured by how rarely anyone needs to ask them to ship something. A site reliability engineer serves the running system and is measured by whether agreed reliability objectives are met and whether incidents recur. The distinction is only meaningful if missing a reliability objective actually changes what gets released, otherwise the SRE title describes operations work.
- Is platform engineering just a new name for DevOps?
- It is a narrower job with a clearer customer. Platform engineering treats other engineers as users of an internal product and is measured by adoption of the paved route and by how quickly a new service reaches production without help. DevOps as a title usually covers that plus incidents, cost, access and whatever else falls between teams. Below about thirty engineers the two are the same person.
- Which role should a company hire first?
- A generalist, whatever the title says, because a first infrastructure hire will do pipelines, provisioning, monitoring, access and cost regardless of the contract. Specialisation is worth introducing only once there are enough engineers that internal tooling has real users. The split then tends to form along the customer line, with one person turning towards developer experience and another towards production reliability.
- Do you need an SRE team to have service level objectives?
- No. Objectives are a decision procedure rather than a team structure, and a small engineering team can agree a target for a critical user journey, measure it and use it to decide whether the next risky change goes out. What matters is whether missing the target changes behaviour. If releases continue unchanged when the target is missed, the objective is a dashboard and no job title will fix that.
- Does the job title affect what you have to pay?
- It affects the shortlist, which affects the price. Titles associated with building internal tooling attract more applicants than titles associated with keeping systems running, so the same work can be harder to fill under an honest name. Inflating a title to widen the shortlist works once per candidate: people arrive expecting one job, find another, and leave, which costs more than the extra weeks of searching would have.
