#BI101: Some SQL Saturday speakers to check out

This is part of a series of articles in which I’m trying to teach myself about BI.  Any related articles I write are preceded with “#BI101” in the title.

As a speaker on the SQL Saturday circuit, I’ve had the honor and privilege of having met, connected with, and even befriended a number of experts in SQL, data, and BI.  If you can get to get to a SQL Saturday, you can also have that opportunity.

In a couple of weeks (July 28), we will be hosting SQL Saturday here in Albany, NY.  I was going through the schedule, and noticed a number of speakers on the docket who will be talking about various BI topics.  I’ve attended a lot of their sessions, and I recommend these speakers highly!

(Note: for purposes of this article, I am limiting this list to BI topics, although these speakers may be giving other presentations as well.)

SQL Saturday is a great free learning resource, a great opportunity to network, and is always a good time!  If you’re looking to learn about BI or other data-related or professional topics, go check out a SQL Saturday event near you!

Advertisements

Humble beginnings

Once again, the Facebook “On This Day” memory feature shows it can be a curious thing.  And again, this is one I wanted to share.

The picture you see above showed up on my Facebook memories feed this morning.  Three years ago today, I gave a presentation at my local SQL Server user group meeting.  I had come up with a presentation idea that I thought would be of interest to my user group, as well as other technical professionals.  I jotted down some notes, put it into a presentation, and presented it at my local user group.

About a month later, I gave this very same presentation at our local SQL Saturday.  It was my first SQL Saturday presentation!

I was curious as to how other events would take to my presentation.  Later that year, I submitted it to, and was accepted at, another SQL Saturday.  It was my second time speaking at SQL Saturday, my first time speaking at an event in “foreign territory,” and my first SQL Saturday — speaking or attending — outside of New York State.

Since that humble beginning, I’ve spoken at 13 (soon to be 14) SQL Saturdays at seven different cities around the northeastern United States.  Thanks to this endeavor, I’ve traveled around the region, met a lot of great people, expanded my professional profile, started a ‘blog (that you’re reading right now!), enhanced my career, gained more confidence, improved my presentation skills, and become a better person.  This all came about because of these conferences and from this simple start three years ago.

I hope I’ll be doing many more!  Happy three year anniversary to me!

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.

SQL Saturday #723, Rochester, NY

My next SQL Saturday is scheduled!  I will be speaking at Rochester, NY on March 24!

I’ll be giving the following two presentations:

Hope to see you there!

SQL Saturday #694, Providence

This morning, I saw a ‘blog post from my friend, Greg Moore, who wrote about his upcoming presentations at SQL Saturday in Washington, DC this Saturday.  Greg is an excellent presenter, and I always recommend his presentations anytime.

It also made me realize a few things.  First, my own SQL Saturday presentations are coming up quickly — this Saturday (December 9), in fact.  Warning: dates in calendar are closer than they appear!  So I figured I should do more to promote my own presentations.  Come hear me speak at SQL Saturday #694 in Providence, RI.  I will be giving the following two presentations:

Providence SQL Saturday is a special one for me.  I first spoke at Providence two years ago, and it represented a couple of milestones.  First, it was the first SQL Saturday I ever attended that was outside New York State.  The first ones I attended were all in New York City (and to this day, I still try to attend that one whenever I can, regardless of whether or not I’m speaking) or in Albany.  Second, it was only the second time that I had ever presented at a SQL Saturday.  The first was earlier that summer, when I spoke at my hometown SQL Saturday in Albany, NY.  In fact, the presentation I gave — talking to non-techies — is the same one that I will be giving this Saturday.  I’ve since added to it and polished it a bit.  Hopefully, this presentation will go even better than the last time I gave it in Providence two years ago!

If you’ve never been to a SQL Saturday, check it out.  It’s a great day of learning (and it’s free — although there’s usually a nominal fee for lunch), it’s a great opportunity to network with industry colleagues, and it’s a fun social event (seriously, it is)!  I look forward to every SQL Saturday that I attend, and this Saturday should be no different.

Hope to see you there!

Upcoming speaking engagements

I have two speaking engagements coming up within the next few weeks:

Hope to see people there.  I can always use a good audience!

My hometown SQL Saturday: Albany, NY, July 29

My local SQL user group is hosting SQL Saturday on July 29, a week from this Saturday!

I will be speaking; I will be giving my presentation on documentation.  There are also a number of other presentations that people might find of interest.

When I attended SQL Saturday in New York City a couple of months ago, I sat in on Lisa Margerum’s session on networking.  It is an excellent session, and I recommend it highly.

A number of my friends are also presenting, including Greg Moore, Thomas Grohser, George Walters, John Miner, and Ed Pollack.  They always give good presentations, and I recommend them highly.  Check out the schedule for more details.

Hope to see you there!