SRE vs DevOps: the difference that matters when it is your job title

Somewhere right now an engineer is staring at two browser tabs, one job listing titled DevOps Engineer and one titled Site Reliability Engineer, trying to work out whether they are two jobs or one job wearing two names. The internet's standard answer is a decade old and delivered in unison: DevOps is a culture, not a job title; SRE is Google's concrete implementation of it. Tidy, quotable, and no help at all with the actual decision in front of you.

Because while the definitional debate was being settled, the job market ignored the verdict. Companies went on posting DevOps Engineer roles in industrial quantities for a thing that is officially not a role, and stuck SRE on everything from genuine error-budget-owning teams to a rebadged night shift. Both words stopped being definitions years ago. They are now signals, and noisy ones.

So this piece takes the question the way you actually meet it: as a choice about which jobs to apply for, what to call yourself, and what the person on the other side of the table thinks they are hiring. The definitions get two paragraphs, because they earned them. The rest is about reading the signal through the noise.

The textbook answer, and why it stops helping

For the record, the textbook is right. DevOps, born around 2009, is a working philosophy: collapse the wall between the people who build software and the people who run it, automate the path to production, share the pager and the incentives. It deliberately is not a job description; the original point was that operations is everyone's problem.

SRE is older and more specific: it began in 2003 as Google's answer to the question "what happens if you ask software engineers to design an operations function?", and was codified publicly in the 2016 SRE book. It comes with real machinery, and the machinery is the point: service-level objectives, error budgets that arbitrate between shipping and stability, a cap on manual toil, blameless post-incident review. Google's own framing is that SRE can be read as a concrete implementation of what DevOps intends: the philosophy made executable. All true, all stable for a decade, and none of it tells you which of your two tabs to close. For that you need the field definitions, which are messier.

What the titles mean when they are hiring titles

In the job market, the centre of gravity of each title is reasonably consistent, even though individual listings wander.

DevOps Engineer, as hired, usually means: you build and run the delivery machinery. CI/CD pipelines, infrastructure as code, the Kubernetes platform, cloud accounts, the paved road other engineers ship on. Your customers are mostly internal, your success metric is how fast and safely other people can deploy, and the word "platform" is drifting into your title a little more every year.

SRE, as hired, usually means: you own the reliability of running services. SLOs and the error budgets behind them, production on-call as a first-class duty rather than a footnote, incident response and the review that follows, capacity and performance. Your customer is the user experiencing the service, and your success metric is the SLO itself (nines of availability are the famous ones, but latency and correctness targets count just as much) and how rarely the same incident happens twice.

Then there is the noise. Plenty of DevOps listings are a systems administrator role that got a fashionable rename and none of the cultural mandate. Plenty of SRE listings are the DevOps job with a title upgrade, often because the market tends to read SRE as more senior and listings follow the incentive. Titles inflate; responsibilities do not. Which is why the real skill is the next section.

How to read a JD past its title

Ignore the first line and interrogate the body. Five signals, between them, separate the two jobs and expose the mislabelled ones faster than any definition:

1. Who owns the SLOs? If the listing names SLOs, error budgets, or reliability targets the team itself sets and defends, you are reading an SRE-shaped role, whatever it is called. If reliability is mentioned only as a virtue, you are not.
2. Where is on-call? In the first paragraph as an owned responsibility: SRE-shaped. In a compliance-toned sentence near the benefits: delivery-platform-shaped. Absent entirely from a role claiming production ownership: a question to ask at interview, pointedly.
3. Build for engineers, or run for users? "Enable teams to ship" is platform work. "Keep the service within SLO" is reliability work. A listing that claims both with equal weight is usually a small company where you will genuinely do both, which is its own information.
4. Is there a software engineering bar? Genuine SRE roles, especially at larger companies, interview for code: not LeetCode theatre but the ability to write the automation that deletes toil. A listing that asks only for tool familiarity is hiring an operator, at either title.
5. What happens after an incident? Post-incident review, learning culture, and follow-through appearing in the listing is a strong maturity signal for either title. Its absence from an SRE listing specifically is the tell that the title is decorative.

The title tells you what the company wishes the team was. The JD body tells you what it is.

The overlap is the career asset

Here is the part the versus framing hides: the two jobs share most of their skeleton. Linux fluency, containers and Kubernetes, at least one cloud, infrastructure as code, observability that goes deeper than dashboard tourism, and the incident habit of diagnosing under pressure with incomplete information. That shared core is where much of either job is lived day to day, and it transfers.

The deltas are real but narrow. Towards SRE: more software engineering, because the mandate is to automate operations out of existence, and more statistical comfort, because SLOs are arithmetic about user harm. Towards DevOps and platform work: more delivery tooling depth, pipeline design, and developer-experience instinct. For an engineer standing on the shared core, the move either way is a lean rather than a retrain; the troubleshooting loop that anchors it is the same loop in both jobs.

This is also why the transition guides we have written point at the same foundation from different starting points: support engineers already own the incident half of the skeleton, and the no-degree path builds the platform half project by project. Neither guide would change materially if you swapped the target title, which is the whole point.

If you are the one writing the JD

A short section for the other reader of this page. Title the role for the work, because mislabelling filters out exactly the people you want: a genuine SRE opening titled DevOps loses the candidates who filter on reliability ownership, and an SRE title on a delivery-platform job burns your first on-site explaining the difference to a candidate who read the listing more carefully than the person who wrote it. The five signals above run in reverse: put the SLO ownership, the on-call reality, and the engineering bar in the body, explicitly, and the right people select themselves in. How you then assess them is its own subject, but the listing is where the funnel quietly succeeds or fails.

The honest limits of any title map

Two concessions. First, the purists are not wrong: DevOps-as-culture is the more important idea, and a company that hires brilliantly titled engineers into a blame-and-ticket culture gets neither DevOps nor reliability. The title map reads the market as it is, not as the movement hoped. Second, the map expires. Platform engineer is already absorbing territory from both titles, and in five years this page will describe one more historical layer in the sediment. The shared core is the durable investment; the titles are how you sell it this decade.

Where we fit in

Notice what every section above kept landing on: not the title, but the evidence behind it. The five JD signals are all attempts to detect, through a listing, whether real operating work happens on that team. Interviews are the same detection problem pointed the other way, and titles survive precisely because that detection is hard.

That is the problem SkillBricks exists to shrink. A verified wall of real operating work, done live in production-like environments, is title-independent evidence: the same bricks answer for an SRE application and a DevOps one, because the underlying skill is the shared core, not the label. If you are the engineer with two tabs open, that evidence is buildable starting today; if you are the one hiring, it is readable before the first phone screen. The titles will keep drifting. Proof does not.