In House IT or an Outside Provider

Two things decide it. How much technical work your business generates in a normal week, and how many different kinds of work that is. Volume argues for hiring somebody. Variety argues against it, because one person cannot stay current on email, networks, backup, security and whatever your main business application happens to be.

So the rough shape is this. If the work is steady, mostly the same sort of thing, and there is enough of it to fill somebody's week, an employee is often the better buy. If it arrives in bursts, covers a lot of ground, and a good share of it is specialist, an outside team usually is. Plenty of businesses sit between the two and end up with a bit of both.

We are an outside provider. That is our commercial interest and you should read the rest of this knowing it. What follows is what we would say to a friend who asked us over a coffee, including the parts that argue against hiring us.

Presence, first. Somebody in the building hears the complaint before it becomes a ticket. They notice the machine in dispatch making a noise it did not make last month. They walk past a desk and see somebody working around a fault they never bothered to report. No ticket system will ever show you that entire category of problem.

Then context. An internal person learns your calendar. They know that the last three days of the month are the ones where nothing can go wrong in finance, that the warehouse system matters more than the website on a Friday, and which member of staff always rings at half past four with something that turns out to be urgent. An outside team builds that knowledge more slowly and never quite as well.

There is also priority. Your work is the only work they have, so nobody else's outage can push you down a queue. And an employee can push back on a supplier in a way a provider sometimes will not, because the provider has its own relationship with that supplier and you are one of several clients on the call.

Cover is the obvious one and it is worse than people expect. Holidays, illness, a training course, a resignation with a month's notice and nobody hired yet. During any of those your entire technical capability is unavailable, and problems do not schedule themselves around annual leave. Businesses handle this by ringing somebody in a hurry at a rate they never budgeted for.

Depth is the quieter failure. Nobody is good at everything. The firewall gets configured by somebody who last configured a firewall years ago, and it works, and nobody looks at it again. The backup runs because the person who set it up believes it runs. Ask one person to be five specialists and this is what you get, whatever their ability.

Then the career problem, which employers underrate badly. Good engineers leave when they stop learning, and a single engineer alone in a business with nobody to compare notes with stops learning fairly quickly. You lose them, and everything they knew goes with them, because none of it was ever written down. It was never written down because they were the only person who needed it.

Distance. We see tickets. We do not see the shop floor, the sighing, or the spreadsheet somebody built because the real system is too slow. If nobody reports a thing, we do not know about it, and plenty of businesses carry long running irritations that never once appear in a ticket because everyone assumed it was normal.

Queueing is real too. Your urgent competes with somebody else's urgent, and on a bad morning both are genuine. A good provider will tell you honestly how it decides that order. A less good one says you are always first, which cannot be true for every client on the list.

The incentives deserve a plain word. A fixed monthly fee rewards a provider for having fewer tickets, which pushes them towards fixing causes properly. It also rewards them for doing less, if nobody is checking. Billing by the hour flips both effects. Neither model is dishonest. You just need to know which way the pressure runs in yours, and keep an eye on the direction it pushes.

The last one is drift. Unless somebody is paid to think about your business between tickets, nobody does. Months pass, the setup ages, and everything stays technically fine while slowly becoming a mess. That is a contract problem more than a people problem, and it is fixable, but only once you notice it.

Salary against monthly fee is not a fair sum, and it is the sum everybody does. On the employee side you also carry employer costs, recruitment, the tools they need, training to keep them current, and cover for the weeks they are away. On top of that you will still call a specialist in for the firewall, the phone system or the accounts software, because one person will not be able to do all of it.

The provider side has its own missing pieces. A monthly fee usually covers running things and excludes projects, so the honest comparison is the fee plus a normal year of project work. Ask what a normal year of project work has looked like for clients of your size. If nobody can tell you, that is worth knowing before you sign anything.

The cost that appears in neither column is the work that does not happen. One internal person spending their whole week on tickets is one internal person who never gets to the improvements that would reduce the tickets. That cost is invisible, it compounds, and it is usually larger than the difference between the two options.

Do the sums honestly and the two totals tend to land close enough that money does not decide it. What decides it is risk, and what you want the person doing with their week.

One internal person with an outside team behind them. The employee owns the relationship with the business, handles the day to day, and knows everyone by name. The provider carries the depth, the out of hours cover, the projects and the holiday weeks. Each side supplies what the other is short of.

It fails in exactly one way, and it fails that way almost every time. Nobody writes down who owns what, so both sides assume the other is watching the backups. Then something breaks and the conversation afterwards is about whose job it was. The fix is dull and it works: a written split, system by system, naming which side monitors it, which side patches it, and who gets called first when it stops.

There is a mirror version worth knowing about. The provider runs everything technical and the internal person is a coordinator rather than an engineer. They translate between the business and the provider, own the priorities, and check the work. That suits businesses where the technology is fairly standard and the internal politics are not.

Take a fortnight and note every technical job as it happens, including the ones people quietly solve themselves. Then sort that list twice. Once by how often each thing happens, and once by whether an ordinary competent generalist could do it or whether it needs somebody who does that particular thing regularly. The shape of those two sorts tells you most of what you need.

A long list of frequent, ordinary jobs argues for an employee. A shorter list with a heavy specialist tail argues for a team. A list where half the entries need somebody physically standing next to a machine argues for at least one person in the building, whatever else you decide.

Then ask the three questions people skip. What happens during the week your person is away. What happens the month after they resign. And is there genuinely enough interesting work to keep a capable engineer, because a bored engineer is a leaving engineer and you will be running this exercise again next year.

If you already have a good internal person who is not drowning, and the work sits mostly within their range, adding a provider on top tends to produce two parties doing the easy half and nobody owning the hard half. In that situation we would rather sell you a specific piece of work, or cover for nights and holidays, than a full contract you do not need.

If nearly all of your technical life runs through one business application and that vendor supports it properly, a full managed contract is often insurance against a risk the vendor already carries. Check what your software supplier actually covers before paying somebody else to cover it again.

And if the reason you are considering a change is that your current provider is poor, changing the category is not the fix. You may be about to spend a great deal of effort arriving at the same place. Work out first whether the problem is the people, the scope you bought, or a price tier that was never going to deliver what you expected. Sometimes the contract was wrong and the provider was fine.

Where we do think we are the right answer, we will say why in terms of the work rather than the package, agree the scope and the price before anything starts, and put you in a room with the people who would actually do it.