By this point, you've acquired the necessary knowledge for your talk, are being respectful of your audience, and have ways to communicate your ideas effectively to them. The next part of improving your technical speaking skills can be summed up in two words: be approachable. Be someone who is willing and happy to talk to your attendees, readers, or viewers.

This is scary for a lot of programmers. Many of us are introverts, used to dealing with a screen, not a real person. But I urge you all to step out of your comfort zones to do this, because there's no faster way to foster a real sense of community that being available to converse with the members of it.

There are three important aspects of this: always take questions, have places where your attendees can chat with you, and have a place to show off your work.

Always Take Questions

The single most important thing you can do to be approachable to your audience is to take questions. Questions allow your audience to get answers (or at least opinions) on their specific problem, and they make your talk interactive, which (as we'll discuss in a later post) helps improve recall and helps reinforce your throughlines.

But why bother taking questions at all? Most speakers get hung up on a damaging idea: that someone will inevitably ask a question that I do not know the answer to, and so I'll look like a fraud and no one will like my talk.

This destructive thought is merely your impostor syndrome rearing its ugly head. No member of your audience ever expects that you will have every answer! (If they do, you have my permission to aggressively ignore them.) By merely showing up to your talk the audience has already communicated that they want you to succeed, want you to do well.

That is, so long as you don't evade the question, or pretend like you know the answer when you really don't. The BS-meter of your audience is VERY sensitive; they are professional problem-solvers, after all. Don't profess to know something that you don't, because once the audience figures out you don't know what you are talking about you instantly lose credibility with them. Your audience is smart and busy; treat them as such!

When to Take Questions

Exactly when you choose to answer questions can vary by talk, with the most popular options being:

1. Take questions throughout the presentation OR
2. Take questions only at the end.

I'll occasionally see a hybrid of the two, where the presenter stops multiple times and asks if there are any questions, but only answers them during those times.

Personally, I'm partial to option 1, because it keeps my audience engaged throughout the talk. I have occasionally needed to say "I'll have to answer the remaining questions at the end of the talk" but most of the time I can answer one or two good questions at any given point.

The important point is this: always take questions! They are invaluable in helping both parties, audience and presenter, learn something from the talk.

Be Reachable

Part of being approachable is being reachable, available to chat to anyone who was in your talk (and those who weren't) through a variety of methods.

The first is through social media. For many of us technical speakers, "social media" primarily means Twitter. Twitter is the fastest, easiest (if not the most thorough) way of contacting individuals. If you don't already have a Twitter account, I highly recommend getting one, and using it often.

Other social media (including Facebook, LinkedIn, Slack, Instagram, etc.) are still useful, though IMO not required for technical speakers. They primarily exist as a way for people who have attended your talks (or read your blog posts, or watched your videos, etc.) to get in contact with you should they have questions.

Of course, there's also the old standby, an email address. I would specifically recommend having two email addresses: one for your "professional" life and one for your personal life. The former one I would make known to your attendees, readers, viewers, and others, and the latter I would keep private.

In short, have some way for people who want your opinions to ask you questions outside of your talks, blog, YouTube, etc. Then the trick is: actually answer as many of these questions as you feel is reasonable.

Have a Public Place For Your Work

I would say that this point is just as important as the previous one: have a publicly-accessible place to store your work.

This might take several forms: GitHub for code repositories and sample projects, Sessionize for talks you can give and conferences you've attended, SlideShare for slide decks, even just a YouTube channel. The form doesn't particularly matter; what matters is that you have some place that showcases the kind of work that you do.

I have a feeling that many programmers (might even be most programmers) are introverts, and are thus apprehensive about sharing their work with others. When you work all day staring at a screen that can neither compliment nor criticize you, you might start to wish that was always the case. But I urge you to take the plunge and have some place you can share your work on, primarily because you can now use that place as an addition on your resume.

When you get a new job, people will search for you. Though, if you have a very common name, as I do, there's no guarantee they'll find the correct you.

What’s the biggest problem you have with your name?

My biggest problem?

Ever tried to google for someone with a really common name? You find them, and EVERYONE ELSE with the same name.

Don’t google for me, you won’t find me.#commonnameproblems

— Matthew Jones (@exceptionnotfnd ) January 10, 2020

You can make this easier on them by providing a place for them to look, and that place should be wherever you store your work.

One other thing that a "work place" provides, and quite possibly another reason why so many programmers don't want to have one, is that people who see your work can submit or suggest changes to it. I suspect that a significant swath of programmers see this as, if not insulting, at least challenging, because they forget that they are not their code. But we as a group need to get over this fear; programming is a team sport, and we must get along with all sorts of teammates.

Summary

A big part of being a better technical speaker is being approachable. Take questions, answer them honestly, have social accounts where people can reach you, and show off your work publicly. Make your audience feel like you are a real person who is more than willing to help them solve problems in your topic.

In the next and final part of this series, we will talk about what is possibly the most important thing for speakers to do during their talks: don't be boring!

Happy Speaking!