I need PowerShell, you need PowerShell, we all need PowerShell…but getting the time to invest in learning the technology can be a challenge! We all have a lot of pressure to be productive with our regular work tasks. When this pressure is combined with existing proficiency in another scripting language, it can be a recipe for not moving forward.
In this article, I’ll discuss how becoming an advocate for PowerShell in your company helps create the room for yourself and others to learn this critical IT skill. The information we’ll discuss is sourced from my own experiments while advocating PowerShell adoption within an IT group of about 250.
Before we get started I should mention that a similar approach could be used for a lot of other technologies or methods at your company - just be sure that you’ll have a sufficient audience to maintain momentum.
A champion or advocate is someone who is passionate enough about the interests of others to act on their behalf. An advocate does not need to be the end-all and be-all PowerShell expert in the company. The focus of this role is to bring people together and encourage them to invest their skills in PowerShell for the benefit of their colleagues, their company, and their careers. Championing PowerShell is a great way to contribute and to grow. All you need is a little initiative and some ideas.
Each new skill we transform into a day-in day-out proficiency is backed by countless, regular attempts to apply the skill to real-world problems that cross our desk. This critical informal learning stage tends to be quite lonely and unsupported. An advocacy program helps rally resources, time and peer connections around individuals who are in this stage of learning.
A company internal initiative has some unique advantages over typical user group scenarios in that [a] it can be leveraged in every work day rather than monthly – putting the help close to the richest learning opportunities, [b] it can help simultaneously build competency and teamwork between a group of colleagues who will be together for a long time, [c] it can have a much more interactive focus, [d] in many cases they can be during work time or at least at the same locations as work.
Having a scheduled event on everyone’s calendars is very effective because this gives participants an excuse to take a break from work and focus on learning. A scheduled meetup on participant’s calendars reminds them of the commitment they’ve made to develop their skills and clears some space from the production demands on their time. I also feel “Meetup” is a preferable term to “meeting” as it connotes a more fun, social, and engaging event than formal meetings. They key is to have the meetings be live – whether they are completely online or a blend of online and physical. If possible, they can be recorded so that people who join the effort (or your company) later can catchup on past content.
Sponsor Coding Clinics (Meetup)
Coding clinics allow new coders to have roadblocks removed from their attempt to solve a real-world work problem. The essential concept is to bring together those in your organization who know more about PowerShell and those who want to learn. Again, you don’t have to be the top PowerShell dog to sponsor the effort. It is a good idea to download a couple free PDF PowerShell guides so that if some participants do not have a production script to work on, they can work though the activities in these resources. Participants can also be reminded to bring the exercise materials from any formal training they’ve taken and work through them again during these sessions.
Encourage Peers to Share Code They’ve Written (Meetup)
If your code shares are live, pair the presenter with a co-presenter (as advocate you are a prime candidate for co-presenter) who helps the presenter flesh out their information at a level that the audience can connect with. It is typical of someone who is very familiar with a language or piece of code to skip over details they consider self-evident. In many cases these details are critical to understanding. A co-presenter can ask curious questions (that they may know the answer to) to guide the presenter to flesh out these critical details. Having a co-presenter also allows experts to relax (some of whom do not enjoy being in front of a crowd) and to not worry quite so much about preparation. Post any discussed code somewhere that participants can access it. It is good early on to invite people who are not necessarily PowerShell experts to share their code. Keep the sessions interactive by allowing people to ask questions and interact. I have seen more than one codeshare session where the presenter learned a few gems from participants.
Offer to review presenter’s materials and/or do a walkthrough session with them before they deliver the material.
Be Available for Code Reviews
Offer to be available to help others review their code for best practice and to help with debugging. It has been interesting to me that just the process of going through with another interested party is very helpful. I remember a specific code review early on where the script was working with technologies I was unfamiliar with and the coder was better at PowerShell than I was. As we walked through they discovered several needed changes just because they had to articulate how the code was intended to work as we went through line by line. I didn’t actually add anything to the mix via my PowerShell knowledge – but the activity resulted in a lot of learning for me and some significant code improvements for them.
Enable Resource Sharing
A very good way to advocate is to be a self-appointed librarian of helpful resources. You can find a central location or cloud drive where you can collect and organize downloadable resources and pointers to online resources. People appreciate being able to look through a smaller list of resources that they know someone has taken a few minutes to review and deem worthy of their attention. Usually all this takes is a few extra minutes to file resources that you will be searching for and stumbling across while researching for your current scripting activities.
Maintain a Shared Code Library
I am the lead PowerShell coder for developing a PowerShell template for application packaging and deployment. It is somewhat agile by virtue of publishing it on a regular monthly schedule. When I am building functionality I try to keep a keen eye on things that will be useful for other IT groups – if a little extra effort will make a new function usable by more IT groups, I will put in the effort if I have the time. One of the primary reasons for taking up the template was actually to allow my group to move into PowerShell more easily. The template is specifically designed to be discoverable by utilizing many of PowerShell’s built-in self-describing mechanisms. Scripters are able to [a] list all template functions with descriptions, [b] list all template variables with descriptions, and [c] use special functions designed only to be used for template development to make it easier. The core of this template and some slides discussing the importance of templating for an enterprise team are available at the eLearning link at the end of this article.
Start a Yammer Group and Post to It Regularly
If your company endorses or tolerates Yammer, you can leverage it to create a buzz about PowerShell in your organization. You can use this to get some momentum around sharing questions, answers, resources and discoveries. A good approach is to invite everyone to contribute, but put yourself on a schedule to post at least once a week. You can post small tips or even links to other PowerShell tidbits. Don’t feel that you have to generate all kinds of original material - the main point is to curate and share information. Yammer followers will really appreciate that someone with knowledge of their company deems a specific PowerShell tidbit to be relevant.
Be a Central Point of Contact and Coordination
This one is not hard to do at all – it’s all about attitude. If you respond cheerfully and helpfully to any requests for information or for locating resources for PowerShell, you will automatically start to become a go-to person for learning more. As people come to you, you end up being prodded to learn more often and on topics beyond your IT specialty. After a while it becomes a self-sustaining cycle – you know more and can help more, so more people come to you which causes you to learn more that can be shared.
Be a Source of Expertise
As you grow along with the group, your personal expertise will grow and you can help others more. But you can be a source of much, much more expertise by keeping tabs on the other PowerShell experts in your organization. You can also direct people to others who have built special skills or who apply PowerShell to specific technologies or knowledge domains. Who is the best PowerShell AD guru? Who does security the best and who has done innovative work with PowerShell and SQL? By knowing who’s who in your organization you can be a source of much more expertise than you can possibly house in your own head.
Don’t Do Formal Training
Whoa, did I just say that? Yep. Formal training whether by book, video, or classroom is helpful and obviously can play a key role in taking on new skills. However, the concept of being a company internal champion is to focus on the support needed to nurture the informal, day-by-day process of truly mastering a skill. If you hold meetings, participants may expect that you are going to do yet another lecture series on PowerShell. My preference was also to try to stay away from content that built upon past events or materials so that participants wouldn’t feel that they’d be lost if they missed a couple events and then drop out altogether. This aspect was another way in which the program deemphasized formal learning approaches in order to put emphasis on how informal learning really happens. To try to get everyone on the same page, I created a kick-off slide deck that tried to bring the point home that this PowerShell effort was addressing the informal needs. You can find a slides video of this session as well as download the slides at http://elearning.csi-windows.com.
Depending on the size and culture of your organization and the type of activities you undertake, you may not need formal authorization from anyone to be an advocate. You can start by simply reaching out to others. To be most effective, an advocacy program would be empowered to have people use some on-the-clock time to meet and participate in peer learning activities – not only will participation be higher, but it shows a level of commitment by the organization. If you might have a challenge getting this justified with your management, it can be helpful to use the ideas in this article to formulate a semi-formal program. Your approach to getting to this point can be an important part of whether you can receive the go ahead. For instance, starting a Yammer group is usually something you can do on your own initiative. Once it gets some momentum and is perceived as boosting IT productivity, you will be in a better position to approach management about some monthly on-work-time code shares.
Think of the above list as a menu – you can pick and choose parts to build a program that fits with your company culture and does not overwhelm you or any others who would like to help with organization.
In the end, one of the most enjoyable aspects of championing is the same as the reason I love doing technical training. When you play a role in helping people improve their skills and careers they show you genuine appreciation. For me, this aspect is a top reward!
“Champion” also means someone who is looked up to as a top talent in their field. Don’t be surprised if championing PowerShell transforms you into a PowerShell Champion.
Sound Off: What are some of the interesting technology advocacy activities you have been a part of or heard of?