One-Person IT Survival Guide
[an error occurred while processing this directive]This guide is for you to use yourself. You\'re doing IT alone because your library is understaffed, not because you're not capable. Use this framework to set boundaries, prioritize ruthlessly, and document what you're doing so it doesn\'t all disappear when you leave. If you hit a specific crisis or need tactical help (vendor escalation, security incident, migration planning), call us then. But this guide is about you surviving, and the systems you're managing thriving, with what you actually have.
- One-person IT is unsustainable as a permanent state, but survivable with boundaries: You cannot do system redesigns, migrations, security audits, 24/7 support, or forensic response alone. Know the difference between critical and nice-to-have.
- Set priorities ruthlessly: Decide which systems you\'ll let fail first if you must choose. Document everything so the next person doesn\'t start from scratch. This is not giving up; it's triage.
- Build a support network: Join peer groups, create internal documentation, automate routine tasks, and push back on unreasonable expectations. You're not alone in being alone.
- You\'re not incompetent: Staffing inequity affects most small and rural libraries. Advocate for realistic funding and staffing, not heroic burnout. This work requires two people. If you have one, that\'s a funding problem, not a you problem.
Why I wrote this: I covered a weekend outage solo for a two-branch system and swore I'd never do it blind again.
Saying yes to everything guarantees burnout; decide which services you're willing to let fail first.
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 pattern: You\'re not one person doing one job. You\'re one person doing five jobs wearing different titles depending on the week. This isn\'t accidental. It\'s structural. When a library can\'t afford five people, it hires one and hopes they're exceptional enough to multiply themselves.
I know you love this library and the mission. I know you\'ve internalized "we do more with less." I know you think burnout is just the cost of commitment. But recognizing a pattern isn\'t the same as accepting it.
Here\'s what you need to understand about your own capacity: You have a fixed amount of time and attention. You cannot do a complete infrastructure redesign AND handle daily emergencies AND maintain security AND be on-call 24/7 AND learn new systems AND mentor staff. That\'s not heroism. That\'s math that doesn\'t work. The trick is being honest about which of these you're actually going to do, then setting expectations accordingly.
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.
| Priority | Response Time | Examples |
|---|---|---|
| Critical Impacts patron/staff access or security |
Same day, drop everything | • Systems offline • Security incident • Staff can't check out books • WiFi down • Backup failure discovered |
| Important Impacts operations or staff productivity |
Within 1 week | • Single workstation issues • Slow performance • Non-critical software issues • Vendor contract review • Staff training requests |
| Nice-to-Have Would be helpful eventually |
Quarterly or annual | • System optimization • Updates to non-critical software • Evaluation of new tools • Documentation improvements • Hardware refreshes (planned, not emergency) |
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)
Sources & Further Reading
- Chada, S. (2025). "Small Library Tech Stack: What You Actually Need." Unhinged Librarian. Retrieved from https://unhingedlibrarian.com/posts/small-library-tech-stack-essentials
- Koha Community. (2025). "Community Implementation Guide for Small Libraries." Retrieved from https://koha-community.org/
- Cyber and Infrastructure Security Agency. (2025). "Small Organization cyber security Guidance." U.S. Department of Homeland Security. Retrieved from https://www.cisa.gov/
- Chada, S. (2025). "How to Actually Talk to Your Board About cyber security." Unhinged Librarian. Retrieved from https://unhingedlibrarian.com/posts/board-cyber security-budget