DEV Community

Matthew Jones
Matthew Jones

Posted on • Edited on • Originally published at exceptionnotfound.net

Improving Your Technical Speaking Skills: Be Knowledgeable

We're starting a new series today, one that talks about how to improve your abilities as a technical speaker. I firmly believe that within all of us technical people is a presenter who can speak intelligently, concisely, informatively about a topic that we are interested in and enthusiastic about.

I refuse to accept that I refuse to accept my own accomplishments. Photo by Charles / Unsplash

This series (with this post being the first of five) will dive into how to make our talks more thoughful, more engaging, more useful to our audiences. It is my hope that more of you will choose to pursue technical speaking, as it is a fantastic way to learn, share, and become more a part of the wider technical community.

Let's get started!

Be Knowledgeable

All worthwhile technical talks start with a knowledgeable speaker. There is no getting around this: you have to know your sh*t to be able to speak about it. The question is: how can you learn a topic enough to be able to talk about it for an hour?

"So, I'll need everyone's hands for the next part of the demonstration." Photo by Austin Distel / Unsplash

The first goal is this: figure out what are the most important things for your audience to take away from your talk.

Establish Throughlines

A common problem I see with new speakers is that they have the mindset of "well it's all related, so I need to include everything that could possibly be related to my topic." That's a great way to overload your audience and ensure that they don't remember anything you said. Instead, what you want to do is create and thoroughly flesh out two or three "throughlines".

Throughlines are the most important points you audience can take away from your talk. Before starting to write the presentation, decide on the critical throughlines you want your audience to take away with them. These might be "here's five reasons why framework X is better than framework Y" or "here's the three things you need to remember when doing task Z" or "here's the one key reason why soft skills A, B, and C are the principal ones to apply to your career." Whatever the throughlines are, we as speakers want to be sure that they are the ideas the audience leaves the room thinking about.

And if those thoughts have colors, you might have synesthesia. Photo by Bilguun Bat-Urnult / Unsplash

When you nail down what your throughlines are, remember the following adage:

"Tell them what you're going to tell them, tell them, and then tell them what you've told them."

Some repetition is a good thing in technical talks! Don't be afraid of repeating the throughlines over and over, because that emphasis is what reminds the audience that they are in fact important points, points they should remember and apply to their careers.

The longer your talk is, the more leeway you have in determining your throughlines. For a lightning talk (e.g. 10 minutes or less), you might only want a single one. For a half-hour or hour-long talk, two to five would be doable. For a longer format (e.g. a 4-hour or 8-hour workshop) you might want multiple "sets" of throughlines, each associated to a different aspect of your topic. However long your talk is, it will be that much more useful to your audience if you know, and can communicate, your throughlines to them in a way they will understand.

You said you're doing a 12-hour talk?! You're on your own, buddy. Photo by Malvestida Magazine / Unsplash

Once you've got the throughlines down pat, how do you learn what kinds of details and examples you should include in your talk? The fastest way to learn something is to build it yourself.

Do The Research Yourself

Blog posts and YouTube videos have their place in learning, and that place is to inspire people to build, or create, or refine. What they cannot do is be a quality substitute for doing your own hands-on building.

Read blog posts or watch videos related to your topic, and try to reproduce their results with your own code. Take their sample projects and run them on your own system. This kind of setup work will tell you amazing things about how these problems get solved in the real world, and that's exactly the sort of content your audience wants! They want to know "how can I solve a problem I'm having?" not "how did this random person solve a related problem?"

Carry the one, divided by i, rounded to the fifth place... Photo by William Iven / Unsplash

Know About Common Pitfalls

A side-effect of doing the research yourself is that you will most likely encounter problems that the blog posts or YouTube videos did not mention. At this point, you will have to solve these problems by looking elsewhere, either at more posts and videos, or by using your own problem-solving.

Remember this: if you are encountering issues trying to solve a problem, you will almost never be the only one.

I got all the reds on one side, and STILL have a blue in the yellows?! Photo by Olav Ahrens Røtne / Unsplash

These kinds of problems are absolute gold for technical talks, because the people in them are, like you, trying to solve problems in the real world. They don't just want the theoretical solution, they want solutions to common pitfalls as well, fixes to issues they themselves might be encountering. Including this kind of content in your talk makes it that much more robust, and likely to help your audience.

Go Beyond Scope to Handle Questions

When doing the actual talk, stick to the scope you defined with your throughlines. When doing the research, you will want to go slightly beyond that scope. This is because of a feature of technical talks that introduces some randomness to your presentations: questions.

"Esto es realmente más un comentario que una pregunta, pero..." Photo by Levi Hernández / Unsplash

IMO you should always allow for questions from your audience (more on why I believe this in a later post). These questions will almost certainly expand beyond your original scope, so any research you've done outside your original boundaries might be useful in answering them.

However, don't be afraid to say "I don't know" and then try to offer places where the answer might be found.

Know About Further Resources

Finally, a technical speaker should, if possible, know about further resources that might provide answers to questions the audience has and the speaker is unable to answer. This might be a dedicated forum, a Stack Overflow tag, a personal blog, a YouTube channel, or something else entirely. Even if you don't know the answer, you should know a place that will likely give the asker the answer they are seeking.

Summary

The first part of being a better technical speaker is to be a knowledgeable speaker. If you know your stuff and can communicate it well, the audience will leave the room with both appreciation toward you for sharing your ideas and knowledge, and awe at the things they can now accomplish in their own lives.

In the next part of this series, we will discuss how important it is to respect your audience, and how that starts and ends with not wasting their precious time.

Happy Speaking!

Top comments (0)