- Use PowerShell splatting and PSBoundParameters to pass parameters - Wed, Nov 9 2022
- Using PowerShell with $PSStyle - Mon, Jan 24 2022
- Clean up user profiles with PowerShell - Mon, Jun 9 2014
The conversation brought into focus something that I think I have sub-consciously pondering for a while and that is a PowerShell “career” path. I’m hoping this article will jump start a discussion in the PowerShell community.
In order to understand where I’m heading, you have to have a better idea about what PowerShell really is and where it is headed. If you missed, I hope you’ll take a few minutes to read PowerShell: Past, Present and Future. With that, here’s my take on where we are going with PowerShell. And to be clear, I’m not talking about actual job titles or positions, (although that would be pretty cool) but rather the role PowerShell might play in your day to day job.
The entry level PowerShell role is something I’m referring to as a PowerShell Technician. This person has enough training to be able to run basic PowerShell commands and scripts. The Technician may even be able to cobble together some simple scripts to assist with their assigned duties.
This group knows just enough PowerShell to get by or doesn’t have the job responsibilities that merit greater PowerShell expertise. There will always be a need for a human element to IT but this doesn’t mean this role can’t take advantage of automation tools built on PowerShell or other automation technologies. Think of this role as the PowerShell tool user.
The next step up is the PowerShell Administrator or perhaps you might think of this as an Engineer role. This person obviously has more PowerShell expertise than the PowerShell Technician. The PowerShell Engineer knows enough PowerShell to be able to use advanced features of PowerShell. They may be responsible for tasks such as enabling remoting, configuring TrustedHosts or setting up delegated endpoints.
This is the group that today I would say we also refer to as toolmakers. The Engineer will create scripts and tools for use by other PowerShell Administrators and Technicians. This role is well-versed in the PowerShell language and paradigm. I would expect many of you fall into this category or at least are striving to reach this level.
In many companies this distinction between these first two groups already exists, most likely in an informal manner. But now, this is where I think we need to take the next step.
Allow me to introduce the PowerShell Architect or Designer. Let’s not get too bogged down in discussing a specific title. Both “Architect” and “Designer” carry a lot of baggage and everyone seems to have an opinion. What I want to focus on is on PowerShell’s role.
This person has the highest level of PowerShell expertise and naturally should serve as mentor and final authority for all PowerShell related issues. I foresee this role having a few responsibilities. First, this role would be responsible for determining how PowerShell is deployed and used throughout the enterprise. This person would determine and provide implementation details for items such as execution policies, remoting configurations, including delegated or constrained end points.
The architect-designer, along with business and operations leaders would identity areas where PowerShell would solve problems, increase efficiency or add value to the organization. At this level we are getting into DevOps waters which is a good thing. Although, a case could be made that the PowerShell Admin-Engineer also plays a critical role in the world of DevOps.
The PowerShell Architect-Designer is also more than just a scripter. This role would be responsible for designing high level tasks that are extensions to the PowerShell language such as work flows. The role would play a major role in designing and implementing Desired State Configuration (DSC).
In fact, the architect-designer could be the person developing new DSC resources. The role is definitely beyond a simple scripter. Even so, I hesitate to say that the role has moved from IT Pro to Developer. 20 years ago we probably had a clear distinction of roles but now the lines are very blurred and probably don’t matter much anyway, at least for progressive and forward-thinking organizations.
To boil this all down you can look at the roles like this:
- Technician = tool user
- Engineer = tool maker
- Designer = automation big picture
You might argue that we don’t really need separate roles but rather we need to understand the value of PowerShell to the business in relation to the work on our plates. I think we can all agree that as projects or tasks grow in complexity and scale that we need trained and experienced resources all along the continuum I’ve been describing.
By now I hope you are trying to figure out where you fit into this hierarchy and where you want to go. Then you have to decide how to get there. I don’t expect companies to start setting up new job titles but I think the general roles need to be discussed and how PowerShell, as well as other automation technologies fit into the big picture. I’m hoping the PowerShell community will take the first step.
So, am I just talking crazy? Is there value in these role definitions that I’ve laid out? How can we get management types to buy-in to this vision? My goal is to kick start the discussion and get you thinking about your relationship to PowerShell.
Subscribe to 4sysops newsletter!
Finally, I’d like to thank fellow PowerShell MVPs Don Jones and Richard Siddaway for their thoughtful opinions on this topic. Now it’s your turn. What do you think?
The company i work on recently (1.5 years ago) started a “Powershell department”. Using your words, the team consists on 3-4 Engineers and 1-2 Designers. They have been making an excellent job creating reusable tools for the rest of the IT admin teams (pretty big company with one team per technology) or the “Technicians” as you would say. I work part time on that team because of my Powershell skills.
I remember when i started with Powershell 3 years ago. I was also in this company and IT admin leads were not too charmed by the fact that i did everything from a Powershell console instead of using the GUI. One of them even called me “Linux guy” 🙂
I’m glad to see things are changing now. It is still hard though to sell Powershell to the management. But i think we are on a good track.
I’m trying to get more info on DSC as it would be a huge selling point.
Thanks for taking the time to comment. Your company sounds like a cool place to work. Eventually admins will learn PowerShell doesn’t mean leaving the GUI behind. The thing about a GUI is that it locks you in to whatever the GUI is designed to do. At the console you have the entire PowerShell arsenal at your disposal.
I’ll have to see about adding some DSC content. Thanks for reading.
Jeff,
I like the categorizations of skill level. One thing I would dispute is that the “architect-level” is where DSC resource production would reside. I think due to the newness of the feature, it seems more unapproachable than it is. In reality those who are talented/skilled enough to make the leap to being the toolmakers or “engineers” in your taxonomy have the capability to do so.
In the context of DSC, the “architect” would likely be responsible for building out the role definitions and the coordination of how groups of resources are applied to classes of machines.