Lean IT

One person IT department: how to make it work

If you are a one person IT department for a company of a hundred people, the industry has plenty of opinions about you, most of them written by firms that would like to replace you. Here is a different claim, and this whole article is a defence of it: one person can run a modern estate properly, but only by refusing to run it the way a big team does, and by treating every manual task as a design fault.

The claim, stated properly

One person can run IT for a hundred or a hundred and fifty users to a standard most larger departments would recognise as good. Patched machines, backups that have actually been restored from, MFA everywhere, tickets answered within a business day, an asset register that reflects reality. None of that requires a team. It requires a person who refuses to do repeatable work by hand.

The distinction matters because the common failure of solo IT is not competence. People who run IT alone are usually generalists of a rare kind, comfortable across networking, endpoints, Microsoft 365 and whatever the finance system throws at them. When they fail, it is because they run a department of one as if it were a scaled down department of ten: the same interrupt-driven queue, the same hand-built machines, the same ad hoc fixes, with a tenth of the hands.

A big team survives that model because it has slack. Someone can go deep on a project while someone else absorbs the interrupts. A department of one has no slack to hide in, so the model itself has to change. The job stops being fixing things and becomes designing an estate that mostly does not need fixing. Every hour spent on a task a machine could do is not just an hour lost. It is an hour that will be lost again next week, and every week after that.

The maths that breaks the heroic model

Common staffing benchmarks put one IT person per sixty to a hundred users, depending on how messy the estate is. Read that as a warning, not a target. The benchmark describes how much manual work a conventional estate generates. It says nothing about how much of that work needs to exist.

Look at what actually fills a solo operator's week. Password resets that self-service could handle. Patch runs babysat by hand. A monitoring inbox where the tenth false alarm of the morning gets deleted on sight, which is exactly the failure we described in our piece on alert fatigue. A new starter set up from memory because the checklist lives in your head. None of this is the job. It is the interest payment on an estate that was never systematised.

Interrupt-driven work is also dearer than it looks, because every context switch has a re-entry cost and a department of one absorbs every interrupt personally. The queueing behaviour is the cruel part: when a single server runs close to capacity, wait times do not grow gradually, they explode. That is why solo IT feels fine at sixty percent load and catastrophic at ninety, and why "busy but coping" is usually the last stop before drowning.

Manual work scales linearly with headcount supported. Systems do not. That asymmetry is the entire argument, and everything below is an objection to it, taken seriously.

Objection one: "this is really an understaffing problem"

Sometimes it is, and it is worth being honest about the floor. If the business genuinely needs round-the-clock cover, carries heavy compliance obligations, or runs several sites that expect someone on the ground, one person cannot be the whole answer, and pretending otherwise just burns that person out. The argument is not that solo IT always works. It is that headcount is the wrong first fix.

Most one person IT departments that are drowning are not drowning in irreducible work. They are drowning in work that should not exist: resets without self-service, machines patched by hand, alerts nobody tuned, knowledge that lives in one head. Hiring into that fixes nothing. A second person doubles your capacity to do unnecessary work, and within a year you have a two person department that is also drowning, plus a salary. The order of operations matters: eliminate the work, automate what remains, then staff for the residue. If the residue still justifies a hire, hire with confidence, because the new person inherits a system instead of a pile.

Objection two: "a one person IT department has no time to standardise"

This objection gets the economics exactly backwards. Standardisation is not a luxury you buy once the fires are out. Variety is why the fires keep starting.

Every non-standard thing in an estate is a compounding cost. A snowflake laptop build means every incident on that machine starts with archaeology. Three PDF editors instead of one means three things to patch, licence and troubleshoot. Local admin rights granted "temporarily" two years ago are a malware surface nobody remembers approving. A big department can absorb variety with brute force. A department of one cannot, so it has to refuse the variety instead.

In practice that means one hardware standard per role on a predictable refresh cycle, one build deployed the same way every time, one approved application per job, and a default answer of no to one-off requests, with an honest path for the rare genuine exception. None of this needs a committee, and that is the solo operator's quiet advantage: there is no committee. You can decide the standard on Tuesday and enforce it on Wednesday. Say yes to every one-off instead, and you will never notice the moment the estate became unmanageable, because it happens one reasonable exception at a time.

Objection three: "unattended automation is too dangerous"

The fear is reasonable on its face. If an automated fix misfires at two in the morning, there is no colleague to catch it. But this objection compares automation to a perfect operator who watches everything, and that operator does not exist. The real comparison is automation with guardrails against an estate drifting unwatched while its one human is heads-down in a ticket.

The unattended risk you already run is far larger than the one you are worried about. Machines quietly months behind on patches. An endpoint whose antivirus lapsed after an update. A backup job that has failed nightly for weeks with nobody reading the report. Manual operation does not prevent any of this. It causes it, because one person's attention cannot be everywhere, and each of these fails silently.

So sequence the automation rather than refusing it. First, visibility: an inventory and monitoring baseline that tells the truth, so "I did not know" stops being a possible sentence. Second, alerting you actually trust, tuned hard enough that every alert means something. Only then remediation, and even then with guardrails: start with actions that are safe to repeat, roll changes to a small ring of machines before the fleet, and log everything so you can read at nine in the morning what happened at two. Built this way, automation is not a junior you cannot supervise. It is the only colleague a department of one can afford.

Objection four: "you cannot do security alone"

You cannot run a security operations centre alone, and you should not try. But most breaches of smaller organisations do not need a SOC to prevent, because they are not sophisticated. They walk in through an unpatched browser, a mailbox without MFA, a forwarding rule nobody noticed, or a machine whose protection silently stopped.

That list is tractable for one person precisely because it can be systematised. MFA enforced everywhere and legacy authentication off. Patching that covers third-party applications, not just Windows. A standing check that every endpoint really is protected, because the gap between "we bought antivirus" and "it is running and current on every machine" is where incidents live. Backups that get restore-tested rather than admired for their green ticks. And a hardened Microsoft 365 baseline, which is a checklist rather than a discipline: our ten-setting Microsoft 365 checklist is a workable start.

Hold that line and you are ahead of plenty of organisations with far larger teams, because these controls stop the attacks that actually arrive. Where outside help genuinely earns its keep is at the edges: an incident response retainer for the bad day, and after-hours cover if the business truly needs it. Buy those as insurance, not as a substitute for basics that only you are positioned to enforce.

Objection five: "what happens when you go on holiday?"

The bus factor is the most honest objection, and it is aimed at the wrong target. The risk was never that IT is one person. The risk is that the estate exists only in that person's head. A heroic department of one really is dangerous to its business: undocumented, irreplaceable and one resignation away from chaos.

A systems-run department of one is the opposite, because the system is the documentation. The asset register is live rather than a spreadsheet from March. Patch state, protection state and backup state are visible on a screen anyone can read. The runbooks are not prose in a wiki, they are the automations themselves, and they keep running whether or not you are on a beach. What remains to write down is small: escalation contacts, the credentials process, and the reasoning behind your standards. Add one arrangement for cover, a retainer with a local provider or a reciprocal agreement with another solo operator, and the holiday question is answered better than many mid-sized departments answer it.

Then hold yourself to the test this whole argument implies. Each month, ask what share of issues resolved without you touching them, and how much of your time went on work only you could have done. A one person IT department run on heroics watches those numbers stand still. One run as a system watches the first climb and the second shrink toward the work that genuinely deserves a human.

Where this fits with Helios

Helios was built on the premise that leverage should come from the platform, not from headcount. One lightweight agent provides the live inventory, patch state including third-party applications, protection gap detection and backup monitoring this argument depends on. The service desk and client portal give the people you support a proper front door, and Helio, the AI layer, triages tickets, investigates devices and resolves routine failures on its own, with every action logged for you to read the next morning. A one person IT department is not an edge case for us. It is close to the design brief.