Engineering connections: a conference talk primer for humans

At Evil Martians, we’ve long tried to build a culture of knowledge sharing (actually, that’s the concept behind the blog you’re reading right now.) We also believe in open source and contributing to the tech community. It follows that we think that presenting what we have learned, experienced, or built is important, too. After all, just take a look at our events page at the time of writing:

Just like crafting a solid developer tool is a team effort, we bring the same collaborative spirit to the table when supporting our speakers behind the scenes. They might be the only one up on stage, but they’re not alone–our team does its best to help them transform their work and expertise into a story that’s both compelling and useful, and which ideally, will inspire fellow developers. But what if you don’t have a full team of skilled professionals, battle-hardened from years of preparing talks, waiting in the wings? No problem! Let’s discuss some of the practices our team uses so that you can prepare with confidence.

In this article, we’ll talk about choosing a topic, submitting your proposal, crafting your talk, practicing it to perfection, performance tips, and more!

Choosing a topic

This is the hard part. The most difficult task for our engineers can actually just be selecting a topic for their talk. Many developers feel they have nothing worth sharing. This can happen when someone is so deeply involved in their work that they fail to realize the impact of their efforts—or just how groundbreaking it may be.

Irina Nazarova CEO at Evil Martians

Schedule call

The best way to gauge if a topic is worthwhile is by opening up about it a bit. Communicate with your team–because the more people are aware of what you’re working on, struggling with, or turning over in your head, the easier it will be to judge if your subject sparks interest in others (and thus, if it has the potential to excite an audience).

But how to share this stuff? One of the best ways is, you guessed it: meetings! (Potentially a developer’s favorite place to be, right?) Our team works on a variety of projects, but the internal departments come together at least once a week to share, encourage, and help one another. In fact, many of our blog posts and conference talks come about from someone completely unassociated with the work saying something like: “Hmm, this sounds interesting, can you share more?”

Writing a proposal

If you’ve got the concept for your talk, a huge part of the battle has been won, but your next challenge is to make the case that it’s a presentation worth a conference’s time. So, when writing your proposal, you’ll really want to speak to your audience… both of them.

For almost all meetups and conferences, you’ll be required to submit a written proposal or form breaking down your subject for the organizers. Drawing up this outline can be daunting enough, so the main thing to keep in mind when writing a proposal is that there needs to be a key takeaway from your talk. They need to understand what they’ll be promoting. Keep in mind that the people organizing these conferences are serious professionals. A proposal that’s all fluff and jokes won’t cut it—you need concrete examples of the value you’ll bring.

In other words, be clear about the benefits you believe your talk will bring to the audience.

Now consider, is your talk targeted to CTOs, project stakeholders, junior engineers, or someone else? No matter your intended audience, clarify this, outline the specific insights they’ll gain by 15–40 minutes listening to you. To help formulate this, as a general rule ask yourself: how can you make their work better?

How to structure your talk?

So, your proposal has been accepted and you’ve got to put your talk together. First of all, congratulations! But what now?

A good mystery writer needs to know “who done it” before they start planting the juicy clues in their text that will compel readers to solve the mystery themselves. Likewise, you should have some ideas about the key outcome(s) for your audience—your story needs an idea or point of view worth sharing. With this in mind, you can then work backwards to build out the path to take them there.

We have to think about structure—and your presentation, like all stories, needs a beginning, middle, and end. (After all, in a world full of information and extreme amounts of data, a presentation can’t just be a bunch of facts thrown together.) There are many ways to do this, but most will involve sharing and explaining the “when”, “why”, and “how” of the situation. Remember, you’re leading up to a climax which will be the “lesson” of the tale and your unique insights. Then finally, just like you promised in your proposal: share the key takeaway your audience can apply in their own work.

But a good talk is about way more than just making sure it fits a defined format: you’ve also got to emotionally connect to your audience in order to make your talk memorable. The human brain is wired to remember stories. So give those brains what they want! For instance, our CEO Irina Nazarova expertly weaved together the real stories of 3 modern Rails startups into her recent keynote for RailsConf, and this all tied into her big idea on how the Rails community can thrive going forward, which she recently went into detail about:

So, don’t just tell your audience about the theoretical advantages and drawbacks of your product. Give them some compelling, dramatic examples of theory in action: just as an example, like when a client made the switch from their previous project on Hotwire to dynamic frontend React.

Practicing your talk like a pro: real audiences and attention to body language

Once you’ve got your story down, you’re not done yet. For the vast, vast majority of people, it would be a big mistake to deliver a talk with no preparation. Well, at least, if you want to have a successful presentation. Just like comedians heading into dive bars to hone their jokes before headlining a Netflix special, you should get a live audience to listen to you.

One strategy we recommend: ask your teammates to listen in and provide feedback for your practice runs. We love doing this for our team–and it really, really helps our speakers!

But even if you’ve got your talk’s content mastered and ready to verbalize, what are you supposed to do with the rest of you? Body language is a huge part of how we can communicate, and it can be really easy to neglect preparing this aspect of your talk. So, record your practice sessions and note your gestures.

Check out the way our Art Director Roman Shamin couples gestures with bold statements and dynamic pacing to bring his talk alive in the video of his talk:

Work on building up your gesture vocabulary because when your spoken language is in sync with your body language, your delivery is going to be so much more powerful. There are a ton of resources online to help with this, but just to give an idea of what we’re talking about let’s share a few: you could spin your hands in a circle to show the passage of time; take a step off to the the side coupled with the word “however” to demonstrate a new, opposing thought; or a give a clear shrug with upward palms to express doubt. Gestures like this communicate to your audience on another level and make your speech much more dynamic.

Don’t be a living README

Your voice matters and sharing your experience and unique perspective matters—but all talks are really more about the audience than the speaker. So, seek human connection!

As we’ve reiterated again and again, you need to give your audience something that they can walk away with–so if you walk away from this post with any big takeaway, let this be it: many developers have this idea that the more information they can pack into a speech, the better the talk will be. But that isn’t the case—and no one learns this way.

Engineers, more than anyone I know, tend to be hands-on learners. They like to dig into the code themselves. So, conference talks shouldn’t just be some form of verbal documentation.

Rather, the goal is for everyone in the audience to connect with what you are saying. Once you get so complicated that your audience becomes lost, they’ll just zone out, and your potential impact has vanished. (This is especially relevant if you consider how our international tech communities with non-native English speakers might not catch every word the first time.)

By the way, when we prep at Evil Martians we often invite a diverse selection of people to listen to practice talks. This includes both subject matter experts and people with essentially zero background in the topic. Doing this means we can be sure a talk provides value without losing the plot or getting bogged down with unhelpful details or irrelevant minutiae.

(On that note, do you have slides prepared? Great. Now go back and delete a third of them. Too many different minor topics are diluting your main idea. Again, it isn’t about how many cool things you can share–but about how profoundly the audience connects to that one piece of inspiration they’ll walk away with.)

If you’re sharing something really revolutionary or novel, your audience will need time to let those big ideas sink in. This means you need to slow down, repeat yourself often, make transitions clear, and don’t cram so much information in there. Keep it simple.

And… the end!

Getting from concept to conference can be a pretty long process, but the important thing is just having the drive to start and keep going. So, start collecting your ideas, follow these guidelines, and we’ll see you on stage!