PowerShell Conference EU 2019 was, as always, an excellent learning experience, a wonderful week with old friends, and a chance to meet new friends. My particular favorite sessions that I attended were given by “Walter Legowski” (security researcher and International Man of Mystery) on sketchy fun with PowerShell, Stephane van Gulick (classy trilingual lover of sportswear that would be garish on anyone else) on his PSHTML module and Polaris, Staffan Gustaffson (will argue your ear off in the hotel bar about epistemology if you admit to being religious) on using a profiler with PowerShell, and Daniel Silva (newcomer making IoT accessible via RaspberryPi to the old Windows server ops crowd) proving that indeed, everyone loves LEDs. I saw several more good sessions, but these are the ones that I’m still thinking about a week later.

However, the session I learned the most from was my own little lightning talk – definitely not for the subject matter (Kubernetes bare basics + the PowerShell ConvertFrom-Json trick), but for finally learning a process for developing and then refining a technical talk from the creator and maintainer of dbatools, Chrissy LeMaire. Her excellence in speaking is a major factor in that project’s success – not only in attracting users, but in building and maintaining a broad community of contributors.

Chrissy’s own process probably differs somewhat from the points I took from her guidance, but this is stuff I want to really remember and that might help others.

Tip #1: Try freestyling your session at least once before starting on slides

“Ok, now stand up and give me your talk.”

“Oh, but I’ve only started my slides – I think I’ll need another half hour before I have anything!”

”You don’t need slides yet – just give me the explanation part and then show your code so that we can see how long it currently is.”

This was the big eye-opener. I’d always opened PowerPoint first and started writing once I’d decided what code I wanted to present, planning to cut or add as needed. Chrissy had me do the reverse. She timed my “freestyle” session, and then gave me some content notes, pointing out the things I mentioned that she didn’t know much about and that my audience was also likely to need more basic info about to follow my code: Kubernetes, AKS (Azure Kubernetes Service).

Tip #2: Do not try to make one slide do the work of five, or do all of *your* work

“There’s too many damn words on that slide! There should not be several completes sentences on a slide. Split it up!”

“Your slides should keep you and the audience on track, not tell them everything they need to know.”

After giving me awhile to do my slides, Chrissy had me run through the talk again. She reminded me that the presentation I was disappointed in a few years ago was due, in great part, to my slide deck. The bigger problem there was due to there being too much on the slides, more so than the count. She encouraged me to split my backgrounder slide into five, one for each of the major points I was making, and then to just leave a few words about each topic, removing the sentences. She also pointed out where I was digressing into unnecessary detail or anecdote that was not central to my topic.

Tip #3: If you have to scroll back and forth in your demo code, re-order your code

Once we were happy with the explanatory portion of my talk, Chrissy had me go through my code again, timing me. She noticed that I was doing an awful lot of scrolling, up and down, so pointed out that re-ordering the code would make things go smoother.

After re-ordering and doing a bit of cleanup, she had me present the code portion again.

Tip #4: Think of your talk in segments and work on them separately

Breaking my 10 minute talk into two segments made developing and then practicing them less intimidating, plus gave me the confidence that I was going to have enough time for the “fun” part (code) because I knew I only needed five minutes to get through the introductory explanation. This has the added benefit of making the talk more modular: you can tailor the same basic talk for a user group that wants you to talk for 30 minutes or for a conference that has 75-minute sessions. For this particular talk, if I want to add more Azure platform information, I just have one new segment to write and learn; or conversely, I now have a five-minute snippet I could present in an even more constrained lightning talk format.

Tip #5: Practice, practice, practice… then practice again.

I didn’t practice the completed presentation as many times as Chrissy recommended (three), let alone as much as she generally does, but it was more than I have in the past, given how much I practiced while developing the slide deck and re-ordering my code.

Steve Jobs would clear his calendar for a month before a big Apple event, and I’ve seen Chrissy spend evenings practicing a talk she had written well in advance. Especially for beginning speakers, the more you rehearse, the more natural you will sound. Do not make the mistake of thinking, “if I practice it too much, I’ll sound stilted.” I’ve seen lots of presentations over the years that would have been better, and speakers who would have had a better time on stage, had they practiced it a few times, by themselves and for an audience.

Tip #6: Get peer feedback throughout the process

Feedback from a PowerShell expert new to Kubernetes, like Chrissy, was more valuable than from a Kubernetes expert unfamiliar with PowerShell, but the latter would have been a good addition to make sure my Kubernetes statements were correct. Even feedback from someone outside of IT, like my mechanical-engineer husband, would have been more helpful than developing the talk on my own. It’s much like having a classmate edit your drafts back in English class: you might not incorporate or even agree with all of their feedback, but having the feedback available throughout the process makes it more useful.

Self-Assessment

For a talk created mostly the night before (after scrapping a more boring initial concept), I think it went well. It would have been better if I’d started the process earlier, allowing more time for feedback.

Things I did well this time:

• hit all the points I wanted to discuss without digressing into less-relevant matters
• fit it into my alloted timeslot exactly, which is a courtesy for the attendees and other speakers
• used slides to keep me and audience focused rather than to explain details
• sparked interest for Kubernetes in a community that I didn’t think would have much

Things I’m going to do differently in the future:

• ask audience to hold questions for later at beginning of talk – in the moment, I answered that first question, which opened the metaphorical floodgates. I should have asked that questioner and subsequent ones to find me afterwards for details.
• “pre-run” code so that I don’t waste our time in case someone wants to see the results (another in-session question)
• find out what PowerShell (legacy Windows ops) people need to know about Kubernetes – I’ve been near it for so long that I’ve lost sight of what I had to learn to be a somewhat-competent administrator
• practice, practice, and then practice some more 🙂

Thanks again to Chrissy for her good advice, encouragement, constructive criticism, positive peer pressure, and above all, patience.

See this talk for yourself, and please leave feedback in this post’s comments, both on style and content: (will add, if recording came out!)

Resources (slides and demo code): Kubernetes and PowerShell

See Chrissy “freestyling” (live-coding) on Twitch, which I’m not nearly brave enough to do: http://sqlps.io/twitch