...Job role?

I'm coming up on 8 months into my job at an MSP after having been farted out of 2 years of community college, and I feel like it's around time I start specializing and step a bit away from generalizing. My official title is "Help Desk Technician" but I feel like some of the things I've been doing (editing registry of a grossly overloaded Terminal Server with 50+ users midnight on early Sunday, expanding a schema, editing GPO, restructuring AD, setting up network monitoring, file migration from a NAS to a file server) have gone well beyond that.

I can't say I care much about job title, they can call me "Mr. Wizard" for all I care. But I do feel that defining a clear and unambiguous role gives me direction on where to focus what little time I have when I'm not working or doing work related things. For example I would say that I'm officially interested in becoming a SysAdmin but I do feel like I don't have much as strength in networking such as setting up VLANs, etc. Or I might be very lost trying to setup a brand new Windows Server VM, else I might have problems trying to change a setting on a server but I have no idea if DSC is in play and if that's why the UAC settings keep reverting themselves or the file permissions keep changing.

If I had to describe it, I'm not as skilled in setting up an environment right, but I'm more than capable of creating a GPO to keep laptops from sleeping during a patch window and then reverting it back to sleep after 60 minutes when the patch window has lapsed. Or creating a GPO to enable and allow WinRM traffic because we just kind of threw a network monitoring solution into an environment without setting up the environment properly and it's just been kind of useless decoration these past few months.

Or say we generally do our client migrations the full manual way:
Go to each workstation, login with domain admin to establish a profile, install our RMM agent, install AV, rename it, restart it, check for lingering admin accounts from previous IT.

Whereas I used our native RMM tools to install the agent software remotely, utilized the RMM agent to install AV, ran Powershell to rename a list of computers pulled from AD, then utilized the RMM agent to check for local administrator accounts. So the only thing techs need to do is label each computer.

Supervisor wants to know if I want to do my own onboarding, but I feel like I can contribute more as backend support. Maybe evaluate our processes, see what we're doing and how we're doing it, and refine it so we're doing our jobs more efficiently.

They say you shouldn't reinvent the wheel, but sometimes it's nice to check whether you invented the round wheel or the square wheel.

Don't know what you'd call that kind of role. Devops? Thus far I'm trying to put more time and effort into Powershell since I have a feeling that's a key to automation or will serve as a force multiplier.

Find more posts tagged with

Comments

paul78

I'm not sure if you are looking for a response or just posting some thoughts. It actually sounds like you understand the concepts that you are interested in - but you just are seeking experience. The role that you described isn't DevOps. DevOps is more about supporting software engineering teams and managing the automation software integration and deployment. It's most common in orgs that develop software using Agile. While in theory devops practices can be used in a Windows environment, it's more common in a cloud based environment using linux stacks.

N7Valiant

paul78 wrote: »

I'm not sure if you are looking for a response or just posting some thoughts. It actually sounds like you understand the concepts that you are interested in - but you just are seeking experience. The role that you described isn't DevOps. DevOps is more about supporting software engineering teams and managing the automation software integration and deployment. It's most common in orgs that develop software using Agile. While in theory devops practices can be used in a Windows environment, it's more common in a cloud based environment using linux stacks.

I am certainly interested in finding out what kind of role I might fit into and drive towards that as I'm a bit scatterbrained at the moment and other than Powershell I'm not sure what to invest my time and effort into.

Ironically as I'm diving into the first chapter of "Learning Powershell Scripting in a Month of Lunches" that is exactly what the author describes it as: a tool for automation and a force multiplier. That is exactly where my interest lies. Not so much on the ground or dealing frontline with clients, but to act as support so that other techs can do their jobs easier and more efficiently.

yoba222

Okay so you're not sure what you want, but you know you don't like your job title. I'd focus on that first--changing out the phrase "help desk" and replacing it with "sysadmin" somehow.

Is that job title a thing where you work now? How about bouncing the idea off your boss that you don't like being a help desk tech and want to be considered sysadmin? Maybe they'd simply change it. If your boss doesn't think you're ready find out what he/she thinks you need to learn first and learn that.

N7Valiant

yoba222 wrote: »

Okay so you're not sure what you want, but you know you don't like your job title. I'd focus on that first--changing out the phrase "help desk" and replacing it with "sysadmin" somehow.

Is that job title a thing where you work now? How about bouncing the idea off your boss that you don't like being a help desk tech and want to be considered sysadmin? Maybe they'd simply change it. If your boss doesn't think you're ready find out what he/she thinks you need to learn first and learn that.

Again, is SysAdmin really what I'm going for based on what I'm doing?

Trying to see what my aptitude is and it might be a bit wrong to chase a title if what I'm actually doing falls far short. I do feel like I'm better at administrating a system that was properly setup to a degree rather than building a proper system from the ground up.

I'm just judging by the 2 actual SysAdmins we had, what I've been doing doesn't quite seem to come close in many instances.

LeBroke

From what you've described doing, I'd describe you as a decent Tier 2 technician.

IMO to be a sysadmin you have to be able to set up a basic environment from scratch at the very least.

N7Valiant

Another reason why I kind of need to know what job title is applicable to me:
Cleaned up my resume and started looking for jobs to apply to. Help Desk, if you'll pardon me, seems a bit beneath me given what I've been doing recently (file migration, re-configuring broken backups to make them work again, setting up network monitoring using SNMP, WinRM, etc.). There are never any junior SysAdmin positions, but at the same time full SysAdmin seems over my head.

NetworkingStudent

I think keeping the help desk role as a job title is fine. You do not want to lie on your resume, or on your job application.

I think a desktop support position would be a good it for you. Depending of the organization some desktop support techs get into GPO's, backup monitoring, and file migration. To be perfectly honest a desktop support role would help you get into an admin role.

As far as working at an MSP, I was told that 1 year at a MSP=3 years if IT experience.

jcundiff

NetworkingStudent wrote: »

As far as working at an MSP, I was told that 1 year at a MSP=3 years if IT experience.

Don't believe everything you're told

(or read on the internet) Guessing, whoever told you that worked for a MSP or recruitd for them ?

N7Valiant

NetworkingStudent wrote: »

I think keeping the help desk role as a job title is fine. You do not want to lie on your resume, or on your job application.

I think a desktop support position would be a good it for you. Depending of the organization some desktop support techs get into GPO's, backup monitoring, and file migration. To be perfectly honest a desktop support role would help you get into an admin role.

As far as working at an MSP, I was told that 1 year at a MSP=3 years if IT experience.

Not looking to lie on my resume, but I've found that knowing what title best describes what you want is important in the job search to some degree.

I've been browsing a few desktop support positions but nothing is quite catching my eye and seems like a downgrade.

And yes, I feel like working at an MSP has, if nothing else, been a huge boon to my skills. Out of necessity more than anything else. I just spend most of my time in amazement that I actually fixed the client's backups instead of blowing them all away because the supposed engineer setup backups and never once checked to see that they've been failing since Day 1 and now I've got to make everything work again.

It's been a hell of a rollercoaster and given that I've seen a few of my in-house peers, I'm actually quite appreciative of my skill growth and would rather stick around at least another 4 years if possible (round it out nicely on a 5). But when your boss decides it's more important to on-board new clients(averaging about 1 a week or two) rather than take care of your current ones even when "we" have already dropped a few balls on backups, it's time to brush up the resume.

LeBroke

N7Valiant wrote: »

It's been a hell of a rollercoaster and given that I've seen a few of my in-house peers, I'm actually quite appreciative of my skill growth and would rather stick around at least another 4 years if possible (round it out nicely on a 5).

I'd argue it's just as important to learn the right skills, as opposed to skills in general.

Unless you want to be an SMB Windows Sysadmin, it's very important to branch out into other fields. Chances are, at an MSP, you'll never really touch anything at a large scale, or play with much in the way of enterprise tech/processes (i.e. SANs, large-scale VM or Openstack deployments, complex networking), or hot buzzword marketable tech (cloud, Kubernetes, etc), and it's rare for you to touch much in the way of Linux.

I mean heavily depends on what you want to do with your career, but IMO working a junior in a medium-large (but not super large that you're not silo'd) company is probably better long-term, as you both have more chance to move up, more technologies you can touch, and more people to learn from. You never want to be the smartest person in the room. If you are, you're in the wrong room.

In any scenario, 4 years is too long in any job in this field, much less 5. It's fine if you're in a cushy, senior position or a director/architect, but until you hit that point, it's much better to move around or not, if only so you don't start to stagnate (or in the case of MSPs, burn out).

N7Valiant

LeBroke wrote: »

I'd argue it's just as important to learn the right skills, as opposed to skills in general.

Unless you want to be an SMB Windows Sysadmin, it's very important to branch out into other fields. Chances are, at an MSP, you'll never really touch anything at a large scale, or play with much in the way of enterprise tech/processes (i.e. SANs, large-scale VM or Openstack deployments, complex networking), or hot buzzword marketable tech (cloud, Kubernetes, etc), and it's rare for you to touch much in the way of Linux.

I mean heavily depends on what you want to do with your career, but IMO working a junior in a medium-large (but not super large that you're not silo'd) company is probably better long-term, as you both have more chance to move up, more technologies you can touch, and more people to learn from. You never want to be the smartest person in the room. If you are, you're in the wrong room.

In any scenario, 4 years is too long in any job in this field, much less 5. It's fine if you're in a cushy, senior position or a director/architect, but until you hit that point, it's much better to move around or not, if only so you don't start to stagnate (or in the case of MSPs, burn out).

Hmm, true. Although I believe I already have a promising interest: Powershell.

I'd really like to focus on that going forward, as that appears to be where the future is going (and may well already be here as I'm still clueless about DSC). Still, it might be a dark day for my future prospects here if a coworker has a major traffic accident while going about the course of work and the boss wants to talk about work instead of checking if said coworker is okay.