Before you hire a DevOps engineer, work out whether you have a people problem or a platform problem. Most teams posting a DevOps role have five engineers each solving deployment slightly differently, and they’re hoping a hire will unify it. That’s a platform problem. A single hire dropped into it becomes a ticket queue, gets no authority to change how anyone works, and leaves inside two years.
That’s not a reason never to hire. It’s a reason to be specific about what you’re hiring for, because the failure mode here is expensive and slow to detect. You’ll spend three to nine months recruiting, pay well above the median engineering salary, and discover in month eight that the person you hired has become a human API for AWS console access.
This covers what the role actually is now, what it costs, the spec and interview that select for the right thing, and the three situations where a contractor is the better purchase.
Key takeaways
- The role has fragmented. “DevOps engineer” now covers at least four distinct jobs. Hiring without picking one is the root cause of most bad outcomes.
- The market has largely moved to platform teams. DORA’s 2025 research found 76% of organizations have dedicated platform teams and 90% report using an internal developer platform.
- US median total compensation is $165,000 for DevOps engineers (Stack Overflow 2025 Developer Survey, n=23,928 salary responses).
- The real cost is often estimated at 3–4x salary once recruiting, ramp and overhead are counted — a rule of thumb, not a measured figure.
- Median US employee tenure was 3.9 years at the last BLS reading, the lowest since 2002 (BLS). Plan for the knowledge to leave.
- A tooling list is not a job spec. If your requirements section is 14 product names, you’re screening for tool familiarity rather than judgment.
First: which of the four jobs are you hiring for?
“DevOps engineer” stopped being one role some time ago. These four get advertised under the same title and need different people.
| The actual job | What they do | Hire when | Mis-hire looks like |
|---|---|---|---|
| Platform builder | Builds the paved road: golden paths, self-service provisioning, internal tooling | Multiple teams each solving deployment differently | You hired an operator who maintains rather than builds |
| Infrastructure operator | Runs clusters, manages IaC, handles capacity, patches | You have a platform and need it operated reliably | You hired a builder who rewrites everything and gets bored |
| Reliability engineer (SRE) | Owns SLOs, incident response, error budgets, postmortems | You have real availability requirements and a pager | You hired a toolsmith who’s never carried a pager |
| Release / CI specialist | Owns the pipeline, build performance, test infrastructure | Builds take 40 minutes and everyone has stopped caring | You hired a generalist who deprioritises this forever |
Most job posts describe all four and pay for one. The candidates who match all four exist, are rare, and are not applying to your posting.
The diagnostic question: if this person joined tomorrow and did nothing but their single most valuable activity for six months, what would that be? If you can’t answer, you’re not ready to hire, and Obsium’s breakdown of SRE vs DevOps and platform engineering vs DevOps is a better next read than a job board.
Why “we need a platform, not a person” is usually true
This isn’t a rhetorical flourish. The industry has already moved.
In November 2023, Gartner predicted that “by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery” (Gartner press release).
It’s now 2026 and we can check. DORA’s 2025 research reports 76% of organizations have dedicated platform teams and 90% report using an internal developer platform (DORA). Gartner was close to right.
The relevant part for a hiring decision is what DORA found about quality rather than existence:
“When platform quality is high, the effect of AI adoption on organizational performance becomes strong and positive. Conversely, when platform quality is low, the effect of AI adoption on organizational performance is negligible.” — DORA, platform engineering capability
Platforms aren’t a binary you either have or don’t. A bad one produces roughly nothing. And a single DevOps hire with no mandate, no budget, and no authority over how other teams work is the standard way to produce a bad one.
DORA also raises the counterpoint honestly: platforms improve productivity but can decrease throughput and change stability when implemented badly. So “hire someone to build a platform” is not automatically safer than “hire someone to run things.” The variable is mandate, not headcount.
Key insight: The question isn’t “should we hire a DevOps engineer.” It’s “does the person we hire get to change how other teams ship, and does anyone senior back that up?” If the answer is no, you’re hiring an operator, and you should write the spec for an operator instead of pretending otherwise.
What it costs
Two credible sources, deliberately different in method.
Stack Overflow 2025 Developer Survey (work section), self-reported by ~49,000 developers with 23,928 usable salary responses:
| Role | US median total comp | Global median |
|---|---|---|
| DevOps engineer / professional | $165,000 | $87,011 |
| Cloud infrastructure engineer | $189,000 | $103,112 |
Robert Half 2026 Salary Guide (DevOps engineer), recruiter-side data with seniority bands:
| Band | US salary |
|---|---|
| Low (new / limited experience) | $118,000 |
| Midpoint | $145,750 |
| High (extensive experience, advanced skills) | $173,750 |
A note on sources, because this market is full of invented numbers. The BLS has no “DevOps engineer” occupation code — anyone citing BLS for a DevOps salary is citing Software Developers ($135,980 median, May 2025) and relabelling it. And there is no published 2026 Dice or Stack Overflow salary data yet; the 2026 Stack Overflow survey only opened in June 2026.
Then multiply. SHRM puts average cost-per-hire at nearly $4,700. In the same article, HR strategist Edie Goldberg notes that many employers estimate the total cost to hire at three to four times the position’s salary, once you count recruiting, onboarding, ramp time, and the productivity cost to everyone helping them ramp. On a $145,750 midpoint that implies a first-year cost between $437,000 and $583,000.
Two caveats on that range: the multiplier is a practitioner rule of thumb rather than SHRM benchmarking data, and the article dates from 2022. Treat it as an order of magnitude.
That range is the one worth putting in front of whoever approves the req, because it changes the build-versus-buy conversation completely.
And plan for departure. As of January 2024, the most recent BLS release, US median employee tenure was 3.9 years, down from 4.1 in 2022 and the lowest since January 2002; private sector was 3.5 years (BLS Employee Tenure Summary). If your platform knowledge lives in one person’s head, you have a 3.5-year fuse on it.
Warning: On time-to-hire, be skeptical of everything you read. The best primary series for days-to-fill (the DHI-DFH Mean Vacancy Duration measure) was discontinued around 2018, and every “average DevOps time-to-hire in 2026” figure online traces back to unsourced SEO content. Budget from your own hiring history, not a benchmark someone made up.
Writing a spec that isn’t a tooling list
The most common DevOps job post is fourteen product names and a salary band. It selects for people who have used fourteen products, which correlates weakly with people who can make your deployments work.
Replace tool requirements with problem statements.
Instead of: “Experience with Terraform, Kubernetes, ArgoCD, Helm, Prometheus, Grafana, Jenkins, GitHub Actions, Vault, Istio, Datadog, AWS, Docker, and Linux.”
Try: “Our six services deploy four different ways, three of them undocumented. We want one paved path that teams choose because it’s easier, not because it’s mandated. You’d own that.”
The second version is harder to write and does three things the first doesn’t. It filters out people who want a maintenance job. It attracts people who want that specific problem. And it tells a good candidate whether you actually understand your own situation, which is the thing strong candidates are screening you for.
Include in the spec:
- The single most valuable thing this person will do in the first six months
- Who owns the platform decision when engineering disagrees
- Whether the role carries a pager, and what the rotation looks like
- Team size and where the role sits
- What’s already built and what’s greenfield
- Honest assessment of the mess (candidates find out in week two anyway, and the good ones respect it)
Leave out: any tool that could be learned in a fortnight, years-of-experience numbers that don’t map to anything, and “DevOps ninja.”
Interviewing for judgment rather than tool recall
Tool knowledge is cheap to verify and nearly worthless as a signal. These questions separate operators from people who have read about operations.
1. “Walk me through the worst production incident you’ve been involved in. What did you get wrong?”
The best answer includes a specific mistake and what changed afterward. Candidates who have only read about incidents describe processes. Candidates who have lived through them describe decisions made with insufficient information at 3am.
2. “A team wants to bypass the platform and deploy their own way. How do you handle it?”
Tests whether they understand platform work as a product problem. “I’d escalate” and “I’d block them” are both weak. The strong answer involves finding out why the platform didn’t serve them.
3. “How would you find out what our Kubernetes workloads actually cost?”
An excellent filter, because the honest answer is inconvenient: the cloud bill stops at the node, and namespace-level attribution needs cluster telemetry joined to node pricing. Candidates who say “check Cost Explorer” haven’t done it.
4. “What’s something you built that you’d now do differently?”
Selects for people who have operated their own work long enough to regret it.
5. “How do you decide what to alert on?”
The bar is whether they distinguish symptoms from causes, and whether they mention deleting alerts. Most infrastructure engineers have never removed one. Obsium’s take on why Kubernetes alerts are useless covers the territory.
6. “What would you want to change in your first month, and what would you deliberately leave alone?”
The second half matters more. Restraint is the rarer trait.
Skip: whiteboard algorithm questions, trivia about flag syntax, and “explain the difference between a Deployment and a StatefulSet.” Any of those can be looked up in eleven seconds by someone who’s never run either in production.
When a contractor beats a hire
Three situations, and they’re more common than the hiring reflex suggests.
1. The work is bounded and you’ll only need it once.
A migration, a cluster rebuild, a compliance push, an initial platform build. Hiring permanently for temporary work means finding something for that person to do afterward, which is how operators become ticket queues.
2. You need a capability you can’t evaluate.
If nobody internally can assess Kubernetes architecture, you also can’t interview for it. Bringing in someone experienced to do the work and build your team’s judgment is a better sequence than hiring blind and hoping.
3. You need it now and the market is slow.
The Linux Foundation’s 2026 State of Tech Talent report characterises the current situation as a skills crisis rather than a jobs crisis, with organizations prioritising upskilling over external hiring. If a critical migration is blocked, waiting two quarters for the perfect hire has a cost too.
When to hire instead: the capability is permanent, it’s differentiating for your business, and someone senior will back the mandate. Those three together justify the $437K–$583K first-year number. Two out of three usually doesn’t.
If you’re weighing the ongoing version of this, DevOps managed services covers what an operations contract does and doesn’t include.
Hire, contractor, or managed service
| Hire | Contractor | Managed service | |
|---|---|---|---|
| Best for | Permanent, differentiating capability | Bounded work, or capability you can’t evaluate | Commodity operations you’d rather not staff |
| Time to productive | 3–9 months including recruiting | Days to weeks | Weeks |
| First-year cost | Commonly estimated at 3–4x salary | Day rate × days, visible | Monthly retainer |
| Knowledge lands with | The person, until they leave | Your team, if the SOW requires it | The provider |
| Main risk | Ticket-queue drift, departure at ~3.5 years | Ends before knowledge transfers | Permanent dependency |
| You need | A mandate and a sponsor | A clear scope | An internal owner of the relationship |
What to take away
- Diagnose before you recruit. Platform problem or people problem — they need different hires.
- Pick one of the four jobs. Specs describing all four attract candidates matching none.
- Budget well above salary. The $165K median is the smaller half of the number.
- A tooling list screens for the wrong thing. Write the problem instead.
- Interview for judgment, not recall. The incident question is the most informative ninety seconds you’ll spend.
- Plan for a 3.5-year fuse. Knowledge in one head is a risk, not an asset.
- Mandate beats seniority. A capable hire with no authority to change how teams ship will not change how teams ship.
The most useful outcome of a hiring process is sometimes deciding not to hire. If the honest problem is that nobody owns how software ships, no candidate fixes that, and the good ones will spot it in the interview and take the other offer.
Where Obsium fits
We’re frequently brought in by teams who’ve had a DevOps req open for five months. Sometimes the right answer is to help them close it faster. Often it’s to build the platform first so the eventual hire inherits something worth operating, and so the job spec can finally describe a real job.
If you’re in that position, book a free 30-minute consultation. No sales deck. An engineer will look at your setup and tell you whether you need a person, a platform, or neither yet.
Related reading: SRE vs DevOps · Platform engineering vs DevOps · Platform engineering explained · DevOps managed services · Top DevOps consulting companies · DevOps metrics that actually matter
FAQs
What does a DevOps engineer actually do?
It depends which of four jobs you’re hiring for: building an internal platform, operating existing infrastructure, owning reliability and incident response, or owning CI/CD and build performance. Job posts routinely describe all four. Pick one before you write the spec.
How much does it cost to hire a DevOps engineer?
US median total compensation is $165,000 (Stack Overflow 2025), with Robert Half’s 2026 guide banding it $118,000 to $173,750 by experience. A widely-used rule of thumb puts the fully-loaded cost of a hire at three to four times salary, implying $437,000–$583,000 for a midpoint hire’s first year. That multiplier is an estimate rather than a measured benchmark, so treat it as an order of magnitude.
Should we hire a DevOps engineer or a platform engineer?
If multiple teams each deploy differently and you want one supported path, that’s platform engineering. If you have a working platform that needs running reliably, that’s an infrastructure operator. The titles overlap in the market; the jobs don’t.
How long does it take to hire a DevOps engineer?
There’s no credible public benchmark. The primary data series for days-to-fill was discontinued around 2018, and current figures online are unsourced. Use your own hiring history. Three to nine months including recruiting and ramp is a realistic planning assumption.
Is it better to hire a DevOps engineer or use a contractor?
Contractor when the work is bounded, when you can’t evaluate the capability internally, or when you’re blocked now. Hire when the capability is permanent, differentiating, and backed by a real mandate. The mandate matters more than the seniority.
What should I ask in a DevOps interview?
Ask about a real incident and what they got wrong, how they’d handle a team bypassing the platform, how they’d find out what workloads cost, and what they’d deliberately leave alone in month one. Skip tool trivia — it’s cheap to verify and predicts little.
Do we need a DevOps engineer if we’re on managed Kubernetes?
Managed control planes remove one category of work and none of the others. You still own workload configuration, cost, security posture, deployment tooling, and incident response. Managed Kubernetes reduces the operational floor; it doesn’t remove the role.
What’s the biggest mistake teams make hiring for DevOps?
Hiring one person to fix an organizational problem. If the underlying issue is that no team is accountable for how software ships, a hire without authority becomes a ticket queue and leaves. Fix the mandate first, then hire into it.
