The req has been open five weeks. It says “DevOps Engineer” because that is what the last three companies you looked at called it, and the resumes arriving do not resemble each other. One candidate has written Terraform modules for a 300-engineer platform team and has never touched a Windows laptop. Another ran a 40-person office network, Active Directory and Intune single-handedly and has never opened a pull request. A third wants to discuss your service mesh. You have 22 engineers, one production environment, a Google Workspace tenant nobody owns, and deploys that break about once a fortnight.

The question “do I need a DevOps person or a sysadmin” cannot be answered as asked, because both titles now cover four or five genuinely different jobs. The answer comes from the work: write down every operational thing that is not getting done, sort it into clusters, count the hours, and the job description falls out of the list. Run that sort and the honest answer is usually one of four. A platform or infrastructure engineer. An SRE. An IT and workplace person. Or two separate part-time needs you had bundled into one hire and would have made miserable.

Why neither title tells you anything anymore

“Sysadmin” used to be precise: servers, in a room, and a person who kept them running. Then servers became API calls, operating systems became container images built by CI, and the job split. Cloud infrastructure went to engineers who write code. Laptops, accounts and the office network stayed with people who now mostly administer SaaS. Both halves kept the old word.

“DevOps engineer” has the opposite problem. DevOps was described from the start as a way of working between development and operations rather than a job you hire for, which is why practitioners have argued for a decade that the title is a category error: a company hiring one DevOps engineer to “do the DevOps” has often just renamed its operations silo. The research side agrees. DORA publishes a model of capabilities, not roles: continuous integration, continuous delivery, deployment automation, monitoring and observability, proactive failure notification, documentation quality. Its platform engineering material describes a discipline built on self-service, repeatability and golden paths for other teams, and treats developer independence, a team shipping without waiting on another team, as what moves delivery performance. None of that is a person. It is a set of practices someone has to own.

One administrative fact before you benchmark pay. The US Standard Occupational Classification has no code for DevOps engineer, site reliability engineer or platform engineer. They do not exist in federal data; people doing those jobs get counted as software developers (SOC 15-1252) or as network and computer systems administrators (15-1244), two codes about $37,000 apart on median pay. Any “average DevOps salary” you find online is a job-board scrape, not official statistics.

The four clusters of work

Nearly everything shoved into an ops req belongs to one of four clusters. Different skills, different temperaments, mostly different people.

1. Build and release. CI pipelines, build times, test infrastructure, environments on demand, database migrations, the release process, rollback. Symptom: shipping is slow, manual or frightening. This person reads and writes application code, inside your repos.

2. Run. Monitoring and alerting, on-call, incident response, postmortems, capacity, performance, restores you have actually tested, cloud cost. Symptom: customers tell you about outages, nobody knows the p99, the bill grew 40% and nobody can say why. This is the SRE cluster, and it has the staffing problem below.

3. Infrastructure as product. Cloud architecture, networking, workload identity, infrastructure as code, secrets management, and the paths other engineers use to ship without filing a ticket. Symptom: every new service needs three weeks of bespoke setup, or one person is the only one who knows how staging is wired. The test: can an engineer stand up a service with logging, secrets, a pipeline and DNS with no human in the loop.

4. Corporate IT and workplace. Laptops, imaging, MDM, identity and SSO, Google Workspace or Microsoft 365 administration, SaaS licences, VPN, office network, onboarding and offboarding. Symptom: new hires wait a week for accounts, and nobody can say who holds admin in Salesforce.

Cluster four is where most mis-hires happen, and always the same way. A company hires a DevOps engineer at a software-engineering salary, then asks them to fix the conference room display, image a laptop and reset an MFA token. The engineer loses most of the week to interrupts, ships no platform work, and leaves inside a year. Everyone concludes “DevOps didn’t work for us.” Nobody behaved badly. The req was wrong. The inverse is quieter: an IT administrator gets handed Kubernetes and Terraform and makes decisions by console click that nobody can reproduce.

Clusters one to three can reasonably live in one person at your size. Cluster four almost never combines with them, and it is often the cluster generating the noise that made you want to hire.

The one-hour diagnostic

Open your incident channel, ticket queue, Slack DMs and your calendar. Go back 60 to 90 days and list the last ten to fifteen operational events: every outage, every bad deploy, every “can someone help me with” that ate more than 20 minutes, every task postponed because nobody owned it. Tag each B (build and release), R (run), P (platform) or IT, add rough hours, and note who absorbed it.

A real-shaped result for a 25-person software company:

• Deploy rolled back twice, root cause unknown. R, 6h, CTO
• Staging drifted from prod and broke a release. P, 8h, senior dev
• New engineer waited six days for accounts and a laptop. IT, 5h, three people
• Postgres disk filled at 2am, found via a customer email. R, 4h, CTO
• CI queue hit 40 minutes, team stopped running the full suite. B, ongoing, nobody
• Enterprise security questionnaire, nobody owns the evidence. IT and P, 12h, COO
• Offboarded contractor still had GitHub and AWS access. IT, found by accident
• Cloud bill up 40%, cause unidentified. R, 3h, CTO
• Two developers spent a day each standing up a new service. P, 16h, devs

Count it: P 24 hours, R 13, IT 6, B ongoing and unquantified, and the person absorbing most of it is the CTO. That is not a DevOps hire question. It is a platform engineer first, because the platform gap is generating the run problems too, plus a separate cluster-four decision that does not involve that person. If the tally comes out IT-heavy instead, as it usually does outside software companies, you need an IT and workplace hire or a managed provider.

On-call is the constraint nobody prices in

This is arithmetic, not opinion, and it sinks most single-hire plans.

Google’s SRE practice publishes its staffing floor: for a single-site team covering 24/7 with a primary and a secondary on-call on week-long shifts, the minimum is eight engineers, or six per site across two sites. It caps incidents at two per 12-hour shift, on the basis that handling one properly including the writeup runs about six hours, and holds that no more than half an SRE’s time should go to operational work.

You do not need a Google rotation. But apply the logic to one hire. That person is on call 168 hours a week, forever. No secondary, no vacation cover. Every 3am alert is theirs, and those are the hours they were hired to spend on automation, so the root problem never gets fixed and alert volume never falls. It is the most reliable way to lose an ops hire in year one.

Three honest options at your size:

• Accept best-effort coverage. Publish it internally and to customers: no overnight commitment, alerts route to a channel, someone looks in the morning. Legitimate when your customers are all asleep in one timezone. It stops being legitimate the day you sign an enterprise contract with an uptime term.
• Build a rotation that includes developers. Four to six people minimum, including the ops hire and the seniors who wrote the services. Pay a stipend, cap shift length, make whoever gets woken own the fix. This is the option that improves the system, because the people who can change the code feel the pages.
• Buy coverage. A managed provider, managed SOC or cloud partner takes the overnight window against documented runbooks while your internal person owns days and escalations. It only works if the runbooks exist, which is an argument for hiring the platform person first.

What does not work is writing “occasional on-call” and hoping. Strong candidates will ask how many people are in the rotation. Have the number ready.

What each option costs, and when to buy instead

US Bureau of Labor Statistics Occupational Outlook Handbook figures below, wages from May 2025, pages current to 27 August 2026. These are national medians across all industries and company sizes, so a funded startup in a metro should expect to pay above them. The ordering is the useful part.

• Software developers (15-1252): median $135,980, about 1,717,800 jobs, 10% projected growth 2025 to 2035. This is the code most platform engineers, SREs and DevOps engineers land in.
• Network and computer systems administrators (15-1244): median $99,130, about 323,600 jobs, projected to decline 4% over the same decade.
• Computer user support specialists (15-1232): median $61,860. Computer network support specialists (15-1231): $76,220. Combined, about 903,100 jobs and roughly 48,700 openings a year, projected to decline 3%.
• Information security analysts (15-1212): median $129,180, about 192,900 jobs, 21% projected growth, the fastest here.

Cluster four work is priced at roughly half of cluster one to three work, which is why paying a $140,000 engineer to do it is expensive in both directions. The declining projections for the sysadmin and support codes reflect consolidation into cloud and managed services rather than the work vanishing, so check which half of that role a candidate has lived in. And salary is not cost: add employer taxes, benefits, equipment and tooling.

A managed provider is the better buy when the work is mostly cluster four, mostly overnight coverage, or compliance work that needs evidence rather than invention. MSPs are genuinely good at laptops, identity, MDM, patching and helpdesk, because they do it at volume with tooling you would otherwise buy. A managed security provider is the better buy for round-the-clock monitoring and triage: staffing that internally is the eight-engineer problem again, with specialists at a $129,180 median.

It is the worse buy when the work is your product. Nobody outside your company can own your deploy pipeline, your service architecture or your internal platform; those decisions are inseparable from what you are building. If clusters one to three dominate, a provider gives you closed tickets and no capability gained.

On contractor versus employee, the risk here is specific. A contractor can build your platform, and for a three-month greenfield build they beat a hire you have not made yet. The failure mode is infrastructure only they can operate: undocumented Terraform, state files you cannot find, credentials in their password manager, a bus factor of one no longer under contract. Fix that in the statement of work.

• All infrastructure code in your repositories, in your organisation, from day one. No “we’ll move it later.”
• Remote state and secrets in accounts your company owns and holds the root credentials for.
• A runbook per system, plus an acceptance test: one of your own engineers performs a deploy, a restore and a rollback unaided before final payment. Hold back a percentage against it.
• Recorded handovers mid-engagement rather than in the final week, and access revoked through your identity provider at contract end.

Write the req so the right cluster applies

Titles attract candidates; the first five lines decide whether they apply.

Before: “DevOps Engineer. Looking for a versatile DevOps engineer to own our infrastructure and improve our processes. Comfortable wearing many hats. Experience with AWS, Docker, Kubernetes, CI/CD and scripting. Will also help support the team with IT needs.”

That says nothing except that you have no plan, and the last sentence tells strong platform candidates to skip it.

After: “Platform Engineer, first infrastructure hire. 22 engineers, one production environment on AWS, Terraform partially adopted, deploys manual at about 30 minutes each. First 90 days: automated and reversible deploys, staging reproducible from code, a self-service path for engineers to stand up a new service. On-call is a five-person weekly rotation including two senior developers and the CTO; you join in month two, not carry it alone. Laptops, Google Workspace and helpdesk sit with an external IT provider and are not part of this role.”

Longer, more specific, and it filters correctly in both directions. Naming the rotation and excluding cluster four are recruiting advantages, because candidates have been burned by reqs that hid both.

In interviews, the signal you want is someone who reduces work rather than absorbs it. Ask about a recurring problem at their last job and what they changed so it stopped recurring. Firefighters describe heroics in vivid detail and cannot name a systemic fix. Automators describe the boring change that made the heroics unnecessary, and usually raise documentation or a guardrail unprompted. Two more that sort fast: what would you turn off in your first month, and tell me about something you built that somebody else had to operate.

If you can only make one hire

An opinion, stated as one. For a software company of 5 to 50 people whose tally is platform-and-run heavy: hire a platform or infrastructure engineer first, buy cluster four from a managed IT provider, and build a developer-inclusive rotation instead of handing on-call to the new hire.

Platform work compounds and run work does not. An SRE dropped into an environment with no automation, no reproducible environments and no runbooks spends the year firefighting and leaves you where you started. A platform engineer who automates deploys, makes environments reproducible from code and writes the runbooks lowers the run load permanently, which makes a thin rotation survivable and a later SRE hire effective. Reverse this if the tally is IT-heavy, or if you have an uptime commitment you cannot currently meet. In that case, buy coverage now and hire second.

The case for hiring nobody yet is also real. If the tally is under roughly 20 hours a month and spread across several people rather than crushing one, buy your way out of the infrastructure you are struggling to operate: managed databases, managed Kubernetes or a platform-as-a-service if you do not actually need Kubernetes, managed CI. Then name an internal owner per area and give them explicit hours in their week. Ownership with allocated time fixes more than an unfunded req does.

Common follow-up questions

Is “DevOps engineer” a real job or not? It is a real job market with thousands of open roles, and the practice literature does describe DevOps as capabilities rather than a role. Both hold. Treat the title as a search term and define the actual job in the body of the req.

What is the real difference between an SRE and a platform engineer? An SRE’s output is reliability of running systems: availability, latency, incident load. A platform engineer’s output is other engineers’ ability to ship unaided: time to stand up a new service, time from commit to production. Many people do both; the distinction sets what you review them on.

Can our best backend developer just do this part-time? For a quarter, with explicit time allocation and a written scope, yes, and it is often the right stopgap. Indefinitely, no. Product deadlines outrank infrastructure work, so the allocation quietly goes to zero while the accountability stays, and you lose a good developer tired of being blamed for the deploy process.

AB7 Solutions works both sides of this decision: recruitment and contract staffing for platform, infrastructure, SRE and IT roles when the answer is a hire, and managed cybersecurity and SOC support when the answer is coverage you cannot sustainably staff in-house. If you have run the tally and want a second read on which cluster it points to, send it to ab@ab7solutions.com or director@ab7solutions.com, call +1 321 341 7733, or see what we cover at ab7solutions.com.

Sources: US Bureau of Labor Statistics, Occupational Outlook Handbook, Software Developers, Network and Computer Systems Administrators, Computer Support Specialists, Information Security Analysts (wages May 2025, pages current 27 August 2026); BLS 2018 Standard Occupational Classification; DORA capability model and DORA on platform engineering; Google, Site Reliability Engineering, “Being On-Call”.