Wearing all the hats without dropping them
If you run IT, security, and compliance at the same organization, here's the reframe that matters most: your job is not to do everything. Your job is to make sure nothing important is unowned. Those are different jobs, and confusing them is how good people burn out in this role.
Three buckets, or one bucket eats the rest
Everything you do falls into one of three buckets:
- Operate — keep the lights on. Tickets, outages, password resets, the printer.
- Improve — projects that change your position. The MFA rollout, the backup redesign, the license cleanup.
- Comply — prove what you do. Evidence, reviews, policies, audits.
Left alone, Operate consumes 100% of every week, because it's the bucket that rings. The only defense I've found is structural: Improve and Comply get scheduled hours before the week starts — even just four protected hours — and you treat them like a meeting with your most important customer. Because that's what they are: Operate keeps today running, but Improve is the only thing that makes next year's Operate smaller.
Operate also includes the work nobody planned. Try this diagnostic for a few weeks: track the delta between what you intended to do and what actually got done. That gap is your unplanned-work tax, and at small shops it's routinely a third of the week. The fix isn't to plan harder — it's to budget for it, the way an emergency fund budgets for the car repair you can't name yet. A week planned to 100% capacity isn't a plan; it's a promise to disappoint someone.
And watch your own work-in-progress. Each additional in-flight commitment slows every other one — the math is unforgiving, and it doesn't care that you meant well when you said yes. The forty-item to-do list isn't a badge of importance; it's a warning light. Stop starting. Start finishing.
The calendar is a security control
The most effective compliance tool in a small shop isn't a GRC platform — it's a recurring task list. Monthly: patch review, backup restore test, new joiner/leaver access check. Quarterly: access review, license audit, risk register review, leadership briefing. Annually: policy review, incident plan walkthrough, vendor list check.
Two things happen when this lives on a real calendar. First, the work actually occurs, which is more than most organizations can claim. Second, every completed item, dated and noted, is compliance evidence. When an auditor asks "how do you ensure access reviews happen?", the answer "here's the recurring task and twelve months of completion notes" is better than any policy document ever written.
There's a deeper reason this matters. Security and maintenance are revenue-protecting work, and revenue-protecting work is invisible by nature — nobody celebrates the outage that didn't happen or the breach that never started. Invisible work loses every prioritization fight it isn't present for. The recurring calendar slot is how you give it a seat at the table. One more habit while you're at it: anything on your list that hasn't moved in two weeks isn't "in progress" — it's blocked or quietly abandoned, and naming which one is usually the day's most useful question.
Write it down, or you are the risk
If critical knowledge lives only in your head, your organization has a severity-one risk and its name is yours. Two artifacts, kept ruthlessly simple:
- A decision log. One line each: date, what was decided, why, who agreed. Settles "why is it built this way?" forever, and protects you when a past decision gets questioned.
- Runbooks for the things that would hurt at 2 a.m. Restore from backup, respond to a compromised account, contact list when systems are down. Written so a competent stranger could follow them.
Then do the honest thing almost nobody does: put "key person dependency — IT/security" on your own risk register, with yourself as the subject. It's accurate, it's the strongest staffing argument you can hand leadership, and it converts "I'm overloaded" (a complaint) into "the organization has a single point of failure" (a risk requiring a decision).
Outsource by the clock, never by the decision
The first thing to outsource is anything that needs to happen at 3 a.m.: after-hours monitoring and response. No single person can provide 24/7 coverage, and pretending otherwise just means breaches that start on Friday night run unattended until Monday — which is precisely why attackers prefer Friday nights.
What never gets outsourced: risk acceptance decisions, vendor relationships, and knowledge of your own environment. An MSP can run your monitoring; it cannot decide what your organization should tolerate, and if an outside party knows your environment better than you do, you haven't outsourced work — you've outsourced control of it.
Saying no with a number
Overload in this role is usually invisible to leadership because everything still ships — at cost only you can see. Make the cost visible by converting it to a choice: "With current staffing I can deliver the ERP upgrade or the compliance prep this quarter, not both. Which one moves?" No complaint, no heroics — a resourcing decision, framed for the people whose job is resourcing decisions. They can answer that question. They cannot answer a sigh.
Direction: three objectives, one page
Finally, the discipline that makes the rest coherent: pick at most three objectives per year, write them on one page, and get leadership to agree to the page. ("All endpoints managed and compliant. Pass the customer audit. Recover any critical system within 24 hours.") Every new request then gets measured against the page — it either serves an objective, displaces one, or waits. That single page is the difference between running a program and being run by a ticket queue.