Anyone can create a technical talk. Yes, even you. Here's the 10-step process I use to make my technical talks the best they can possibly be.
1. Settle on an Idea
This is usually the step that takes the longest. There are a LOT of technical and programming conferences today, and a lot of attendees for them. On the one hand, that's wonderful, because most people can find one near them to attend. But on the other hand it also means a lot of speakers, both new and established, and a lot of topics. Ultimately this results in prospective speakers (like myself) needing to find ideas that a) we know enough about to be able to talk about, b) are interesting and c) aren't already presented better by someone else.
The time involved in this task varies for different people. For me, I want to be as engaging as possible while also still being able to teach something. That means that my topics have to be stuff I'm familiar with (you'll never see me teaching a course on Kotlin, because I have no idea what that is).
The trick is that while ideas may be shared by many people, experiences aren't. Experiences make for engaging technical talks, because everything you know is something someone else doesn't. If you want to make a new talk, start looking at your experiences first.
2. Find The Goal Of Your Talk
Here's a dirty little secret of technical talks and public speaking in general: no one will ever remember all the things you said. You'll be lucky if your attendees take away just one thing from your talk that they can apply to their life and career. This one thing, the one idea you want your listeners to be able to use, is the goal of your talk.
3. Make an Outline
Once you've got a goal for your talk in mind, you can start writing up an outline. Never jump full-bore into writing a technical talk without an outline, even if you've got a killer idea; you'll give up before getting half way. Instead, make a list of the points you want to talk about, and how each is applied toward the goal of the talk; these two items are important in equal measure.
Ever heard the adage, "weeks of coding will save you hours of planning"? Well, weeks of writing will save you hours of outlining. Take the time to make a plan!
4. Be Entertaining!
This is the step most often forgotten in technical talks. Here's the thing: talks are entertainment first and teaching second. You can be as helpful as you like, but if you're not entertaining you'll lose your audience at some point during the talk, and that's the worst thing that can happen for you as a speaker. Being boring is a death knell to speakers. Don't be boring, be.... not-boring!
This is Step 4 in this process because being not-boring takes planning and practice. The form of this entertainment could be many things: tell jokes, tell stories, use memes, do something to break the monotony of having to listen to the same person for an hour. The absolute worst thing you can do when giving a technical talk is to be boring! Delivering a technical talk is a performance. Use any tools at your disposal to make your performance as not-boring as it can possibly be.
5. Write a Script
Once you've got your goal, outline, and entertainment options, you are now ready to write a script your talk. This step varies quite a bit; many speakers I've interviewed are comfortable with a simple outline and a few jokes before stepping on stage. I am not one of these people. Consequently I have a tendency to write an entire script for my talks.
This script doesn't need to be as detailed as, say, a movie script. It just needs to show the important points, tips, and stories you're going to use. You could even list the maximum time you want to spend on certain sections.
The real trick, though, is that you might not even need the finished script. The mere act of writing it will cement the points you want to make in your mind, and for many people (myself included) that's enough to be able to deliver it effectively. But if you do need it, put it somewhere discrete but easily accessible when it comes time to deliver your talk.
With the script written, it's time to throw it away. Not even kidding.
The first pass at your script is probably garbage. It'll be a jumbled mess of half-formed ideas, flat jokes, meandering stories without a point, and other boring junk. Once you've finished it, leave it alone for a few days and come back to it, and you'll see just how terrible it is. Now is your chance to make it better. As you make changes, you'll start to see how best to deliver your ideas, how best to be entertaining.
Most software development teams develop their code iteratively: write it, test it, use it, fix it till it doesn't break anymore (Daft Punk songs being optional). Talks are no different. In fact, there will be several points during the life of a talk at which you'll do revisions, up to and including five minutes before you are scheduled to perform. Accept them; they'll probably save you once or twice.
I cannot say this more clearly: by the time you are scheduled to deliver your talk you should have already practiced it multiple times. DO NOT go on stage having never practiced your talk, because it will be immediately and incredibly obvious to your attendees. If you don't care enough to practice your performance, why should they care enough to listen?
Instead, do a series of dry runs, whether in front of people are not. In my case, I sometimes deliver talks-in-progress to my five-year-old daughter's stuffed animals, because I know they won't hold back with their criticism.
What? That monkey is vicious. Might as well get the toughest critic out of the way.
In any case, practice your talk! Several times, preferably. Believe me, it make a huge difference.
8. ...and Revise Again
Yes, revisions are two different steps in this process. You should always be making incremental improvements to your talks (for whatever you define as an "improvement"). By keeping your talks as up-to-date as feasible, you make them more useful to attendees. Revise as often as necessary!
9. Practice the Final Talk
Once you've revised multiple times, you can settle on a temporarily-final version that you can practice in full. Whether you practice this in front of people or stuffed animals doesn't matter, just practice it until you're comfortable with it.
This is it. The moment you've been preparing for, the performance of your life! Or, at least, the performance of your last two weeks.
This is where it all comes together: the goal, the outline, the not-boring jokes, the practice, the revisions, all of it builds to this moment and this place. It is now that you can go out on stage and rock your performance. Or, more likely, elementary-school-band your performance.
If this is your first technical talk or your hundredth, you are going to stumble, to lose your train of thought, to mix up words. At one of my talks I mentioned my beloved wife K.C. but totally spaced on the words "wife" and "spouse"; I ended up calling her "person that I live with" and then pointing fretfully to my wedding ring. I must have looked like an idiot.
You will probably end up looking like an idiot at some point. But the resolve you show by merely standing on stage more than cancels that out.
Take the performance slowly. Remember to slow down, to take breaths, to drink water if you need it. You've already done the hard part: the planning and practice. All that's left is to show your attendees that you know something, that you're willing to share and learn and grow with them. That's all attendees want: to learn something, and to be entertained. If you give them that, you've already won the battle.
Creating a technical talk is hard. It takes planning, goal-setting, practice, revisions, and at least an attempt at being not-boring. But anyone, anyone, can do it. Yes, even you. Keep these steps in mind as you create your talks, and you'll hopefully find, as I have, that your talks will be funny, engaging, useful, and attended.
Did I miss a step in the process above? Am I totally off my rocker? Did I forget a synonym for "spouse" that you feel a burning desire to inform me about? Share in the comments!