I've worked in help desk and several solo or mostly solo IT positions. One role involved supporting about 30 locations with a small team, while another was a quiet single-site enterprise job with little room to grow. I recently accepted a new position paying $70,000, up from $45,000, where the company is moving away from an MSP and building an internal IT department across more than 20 sites in several states.
The opportunity is appealing because I'll help establish the department, create documentation and policies, and gain broader experience. However, I'm worried that I may be signing up for too much responsibility without enough support. The role could require flexibility outside normal business hours, and I'm not especially confident with networking. My background is mainly in Microsoft environments, while this company relies heavily on Google Workspace and several integrated platforms.
I often feel like I'm just getting by, make mistakes, and don't always speak up as much as I should. I'm concerned about meeting expectations, allowing work to consume my life, and continuing to move into jobs with more responsibility and smaller teams. Ideally, I'd like to stay somewhere for at least two years, learn as much as possible, and eventually move into a more specialized IT role rather than becoming a systems administrator or corporate IT manager.
For people who have worked alone or with very little IT support, what kept you going? How did you decide when to move on, and what did you eventually transition into?
5 Answers
I spent years as the primary IT person with an MSP available for major issues. It made me more capable, but it also showed me that I prefer having another technical person around to compare ideas with. A solo job can teach you a lot, but set boundaries early: clarify after-hours expectations, define what success looks like, ask when additional staff will be considered, and get priorities in writing. If the company expects one person to support dozens of sites indefinitely, that’s a staffing problem—not a personal failure.
For the first few months, focus on visibility and risk reduction rather than trying to redesign everything. Map the sites and network, identify unsupported systems, verify backups, review administrative access, confirm endpoint protection, and document the current state. Then turn the gaps into a roadmap with estimated effort and business impact. That gives leadership a realistic basis for deciding whether the department needs more people or outside help.
Solo work can become a legitimate long-term career path. Some companies are too large or too demanding for an MSP but too small for a full IT department, and someone who can run that environment can move through titles like network administrator, systems administrator, IT director, or even executive-level IT roles. The workload can be heavy, but strong communication and business judgment may matter just as much as deep technical expertise. Don’t assume you need to be the best engineer in the room to create value.
You’re not cooked. Solo IT often means being a generalist, and nobody knows everything—especially when networking, cloud tools, security, and business systems all overlap. Even experienced people deal with imposter syndrome. The valuable skills are learning quickly, communicating clearly, and knowing when to find reliable information or bring in an expert. This role could help you discover which parts of IT you actually want to specialize in.
A good way to make a solo role manageable is to reduce repetitive work first. Build a complete inventory, document the environment, automate routine tasks, and create clear procedures. Once the basics are under control, you’ll have time to improve security and infrastructure instead of constantly reacting to emergencies. Treat the first phase as learning what exists, not proving that you already know everything.
Start with assets, accounts, warranties, software, network equipment, backups, security tools, and vendor contacts. Confirm that passwords and recovery methods actually work, and make sure the documentation is stored somewhere the company can access if you’re unavailable.
That’s part of what worries me. I’m excited to build things out, but I don’t want “building the department” to quietly become “being the entire department forever.”