SysAdmin Career Query: Internal or Client Based [closed]

ServerFault Community,

It seems there are two positions SysAdmins find themselves in, either you are working for a non-IT services based single client (your employer) and providing in-house IT support or you work for a company who provides out sourced IT services to multiple clients.

Right now I work for a company who does the latter, and I often consider how nice it would be doing the in-house side of things, to just have one network I am focused on and instead of feeling like I have a dozen bosses between clients and internal management, I would just have one set of management and people to appease.

There is also the technical aspect of every client wanting something different, and having to manage numerous different technology platforms, or trying to force clients into using the technologies we prefer, neither situation is enjoyable.

Is this just "the grass is greener on the other side" syndrome, or is there some legitimacy to the the stress of client based IT work compared to being an in-house IT guy?

Thanks!

Solution 1:

I've done both.

The first six years of my career was for a software company where I was on a team which did desktop support, server operations, backups, network architecture -- you name it, we did it. All that and the configuration management/release management for the product too. Through that six years I was twice offered the open door into entry-level management.

Since then I've been an employee at a company which provides contract services to customers of varying sizes (think being a consultant without having to find my own customers). I've had both long-term customers (like eight of the nine years I've been here) and one-visit, hit-and-run jobs. I've done everything from being a one-man IT department to being highly focused on one small part of a massive project.

There are advantages and disadvantages to both.

Currently I enjoy being the go-to guy for my long-term customers (even though coincidentally both are ending shortly for unrelated reasons). I have built fairly robust networks at both pieces and I have the architecture, and reasons for that architecture, in my head. Even though one site is fairly well documented, it is kind of neat to me to be able to tell people the reasoning behind the choices made.

Of course the goal is to document everything, and that philosophy is what drives answers like this: If you got hit by a bus, would your company be in trouble?

There is also the constant change of scenery and moving around to visit different sites at different times. Plus the occasional rush when something blows up somewhere and you have to rush to be the hero of the hour. (Or try, anyways).

There are downsides. Some of our customers go against our recommendations, resulting in the very fires we have to rush to fix. Sometimes it is tiring to be on the road all the time. Sometimes it is worrying when there isn't enough to do and you start to wonder how your employer will pay you.

My big negative right now is that it is hard to take comp time when overtime or special jobs happen. The problem is that even if you work an extra 8 hours for customer A, you can't take the comp time the next day because those are scheduled visits to customers B C and D, none of which had anything to do with the overtime happened.

And a long-term negative, one which surprised me, is that I miss having a regular, daily commute and a cubical to hang all the artwork the kids do in school in.

I periodically look at the help-wanted and jobs boards to see what is available, but I have not hit that magic combination where the job was interesting and I was at a negative enough point in my cycle with my current job to want to apply.

Eventually I'll probably switch back if I find an interesting enough job.

Solution 2:

Well, I'm lucky in that I'm in house, but also corporate. So I have my site, and my network, but I'm also a corporate "expert" who gets called by everyone and their mother to remote in and fix this or that. I even get to travel a bit.

So it's nice.

On the other hand, I've worked in house in places where there was no money, and no good toys, and you had to put everything together as best you could, and weather the inevitable storms when some piece of substandard gear kicked the bucket.

So I'd say, on balance, it all depends on the location. Being a contractor can be fun because you're seeing new things, and you get to do huge satisfying jobs, but you've also got to deal with angry local employees, and you don't ever get to rest, or deal with the big system (aside from epic contracts). And being an in-house guy can be fun...in the right house...but in the wrong house it can be ugly.

Solution 3:

Part part. Some grass IS greener on the other side. Single client is nice for stability, multi clients keeps you more on your toes - good for a career start, especially to slowly move towards higher ranks (planning, organization). It also keeps your knowledge more shallow, as you have less time with every technology.

Solution 4:

My day job (well, 30 hrs/wk currently) experience is in-house at a large University, though I've done a bit of consulting/project-based work, mainly for companies that have a few Linux/Unix boxes but a mostly-Windows admin.

Being in-house, especially at as large a place as I am (university, > 50k faculty, staff and students), definitely has its benifits. "Non-technical" management (in job title, not necessarily in aptitude) is so many levels above me that I don't really have to worry about "selling" IT. We're all quite specialized - my group runs a few services (albeit some rather complex ones) and that's what we do. I've never spoken directly to a user in an official capacity (aside from trips outside the office), which fits me quite well. Even if you're in a small IT department, you might still have to sell your newest project to management, but at least you don't have to worry about management being, literally, your client (and you always have the benifit that, while you can get fired, it's nowhere near as easy to sack the whole internal IT department as it is to switch to another consultant/outsourced provider). You also get the benefit of (hopefully) having more push in terms of IT direction - hopefully there's at least someone around who, at some level, has the respect to be able to say "this is the right way to do the job. this is how we're going to do it."

On the other hand, there is an element of challenge and unknown missing from working in-house (probably why I do what consulting I can). When working with multiple clients, even if they're usually the same ones, the problems can get more interesting, or at least different. Not to say that internal IT groups don't have more than their share of unusual situations, but a lot of the "fires" we (at least my group) put out turn out to be "oh, bug X surfaced in the DHCP server again, follow the checklist."