The PowerShell career pipeline

• Author
• Recent Posts

Jeffery Hicks

Jeff Hicks is a long-time Microsoft MVP specializing in PowerShell and automation. He creates PowerShell content for Pluralsight and blogs regularly at https://jdhitsolutions.com/blog. Jeff's latest project is a premium content newsletter at jeffhicks.substack.com Follow him on Twitter as @jeffhicks.

Latest posts by Jeffery Hicks (see all)

• 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.

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?