Level Up Your Entire Team's PowerShell
by Crista Perlton, on Feb 16, 2021 3:32:03 AM
There are TONS of articles teaching you how to get better at PowerShell. This isn’t one of them. In this article, get 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:
- You can't just have a PowerShell guru.
- Embrace the various levels of PowerShell expertise.
- You're probably already using PowerShell even if you don't think you are.
- Remember that not all scripts are PowerShell.
- PowerShell scripts are processes, company assets, and standardized operating procedures.
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 just relying on Heidi the PowerShell expert will slow down (or block) your PowerShell level-up. This is for two reasons:
- 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.
- 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?
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 obviously very good drawing 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 Heidi the 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 the relative "experience points" needed to work at that role.
|1||Uses THE PowerShell||anyone who knows how to open the literal PowerShell shell/command line. Everyone uses it, as it's only way to run/use cmdlets|
|10||Runs Scripts||knows what a script is and how to carefully paste in parameters|
|50||Reads Scripts||can understand what most do by reading it and knows how to research cmdlets|
|200||Modifies Scripts||makes changes to existing scripts to solve a somewhat different problem but does NOT write wholly new scripts|
|1,000||Creates Scripts||identifies problems and creates a wholly new/mostly new script to solve that problem|
|10,000||Develops Modules||creates and packages functions into modules can be used to help create scripts|
|50,000||Develops cmdlets||uses C# to write, test, and build cmdlets that are packaged in modules|
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.
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, like Sam, 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.
As an avid karaoke singer, I love this analogy: If you can perfectly sing a song in another language, does it matter if you don’t know that language or what you’re saying? To your listeners, it won’t matter as long as you sing the lyrics correctly and you perform well! The same holds for running PowerShell scripts.
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. As you know, 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 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.)
Your PowerShell scripts aren’t just processes; they’re also company assets AND standardized operational procedures (SOP).
PowerShell scripts both describe and execute some process. 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 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 process. 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). You can learn how to adapt your SCM usage for scripts in our upcoming guide.
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 future) is essential.
Align the Technology with the People You Have
PowerShell is a very complex scripting language. It’s easy to get caught up in the technical questions and to forget about the human elements. 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 THE PowerShell doesn’t require that level of training. The threshold to enter the world of PowerShell should be, can be, and is actually 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!
Help Shape the Guide
We’re creating a guide to address these people parts of PowerShell and to help you answer the question “How can my Ops team live in a world where we DON’T ‘just have a PowerShell guru’?”