Makes of a Good Sharing Talk

Sharing a few practical tips for preparing technical sharing as a work-in-progress talk organizer.

Motivation

I have been running React Knowledgeable, a sharing series for our company’s React team, for about four months now. With our roughly 30 engineers, we produce a “mini-conference” style sharing consists of a 30-minute feature talk and (most of the time) a 7-minute lightning talk every week. With the exception of a few new hires, we are run on a proposal basis — people propose to talk as opposed to being required by management.

None of our speakers have prior experience of speaking at a conference. A very few of us have perhaps given lectures as TA in college. Most of us have given a presentation before, although the duration and the quality varies significantly, which was one of our original motivations to start organizing the talks under the name of React Knowledgeable, <ReactKnowledgeable />, or `🙂.

With <RK /> we have run preparation workshops for each one of our talks, and have worked with more than 20 speakers. Together we have learned many lessons about how to prepare for a sharing talk. And those lesson learned seem both interesting and valuable to me. As a React developer myself, and as one who seeks for greater impact than delivering features (this, too, shall create greater impact, but allow me to leave this unjustified for the context of this talk), discovering those lessons feels like revealing secrets of some propelling truths. And I cannot help but sharing these lessons to a greater audience.

Intended audience for this post

The focus of this post is on preparation of sharing talks, not conference talks, and not the actual moments of giving the talks. It may be most beneficial to:

• First-time or relatively new speakers who need to give a presentation
• Developers who are interested in giving a talk at a local meetup
• Local community organizers

Preface

First of all, I’d like to admit that speaking is hard. Even after going through the process so many times, every single week I end my last couple of hours in full admiration of the amount of work and thoughts I see in our speakers’ commitments of their talks. It doesn’t matter how short the talk is, how acquainted you are with the audience, the idea of speaking in front of a fair number of people gets you fully serious about it.

But you don’t want to be too nervous about it. If you are too nervous, you may trap yourself in an adamant expectation and lose your personalities to your talk, with which almost always makes the talk more interesting. And the best way to lift the nerve is to get prepared, and get practiced.

Now at four months old, and with the 30+ talks we’ve prepared, we’ve identified a few types of talks that we like in nature. Not that they form the only good talks, but they are some patterns that work for us:

• Introductory talks
• Project-based talks
• Problem-based talks

Three Types of Talks

Introductory talks

This is perhaps the most common type of sharing that comes to mind. Unfortunately, as a personal experience, they are also the hardest type to be made interesting. The potential lack of depth makes introductory topics hard to relate for some and too plain for others.

Still, we managed to find a couple of hints to a possibly more attractive talk:

• New release of an existing library / framework / API that the speaker has been familiar with

Some recent examples include hooks, react-redux v6, “new” context API, CSS in JS, etc. Some of the above may not be that recent, but they may be recent with respect to your tech stack, making them a proper fit for your audience.

If you are a developer, keeping up with your favorite libraries is rewarding. Other than speaking, you can contribute to the project, write documentation or blog posts, or build side projects with them. Sometimes they lead to one another.

From an organizer’s perspective, another reason they make good candidates is that despite the introductory level for the talk content, the speakers who are able to keep up with the edge releases are likely more senior or active. They would make the composition and the conduct of the talk more fluent if not completely natural.

• Topics on engineering tools

We use these tools every day, but due to the complexity on their own and their supporting nature (to us), people may overlook them and get fairly confused from time to time. For us, such tools include Lerna, Flow, CI tools, VSCode, git, etc.

We encourage our developers to pick up those topics, with good reasons. Such topics are abundant. Going deep enough into one of them yields rewarding learning. And we want average developers to know more about them even just to save time.

Project-based talks

We call them “project-based” because they come from a project or a side project that the speaker has been working on. They make the greatest talks of all in our setting. People applaud and applaud and talk with the speaker forever after the talk, amazed at our peer. I observe a striking but simple similarity across all of those great talks: the speaker has already worked for months on the project before even thinking to talk about it.

There’s not much magic after all. Good talk is good content plus good preparation. While this type of talk already has a good basis to work on — that the speaker has diligently worked on this topic for a few months, there must be something that attracts him — it can still take much amount of work and persistence to make it into a good talk.

The most challenging task is organization. There are simply way too many materials. But you need one theme to connect them all. And here are a few schemes that worked for us.

Here are a few simple schemes that should make sense without much justification:

• Motivation - common cases / simple usages - special cases / advanced usages - limits
• Pose a question and try to answer it step-by-step
• Give a demo and show how it was created: Here I’d like to link my "role model" conference talk Joshua Comeau - Explorable Explanations with React

And I’d like to share one more

• A few things that left the most impression

So you’ve worked on your project and you know a lot about it. You sit down to start prepare a talk, you may find yourself attempted to follow some kind of methodology. Like follow its history of development, or some scheme that is natural to the field.

You may be attempted to think that you’re supposed to talk about this and that. Sometimes it’d work. Some other time you’d just get stuck. Likely because they’re not that relevant and you don’t have much to say about those aspects.

We had a speaker who uses Windows at home but needs a Unix environment to work occasionally. So he prepared to speak about how to “Unix” on a Windows machine. At first he tried to present a grand comparison cross all the options he had, only to leave us trying to match all the abbreviated terms on a daunting chart. After a round of sorting out, we started to check with him with a few bullet points that left an impression with us. And we eventually made the talk out of those impressions, a few demos, and filled out any missing links in between.

It happened quite a few times to us. I think sometimes it takes a step back and ask: What were the few things that left the most impression? Once you've figured a few crucial parts, you can go about ordering them, and filling out the missing links. Then you either have a ready talk, or you figure out an organization that makes sense along the way.

Problem-based talks

This type of talks is perhaps the least identifiable, but for me is the most interesting to work with.

I’d like to share a story how one such topic was identified.

We once had an intern who needed to do an exit talk for her internship. She did not work with major features and so she was very stuck at what she could talk about to fill a presentation. We welcomed her to talk at <RK /> and so I proceeded to ask her this question:

What was the most interesting problem you’ve worked on during your internship?

She could answer this without hesitation, that a CSS problem, namely, to replace all pixel value in our codebase with a toRem utility, was the most interesting. I suggested that she give a 7-min lightning talk explaining what the problem was, how she solved it, and what she learned from it.

Turned out that she did have an interesting problem. She ended up talking about CSS AST, string interpolation with SASS + CSS calc(), how Chrome with traditional Chinese has a minimum font size and how that affects rendering, and a number of edge cases she encountered. Many of our more senior developers had not even heard of them. And she pulled together everything with the thread of this problem she encountered.

When you know you have this talk?

• Stack Overflow doesn’t solve your problem
• You have a rare combination of situations, existing patterns don’t solve your case and you ended up coming up with one of your own

Another perspective is to replace your inner voice of “this is weird 🤔”, “this is annoying 🙄” with “this is interesting 😎” and you would have a higher chance of ending up with something interesting and worth sharing.

Notes

• Problem-based talks are more prone to time

It is quite common for people to drop those talk ideas after a while. In other words, if you’ve encountered an interesting problem that makes you wish to give a talk or write a blog post, do it right now. If you cannot fill in all the loopholes that are not directly related, aim at keeping your key points intact and say things like you shall have a separate talk / post / study on those issues. You should not wait until you feel every single detail is in place. In a few weeks of time you may be spinning with other issues, and might feel that that problem is “not that interesting after all”. And you’d lost your chance to share your valuable learning progresses with others.

Preparation Tips

It is OK to use “I”

We’ve learned that a decent hint of personality almost always makes the talk more interesting.

If you’re introducing us to a library, we’d like to know what your unique opinion on it is. Tell us something we can’t read from its docs. We’d like to learn how you use Git that makes your development more efficient, or what your approach is to learn about the new release of React. If it is not you who are speaking with us, you can just write and then play all the slides, right?

So when you prepare for your talk, relax a little bit, think about what is your role inside your talk. Maybe you can start with a story, it’ll relax you, and it’ll make your talk humane. When you start to feel like talking to a friend, your audience will feel natural, too.

Invite someone with the field of knowledge or interest to help with your talk

We’d love it when the participants of our prep workshops contain someone who has expertise or is simply more interested in the topic. He’d provide so many great insights, sometimes even transform the whole talk for the good. If you know someone who’d be interested and you’re not so shy to ask for help from, invite him to listen to your talk once. Maybe you’d even collaborate.

Have one single idea, make compact and clear points that relate to it

I think this point is very important, but Dan Abramov has already written a nice article that illustrates it. So I’ll just leave it here.

Use chances to talk to advance your seniority

If you are giving a talk internally, this may be your chance to become the go-to person in your team on a topic. Those tiny steps ahead will accumulate and give you a valuable edge.

Suggestions to organizers

Things we do

• Rather than topics, be selective on scopes instead

We run a React talk series to a group of React developers. If someone says he wants to give a talk on React itself, we’d expect him to talk about something we don’t know about React, rather than a shallow introduction.

We don’t turn down less related talks. But we’d like the speaker to focus more on intuition, insight, or motivation, rather than technical details. Demos also work two ways. But the key is to find where the audience is.

• Run an introductory interview before the talk

During one of our preparation workshops, we realized that we’re often curious about what motivates the talk. So we decided to add an interview section that works really well. We’d send a list of questions we might ask to our speaker that he may or may not prepare for.

The interview helps in many ways. It gets the audience curious, relaxes the speaker to speak. It’s a natural signal to the start of the event but it creates a buffer for people to settle down.

Things we wish we could do

(may be considered good practice we recommend to other community builders)

• Set a deadline for talk delivery

This may not be a problem for most tech communities because a deadline is automatically set to his talk date, and the speaker is responsible to meet that deadline. We are more lenient because we’d rather the speaker is well-prepared than having to rush for deadline. And we prepare back-up talks to stay flexible. However, we do feel allowing speakers to postpone talks indefinitely actually hurts the preparation process in addition to scheduling.

• Replace Q&A with a break intended for networking

In our opinion the Q&A session has more downsides than pluses. Sometimes the Q&A session drags on forever. Other times, no one asks a question and you and your speaker have to bear with the embarrassment. And who guarantees that one question asked by this person is valuable to all if not most of your audience? Having a great Q&A session is just an occurrence you cannot count on.

One good practice I see from conferences such as React Rally removes Q&A sessions completely, and replaces it with a networking break. If people have questions, they can talk to the speaker during the break. Since networking is one intention for people to go to meetups, I find this approach quite appealing.

In our case we actually don’t strive for exact efficiency, and our speakers and audience are happy having a little discussion after each talk (a break does not make sense for us because people would just sit there anyway), so we kept the Q&A session. But not without struggle. Once our Q&A session routinely fell into random chats and jokes so we had to find a way to nicely remind everyone to stay on topic. We eventually used a fluffy toy to pass around to mark the boundary of a Q - A round.

Closing words

You’d know it when you have a good talk. It’s magically unanimous, everyone in the house agrees. You may think of all the effort trying to answer “what makes a good talk” as the effort trying to reverse-engineer a mysterious result.

After breaking things down and examining them one by one, I find myself owing the readers to this post a very striking and surprising truth that I’ve grown to believe in. I think there are not three types of good talks. There can be an infinitely many types of them, each subject to a unique combination of inspirations, creativity, preparation, and characteristics of the speakers. And then for every developer there is one type of good talks, the one that fits you.

With <RK />, speakers who have spoken once most often would return and speak again. And with a few times of practice, almost everyone finds his own flow and style in his talks, and goes on the track to constantly improve them in his future talks. I think this is the most fulfilling result I’m seeing. And I’d want everybody to know 🙂