In July, your DevOps engineer had a quiet month. The pipelines ran. Nothing caught fire. They tidied some Terraform, updated a runbook nobody has read since, and answered four access requests. It was, by any reasonable measure, a good month.
You paid for 160 hours of it.
This is not an article about lazy engineers. The engineer in that story did nothing wrong — infrastructure work is supposed to be quiet when it is going well, and a calm July is the product of someone doing their job properly in March. The ghost on your payroll is not a person. It is the gap between the capacity a salary buys and the capacity the work actually asks for, and it is almost always much larger than anyone expects, because nobody ever measures it.
So let's measure it.
The bill you can see, and the one you can't
The visible number is the salary. A senior DevOps engineer in a competitive market runs $150K–$200K+ once you load in benefits, equipment, recruiting fees and payroll tax — we broke that figure down in The True Cost of a Full-Time DevOps Engineer, and this article deliberately does not repeat that arithmetic.
The invisible number is simpler and, once you see it, harder to unsee. A full-time hire is a commitment to buy roughly 160 hours every month, 1,920 hours a year, at a flat rate, in advance, regardless of what the year turns out to need. You are not really buying an engineer. You are buying a fixed block of capacity and hoping the work turns up in the same shape.
It never does.
Infrastructure work is spiky, and salaries are flat
Think about what actually generates DevOps work over a year. A compliance audit. A cloud migration. A product launch that triples traffic. An incident that eats a fortnight. A new region. A database version that goes end-of-life. Every one of those is an event, not a constant — and between them are long stretches where the correct amount of infrastructure work is "keep it running and don't touch anything before the holiday freeze."
Plotted over twelve months, the work is not a line. It is a heartbeat. And the mismatch between that heartbeat and a flat salary is where the money goes.
A worked example: one year, one platform
Here is a full year for a Series A company with about eighteen engineers, a production Kubernetes cluster, a SOC 2 deadline and a cloud migration — a shape we see constantly. The bars are the hours the infrastructure genuinely required each month. The dashed line is what a single full-time hire costs you every month whether the work is there or not.
Three things that chart is telling you
1. You are paying for the white space
The grey area above the bars is the product. It is 1,050 hours of purchased capacity that no piece of work ever claimed — more than half the year's payroll for that role, spent on availability rather than output. With a service you buy the bars instead: 870 hours instead of 1,920. That is the entire cost argument, and it does not depend on anyone's hourly rate being cheap. It depends on not buying the white space.
And note where the savings actually come from. Nobody is working harder or faster in this model. The work is identical. You have simply stopped pre-purchasing the quiet months.
2. Flexible hours means the quiet months are allowed to be quiet
May, June, July and November in that chart total 105 hours between them — about two-thirds of a single month's salaried capacity, spread across four months. On a service you scale down to a maintenance floor for that stretch and scale back up in August, month by month, without a conversation about headcount.
This is the part that is hard to replicate with an employee, and not for any technical reason. You cannot ask a salaried engineer to work a 25-hour August and a 210-hour September. You cannot furlough someone for a quiet quarter and expect them to be there, motivated, when the migration lands. The flexibility is not a billing detail — it is the only arrangement under which "we need less this month" is a neutral sentence rather than a threat.
3. Scaling works in the direction that actually hurts
Everyone frames scaling as growth, so the August bar is the one worth staring at. That month needed 210 hours. One engineer cannot supply 210 hours in a month — not sustainably, and not while also being on call for the thing they are migrating. The red band is not a budgeting inconvenience; it is the month your migration slips, or your one engineer burns out, or both.
A single hire is a capacity ceiling as well as a capacity floor. When the work exceeds one person, the options are contractors hired in a hurry, a slipped date, or a quiet erosion of the person you have. A service that puts two dedicated engineers on every engagement as a minimum, with specialists rotating in for the work that needs them, absorbs that month as a scheduling question instead of a crisis.
The same asymmetry applies to holidays, notice periods and illness. One engineer going on leave in August is a problem no budget line solves.
What you give up, honestly
A full-time hire buys things this model genuinely does not. They are in the room for the conversation where the architecture gets decided. They accumulate context about your product that nobody writes down. They own the thing in a way a contract cannot quite reproduce, and at a certain scale that ownership is worth more than the utilisation gap.
Our own read on where the line sits: below roughly twenty engineers, a dedicated DevOps hire will spend most of their time waiting for something to break. Past fifty, and especially once infrastructure work stops being spiky and becomes genuinely continuous, the bars start filling the band — and when your chart no longer has white space in it, hiring is the right answer and we will tell you so.
The useful question is not "service or employee." It is: what does my next twelve months actually look like, and do I know? Most companies have never plotted it. The ones that do are often surprised by how much of the year is May.
How this gets billed in practice
Three shapes, depending on which of the above is your problem. Hourly from a 20 h/month floor, scaled up or down each month — that is the chart above, bought as drawn. Project-based with a fixed scope and price for the August-shaped events: a migration, a compliance push, a CI/CD rebuild. Performance-based for long-term partnerships, where part of what we earn is tied to the infrastructure metrics you care about. All three include two dedicated engineers, a shared Slack channel and a monthly infrastructure report; details are on the pricing page.
What none of them include is a bill for July.