Speaking at User Groups

I recently had the opportunity to speak at a user group, the Australia and New Zealand PowerShell & DevOps User Group for their October 2019 session, to be specific. It was my first ever time doing something like this so I wasn’t entirely sure what to expect.

It came about via Twitter as Brett Miller (@BrettMiller_IT) re-tweated an open invite by Josh King (@WindosNZ), one of the user group organisers. There may have also been alcohol involved but that’s not the point. It was only a 30 minute slot in the end but after watching it back there are a few points to note for next time; some things I did right, not so right, and some I just don’t want to do again should there be a next time.

Preparation and Planning

Accessibility

Always think of this up-front if you can. At some point you are going to show something, perhaps on a projector or across screen-sharing. Try to make sure you take this into account as you prepare any materials.

The slide-deck I prepared had a dark background and green text, while I personally like this, it might not be the best for projecting.

I decided to duplicate the deck with a light background, just in-case any part of the user group would be using a projector. While I’m glad I did this, and will continue to keep both up to date, it was a waste of effort at the time. Should I have checked with Josh he would have let me know that it was just Teams this time round, with no one presenting to a room.

I’ll probably look into accessibility a little more to ensure I maintain a deck format that is widely re-usable to save re-work. I just like the darker one so will continue to use it and evolve it as required.

Know your point

Decide very early-on what point(s) you want to get across. What do you want your audience to come away knowing?

This can change as you develop your idea(s) but at least try to keep to a plan if time is limited otherwise you may end up under increased pressure as the time comes closer to present.

I had decided this quite early but actually changed slightly at the last minute due to not finishing everything I wanted to; bringing us on to

Know your time

The original slot was ‘up to an hour’, so I planned to take 45-50 minutes for the talk, 5 minutes for trying and failiing to fix any bugs that came up and pivot, and at least 5 minutes at the end for a few questions or minutes of silence (it’s often the latter, I’m told).

The time was reduced due to another speaker, Mike Kanakos, volunteering to better inform people about the security benefits of enabling and using PowerShell Remoting over legacy protocols such as Remote Desktop (this intro doesn’t do the depth or breadth justice so give it a watch, he’s on after about 35-ish minutes). This actually went in my favour as it forced me to focus on key areas – there are quite a few components in what I was showing and, with it being across video conferencing, you’re never sure how your audience is handling the content, speed, or even speaker. I was reasonably confident that I could get it down to 30 minutes but just to make sure I’d gone over it with a friend the day before (nothing like a last minute review session to keep you on your toes)

Rehearse

Try to use a friend or colleague; they don’t even have to know the topic, in fact it might sometimes be better they don’t – depending on the level you’re pitching at. Ideally someone who isn’t afraid to ask questions, and you’ll need to be patient if they do. Either update your talk to provide additional context or information, or reserve additional question time in the talk if you think you’ll get these questions again.

While the topic I had chosen, “PowerShell Module Development using Azure DevOps“, is actually an intermediate topic (in my opinion), I still planned to show novice PowerShell users how easy it can be to create high quality modules. You just need to have a good starting point and guides to keep you on the right path.

I went over the content with a friend and former colleage. He is another engineer that likes talking about cloud, automation, and technology in general. I showed him the mini-project I’d created for the talk and we reviewed the basic slides I’d prepared to ensure the right points were being made.

I could tell from his reaction that there was a lot of content and I risked losing audience members due to the amount of information coming across. I decided to simplify things by not reviewing the code, but instead reviewing the ‘why‘ of the code. It was still a lot of content for 30 minutes.

In future I think I’ll break it down even more and focus on a single important aspect a little more, or just request more time. I’ll figure this out in time I’m sure.

Refactor (responsibly)

Your talk isn’t going to be perfect. You will most likely have lots of changes you want to make. I’d say either add those changes to a backlog or, if you really can’t settle until making them, make changes on a branch/copy of your work and give it time to bed-in. If you like your changes after they’ve had time to bake, bring them in and refactor your talk. There is no harm in making changes, you just don’t want to fall into the habit of constantly tweaking and risking losing the actual benefit of your talk for others. Spending hours tweaking the formatting may make it ‘look better’, but if your only going to have it shown for a minute is there that much point?

There were a few times where I caught myself tweaking the console output for something that would unlikely be seen. This is just something I have to watch out for and catch before it wastes too much time – things like these should really be classed as ‘nice-to-have’ and tagged accordingly. Often just getting the requirement written down is enough to let your mind move on from it. I ended up using Azure Boards and Pester Tests to track my work and what I ‘needed’ to get done, helping to control and reduce the detours.

Prepare the area

No matter the equipment you’re using, you’re going to benefit from a quiet and well lit space. Your audience want to hear and see you.

If presenting remotely, your mic is going to want as little background noise as possible and your webcam as much light – think about this before the talk. Of course nothing states that you have to be seen, perhaps this makes you uncomfortable – just explain it to the host before hand and don’t have your webcam on. Get your slides and desktop ready to be shared, sit-back, relax (you’re still going to need to be heard, so make sure that is the case by having a chat with the host before the start of the session)

I decided to trust my dog Bruce to stay in his bed under my desk. This was a mistake. He remained silent right up until I started my presentation, he knew. Throughout the video I could hear him scratching his collar or chewing something. At various points you even see me having to push him away as he wanted attention or to jump on the desk; something he at least waited for the end of my session to do!

At the talk

Arrive Early

Whether in-person of via conferencing tools (this was a Microsoft Teams meeting) you want to get into the meeting a little early. This gives you time to meet you host(s) and have a few minutes to introduce yourself in a frienly manner and thank them for the invite and the time they’ve given you. It will also give you time to check your setup is working, font-sizes are ok, and general audience accessibility has been taken care of.

Talk don’t Teach

This is a weird one as I will always encourage teaching others what you know, sharing knowledge, and generally helping people become better quicker. User Groups are a collection of like minded individuals just sharing experience and knowledge on a common topic; for this reason you are just there as an equal, not an expert. This is good as it reduces the pressure on the speaker.

Talk to the Audience

I wasn’t great at this, at the beginning of my talk I am often looking to the side or leaning on my desk, as if on a call and not in front of a (virtual) room full of people staring at me.

Even virtual user groups need to be treated as in-person. You’re going to need to pretend that your webcam is a person; perhaps I’ll stick a smiley face around mine.

Don’t rush

Take your time. While you want to finish and have time for questions, you don’t want every question to be because you were rusing the entire demo.

Break between sections. One or two seconds can be enough to keep the pace comfortable for those watching. If it’s tough to talk about, it’s tough to listen to and follow.

Breathe and relax. Air is kind of important.

Don’t panic

Remember, you are hoping the audience will learn something from you, so in return learn from them or the experience of the talk. Don’t worry or fret over it. The worst thing that can happen is you get it wrong and have to start again or come back, no one will judge – these are just people who see a lot of errors on thier screens all day too.

Closing

The experience wasn’t that bad by the end, no real difference to talking to my former team or customers about something you wish to share.

I’m hoping to do some more in the future but first I need to write up the work created for this session. As agreed with Josh, I’m looking to put the work and slides up on Github once I’ve worked through a couple of issues with it.

*Point to note, if you’re going to publish something to the PowerShell Gallery, check the module name isn’t already in use!

Share

Let me know what you think in the comments.