Reminder: SQL Saturday #714, Philadelphia

This is a reminder that this coming Saturday, April 21, I will be speaking at SQL Saturday #714, Philadelphia (more accurately, Blue Bell, PA).  Go to the link to register for the event.

I will be giving my career/job hunt presentation, entitled: “I lost my job!  Now what?!?

Hope to see you there!

Advertisements

Suppose you gave a presentation, and nobody came?

“When life gives you lemons, make lemonade.”
— unknown

“S**t happens.”
— unknown (or Forrest Gump — take your pick)

An article by my friend, Greg Moore, reminded me of a SQL Saturday presentation that I was supposed to do in Philadelphia last year.  It was one of the first sessions that afternoon, right after the lunch break.

My total attendance for my presentation: zero.

I don’t remember how long I waited for people — anyone, really — to show up; it might have been about ten or fifteen minutes before I packed up my laptop and left the room.  I was disappointed and even a little hurt.  How is it that I drive four hours to give a presentation, and nobody shows up?  At the same time, I also tried not to take it personally.  I posted my experience to my Facebook page to get it out of my system, I pretty much said “stuff happens,” and I shrugged it off.

I found out later that a large number of attendees — I don’t know how many, but I’ll guess about half — left the conference right after lunch.

(For what it’s worth, I actually gave two presentations that day.  My morning presentation was well-attended, and went very well.)

I also did a presentation at my hometown SQL Saturday last year.  Unlike Philadelphia, people did show up — there were five people, not including myself, in the room.  But for all intents and purposes, the room might as well have been empty.

Those of you who know me or who’ve seen my presentations know that I do my best to get my audience engaged.  I’ll ask questions, I’ll ask for volunteers, and I’ll ask for feedback.  I don’t like to lecture — that is, talk at an audience.  My preferred modus operandi for teaching is to have a discussion where I act as a facilitator.  I want to make sure that I’m making my audience’s time worthwhile.

However, this was problematic at this particular presentation.  These people were the five most introverted people I’ve ever had for an audience.  They barely responded at all.  During my presentation, the only acknowledgement I saw were a few barely discernible nods.  I had to force someone to volunteer for my demo (and she did not even come to the front of the room).  Trying to get these people to respond in any way, shape, or form was like pulling teeth.  Despite asking if anyone had questions, the only questions I got was from the event photographer — who was a friend of mine — going from room to room taking pictures.  (He saw my dilemma and decided to speak up.  After my presentation, I flagged him down and said to him, where the hell were you earlier?!?)

I won’t lie.  I was very disappointed with my audience in that presentation.  There might have been five people in the audience, but for what it’s worth, I might as well have been talking to an empty room.

Greg cites an article by Catherine Wilhelmsen where she talks about a similar experience.  (Her article is a great read; go check it out!)  As it’s often been said, s**t happens.  Failures happen.  Sometimes, all you can do is take your lumps, shake it off, and move on.

(Speaking of which, check out my previous article where I talk about screwing up not necessarily being a bad thing.)

I used to teach part-time at a local business school (roughly at the community college level).  Every now and then, my students would show up late.  (That’s where I learned that the ten minute rule applied to teachers, too.)  More often than not, however, my students did eventually show up.

I often joke that if I hold a class, a presentation, or a lecture where nobody shows up, I’ll start talking to the empty room — and see if anyone notices.  Some people have told me in reply that it’s an opportunity to practice your presentation.

Sometimes, things happen that are beyond your control.  Often, your first instinct is to be disappointed and take it personally (at least I know mine is).  Whenever such an event occurs, ask yourself if you could’ve done anything differently to avert the situation.  If the answer is yes, then learn from it and remember it for the next time.  But if the answer is no, then there’s nothing you can really do.  In either case, just shrug it off, move on, and try again next time.

The art of talking technology to non-technical people

“Eschew obfuscation.”
— unknown

Let’s discuss how to tie a tie.  First, you take the tie and put it around your neck, making sure that it lies within your shirt collar.  Make sure the seam is facing toward your body, and the wider end of the tie hangs down roughly two-thirds of the length of the tie.  In other words, the wider end should hang down farther than the narrower end.  Take the larger end over the narrower end.  Wrap it around once so that it forms a knot.  Take the larger end and put it through the knot you created.  Once that’s done, pull it tight.  Adjust your tie by pulling on the narrow end, which should now be behind the wide end.  Your tie should now appear neat and flush against your shirt.

Raise your hand if you actually followed the above paragraph.  And when I say “followed,” I mean that you read (as opposed to skimmed) through the entire paragraph, following every step and not falling asleep while reading it.  I’ll bet that not a lot of hands are up.

Yet this is exactly the way that so many technologists tend to write when they are asked to convey a set of instructions.  They will write (or talk) in lengthy detail, explaining every little thing and believing that the reader (or listener) is soaking up every detail and is in rapt fascination of the subject, holding on to every single word.

Oh, if only that was true.  If that was the case, we wouldn’t have technical writers.

I wrote a couple of articles a while back about tech writing frustration and why design matters.  They provide some thoughts that are directly related to this article, so I suggest you read them before continuing with this article.  If you haven’t read them yet, check them out.  Go ahead.  I’ll wait.

At this point, I’m trusting that you understand at least some of the principles behind good writing and design.  (If you don’t, and you didn’t read those previous articles, shame on you.)  Many, if not all, of them come into play when talking about talking to a non-technical audience.

Giving (and taking) instructions is hard

Let’s talk about that initial tie instruction paragraph for a moment.

This is a demo I use in two of my presentations.  I ask for a volunteer, preferably someone who does not know how to tie a tie.  I hand him or her a tie, and give that person simple instructions: “put it on.”  Of course, if the person doesn’t know how to put on a tie, he or she is likely to struggle doing so.

At that point, I get the rest of the audience involved.  My instructions to the rest of the group: “you folks are the help desk.  Tell this person how to put on the tie!”

I’ve done this demo to varying degrees of success.  In some cases, the audience does a very good job of explaining how to tie the tie, and it ends up looking pretty good.  I’ve also seen demos where my volunteer looks like he or she tried to tie the tie using only one hand, two fingers, and blindfolded.

The point of this exercise is to demonstrate that giving and receiving direction is difficult.  A lot of people mock tech writers, thinking that writing step-by-step instructions is no big deal.  But after putting people through this exercise, they usually end up singing a different tune.

Be patient!

When you’re talking to a non-technical audience, patience is a vital virtue.  People can be intimidated by technology, and lack of patience on your part will only do more to add to their discomfort.  Bear in mind that your audience is not as tech-savvy as you are, and will likely not have a grasp of technological concepts.

Any time you try to do a task you’ve never done before, how do you feel?  Most likely, you’re going to be at least a little nervous.  These people are likely to feel the same way.  Telling them to “click Enter” might as well be telling them to hit the gas pedal while they’re blindfolded.

Speaking of clicking Enter, don’t take for granted that people might not know what some technologies are.  I’ve heard stories of people using mice to different degrees, including using them as foot pedals and holding them up to the screen.  (And by the way, I’m sure you’ve heard the joke about not being able to find the “any” key.  I can tell you from firsthand experience that those are not jokes — the stories are true!)

What you see may not be what the audience sees

I’m sure you’ve seen the classic image below.

rubingestalt

What did you see first: a vase or two faces?  Perspectives matter, and it happens all the time when trying to explain technical concepts.  Don’t assume that your audience sees the same thing that you are.  Even if you and your audience are looking at the same screen, what you and your audience see might not be the same thing.

Having said that…

A picture is worth a thousand words.

Very early in my professional career, I was tasked with writing a document for the nighttime support staff, explaining how to support a WORM drive.  When a customer requested data from an optical platter that was not in the drive, the user needed to insert the new platter into the drive.  I could have written an instruction saying that the A side had to be up, with the A label on the left edge, and the disk slide facing away from you as you put it in the drive.

Instead, I opened my very primitive paint program and drew something similar to this:

disk

Suddenly, the instructions were clear.  The document was successful, and the operators were able to follow it to perfection.

However, be careful — there is a wrong way to use illustrations!  Imagine, for example, that you’re trying to find a Little Caesar’s Pizza or a Home Depot.  You find a site that has a map.  The problem is, the map is an image that’s zoomed in (with no way to expand the map).  The image looks like this:

map

Tell me, on what street are these places?  For that matter, in what city, state, or even country are these located?  There’s no way to tell, because there is absolutely no point of reference or context to this illustration.  A picture might be worth a thousand words, but if you’re not careful, it could be worth exactly zero words.

Use analogies

I once sat in on a SQL Saturday presentation by Thomas Grohser where he was talking about SQL data storage systems and data access.  I’ll admit that I had a hard time following some of what he was saying, until he gave the following analogy:

“Imagine you get on an elevator with ten people.  Each person presses a different button.  Now imagine that the elevator has to go to every floor in the order that the buttons were pushed!

Suddenly, Thomas’s concept was crystal clear!

Another time, I was speaking to a co-worker who had tried to explain to someone that she was trying to store more data on a disk than there was space on the disk.  (This person did not understand that data takes up disk space.)  I told him, “you should’ve said that you can’t put ten pounds of stuff* into a five pound bag!”

(*Okay, I didn’t say “stuff!”)

The moral of the story is that analogies are highly effective in communicating concepts.  If you can effectively explain a concept using an analogy (note: make sure the analogy you’re using is business-appropriate), then go ahead and do so.

KISS!  KISS!  KISS!!!

No, I don’t mean hanging out with your sweetheart.

Make sure you follow the KISS principle: KEEP IT SIMPLE, STUPID!

Technical instructions need to be kept simple.  A lot of technologists don’t understand that reading is work!  It takes work to read and comprehend a paragraph.  What if a set of instructions needs to be understood quickly?  If a person needs to take a minute to figure out what is being said, that’s a minute that was just wasted.

Generally, the rule of thumb I use is, if it takes more than a few seconds for a reader to understand my instruction, then my instruction has failed.  Don’t make the reader have to work.

Realize that this will not happen overnight

Now that I’ve gone through some of the suggestions for talking to non-technical people, understand that not everyone has the ability to convey technical information in a manner that can be understood, and being able to do so won’t happen overnight.  Like everything else, it takes time and practice to get that skill down.

In any case, hopefully, these tips will help you become a better technical communicator.  In the long run, this ability will enhance your skill set — not just as a communicator, but as a technologist as well.

What to expect at a SQL Saturday

Those of you who follow my ‘blog know that I post a lot about SQL Saturday.  I attended my first SQL Saturday in New York City in 2010, and had a great time.  I’ve attended SQL Saturday events every year since, and my involvement has grown, first when my hometown SQL user group started hosting our own SQL Saturday events, then again in 2015 when I first started speaking with my own presentations.

For the benefit of those of you who have no idea as to what SQL Saturday is, here’s a primer.  SQL Saturday is a technical conference that takes place on (mainly) Saturdays at various locations (despite the name, SQL Saturday does not necessarily have to take place on Saturday).  As the name implies, these conferences revolve primarily around technologies related to Microsoft SQL Server.  However, while SQL Server is the primary focus for these conferences, not all presentations focus on SQL Server.  Some presentations may be of interest to developers, other data professionals, and people who just want to learn more about data technologies or technological trends in general.  Some presentation topics don’t focus on technology at all; SQL Saturday includes a professional development track where presentations focus on various professional soft skills, including (but not limited to) non-technical business skills, business-related social skills, networking, career, job hunt, communication, and so on.

My friend, Ed Pollack, wrote an article about happens at a SQL Saturday.  It’s a great read, and I highly recommend it.

So for people who might be interested in attending a SQL Saturday, I put together this primer (in a FAQ format) based on my own experience with SQL Saturday.  Hopefully, this will answer your questions as to what SQL Saturday is about, as well as whet your appetite for attending these conferences!

If this article doesn’t answer your questions, feel free to comment!

Who can go to a SQL Saturday?

Short answer: anyone!

Longer answer: anyone who has an interest in databases, data science, analytics, business intelligence, statistics, technology, development, career and professional development, or even if you just want to network with professionals in technology.  Not only is SQL Saturday a wonderful opportunity for free training, it’s a fun social event where you can meet people in the field.

Most SQL Saturday events do require you to register, since space is often limited (also, some locations are secure facilities, which require pre-registration).  Register on the individual location website for the event that you want to attend; these links can be found at sqlsaturday.com.

I know nothing about technology, or I am not a technical professional.  Can I go to SQL Saturday?

Yes!  See my answer above.  You do not need to be a professional to attend.  If you have an interest in anything related to data, you’re encouraged to show up.  And because the event is free, it’s ideal for students.

Did you say free?  How much does it cost to attend a SQL Saturday?

Yep, that’s correct.  SQL Saturday is free to attend.  Most events charge a nominal fee for lunch; that amount varies with the event.  It’s usually in the ballpark of around $10 to $15 (US).

So who pays for all this?

Sponsors cover the costs for these events.

What about this fee for a precon?  What is a precon?

A precon is a daylong presentation on an individual data topic (topics vary).  These precons generally take place the day before SQL Saturday.  Unlike the main SQL Saturday  event itself, there is a fee to attend a precon, usually in the ballpark of $150 to $200, depending on the topic.

Do I need to know anything about SQL to attend a SQL Saturday?

Nope!  SQL Saturday welcomes people of all technical levels, even if you don’t know anything about databases.  Some events even include a beginner track that offer introductory topics for SQL and database newbies.

What topics are presented?

It varies, depending on the event.  Different events can have different subject tracks.  Also, because these events have different speakers, presentation topics vary as well.  Most topics revolve around SQL Server, but application, administrative, and professional development topics are offered as well.

How much do SQL Saturday speakers and staff get paid?

Zero.  Nada.  Zilch.  SQL Saturday is an all-volunteer event.  When I apply to speak at SQL Saturday events, I do so knowing that I’ll do this on my own dime.  Distance from home, transportation costs, lodging, food, and schedules all factor into my planning whenever I apply to speak at a SQL Saturday.

How should I dress for a SQL Saturday?

SQL Saturday tends to be a casual event.  I’ve worn t-shirts, jeans, summer shorts, sandals, Hawaiian shirts, baseball jerseys, and baseball caps to these events (not necessarily all at the same time).  Heck, I even remember a SQL Saturday where Grant Fritchey wore a kilt.  (No, I have no idea if he wore it in the “traditional” Scottish style, and I didn’t ask.)

I’ve often seen job seekers attend SQL Saturday dressed in full suits.  While suits can be worn at these events, be advised that you will likely stick out like a sore thumb.  Additionally, note that SQL Saturday is an all-day event, and a suit might not be comfortable for an entire day, especially if it takes place in the middle of the summer!

My advice: dress comfortably, and however you think is appropriate.  If you feel a need to dress up to impress potential employers, I would recommend slacks and a decent shirt (if you’re a guy, that is; I’ll admit that I don’t know what the female equivalent would be).  A tie and jacket are optional.  You don’t need a full suit.

I want to be a SQL Saturday speaker.  How can I get started?

You can start by reading my previous article that talks about how I got into it.  Additionally, I have a presentation that talks about becoming a SQL Saturday speaker (this is a brand new presentation that will make its debut at SQL Saturday #716, New York City!).  There are also a number of other presentations about becoming a speaker as well; go check them out!

I have more questions.  How can I get them answered?

Did I not answer your question?  For starters, you can leave me a comment, and I will answer your question as best as I can!

I also recommend SQL Saturday’s website.

There are also a number of articles that discuss what to expect at SQL Saturday.  I highly recommend Ed’s article, for starters.

The bane of unsolicited recruiters

If you are a technology professional, chances are you’ve received the emails.  They usually look something like this:

To: Ray_Kim@MyEmail.com*
From: SomeRecruiterIveNeverHeardOf@somecompany.com
Subject: [Some job that doesn’t interest me] located in [some place where I’m not willing to relocate]

Dear job seeker:

I trust you are having a pleasant day!

I came across your profile, and I believe you are a perfect fit for our exciting job opportunity!  We have a position for [some position about which I couldn’t care less] located in [some place where I’m not willing to move].

If you think you are an ideal candidate for this exciting position, please call me immediately at (800) 555-1212!

(* My actual email address is suppressed for reasons I think are obvious.)

To me, these emails are no different from the email spam I receive that says I need to respond to claim $1,000,000 from a bank in Nigeria.  I’ll make this clear: spam is a major pet peeve of mine, and is something I hate passionately.

I came across this link that perfectly sums up why I hate these recruitment tactics.  I recently performed a Google search on “recruiting spam” — and the number of links I saw was overwhelming.

Among other things, I found a link by my friend, James Serra, who wrote this article about low-rate recruiters.  I also recently saw one of his SQL Saturday presentations where he talks about enhancing your career.  (It is an excellent presentation; I recommend it highly.)

In his presentation, James talks about taking risks, and he told stories about how he pulled up stakes to seek lucrative opportunities elsewhere.  Personally, I am not willing to pull up my roots and relocate (having said that, you are not me), but I do understand what he means by taking risks, especially calculated ones.  You need to take risks to get ahead, and you need to step out of your comfort zone.  (This is outside the scope of this article, and is another topic for another time.)

However, it’s one thing for opportunity (where you’d take a risk) to present itself.  It is quite another when a “get rich scheme” crosses your inbox.

I once had a bad experience with a spam recruiter.  He set me up on an interview.  When I asked the company with which I was interviewing, he would only say it was “an insurance company.”  He did not reveal much in the way of information.  I only found out where I was interviewing only hours before I was supposed to interview.  It ended up being for a company where I was not interested in working.  After that experience, I told myself that not only was I never going to work with that recruiter again, I also would never again accept any unsolicited recruiter requests.

A good ethical recruiter will take the time to get to know you, gauge your career interests, get an idea of where you want to go, and respect what you want to do.  A spam recruiter could not care less about any of this.  All they want to do is make a buck, and they are willing to exploit you to do it.

I recently responded to a recruiter in which I apologized for my harsh response.  Like so many unsolicited recruiting emails, he pitched a position outside my geographic interests that did not interest me.  After I responded, he wrote me back to apologize, and he was sincere in his response.  I had made numerous attempts to unsubscribe from his list, to no avail (a fact that I mentioned in my email to him).  He mentioned that he had looked into it, confirmed that there was an issue, and made efforts to correct it.  His efforts actually swayed me.  I wrote back to apologize and to say that I was willing to work with him.  (Legitimate recruiters, take note; efforts like this go a long way.)

(Disclosure: I am not, I repeat, not, actively seeking new employment; I’m happy in my current position.  However, I would also be remiss if I did not consider opportunities that could potentially represent a step up.  See my paragraph above about taking calculated risks.)

Swimming in the candidate pool can be an interesting, exciting, and even rewarding experience.  Just be aware that, within that pool, you might be swimming with sharks.

My SQL Saturday schedule, 2018 (so far!)

Well, I can now call it official!  I am speaking in New York City on May 19!  So, my 2018 SQL Saturday schedule is starting to shape up.

As of right now, I am confirmed to be speaking at the following SQL Saturday events.

I submitted presentations to these events, but am not yet confirmed (and there’s no guarantee that I will be speaking at any of these).

Of course, this schedule is subject to change, depending on whether or not I’m picked to speak, and as more events are added to the schedule, so stay tuned.  I might be coming to a SQL Saturday near you.  If so, come out and say hi to me!

SQL Saturday #714, Philadelphia

Last week, I received word that I’ve been selected to speak at SQL Saturday #714, Philadelphia (the actual location is Blue Bell, PA, which is outside of Philadelphia) on April 21!

At this time, I don’t yet know what I will be presenting.  When I do, I’ll post them to another ‘blog article.

Hope to see you there!