Come on out, check out my presentation (as well as a bunch of other good ones), do some networking, and have fun! See you on Saturday!
Once upon a time, I wanted to be the rockstar in pretty much anything and everything I did, whether it was my job, my extracurricular activities, or my relationships. I wanted the glory and the recognition. More importantly, I wanted to be respected for whatever I did. In my youth, I thought that demonstrating that I was good at whatever I did was the path to glory.
But now that I’m older, that perspective has changed. I no longer need (or, sometimes, even want) to be the rockstar. These days, I get a great deal of satisfaction out of helping someone else become the rockstar. While I still try to perform well in whatever I do, it’s more important to me to help everyone around me be better.
This has become a passion of mine. It’s why I’m so passionate about speaking at SQL Saturday. It’s why I take such an interest in technical communication, writing, training, and mentoring. It’s why I continually encourage people to be better. It’s even one of the major reasons why I maintain my ‘blog. While it’s important to make myself better in whatever I do, I think it’s also equally important to make people around you better as well.
I’ve had a number of opportunities to give something back. For the past couple of years, I’ve taken part in a program by my alma mater, Syracuse University, specifically the College of Engineering and Computer Science (ECS). They sponsor a “job shadow” program in which current students are paired with alumni working in various industries. The program typically takes place during winter break, between the fall and spring semesters.
Unfortunately, I work in a data-secure office, so an office shadow tends to be out of the question. (I don’t think students would really be interested in seeing me sit at a desk all day, anyway.) In lieu of a job shadow, the university suggests other ways to interact with students — over a cup of coffee, lunch, and so on. For the past couple of years, I’ve offered to take students out to dinner. It offers a nice, relaxed atmosphere to chat, not to mention that, since I usually don’t have any commitments after dinner, I’m not constrained by time; I don’t have to worry about being back in the office by a certain time.
I’ve found numerous other ways to pay it forward. During one unemployment stint, I found a part-time position as an instructor at a local business school to hold myself over. I discovered that I enjoyed teaching so much that, even after I found gainful full-time employment, I continued with the teaching job for a few more years. I am heavily involved with my local SQL user group. By giving back to my user group, I can help other people with the same interests. I also wrote a while back about some of my networking activities in which I was able to give back. When you network, you have multiple avenues in which you can pay it forward.
As an old saying goes, a rising tide lifts all boats. Improvement doesn’t just mean making yourself better. It also means making everyone around you better as well. When you help other people succeed, then we all succeed.
On Saturday, July 28 (a week from tomorrow as I write this), our local Albany-area SQL user group will host our fifth SQL Saturday! I have participated in all five; I worked as a volunteer at the first one, and I presented at the other four (including next Saturday). This is one of my favorite events, and I look forward to it every single year!
This year, I am debuting a brand-new presentation: “Networking: it isn’t just for breakfast anymore,” based upon my ‘blog article of the same name. (An alternate name for it could be “Networking 101: networking for beginners.”) This presentation is primarily for people who want to get better at networking but don’t know how to do it, although seasoned veterans might be able to get something out of it as well. It’s one of the first sessions of the day (8:30 am!), so come early!
As much as I promote my own presentations, mine is not the only one on the docket. There are many wonderful speakers and presentations being given at this event, and I encourage you to come out and check out as many as you can that interest you!
SQL Saturday is always a great time, a great opportunity for free learning, and a great opportunity to network with data professionals. The Capital District region here in upstate New York has been my home for many years. I hope to see you here in my home turf!
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.)
- Steve Simon is giving talks on DAX and the tabular model and data mining with SQL Server 2016.
- Derik Hammer discusses the Azure SQL data warehouse.
- Paresh Motiwala talks about BI infrastructure in Azure.
- Bryan Cafferky presents about predictive modeling with R.
- James Serra gives a talk on big data architectures and the data lake.
- Sunil Kadimdiwan discusses SSRS 2017 with Power BI and other new enhancements.
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!
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!
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.
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.
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:
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:
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.
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.