I am the IT department. Not the head of it — the whole thing. Hundreds of people, a fleet of laptops, one of me.
That arrangement works, but not because I'm fast. It works because after four years I stopped trying to watch the fleet and started building things that watch it for me, and — more importantly — learned which of those things were worth trusting.
This is what that actually looks like. Not a tooling list. The three habits that made a two-person job into a one-person job.
1. The work that repeats has to stop being work
People joining and leaving is not an occasional event in my week. It's the background hum of the job — the thing that's always in progress, usually more than one at a time.
Onboarding is the obvious half. Account, groups, licenses, device, agent installs, asset record, the welcome message, the manager's "is she set up yet?" — none of it hard, all of it sequential, every step a place to get interrupted and lose your spot. Done occasionally, that's annoying. Done constantly, it's a second job.
The fix wasn't a better checklist. It was making the checklist the system: a joiner/mover/leaver workflow where each step is a tracked item that knows what it's waiting on. The time saved is the less interesting half. The half that matters is that I can be interrupted mid-onboarding — and I am always interrupted mid-onboarding — and lose nothing, because the state lives in the queue instead of in my head.
Offboarding got the bigger win, because offboarding is where solo IT quietly accrues risk. A departure touches four systems, and the failure mode isn't dramatic — it's the one system nobody remembers, six months later, still holding an active credential. Nobody notices that. There's no ticket for it. It just sits there.
Encoding the teardown as four tracked steps with checkboxes means "did we actually remove them everywhere" has an answer instead of a feeling. When you're the only one who could have done it, "I'm pretty sure I got it" is not a control.
The best ticket is the one that never gets filed. Two things did more for my ticket volume than any macro or template ever has: giving people a self-serve intake instead of a Slack DM, and sitting down with someone once and actually walking them through a thing, instead of quietly fixing it for them every time it comes up. The first cuts the noise. The second cuts the recurrence — a five-minute walkthrough now is a dozen future tickets that don't happen.
2. The platform does most of it. Vendor fluency finishes the job.
Reconciling device state by hand — checking a device-management console, then an endpoint-security console, then an asset spreadsheet, one device at a time — does not scale to one person on a fleet this size. So I stopped doing it by hand. The audit system I built cross-references every vendor in the stack against every other one automatically, and flags only what actually disagrees. Most of the week that used to be manual reconciliation is now a report I read.
That's the honest split, and it's the one worth being precise about: the platform carries the reconciliation. It doesn't carry the judgment. Every vendor has its own definition of "healthy," its own reporting lag, its own quirks in how a re-enrolled or renamed device shows up in its console. The system tells me two sources disagree. Whether that disagreement is a real problem or just how a particular vendor's sync behaves — that's still me. No dashboard replaces knowing your vendors' actual behavior, not just their marketing docs.
That's the part I'd tell another solo admin to invest in first, once the automation is in place: not a better alert, but a better understanding of what each vendor's alert actually means when it fires. The system gets you most of the way. The vendor-specific knowledge gets you the rest.
3. Nothing gets a pass because it's "just me"
The temptation of solo IT is to skip the ceremony. No one's reviewing your work, so why write it down?
Because the audit trail isn't for a reviewer. It's for me in eight months, when someone asks why a device was decommissioned in March and I have precisely no memory of it. And because "just me" is exactly one bus away from "nobody" — every runbook I've written is a bet that someone eventually inherits this and shouldn't have to re-derive it from scratch.
Every remediation I do more than twice becomes a written playbook. Not aspirational documentation — the actual steps, including the ugly ones, including the order that matters and why.
What runs it
All of the above lives in OpenTechnologyApp, which I build. That's not incidental and I won't pretend it is: I built the parts I needed because I needed them, and the templates that ship with it — IT Device Audit, Access Automation, and the request-intake project — are the ones I run my own week on.
The device audit started as a Google Sheet and an Apps Script reconciling device management against endpoint security. It outgrew the spreadsheet. What it became is importable in one click.
If you're the only one
Three things, in the order I'd do them again:
- Automate the repeating thing first, not the interesting thing. Count how many times you did each task last year — the biggest number is your answer, and it is almost never the clever dashboard.
- Automation earns you the time to go deep on vendors, not an excuse to skip it. A system that reconciles everything still needs someone who knows what each vendor's version of "everything" actually means.
- Write the runbook the second time you do something, not the fifth.
None of this makes you less busy. It makes you interruptible — and when you're the only one, that's the thing that actually matters.
If reading this made you think "I need someone who already knows how to do this" rather than "I should build this myself" — that's the other thing I do. Get in touch.