While there are TONS of articles teaching you how to get better at PowerShell, this one provides a different perspective on leveling up your PowerShell teams.

One of the fastest ways to level up your PowerShell teams is to invest in the people using it. The real power behind PowerShell is people’s relationship to this scripting language.

Our five pieces of advice are:

1. You can’t just have a PowerShell guru.
2. Embrace the various levels of PowerShell expertise.
3. You’re probably already using PowerShell even if you don’t think you are.
4. Remember that not all scripts are PowerShell.
5. PowerShell scripts are processes, company assets, and standardized operating procedures.

1. Make this your mantra: We can’t just have a PowerShell guru

There’s nothing wrong with having a PowerShell guru on your team, but that person can’t be the only one doing your PowerShell work.

This is one of the hardest mental obstacles to overcome when leveling up PowerShell. Why? Because PowerShell is difficult, people will come to specialize in it, and most teams end up with one of those specialists (let’s call her Heidi). Whenever PowerShell work is needed, you send the work to Heidi.

But relying on Heidi the PowerShell expert will slow down (or block) your PowerShell level-up. This is for two reasons:

1. PowerShell is pervasive. In many Windows cases, the only way to do X task is to run cmdlets—something you could previously do in other, non-PowerShell ways.
2. Heidi is just one person. Few companies can pay Heidi to just be doing PowerShell tasks to support other staff all day. This creates a major bottleneck. And what if she goes on vacation, or if she quits or retires? If Heidi is “The Keeper of the Scripts,” your teams are in for a painful experience adjusting to post-Heidi work life.

Having a team with just a “PowerShell guru” is totally impractical. The first step to leveling up your team’s PowerShell game is to reject that PowerShell is a specialized skill that only one person should possess.

But if there’s no single PowerShell guru, what will there be?

2. There are different levels of PowerShell expertise. Embrace them!

Isn’t it better to have a whole team of PowerShell people than just one Heidi? Your whole Ops team is probably already halfway there.

PowerShell is not just scriptwriting; it’s using those scripts too! In fact, as my ten minutes in MS Paint below shows, there is a much wider gap between PowerShell novices and experts than between having zero knowledge and becoming a novice.

Thinking of it this way means you have a battalion of teammates with novice-level PowerShell skills and some with higher skill levels, rather than just one PowerShell expert.

Don’t let “the perfect” get in the way of “the good.” Minimal PowerShell abilities can be the end goal! There are plenty of minimalist tutorials folks can use to learn, for example, to just RUN a PowerShell script.

That is one of the “roles” or “levels” of PowerShell we came up with, along with some of the relative “experience points” needed to work at that role.

This is just a starting point. Develop the skill levels that work for your team and your organization. For example, some types of scripts will be much more difficult to modify than other types, and not everyone will need – nor wish – to gain the skills required to edit those scripts.

But nearly everyone could modify very simple scripts, that just require carefully changing some text on one specific line.

3. PowerShell is the only path forward—and you’re probably already on it.

Whether you realize it, odds are you’re already using PowerShell even if you don’t consider yourself to possess PowerShell skills.

Let’s use the example of Sam the SysAdmin changing Outlook email storage. It’s been at least five years since it was possible to be a Windows SysAdmin with absolutely no PowerShell abilities. This is because Microsoft is now PowerShell-first, not GUI-first. In the GUI-first era, SysAdmins who needed to change (for example) a user’s Outlook email inbox capacity from 1GB to 5GB could do it through the Microsoft Exchange Admin GUI.

Modern Windows SysAdmins are using PowerShell but they don’t need to be PowerShell experts. Sam knows how to open PowerShell and how to carefully copy/paste, and run the script, and thus he has the minimal competencies needed to do his SysAdmin PowerShell duties. Unlike using the GUI, Sam gets the required PowerShell script from Heidi the scripting expert. He copy/pastes it (maybe editing a few values like username and GB increase) and thus runs the cmdlet for making this change.

It’s important to be aware – while PowerShell GUI helps lower-XP users, it’s not a great idea to write a PowerShell GUI USING PowerShell.

If you can perfectly sing a song in another language, it doesn’t really matter to your listeners if you don’t know the language or what you’re saying, as long as you sing the lyrics correctly and you perform well! The same holds for running PowerShell scripts.

Related article: Using PowerShell to Write PowerShell GUIs? You May Be Making a Mistake

4. Remember: “Scripts” don’t just mean PowerShell.

Now that you’ve realized that you can’t have your “PowerShell guru” do it all, that there are different levels of PowerShell use, and that pretty much everyone is using PowerShell even if they don’t realize it… now what?

Some good news for you if you’re overwhelmed: Just because PowerShell is the most powerful doesn’t make it the only scripting language. Your team will most certainly still use Windows Batch Script (.bat or .cmd files) and likely even Bash scripting (on Linux), alongside PowerShell.

PowerShell is usually used to manage servers, and servers run a specific operating system (OS), usually either Windows or Linux. Windows and Linux are very different OSes, and each uses different scripting languages. Simply put, the scripts you’re writing for your Windows servers that use PowerShell aren’t MEANT to work on Linux.

In general, PowerShell cmdlets aren’t meant to work on Linux. It’s like having a Ferrari that isn’t road legal: lots of power and nowhere to go. There are PowerShell cmdlets for things like managing Azure or AWS services, and those would run fine on Linux. But the majority of cmdlets were written specifically to run on Windows. Linux servers are usually best maintained with Bash, since it’s Linux-primary.

And you probably already have a lot of .bat and .cmd scripts at work in your organization. For simplicity’s sake, sometimes a good, old-fashioned Windows Batch script will do. If you just need to run a list of commands like you would at the regular, non-PowerShell command prompt, Batch is the easiest choice. It’s likely your organization has lots of .bat scripts, and while rewriting to PowerShell may be easy, it just isn’t worth the risk. (My article on Batch gives you a mathematical way to decide whether a rewrite is a good call.)

5. Your PowerShell scripts aren’t just processes; they’re also company assets AND standardized operational procedures (SOP).

PowerShell scripts both describe and execute some processes. This part is a no-brainer. The whole point of PowerShell scripts is to execute something, right? Well, yes, but they’re so much more.

What you might take for granted is that PowerShell scripts are also company assets and standardized operational procedures (SOP).

First, scripts are valuable organizational assets. PowerShell is a very particular scripting language; getting it wrong is easy and can have very serious consequences for security and uptime. Scripts, especially created using the valuable time of your PowerShell experts, are expensive company assets and thus should be stored, organized, and made accessible to others in the organization (not just to Heidi the PowerShell expert). After the up-front investment of time and effort, your PowerShell novices can then use the appropriate scripts from the script library, so long as they know where to look.

Second, in most ways, PowerShell scripts are a type of “standard operating procedure” (SOP)—except that they’re executed by a computer rather than by a human. Of course, scripts run some processes. But they ALSO are a rigorous, strictly enforced way of precisely executing that process. SOPs (and PowerShell scripts) take lots of organizational time to create and must therefore be stored accessibly and remain available to everyone.

Many tools exist to manage your valuable company assets. Heidi, the PowerShell expert’s desktop is not one of them! Scripts are code; source control, which is designed to manage your code-based assets, is the appropriate place to keep your scripts. Those who will modify and/or write PowerShell scripts must understand how to use source control management (SCM) tools. SCM tools are designed for this use case (unlike software applications, which are maintained by dozens of full-time programmers). Check out this guide for the PowerShell Source Control best practices.

There are also many tools to manage SOP. Heidi, the PowerShell expert’s email inbox isn’t one of them! Applications use Continuous Integration/Continuous Delivery (CI/CD) for maintenance. To up your PowerShell game, you’ll need to adapt. Since PowerShell is so complex and the implications for getting it wrong can be so dire, having a reliable, repeatable process (and especially one that could be changed in the future) is essential.

Your PowerShell Scripts need Support

Your PowerShell scripts shouldn’t be created and then just left alone. Things like comment-based help and modularization are necessary if you intend to keep them around for the long run. PowerShell scripts are versatile tools and don’t have to be executed alone. Tools like ProGet or Otter work with your scripts to level up your PowerShell usage, extend the usefulness, and prolong the life of your scripts.  

SO WHAT?

Align the Technology with the People You Have

PowerShell is a very complex scripting language. It’s easy to get caught up in technical questions and forget about the human element. But you can level up your team’s PowerShell use by rethinking the relationship between your team and PowerShell and by incorporating better tools and processes to help PowerShell and your humans work better together.

Level Up Faster

If you embrace the idea of different roles/ways of using PowerShell, you increase skills while decreasing the skills needed to “level up.” Using video game parlance, you can increase Experience points (XP) faster while lowering the amount of XP needed to reach the next level. Like unlocking a super-sword, better tools and processes can help those with lower XP use PowerShell at a higher level faster.

Leveling up PowerShell depends not just on “hard” skills like learning better ways to use PowerShell but also on “soft” skills like good communication workflows (e.g., efficiently getting scripts from PowerShell experts to PowerShell users and working with those with lower PowerShell expertise). By developing and documenting internal processes, you avoid repeated work and wasted time.

While the highest-level PowerShell experts (who you may not even need or have on your team) are full-fledged developers with knowledge of C#, automated testing, CI/CD, and other advanced processes, just using PowerShell doesn’t require that level of training. The threshold to enter the world of PowerShell should be lower today than it was in the past. By taking to heart the different levels of PowerShell, that there is no single “PowerShell guru,” and treating your scripts as assets and SOP, you can level up faster than ever!

This is just the tip of the iceberg for all things PowerShell. For many more ways to give your PowerShell scripts and modules a boost, take a look at our free eBook, “Ultimate Powershell Levelup Guide”. Sign up for your copy today!