Every small engineering team knows the pattern. Someone in sales cannot connect to the VPN. The office printer has vanished from the network again. A new hire's laptop needs "setting up", which turns out to mean two hours of installing tools, joining the domain and chasing a licence key. And the person who ends up doing all of it is a developer, because developers are "good with computers" and the company has no one else.
Individually these interruptions look small. Collectively they are one of the most expensive line items an engineering organisation carries, and they almost never appear on any budget.
The cost is not the ticket. It is the context switch.
A twenty-minute password reset does not cost twenty minutes. It costs the twenty minutes, plus the time it takes to rebuild the mental model of the code the developer was in the middle of, plus the compound effect of being known as the person who fixes things, which means the next request arrives before the model is rebuilt. Studies on interruption recovery vary in their exact numbers, but every one of them agrees on the direction: fragmented attention is far more expensive than the sum of the fragments.
There is a second cost that is easier to miss. The developer doing ad hoc support is not doing it well, because it is not their job and they have no tooling for it. There is no ticket queue, so requests arrive by Slack DM and get lost. There is no asset inventory, so nobody knows which laptops are still on an unpatched OS. There is no standard build image, so every new machine is configured slightly differently and "works on my machine" stops being a joke. The team is paying senior engineering rates for amateur IT operations.
How it happens
The pattern usually starts at the founding stage, when the technical co-founder genuinely is the IT department and it takes ten minutes a week. Then the company grows. Headcount doubles, then doubles again. The support work grows roughly linearly with people, but nobody re-evaluates who does it, because it has always been "just something the dev team handles". By the time there are forty employees and six engineers, one of those engineers is effectively a part-time sysadmin without the title, the tools, or the authority to fix the underlying problems.
What makes this hard to unwind is that the arrangement looks free. There is no invoice for the developer's time. Hiring a dedicated IT person feels like a new cost, whereas the current cost is invisible. That is exactly backwards, and the fix begins with making the hidden cost visible.
Step one: measure it
For two weeks, have every engineer log the interruptions. Not a formal ticket system, just a shared note: time, what it was, how long it took. Include the "quick question" that took ninety seconds and the laptop rebuild that took an afternoon. Then multiply by loaded hourly cost and add a context-switch factor. Most teams that do this exercise discover they are spending somewhere between half a day and two days of engineering time a week on work that has nothing to do with the product.
Step two: separate the two jobs
Engineering infrastructure (CI pipelines, cloud environments, deployment tooling) belongs with the engineers. It is part of the product. End-user IT (laptops, identity and access, email, office networking, printers, backups of business data, security baselines) is a different discipline with different tools, and it belongs somewhere else.
That "somewhere else" has three options. Hire an internal IT administrator, which makes sense once there is enough daily volume to fill a role and enough budget for a salary plus the specialist help that person will still occasionally need. Assign it formally to an operations manager with a proper helpdesk tool, which works for very small companies but caps out quickly. Or contract it to a managed IT services provider on a fixed monthly scope, which is the route most companies in the twenty-to-two-hundred range end up taking, because it converts an unpredictable drain on engineering time into a predictable line item with a response commitment attached.
What "done properly" looks like
Whoever ends up owning end-user IT, the output should be the same, and engineers should insist on it because they are the ones who suffer when it is missing:
- A single identity provider with MFA enforced everywhere, so onboarding and offboarding are one action rather than a scavenger hunt across a dozen admin panels.
- A standard laptop image that a new hire receives on day one with the development toolchain already installed, so "setting up a machine" is a fifteen-minute handover rather than a lost afternoon.
- A ticket queue with a response SLA, so requests stop arriving as DMs to whichever engineer seems most awake.
- Patching and endpoint protection that runs without anyone remembering, with a report someone actually reads.
- Tested backups of business data, separate from the engineering team's source control and infrastructure-as-code, because the finance folder and the sales CRM export are not in git.
The last point deserves emphasis. Engineering teams are usually confident about backups because their code is in version control and their infrastructure is reproducible. That confidence rarely extends to the shared drive where the company's contracts live, and it is that drive, not the repository, that a ransomware incident goes after.
The conversation to have with leadership
The pitch is not "we need an IT person". The pitch is the number from step one: here is how much engineering time we are spending on end-user support, here is what that costs at our loaded rates, and here is what it would cost to have it done properly by people whose job it is. Providers such as Rezolva in Singapore, and their equivalents in other markets, publish their scopes and response commitments, which makes the comparison straightforward. In most cases the fixed cost is lower than the hidden one, and the engineering team gets its afternoons back.
Developers being "good with computers" is not a staffing plan. It is a symptom of a company that grew faster than its operating model. Fixing it is one of the cheapest productivity gains an engineering leader can make, precisely because the cost being removed was never counted in the first place.
