I wish I were a natural at giving talks. Sadly, I'm not. I had to learn the hard way: by teaching a week long Android class (with 20-30 presentations over the course of a week) with almost no speaking experience.
When I taught the first lecture in that class, I wasn't even sure what the point of speaking was. Brian Hardy and I had written 30 odd chapters of tutorial exercises and slide decks to make it happen, but, not knowing what to put in them or what made them any different from the chapters, I put the exact same stuff in the slides as the chapters.
Why? Because I was told to. I wasn't given the point of what I was doing, but I was given a job, so I went ahead and did the job. And surprise, surprise: it did not go well.
What I didn't know is that, while the tutorials and the talks may have had similar content, they served two completely different purposes. The written tutorials were technical tools for my students to use. The lectures, on the other hand, were there as tools of persuasion. They were there to encourage the students to do the work!
Engineering values logic and reason above all else, because logic and reason determine whether the systems we build will actually work. We engineers see plenty of technology that is long on advocacy, but short on functionality. So it's no surprise that we're often suspicious of persuasion.
All those systems are built on a foundation, though, which was itself built by other engineers to solve a problem, and then shared with us. We're standing on their shoulders. One day you'll wake up and find yourself thinking, "Hmm, to get my next project off the ground I'm going to need other people to stand on my shoulders." Or you'll be awkwardly balanced upon someone's shoulders, working with a different person who's balanced on a different set of shoulders, and you'll ask, "Look, isn't this awkward? Could we maybe stand on the same shoulders?"
Those are problems of persuasion. And if you're using logic to persuade without considering the ethos or pathos dimensions of your message, you might not find yourself understood. You might even look like an ass.
But, like with anything, we have to start by understanding our purpose: what is the point of a tech talk?
Is the point give your career a boost? Or to promote your library? Maybe that's your goal, but I've got some bad news: nobody cares about your career or your library. They care about their own career, and their own code! A good tech talk can help you achieve other goals, but first you have to give a good tech talk.
Is the point to entertain? That's not a bad thing, either. I link to Gary Bernhardt's famous wat talk periodically just because it's fun to watch. But wat would be a completely different thing if it didn't work as a tech talk first.
A tech talk is, first and foremost, a call to action:
That means that the goal of your talk isn't simply to explain how an API works, or to dive into interesting technical problems, or show off how impressive your work is. Your talk must also plant an idea in an audience member's head in such a way that, after they go home and work on their own projects, it will sprout into action. They'll try out that new library, or change their testing practices, write code or tests in a different way, or collaborate on an open source project with you.
Classical rhetoric identifies three aspects of speech that affect the impact it has on an audience:
Being clear about your intentions can only improve your ability to meet your goals. But ultimately, the outcome is not entirely up to you: everyone you talk to is at liberty to do what they believe is best. So they may not do exactly what you want, even if you do everything right! The lens of rhetoric can help you understand why, though. That won't get everyone on board, but it will help you get more people on board.