I  vividly remember one of the early conferences that I attended as a SQL Server professional. It was a Professional Association for SQL Server conference (PASS) in San Francisco, California. I stood in awe as I looked around and saw the authors of many of the technical books I had in my collection. What a great place to meet the stalwarts of our community! And I was determined to get more involved in one way or another.

I had almost convinced myself that I could submit an abstract for an introductory level session the following year when I witnessed an exchange that changed my mind. I was sitting in a very good session by a well known author when someone politely interrupted the speaker with a question. The speaker apparently didn’t know the answer and fumbled around trying to satisfy the questioner. Then another well known and highly respected author that had been sitting in the back stood up and kindly offered input. She was followed by a Product Manager for Microsoft SQL Server who added to the response and provided insight into the direction of future enhancements in SQL Server.

If someone who had written a book that I regularly turned to for information could be so readily corrected in front of a room full of people, I reasoned, then I would have little chance of ever getting through a presentation unscathed. I solemnly resigned then that I would never volunteer to speak at a PASS conference or any other conference.

Common objections to speaking

The fear of speaking in public, or glossophobia, is one of the most common fears affecting the general population. It is believed to be more common than the fear of dying. As comedian Jerry Seinfeld once noted, “The average person at a funeral would rather be in the casket than doing the eulogy.”

As technical people, we are certainly not immune to glossophobia. In fact, we may even be more subject to it than the average person. As a result, it’s rather easy to find reasons why we cannot create a technical presentation to share with others.

‘I don’t know enough to share’

Looking back to that ill-fated session at PASS in the fall of 2000, I’m glad that I didn’t follow through with that in-the-heat-of-the-moment resolution. Since then, I’ve spoken at dozens of conferences in North America and in Europe and I receive a great deal of satisfaction in sharing my experiences.

And that’s a key point. I share my experiences. I don’t claim to be an expert in any particular area. I set out in each of my sessions with a mind set that I will share with the audience my experiences, the approaches I’ve taken, and the results that they’ve garnered. Taking that approach offers me the freedom to learn from the audience if there is a better way.

‘Someone else will do it’

Many technical communities, whether it’s .NET, SQL Server, or another technology altogether such as VMWare, have been fortunate in that there have consistently been people who are willing to freely share their expertise in one subject or another. Some of the these people, such as Technical Evangelists or Product Managers, consider this a normal part of the jobs. Many consultant consider speaking a form of marketing their services. Others speak for purely altruistic purposes. Regardless of their intentions, there has historically been a surplus of people wiling to speak at technical conferences.

That is certainly not the norm for smaller stages, however. One of the most difficult aspects of running a local user group is finding local people who can or will speak at a meeting. Finding a speaker can be extremely time consuming and frustrating for the group organizer. A lack of speakers is the underlying cause for the collapse of many technical user groups. When that happens, we all lose.

‘I don’t have anything interesting to share’

While many technical professionals like to learn and work with the latest and greatest technology available, the fact is that most of us are “stuck” using technology that is at least one revision old. How are many instances of SQL Server 2000 are still in production? How many lines of Visual Basic 6.0 are still being maintained?

Despite the fact that many of us feel relegated to using older technology, that doesn’t preclude us from creating technical presentations. Some presentation materials are almost timeless. For example, last month I gave presentation at DevLink just outside of Nashville, Tennessee, that highlighted tips and tricks for writing better queries. The information offered in the presentation was applicable to Microsoft SQL Server 7.0, 2000, 2005, and even 2008.

Other nearly timeless possibilities could include the basics of inheritance and troubleshooting poor performance.

‘I don’t know where to start’

The first time I sought to create a technical presentation, I did so with little input from others. I didn’t know where to start so I looked to prior sessions that I had once attended for guidance. I tried to figure out how many slides to include in the PowerPoint presentation, what the ratio of presentation and demonstrations should be, and how to best structure the presentation to so that it makes sense.

In retrospect, I made the process much harder than it had to be. Going it alone is generally not the best way to accomplish anything. That’s one reason I’m writing this article. I would like to provide to you some guidelines that I’ve found to be useful as I’ve created technical presentations.

I would also encourage you to solicit the advice and input of others; i.e. ask the user group leader for input and feedback.

Why you should make a technical presentation

Preparing a technical presentation takes time. Many of us already feel that we spend an inordinate amount of time doing the required work-related activities. We learn new technologies during our off-time; we’re on call during non-business hours; we are already overly committed as it is. Why should we take on the added, and perhaps unnecessary task, of creating a technical presentation?

If viewed as a competing activity to those already mentioned, you shouldn’t. But in reality, creating a technical presentation is less of a competing activity and more of a complementary activity.

Most of the aforementioned activities are actually designed to help us to our jobs better and to grow our  individual careers. Creating a presentation assists in that goal.

Practice your presentation skills

there is certainly
a perception outside
 of the technical
community that
most of us are indeed
socially challenged

Although most of us are far from the stereotypical characterization of a socially inept geek, there is certainly a perception outside of the technical community that most of us are indeed socially challenged. One old joke has an element of truth. How do you recognize an extroverted programmer, he stares at your shoes when talking to you.

The brightest person can be significantly hindered if he cannot adequately express his knowledge to those around him. Being able to succinctly take a complex concept and communicate it in a manner that is easy to understand by those less technical is truly a skill that is as highly sought after as the technology expertise itself.

Creating technical presentations is a great way to practice organizing your thoughts, speaking with clarity, and communicating effectively with others.

You’ll learn as you prepare

Learning a new topic or technology can be fun. We can explore new ways of doing things. We see how the new version helps to address some of the challenges we’ve faced in prior versions. We can take what we know and expand upon it.

But, when learning something new, we tend to focus on those aspects that seem most relevant to us. It’s natural to spend less time delving into areas we don’t find nearly as applicable. However, it may be that those other facets are exactly what we need in order to do our job better.

For example, when Visual Studio .NET first made its appearance in 2002, many developers were eager to adopt the and improved software development tools. But the new .NET environment made it easy to keep programming using the same techniques that were prevalent in Visual Basic 6.0. Until we stepped out of our comfort zone and began learning true object oriented programming techniques rather than continuing our object based programming practices of Visual Basic 6.0, we missed the true power of the .NET world.

One of the best ways to learn about a topic is to prepare to teach it. Preparing to teach compels us to learn aspects of the topic that we may not other wise feel the need to explore. Doing so may lead to not only a better understanding of the technology, but to being able to put the newly acquired knowledge to practical use.

Expand your social networking

Delivering a presentation puts you in front of people you probably don’t know, or at least you don’t know very well. Sharing your knowledges and experiences with them will help them to feel as if they know you, and will likely help them to feel a certain sense of appreciation for the efforts you’ve taken to create and present the information to them for their benefit. It’s a form of helping others.

Later when faced with technical challenges, that network may be strengthened as they contact you for input into problems they may face. And that communication doesn’t have to be unidirectional. You’ll develop a network from which you can draw when you’re up against a technical problem.

Additionally, in this era when many jobs are being exported to other, lower cost, areas of the world, it behooves each of us to get to know others in our technical community. When looking for another job, we’ll have a social network of friends on which we can lean to assist us in our job search.

Give back to the community

As one who has certainly benefited from the local and global technical communities, I feel a strong sense to give back in whatever meaningful ways that I can. I try very hard to spend time in the newsgroups and forums, writing articles, and yes, delivering technical presentations at various levels.

When the community is active and vibrant we all benefit. Being able to turn to a pool of resources who are actively willing to share knowledge in a very unselfish way helps us to all do our jobs a bit better. And that’s a good thing.

Preparing the presentation

Like many activities, preparing a technical presentation takes practice. The more you practice, the easier it gets. Let’s consider some of the tasks you’ll undertake as you put together your presentation and exercise your preparation skills.

Selecting an audience

One of the first things to consider is when and where you’ll make your presentation. If you’re a seasoned presenter and are comfortable with public speaking, most any venue is available to you. You can submit abstract for large public conferences like PASS or DevConnections, or you can target smaller and more intimate settings like local user groups or web casts.

For those that have less experience, I’d recommend starting in a more relaxed and less stressful environment, such as a local user group meeting or perhaps a company Lunch-and-Learn session. Starting in groups where you feel more at home will help you to build confidence and gain experience before tackling the more public opportunities.

It’s also important to consider your intended audience, as best you can, before creating the presentation. Knowing their expectations, their backgrounds, their experiences, and their technical bent will help to create the most applicable presentation for them and hence give you a better chance of having it well received.

How can you get to know your audience? In some cases, like small local user groups, you may already know many of the members. However in larger groups or conferences, knowing who may attend ahead of time is impossible. In those cases, take your best guess.

For example, when I am speaking about Microsoft SQL Server at a conference that is known to attract more developers than database administrators, I’ll adjust my presentation accordingly. I’ll also craft session abstracts that clearly state what the goals for the session are along with any prerequisites for getting the most out of the session. Don’t overlook this aspect as it can help you control to some extent who comes to your session.

Select technology you know

Many seasoned professionals can confidently step before a crowded room and discuss most any topic given to them with great poise and even an air of authority. However for the rest of us attempting to make a technical presentation, it’s better to stick with a technology with which we have a confidence and experience.

I generally speak about Microsoft SQL Server since that’s the technology I spend most of my working time using. That’s the technology I know best. I also use Linux for my desktop and VMWare for my virtual machines. However since I don’t feel that I have the technical expertise to put together a technical presentation for either of those two technologies I would tend to shy away from those potential topics.

Selecting a topic

Within the scope of a broad technology such as SQL Server or Visual C#, there are literally thousands of more narrowly defined topics on which a presentation can be built. Select a topic that is of interest to you since you’re likely going to have to research the topic as you prepare the presentation. Even if you’re presenting something that you’ve already done, i.e. how you addressed resource contention while developing a multi-threaded application, you’ll likely have to investigate some of the finer points before presenting.

Narrowing the scope of the presentation to something that can fit within approximately one hour is rather tricky. You certainly don’t want to run out of material, but at the same time you don’t want to tackle something too broad either.

As a general rule, the broader the topic the less in depth you’ll be able to go. You just won’t have the time to cover all of the aspects of the topics. For example, a presentation on Performance Tuning Microsoft SQL Server may only devote one or two slides on reading execution plans. Conversely, you could more narrowly define the topic and make the entire presentation about how to read the plans.

Creating the PowerPoint presentation

 PowerPoint can
 ruin an otherwise
 engaging presentation.

When Microsoft release PowerPoint many years ago, it, perhaps unknowingly at the time, changed the way presentations are created and delivered. When used effectively, PowerPoint can be a wonderful tool to help get a message across to the audience. When misused, PowerPoint can ruin an otherwise engaging presentation.

Don’t overuse some of the features in PowerPoint. Use the animations very, very sparsely. It’s better to err on the side of being overly conservative than to over-stimulate your audience with effects. For example, don’t use the sound effects of tires screeching as words come zooming in from the left or right. Those kinds of effects detract from the overall presentation.

A PowerPoint slide deck for a technical presentation should be used to augment the presentation; it should not become the presentation. Use the slide deck to help the audience follow along.

I’ve found that I can adequately speak to approximately 20 slides in one hour, including the introduction, agenda, addition resources, and thank you slides. Or put another way excluding those four slides, I typically have 16 slides worth of content per 60-75 minute presentation. That doesn’t sound like a lot of content. But I’ve found that if I don’t carefully budget my time I end up rushing through the final three or four slides at the end of the presentation.

You’ll want to keep the presentation engaging, and the slide deck can help in this regard. For example at one conference I was slated to speak in the last slot of the last day. I knew that most attendees by this point would be exhausted and would have seen more than their share of bullet-pointed slides. So, I decided to have fun with it. I told the audience up front that I had created an entire presentation without using a single bullet point. I tastefully used shapes and figures to create my presentation and to convey the information I wanted to present. That seemed to go over well. As a side note, I did include one slide about two-thirds of the way through the presentation that was full of bullet points. I did so as a joke. When I got to the slide, I told the audience that I knew they’d have withdrawal pains or would feel cheated if they didn’t have at least one slide full of bullet points.

Creating the demos

Technical audiences expect demonstrations. A presentation without demonstrations is usually received as marketing fluff. There are of course some exceptions to this generalization, but all in all it’s better to demonstrate the concepts you’re presenting.

I typically to make active demos approximately 40% to 50% of my presentations. People tend to accept and remember information better when it’s presented in a more interactive and illustrated way.

The specifics of a demonstration will of course vary, however there are some core elements that should considered when creating a demo.

Demonstrate an application of the concept

The best demonstrations illustrate an application of the point discussed in the presentation. For example, if you’ve discussed how to use conditional formatting techniques in Reporting Services, consider adding a demonstration that will illustrate the point by using the technique to alternate the background color for the evenly numbered rows in a report.

Noticeable outcomes

Each demonstration should have a noticeable outcome, something that the audience can readily use to see that the demonstration actually worked. As an example, if your presentation is Using Silverlight in Business Applications, it only makes sense to prove your point via a demonstration.

Script-based yet flexible

I always create a script for my demonstrations. Scripts are presentation notes that help me to remember the specifics of the demonstration. I typically include the slide number where the demonstration should occur, any points that I wish to emphasize, as well as setup and requirement notes.

I use the script to help prepare for the presentation. I typically read through it right before delivering my session and I keep it handy during the session as a fall back just in case something usually happens and I lose my place. Do not use the script as a crutch to carry you through the presentation. No one wants to watch you read through a scripted presentation. Use it to prepare, but not to deliver.

If your demonstrations include developing scripts or source code, I recommend creating a Starter, Demo, and Solution folder for each demonstration. The Starter folder contains the starting point for the demonstration. You will not modify this folder directly. It is primarily used to store a read-only copy of the starting point for the presentation. You’ll use this to quickly reset the demo code before your presentation.

The Demo folder initially contains an exact copy of the Starter folder. The Demo folder is the folder that contains the files you will modify during the demonstration.

The Solution folder contains the finished product for the demonstration; it’s what you are working toward in your demo. It can be used in an emergency. You can always open the solution should your demo get bungled to point of not being able to recover.

Preparing for the presentation

Once the presentation has been completed, it’s time to prepare to deliver it. Don’t overlook this part of the process.

Rehearse, rehearse, rehearse

As you gain experience making technical presentations, you’ll of course become more and more proficient at it. I have several good friends that can pull a presentation out of their repertoire and deliver it with only a moment’s notice.

Until you get to that point, however, it’s best to be well prepared. Go through the presentation until you know the order of the slides inside and out. Find transitions to help you ease the audience from topic to topic and slide to slide.

Make sure that you’ve experimented with the demonstrations enough to anticipate what may go wrong. There are few things more disheartening during a presentation than to not be able to get your demos to work properly.

Rehearse the timings of the presentation. Make sure you know where the halfway point is so you can better allocate time during the presentation. Knowing the subject matter and slides instills a sense of confidence as you progress through the presentation.

Setting the stage

Before delivering the presentation, review the script you’ve created. Make sure that you’ve reset the demonstration database and/or source files.

Adjust your environment for the presentation. Make sure your laptop’s screen saver is disabled. If your demonstrations include editing text, enlarge the font to 18 or 20 so that those in the back of the room can see it more easily. I also like to change the highlight color from blue to yellow.

Making the presentation

When the moment of the presentation arrives, relax. Prior preparation is the cure for worry and anxiety. You’ve prepared. You know your stuff. And you’re ready to share it with others.

Remember that those in the room want you to do well. They’re not there to shoot you down or to intentionally try to thwart your presentation. They’re there to learn.

As you go through your presentation, have fun. Try to interject humor where you can, even if it’s at your own expense. Do stay away from remarks that can be offensive or considered off color. There is no positive outcome from that.

When questions are asked, answer them as best you can. But don’t make up an answer. The attendees will know. It’s much better to honestly say that you don’t know or haven’t experienced that. Ask if someone else in the room knows the answer. If not, offer to find the answer for them if they’ll email you the question.

After the presentation

Once you’ve completed the presentation, it’s not uncommon for some of the attendees to come up to you afterward for specific questions. Hang around and enjoy this. They are coming to you for answers. Try to help them.

Get feedback

Talking with attendees after the presentation also affords you an opportunity to solicit feedback from them. Ask them about their likes and dislike regarding the presentation. Give them permission to speak candidly so that you can improve upon it for the next time. If evaluation forms were collected, try to gain access to those so you can see how you did. I most often find that I am much more critical of my own performance than those that are sitting in the audience are.

Get ready for next time

While the presentation is still fresh on your mind, it’s always a good idea to update the your presentation for the next time. Make adjustments to the slide deck, adding or removing slides as needed. Modify the demonstrations so that they go even more smoothly the next around. Revise the script, capturing important points that were not apparent beforehand but that became obvious during the presentation.

And finally, save the presentation for the next time.