Sink or Swim

A few weeks ago in “Conquer Your Fears: Public Speaking in Your Underwear,” I encouraged people to submit an abstract to speak at the Fall 2007 PASS Community Summit. The deadline for submitting abstracts for that conference has passed, but I wanted to expound a bit more on the benefits of giving presentations in the IT community. I know I can’t convince everyone to dip their toes into the waters of speakerdom, and to be honest, not all toes should be dipped. But I suspect that many of your toes are ready for dipping and you just need little a push to get in the water. I’ll consider my time writing this week’s editorial well spent if I can help launch just a few of you.

A recent reader poll that ran on the SQL Server Magazine home page (http://www.sqlmag.com) asked, “Do you ever present at IT conferences?” 63 readers responded as follows:

(Note: Yes, that adds up to 101%--the Web site admits it has a problem with rounding.)

Now 63 responses don’t necessarily constitute the world’s largest and most statistically accurate demographic sample. Clearly, most of the respondents don’t regularly speak at conferences--and many find the thought horrifying. But I was a bit surprised that the number of people who said they’d been speakers was as high as it was. The reality is that the number of conference speaking slots at national conferences is limited, so a large percentage of the SQL Server community might not have the chance to speak at a major show.

However, speaking opportunities are often where you look for them. I’ve been involved in running local Microsoft-focused user groups for about 15 years and I know that most user groups are always on the lookout for experts who are interested in “dipping their toes.” Plus, I’m confident that most of you work at companies that would love to have you present a lunchtime “brown bag” session for the edification of your peers. So the lack of speaking slots at major conferences isn’t a good excuse.

Presenting a session--whether at a major conference or during lunch in your company’s conference room--is a lot of work and certainly exposes you to the risk of looking silly. So why would anyone want to go down this path? From my perspective, it’s all about career management. Giving a talk about something you know doesn’t inherently make you an expert and doesn’t implicitly mean you’re smarter or more talented than your less vocal peers. But, speaking certainly is one way to differentiate yourself from your peers in our competitive professional worlds. And although speaking doesn’t magically make you an expert, it does grant you credibility that suggests that you have more advanced knowledge than your peers.

Honestly, I wasn’t an expert the first time that I stood up in front of a crowd to give a talk, and to be blunt, I probably wasn’t very good at it. With few exceptions, even the most widely acclaimed speakers on the conference tour didn’t drop out of their mothers womb as an expert in technical or presentation skills, and most speakers weren’t experts for their first, second, or third talks. But as I said a few weeks ago, speaking is one of the best motivators to help you master a subject. It’s embarrassing to give a talk on a topic that you clearly don’t know inside and out. Forcing yourself to speak regularly will help you to propel yourself towards expert status and mastery of a subject area.

And what about the money? Trust me, very few people in IT make any sort of substantial income directly from speaking at conferences. But, speakers are often highly regarded in the IT community, so the recognition you get from speaking can open a tremendous number of doors.

So although speaking doesn’t automatically make you an expert or land you a better job, choosing to give a presentation, even at your local user group, will force you to be a better technician, make it more likely that you become an expert, and can lead to opportunities that you might not otherwise have been presented with. Enough said. I’ve done my good deed for the week. Go forth and speak.

From the Blogs

My initial goal in writing this series of posts was to outline some of the concerns surrounding Availability Groups (AGs) and SQL Server Agent Jobs – and call out how there is virtually no guidance from Microsoft on this front and then detail some of the pitfalls and options available for tackling this problem domain. I initially expected this series of posts to have between 25 and 30 posts – according to some of the early outlines I created ‘way back when’....More

Throughout this series of posts I’ve taken a somewhat pessimistic view of how SQL Server Agent jobs are managed within most organizations – meaning that most of the code and examples I’ve provided up until this point were based on assumptions about how CHANGE to jobs is managed. That pessimism, to date, has come in two forms:...More

In this series of posts I’ve called out some of the concerns related to SQL Server AlwaysOn Availability Groups and their interaction with SQL Server Agent jobs – both in the form of Batch Jobs (see post #3) and backups....More