The question of whether to hire another operations engineer or sign a managed infrastructure contract is usually answered with a two-column spreadsheet and a conclusion that was decided in advance. That spreadsheet almost always omits three things: how long a new hire takes to become genuinely useful, the arithmetic of covering hours outside the working day, and what happens when the person who understands the systems best resigns.
This article deliberately contains no figures. Salary, allowance and service pricing all vary by city, sector and moment, so any number printed in an article will be wrong for your situation. Instead it builds a model with variables you fill in from your own recruitment and finance data, then covers the non-monetary factors the model cannot capture — on both sides of the decision.
Building the model: the variables you supply
Define the variables first. Take them from your HR system, your accounts and real quotations, not from memory or from articles.
- C — fully loaded annual cost of one operations engineer: salary, mandatory contributions, bonus, equipment, software, workspace, training. This is the accounting number, not the offer-letter number.
- N — the number of engineers needed to cover your operational scope at a standard you accept, including leave and public holidays.
- R — months a new hire needs to reach full productivity on your systems. Estimate from your last hire, not from your hopes.
- H — average time from opening a role to the new person starting, including their notice period at their current employer.
- A — annual attrition for technical roles in your organisation, taken from the last three years if you have them.
- M — management hours per month this team consumes from a lead or CTO: hiring, reviews, rota disputes, approvals.
- V — annual managed service fee from a real quotation, plus onboarding fees and charges for out-of-scope work.
- K — your internal cost of working with a vendor: a coordinator, review meetings, time spent writing requirements. This is never zero and is routinely forgotten.
With those, the in-house side costs roughly N × C plus the monetised value of M, plus the hidden cost of R and H every time someone is replaced. The outsourced side costs roughly V + K. The important point is that the two sides do not carry the same kind of risk, so comparing totals alone is not enough.
The arithmetic of 24/7 coverage
This part is pure arithmetic, independent of any market, and it is the part most often misjudged.
A week contains 168 hours. One full-time engineer covers roughly 40 of them. If you want someone actually on shift across the whole week, simple division already shows you need more than four people before you account for leave, holidays, sickness and training. If you use an on-call model rather than staffed shifts, the numbers are kinder but the constraint remains: for nobody to be on call more than one week in four or five, you need at least four to five people capable of handling your most severe incidents.
The load-bearing word is capable. A rotation is only worth what it can resolve. If the person on call can receive an alert but must phone someone else to fix anything serious, you do not have a rotation — you have one permanently on-call engineer and five people forwarding calls.
Try this test: list your last three severe incidents and write down who actually resolved each one. If all three are the same name, your in-house cost model counts N people while your resilience depends on one.
Ramp time and recruitment difficulty
R is usually set far too low. A strong engineer can learn the tooling in weeks, but learning your environment — the historical quirks, the things that have broken before, why a strange configuration exists — takes considerably longer. During R the new hire also consumes existing engineers’ time answering questions, so real cost in the first months exceeds nominal cost.
H is rarely added correctly either. Time from deciding to hire to receiving useful output is H + R, not H. If you have committed to a plan that assumes the team will be at strength next quarter, re-check it against H + R.
On recruitment difficulty, one point can be made without any figures: infrastructure operations roles compete for the same people as software engineering roles and as every other technology employer in your city. If your organisation is not itself a technology company, you are hiring in a market where you are not the most attractive employer, and that belongs in your estimate of H rather than in your optimism.
Knowledge retention and bus factor
Bus factor is the number of people who would have to leave before a system becomes unoperable. For many small in-house teams the answer is one. This is the most serious risk in the in-house model, and it never appears on the cost line.
It is reducible, but only by spending real effort:
- Runbooks written for someone who has never touched the system, validated by having a different person follow them.
- Rotating incident ownership even when letting the expert do it would be faster today.
- Recording architectural decisions with their reasoning, because the reasoning is what leaves when a person does.
- Regular restore rehearsals performed by someone who did not build the system.
If you do none of this, your in-house model carries hidden debt. In fairness, outsourcing does not automatically clear it. If your vendor also has exactly one engineer who understands your environment, you have moved the bus factor into another organisation and lost the ability to see it. That is precisely the question to ask any vendor directly.
What outsourcing does worse
This section matters more than the previous one, because it is rarely written by the party selling the service. Managed infrastructure has four systematic weaknesses, and a good contract does not make them disappear.
- Loss of business context. An in-house engineer knows the last Friday of the month is closing day and knows which system must not be touched then. An external engineer knows this only if someone wrote it down and handed it over. Most business context has never been written down.
- Escalation friction. Internally you walk to a desk. With a vendor you open a ticket, wait for triage, re-explain the context, and may reach a different person than last time. Each step is small; together they slow down exactly the hard incidents where speed matters most.
- Dependency. After a few years, operational knowledge lives outside your organisation. If the contract carries no documentation and handover obligations, you have created a lock-in with a high exit cost. This has to be solved in the contract, not with goodwill.
- Slower response to ad-hoc work. A small request outside the agreed scope tends to take far longer than asking a colleague to spend ten minutes on it. If your business generates many such requests, the outsourced model will frustrate you regardless of how good the vendor is.
The two sides side by side
| Factor | In-house team | Managed service |
|---|---|---|
| Direct cost | N × C, moves with the labour market | V, fixed by contract for the term |
| Hidden cost | H + R per replacement, M management hours | K coordination hours, out-of-scope fees |
| Out-of-hours cover | Needs at least four to five capable responders | Per the agreed service commitment |
| Staffing risk | Bus factor is often one | Moved to the vendor; verify it |
| Business context | Strong, held in people’s heads | Weak unless written down and handed over |
| Ad-hoc speed | Fast, no process required | Slower, bounded by contract scope |
| Exit cost | Low contractually, high if people leave | Depends entirely on handover terms |
When keeping the team in-house is the right answer
There are clear cases for keeping operations in-house, and a vendor arguing honestly should say so.
- Your infrastructure is so entangled with your business that every operational action requires business judgement, not only technical judgement.
- You already have four to five engineers capable of handling severe incidents, and your attrition rate A is low and stable.
- Unplanned ad-hoc requests are frequent, and the value is in response speed rather than in round-the-clock availability.
- Internal policy or compliance requirements mean granting a third party access creates more risk than it removes.
If three of those four hold, invest in your team instead: write the runbooks, widen the pool of capable responders, and reduce the bus factor. That is better spending than a contract signed to avoid an organisational problem.
The hybrid model is usually the realistic answer
In practice the boundary is rarely all or nothing. A common structure: the in-house team keeps architecture, relationships with business stakeholders, and any action requiring context; the vendor takes overnight cover, routine patching, monitoring and repeatable procedural work. This keeps business context inside the company while solving the hardest part of the in-house model, which is out-of-hours coverage.
The hybrid only works if the responsibility boundary is sharp enough to write as sentences: who decides, who executes, who is called at two in the morning, and what happens when the two sides disagree. If the boundary is vague, you pay both sides and neither truly owns the outcome.
Running the comparison once and finishing it
Fill in C, N, R, H, A and M from your own data. Take V and K from real quotations, not estimates. Then run two scenarios: a normal one, and one in which your strongest operations engineer resigns next month. The second scenario is the more reliable basis for a decision, because it happens more often than anyone admits.
If the two scenarios point to opposite conclusions, your problem is not cost but concentration risk, and it should be addressed before you choose a model at all.
How HiTechCloud can help
HiTechCloud provides managed infrastructure and software development services, is an AWS partner and a Google Premier Partner, and operates in-country infrastructure for customers with data location requirements. We can work through the model above with your team using your real numbers, identify which parts of the operational load transfer well and which should stay with you, and scope a service to that boundary. If the result says you should hire rather than contract, we will say so.
