One-Person IT Department Survival Guide

Your title says "Systems Administrator" or "Technology Coordinator." What you actually are is the person who fixes everything when it breaks, who keeps systems running that you never wanted to be responsible for, who resets passwords at 4 PM on a Friday, who gets called at home because the Wi-Fi died during a program.

You're doing the work of 3-5 people. You're paid for 1. You're running on fumes and coffee and a growing sense that this isn't sustainable.

I've watched this happen at dozens of libraries. Small systems. Rural systems. Systems with no budget for IT staff. The pattern is always the same: One person becomes the infrastructure. That person eventually burns out or leaves. Then the library scrambles to replace them and starts the cycle over.

I covered a weekend outage solo for a two-branch system once. Three hours of troubleshooting. Patrons stranded. Staff panicking. Afterward I swore I'd figure out how to keep this from happening again.

Here's what I learned: You can't do this alone. But you can set up your library so one person has a fighting chance.

Stop Pretending You're a Real IT Department

Here's the thing: You're not one person doing one job. You're one person doing five jobs. Your organization knows this. They just hope you don't realize it, or that you'll keep doing it anyway because you care about the library.

I know that sounds harsh. I know you love your library and the mission. I know you've internalized that "we do more with less" and that you should be grateful to have a job.

But here's the reality: You cannot sustain this. And if you don't acknowledge that up front, you'll burn out trying. So let's be honest about what you can and cannot do.

What you can realistically do:

• Keep systems running
• User support (passwords, troubleshooting)
• Basic maintenance (updates, patches)
• Vendor communication and contract management
• Documentation and knowledge base building

What you cannot do alone:

• Complete system redesigns
• Complex migrations
• Security audits and implementation
• 24/7 on-call support
• Major vendor negotiations from scratch
• Forensic incident response if breached

Knowing the difference will save your sanity.

The Triage Matrix: Prioritizing What Matters

You have 40 hours/week. Vendors want 60. Patrons need 80. You can't do it all. So you triage.

When someone says "I need this fixed": Ask what category it falls into. Most things are "Nice-to-Have" pretending to be "Critical." Your job is to be honest about that.

Your actual calendar should look like:

• 40% emergency/critical fixes (you can't control this)
• 35% ongoing maintenance (updates, backups, monitoring)
• 15% user support (training, passwords, troubleshooting)
• 10% strategic work (planning, documentation, evaluation)

You'll never stick perfectly to this. But it gives you a framework.

Vendor Support Escalation: The Art of Not Taking It

Vendor support is often terrible because they don't care about small libraries. Here's how to actually get help.

Level 1: Document Everything in Email

When you contact a vendor:

• What's broken (specific: "I can't search the catalog" not "it's slow")
• When it broke (exact time, date)
• What you've tried to fix it
• Screenshots or exact error messages
• Your library name and contact info
• Your contract/account number

Email everything. Every follow-up, every attempt, every error message. This creates a paper trail. Vendor support will be unhelpful. But they'll be unhelpful on record, which matters.

Level 2: Know Your Contract

Find your service level agreement (SLA). It probably says something like:

"Critical issues: 4-hour response, 24-hour resolution target. Important issues: business day response, 5-day resolution target."

Your vendor probably violates this regularly. When they do:

• Cite the SLA in your escalation email
• Request expedited support or compensation
• Copy your director/board (if applicable)

Most vendors will suddenly become responsive when you mention their own SLA.

Level 3: Escalate Appropriately

Tier 1 support (first-line help) often can't fix anything. They'll say "I don't know" and close the ticket. When that happens:

• Ask to speak to a supervisor or Level 2 engineer
• Send a formal escalation request (email, make sure it's documented)
• Mention your dissatisfaction with the response
• Reference your contract SLA again

Level 4: Hire Outside Help

For complex issues (migrations, security breaches, major implementations), hire a consultant. Budget: $150-300/hour.

Your vendor will suddenly cooperate when they see you have outside technical support watching them.

Level 5: The Nuclear Option

If a vendor is repeatedly unresponsive:

• Send a formal complaint letter (certified mail) referencing breach of SLA
• Request compensation or service credit
• Mention you're evaluating alternative vendors
• Contact their account manager directly (escalate past support)

Most vendors won't push it further. They want your renewal.

Building Your Support Network: You Need Help

You can't do this alone, but you might not have a budget for outside staff. So build a network.

State Library Resources

Your state library probably offers:

• Group purchasing for systems (better prices)
• Shared IT support (some states offer this)
• Technology training webinars (free)
• Peer learning networks (connect with other small library IT staff)
• Grant funding for technology projects

Action item: Call your state library. Ask what technology support they offer. Many librarians don't know.

Library Consortium Resources

If your library is in a consortium:

• They might have shared IT staff
• They might negotiate better vendor rates
• They might run shared training or peer groups
• They might have group insurance for breaches

Use these. That's why consortia exist.

Open Source Communities

If you use open-source systems (Koha, Evergreen):

• Join community forums and mailing lists
• Attend virtual conference sessions
• Connect with other librarians using the same system
• Hire community experts for implementation help

Open source communities are often more helpful than vendor support because they're peers, not a customer service department.

Peer Libraries in Your Region

Find other small libraries near you. Talk to them. Learn what they use, what works, what doesn't. Offer to swap knowledge.

Coffee with IT staff from three nearby libraries is worth more than a $1K vendor training.

Online Communities & Forums

• Library-L and LIBADMIN mailing lists: Peer-to-peer support from thousands of librarians
• ALA Connect Groups: Technology and systems administration forums
• Reddit (r/libraries): Surprisingly helpful peer community
• Stack Overflow: For general tech issues

Someone has had your problem before. Find them.

What You Can Realistically Do (And Should Own)

System Monitoring

Set up Pingdom or Uptime Robot (free tier). Seriously. Not "eventually." Right now.

What this does: You get pinged the moment your catalog goes down instead of discovering it when a patron complains. That's 30 seconds of peace you don't think you deserve but absolutely do.

Investment: 2-3 hours to set up. 30 minutes a month to check the dashboard. The ROI is you getting to leave work knowing you've seen the status of your systems at least once that day.

User Training

Staff will cause your problems. Not maliciously. They just don't know any better. So teach them:

• Phishing recognition (you know, "this email looks weird, here's why")
• Password basics (and why writing them on the monitor is bad)
• How to report stuff WITHOUT just yelling at you across the room at 4:55 PM
• The magic of turning it off and back on before calling you

Invest 4-6 hours a year. Do it in brown-bag lunches where there's free pizza. Suddenly staff engagement goes up and your workload goes down.

Basic Troubleshooting

These are your bread and butter. You'll handle them hundreds of times:

• Password resets (the majority of your tickets)
• Network weirdness ("Why can't I print?")
• Printer driver gremlins (because printers are proof that chaos is real)
• Email configuration (surprisingly fixable if you know where to look)
• Basic software stuff (resetting a view, clearing a cache, restarting a service)

Keep a running checklist. Seriously. Write it down. After about month two, you'll know it cold and never need the sheet again. But you'll keep it anyway because someday you'll forget something obvious and that sheet will save your sanity.

Documentation: The Difference Between "We're Prepared" and "We're Screwed"

I watched a library lose three IT staff in five years because none of them documented anything. Each person left with years of knowledge that walked out the door. The next hire had to reverse-engineer everything. By the time they figured out how systems worked, they were already burned out and left too.

Create and maintain:

• How-to guides for common tasks. "When someone forgets their password, here are the exact steps." "When the printer stops working, try these things first." Write it down so the next person - or a coverage person when you're sick - can actually help patrons instead of just saying "I don't know."
• System inventory spreadsheet. What hardware do you have? What software licenses do you own? When do they expire? When were they last updated? When do they need replacing? This is not optional. This is how you plan a budget instead of panicking when something dies unexpectedly.
• Vendor contacts and contract details. Every vendor you work with: contact name, phone, email, account number, contract renewal date, service level agreement terms. All in one place. Because at 3 AM when something's down, you need this immediately and you won't remember any of it under stress.
• Disaster recovery checklist. When systems go down, write down what happened. What went wrong? How did you fix it? What would you do differently next time? This becomes your playbook. The second time something similar happens, you already know the solution.
• Password management and access documentation. Who has access to what? How do new people get onboarded? Where's the emergency access if you're not available? If something happens to you - you get sick, you leave - does someone else know how to keep the library running?

I know this sounds tedious. I know you'd rather be solving problems than writing documentation. But here's what actually happens: When you leave - and statistically you will, because this job burns people out - the next person either has a roadmap or starts from zero. Guess which one keeps the library functioning?

What You Should Outsource

Complex Migrations

Moving from one ILS to another? Hire a consultant. Cost: $5-15K. Pain prevented: priceless.

Security Audits

A professional security audit ($2-5K) will find things you can't. It's worth it.

Major System Implementations

Implementing a new discovery layer? New authentication system? Hire help. You can't do this alone and work your day job.

Incident Response

If you're breached (ransomware, data leak), immediately hire forensic incident response specialists. Your cyber insurance might cover it.

Do not try to handle this yourself. This is "call the professionals" territory.

The Self-Care Part: You Can't Do Everything

Let me be direct: You cannot do the job of 3-5 people by yourself. If your director, board, or patrons are acting like you should, they're wrong.

You're not failing. The structure is failing you.

What this means:

• You can't maintain everything perfectly
• Some things will break
• You can't be on call 24/7 indefinitely
• You're allowed to say "I don't know"
• You're allowed to say "That will take longer than you want to wait"
• You're allowed to say "That's not my job, that's a consultant's job"

Burnout is the biggest threat to small library technology. When you burn out, you leave, and the library loses institutional knowledge.

Protect yourself:

• Set office hours for IT support (not 24/7)
• Establish an "on-call" schedule if emergencies happen after hours
• Document everything so the next person can recover
• Say no to things that aren't realistic given your bandwidth
• Build relationships with consultants now so help is available when you need it

Templates & Tools: Practical Resources

Issue Ticketing System (Free)

Use Zulip or OpenDesk (free open-source options) to track issues instead of sticky notes.

What to track:

• What the issue is
• Who reported it
• When it was reported
• Priority level
• Status (open/in progress/resolved)
• What you did to fix it

Knowledge Base Template

Issue: [Description of the problem]
Symptoms: [What users see]
Cause: [Why it happens]
Solution: [How to fix it]
Time to resolve: [Realistic estimate]
Who can fix it: [Self-service or IT]
Prevention: [How to prevent it next time]

Build a document with answers to common issues. It becomes incredibly useful.

Disaster Recovery Checklist

If systems go down, print and follow this:

• What's offline? (check each system)
• Call vendor support (use email, document everything)
• Notify director/board
• Assess patron impact (can patrons search? check out? access WiFi?)
• Implement workarounds (manual checkouts, extended hours to recover later)
• Update status every 30 minutes
• Document everything that happened
• Post-incident: What went wrong? How do we prevent it?

Vendor Escalation Email Template

Subject: URGENT: SLA Violation - [Issue name] - [Your library name]

Dear [Vendor support team leader/account manager],

We opened a ticket on [DATE] for [ISSUE]. Our SLA specifies [RESOLUTION TIME TARGET]. We have not received a resolution and are now [TIME AMOUNT] beyond the target.

Details:
• Ticket #: [NUMBER]
• Issue: [DESCRIPTION]
• Impact: [PATRON/STAFF IMPACT]
• Relevant error messages: [PASTE HERE]

This is impacting [NUMBER] patrons and [NUMBER] staff members. We require either:
1. A technical solution within 24 hours, or
2. A service credit for the outage period

Please confirm receipt and provide a timeline for resolution.

Regards,
[Your name]
[Your library]
[Your contact info]

This tone usually gets you escalated to someone who can actually help.

What You Should Ask Your Board For (Even If You Don't Think You'll Get It)

• Budget for training: $2-3K/year to attend conferences or take online training
• Consultant budget: $5-10K/year for emergency support
• Workstation upgrade cycle: Replace 25% of computers each year instead of all at once
• Professional development time: 40 hours/year for learning new systems
• Clear prioritization: Help the board understand you can't do everything, so they decide what matters
• On-call compensation: If you're expected to respond to emergencies after hours, get paid or get time off

You probably won't get all of this. But ask for it. Your library leadership needs to understand what you actually need to do your job.

The Reality Check

In an ideal world:

• You'd have a team of 3-4 people
• You'd have a budget of $40-50K/year
• You'd work 40 hours/week during office hours
• You'd have time for strategic planning

In the actual world of most small libraries:

• You're alone
• Your budget is $5-15K/year
• You work 50+ hours/week including emergencies
• Strategic planning happens if you're lucky

This isn't sustainable. But it's the reality. Knowing that helps. Your exhaustion isn't a personal failure. It's a structural problem.

In the meantime: Prioritize ruthlessly. Build a support network. Outsource what you can't do. Document everything so the next person has a better shot. Protect your mental health. And remember: You're doing better than you think.

Resources & Tools Mentioned

• Uptime Robot (System Monitoring)
• Zulip (Open Source Ticketing)
• American Library Association (Peer Support & Training)
• Library-L Mailing List (Peer Community)
• CISA (Free Security Resources)
• Koha Community (ILS Support)
• Evergreen Community (ILS Support)
• Bitwarden (Password Management)