Well, it’s officially Blogtober! Blogtober is all about the community. Blogging is only a part of contributing what you know for the greater good. Once you start contributing, it is extremely satisfying.
As a leader of two VMware User Groups, the holy grail in the community is to find a community member that is willing to speak in public and watch what it does to their IT career. It is very difficult to find folks willing to present, but when a community member that gets the presentation bug, an amazing thing happens. You don’t need to find them anymore, they find you! I have seen it several times, and my goal is to do anything I can to help groom future community members to help get them to the next level.
I decided it was worth the time to form a professional development presentation and try it out at a couple events in Q4 of 2017. The two events will be the Atlanta UserCon on October 19th, and one of the largest Minnesota IT Conferences (The Minnesota State Government IT Symposium) on December 6th. The presentation isn’t finished yet, but this is the idea.
Everyone is aware of the stereotype. The IT Engineer has historically been pigeon-holed as the socially awkward, flood-pants-wearing, top-shirt-buttoned introvert that has been portrayed on many a TV show. Whereas this stereotype isn’t always incorrect, the fact remains that most Information Technology Engineers should make it a point to hone their public speaking skills. Here are some common excuses why these people don’t want to present.
- I don’t have anything I am working on that interests this crowd.
- My work won’t let me present on anything due to disclosure rules.
- I’ve got a big project coming up… maybe I will present on it after it’s over!
- I don’t have enough time, I’m too busy!
- I’m too shy… and my job doesn’t require public speaking anyway.
The first step in alleviating these concerns is to make sure the prospective speaker understands they may be mistaken. Once you get through the “why not”, you can move on to the “why.”
Engineers may not understand that lots of people are fascinated by simple, operational presentations. We all want to know what others are doing. Most audiences are formed by folks from many verticals, and all organizational sizes. Leaders should enable SMB customers to present by creating a platform for those speakers to flourish.
Engineers that are worried about disclosure rules are typically from larger enterprises. If that is the case, make sure that they know there is value in presenting on a concept or strategy, and not an actual production environment. Sometimes a large enterprise test environment will be exempt from these disclosure rules.
It is understandable that a large project could be a great opportunity for a presentation. The fact is, that large project can often turn from a 3-6 month endeavor to something that lasts a year or more or never truly finishes at all. There is good value in presenting on the earlier phases in a project. Sometimes a presentation on how you arrived to your decisions regarding product selection, architectural decision-points, or infrastructure components, make for an interesting breakout.
Engineers who claim they are too busy may have their priorities out of whack. I have seen many groups that claim they are too busy, yet their processes are making it impossible for them to become more productive. Now for my favorite analogy. Back in 6th grade, I took my first typing class. I remember how frustrating it was. Why would I possibly want to learn to type? I could hunt-and-peck to about 20 words-per-minute. Once I started learning how to type properly, my production was reduced to around 10 words-per-minute. Down the road, I got better and increased my output to a much higher level than my best hunt-and-peck days.
Automation provides the same analogy. Using a GUI that is familiar will bring a standard level of production that will plateau. Learning to script will reduce your productivity while you are learning the skill, but far surpass it once you have mastered it.
Why the above analogies? A team that is having trouble communicating will reduce its productivity. Simple miscommunication will increase the amount of time it takes to finish a project. Presenting in public is a great way to practice organizing your ideas in a way that is understood by those in your audience. This will save you time in the end.
Now on to the “why”. For the Engineer that says they are too shy and their job doesn’t require public speaking… don’t be too sure your job doesn’t require it. Although it may not require “public” speaking, there are many times that you may need to “present.” It may just be a simple thought you are trying to convey to a colleague. It may be your CTO asking you why we need a product that just so happens to be your livelihood at your job. It might be your lead architect asking you critical questions about a change you are making at your CAB meeting.
There are many opportunities for you to present at work. Honing your public presentation skills are the best way to gather your thoughts, and present them in an understandable manner.
The most important thing to understand, is people want to hear what you have to say. I have sat through many post-VMUG UserCon event briefings. Each time we talk about the feedback ratings for the community sessions, they are usually the highest rated sessions compared to VMware breakouts, and vendor breakouts. This includes the first-time presenters we have invited.
If you are thinking about presenting at a local group meeting, or a conference, I hope this helps get you over the hump. Try it out!