Skip to content

· public speaking · 9 min read

Speaking at Tech Conferences - How to get started

Speaking at tech conferences is a great way to share your knowledge and experience with the community. Here are some tips on how to get started.

Neciu Dan

Neciu Dan

Hi there, it's Dan, Senior Engineering Manager at Perk, host of Señors at Scale - a podcast for Senior Engineers, Organizer of ReactJS Barcelona meetup, and international speaker, I'm here to share insights on combining technology and education to solve real problems.

I write about startup challenges, tech innovations, and the Frontend Development. Subscribe to join me on this journey of transforming education through technology. Want to discuss Tech, Frontend or Startup life? Let's connect.

Share:

How to be a speaker

Recently a friend got accepted to speak at a popular tech conference and asked me for some advice. I started writing some quick notes for him and it got bigger and bigger until this article came to be. It contains a how-to and all the guidance I can think of for first-time speakers or people who want to try it.

Many people think that speakers are usually invited by the conference organizers, which happens with big names like Framework creators or Open source maintainers, but in truth, people actually have to apply to speak at conferences, and I will explain how you can do this later.

First, find your passion. What do you care about? Where do you bring most to the table? Is it Javascript skills? Hard tech skills like automated testing?

List 10-15 tags or topics representing what you can talk about, and then create 3-4 ideas that can eventually become talks.

I suggest that you don’t be controversial. Some conferences like this because your content has a better reach, but it is always better to be friendly; the internet is filled with controversial content, and people who pay to attend the conference won’t appreciate it.

Then, find a list of conferences with the theme of your subject. If you talk about Python, maybe all the pyConfs, but also dev-related conferences like Techorama or Voxxed Days, all the React conferences, Javascript Conferences, and so on. Follow them on social media, follow the organizers, and engage with them.

Once the event date is approaching, the conference will typically open its CFP (call for papers), where speakers can submit their proposals. The CFP is usually a Google Form or a page on a speaker submission platform.

The most comprehensive list of conferences and their CFPs can be found on Confs.tech.

How to apply

There are speaker platforms like Sessionize and Papercall, where you create a profile, create your talks, and, based on your topics, they will recommend conferences to you.

Now, I recommend not applying directly and blindly. I would usually reach out to the organizers and wait a bit before the end date of the CFP. I would then introduce myself to the organizers (if I don’t know them already) and ask them what topics they are missing, what subjects they have in mind, and what sort of audience will be at the conference.

A little side note: This is the exact methodology my company: CareerOS, advocates when trying to land your dream job.

Based on this feedback, I would then submit 2-3 talks.

Keep in mind that you don’t need your talk to be already finished and ready; you can easily apply with an abstract, a description, and a title.

I recommend keeping the title fun and engaging and not using chatGPT or other LLM tools to generate it; those are spotted from a mile away.

You will start with 5-6 ideas for your talks, and usually 1-2 are accepted yearly. By the time you have done this for 3 or 4 years, you will have an excellent portfolio of presentations to submit to conferences.

Once you get accepted, congratulations! Now it’s time to start working on your talk.

How to build a talk

Usually, the conference will give you a timeslot for the length of the talk. Typically, lightning talks are 15 minutes long, normal talks 30 minutes long, and longer ones 45 minutes long. Keynotes might take 1 hour.

Ask the organizers if you must include time for questions in your slot. If they say 15 minutes is for Q&A and you have a 35’ slot, your talk should be around 20 minutes. Quick maths!

When working on your talk, I recommend building it into a one-hour talk. Include as much content as you can, then trim it down to only the essentials.

The way I do it is simple:

Start with the title and abstract, then create an outline with the talking points:

  • Introduction
  • First talking point
  • Second talking point
  • Third talking point
  • Conclusion

Then, I will add a time slot for each specific point. For example, the introduction should be 7 minutes, the conclusion 3 minutes, the first point 12 minutes, the second 10 minutes, and the last 13 minutes. You can have four talking points, but I would not recommend more than that.

In each section, also break them down into :

  • Setup
  • Content and examples
  • The point this section is trying to make

Then, I fill each section with my script — the exact content I would say on stage.

All three or four talking points should take the audience on a journey with the same big conclusion. I would also recommend adding personal anecdotes and examples from your professional experience, plus a joke here and there. I personally like to start with a joke as part of the introduction.

Another way to keep the audience engaged is to ask them questions. How many of you know this? Who here uses this framework? Who here thinks this is wrong and this is right? Ask them to raise their hands, or better yet, have a Kahoot game that actively engages the audience. But make sure to keep it light and don’t overuse it. One question per talking point is enough.

Getting ready

After you finish building your 50’ to 1-hour talk, it is time to practice, practice, and practice.

First, I would read the script in my head, imagining how it would sound on stage, including the jokes and the questions, and timing myself to measure how long each part would take.

Later, I would start practicing with my laptop and presentation in front of me as I would on stage. I would add the script to my notes and start reading, and in every practice session, I try to read a little less until I have it memorized.

A quick tip here is to practice at your talk’s exact hour. So if you are the first to talk in the morning, practice in the morning; if you are exactly after lunch, practice after lunch; if you are closing the conference, practice at the exact hour of your talk. This way, your body will be in the right mood when adrenaline strikes.

What to know before the conference

Typically, conferences pay for travel and 1-2 nights of accommodation (depending on the length of the conference). They also have a free speaker dinner, and some might have some extra activities in the city. Some conferences also arrange for airport pickup, and they include the conference ticket and maybe one for a guest as well.

Now, some conferences are either non-profits or organized by the local community and won’t have budgets to bring in speakers from out of the country. They will usually mention this as part of their CFP. Also, it’s normal for speakers to pay for their travel and then issue an invoice to the organizers.

That way, it’s less risky for the conference if speakers cancel.

If you are just starting to apply and don’t have a huge name in the industry, I would recommend applying to conferences in your city first. This will increase your chances of being accepted. The reason for this is that organizing a conference is expensive, and if the organizers can save some money on travel and accommodation, they will gladly do so.

But once you’ve done it once or twice, it’s time to spread your wings, apply in neighboring countries, and, finally, everywhere you want to go.

I have personally been accepted to conferences in Utah two times. To Utah Js and React Rally, and without the conferences, I doubt I would have visited Utah, and it’s a shame because it was the most beautiful place I have ever visited (sans maybe Iceland)

Now you made it to the conference! It’s game day.

Welcome to the conference

What you should do, and I can’t stress this enough, Is Go to the speaker dinner and talk to people. If you have a conference Slack or a Whatsup channel, reach out to people to get dinner! Network! 90% of the speaker benefits are from the other speakers and experts you meet. Talk to them, get to know them, what they do, and what they will talk about.

On conference day, wake up as you normally do, don’t overeat, and try to drink the exact amount of coffee you normally do.

You might think you need more, but you don’t. Also, try not to drink too many Coca-Cola drinks or energy drinks.

Especially avoid alcohol until your talk is finished.

Try not to speak too much or too loud before your presentation. Speak, but save your voice.

Fun Fact: I usually get very, very nervous around 30 minutes before my talk and have to pee every 5 minutes. So you might see me go to the bathroom every 7 minutes.

But once I am on stage, it’s show time, and all my nerves go away.

Before I walk on stage, I do 20 seconds of breathing exercises, and If I am able, I give a massive shout or yell at the end to pump me up ( I learned this from the movie Coco )

On stage, I keep my keynote view to show me:

  • My notes half the screen
  • Current slide at the top
  • Next slide below it
  • A big timer at the top so I know how I am doing on time

And then I rock and roll. I don’t like using a clicker or my phone to change the slides. I prefer to stay in front of my laptop.

Another thing I would recommend is to try not to fidget. Control your body. If you have to gesticulate, do it when making a point, especially with your feet and body movements. Try to be as still as you can.

I still have this problem, and it takes a lot of willpower to remember it on stage.

A final tip: If you forget something you wanted to say or you’re having a brain freeze, move on. It’s worse to try to remember and mumble something than just to move to the next slide. Your audience won’t know you skipped something, and if it happens, it’s okay! It’s normal! It’s part of life!

After that, you did it! Take a selfie on stage, thank the organizers, thank Beyonce, and enjoy the rest of the conference!

Go talk to people! Post on social media, mingle, answer questions, and attend the rest of the talks! Don’t leave. The organizers love it when speakers mingle with the attendees and will most likely invite you again if you are a good sport.

And most importantly, have fun! You are doing this because you love it, and you want to share your knowledge with the world.

Neciu Dan

Discover more from The Neciu Dan Newsletter

A weekly column on Tech & Education, startup building and occasional hot takes.

Over 1,000 subscribers

🎙️ Latest Podcast Episodes

Dive deeper with conversations from senior engineers about scaling applications, teams, and careers.

Hypermedia at Scale with Carson Gross
Episode 53
58 minutes

Señors @ Scale host Neciu Dan sits down with Carson Gross, creator of HTMX, principal at Big Sky Software, and computer science professor at Montana State University. Carson has been programming for more than 30 years, from HyperCard on a family Mac to Excel macros for an industrial engineering firm, a JVM language called Gosu, a Rails startup, and the 2012 library Intercooler.js that he rewrote without jQuery during COVID and released as HTMX. His argument is that the web was built as a hypermedia system, that links and forms are control logic living inside the document, and that most of what we call REST today fails the one constraint Roy Fielding cared about. He also covers which apps HTMX is wrong for, what changed in HTMX 4 and why 3 was skipped, and why his students now sit pencil and paper exams. It is a conversation about using the browser as the hypermedia client it was built to be.

📖 Read Takeaways
Performance at Scale with Ryan Townsend
Episode 52
52 minutes

Señors @ Scale host Neciu Dan sits down with Ryan Townsend, Principal Product Manager for Performance at Cloudflare, where he owns real user monitoring and the wider performance measurement remit. Ryan has over 20 years in web technology and a decade as a CTO: he co-founded Shift Commerce, the first enterprise scale headless SaaS, and was CTO of Matalan Direct after the business he built came second in Shopify's Build a Business competition with only three months of trading. We cover why the 'Rails doesn't scale' story was always a myth, the resume driven development he kept finding as a fractional CTO, the personalization script that claimed zero performance impact and cost seconds at P90, and how Shift ran over 99% cache hit ratios by splitting the anonymous page from the basket.

📖 Read Takeaways
Design Systems at Scale with Szymon Chudy
Episode 51
56 minutes

Señors @ Scale host Neciu Dan sits down with Szymon Chudy, Software Engineer at Netflix on the Hawkins team, which builds the design system behind thousands of internal applications used to produce the shows you watch. Before Netflix, Szymon spent two and a half years at Lokalise, growing from senior to staff frontend engineer and leading frontend direction across teams, and before that he toured Poland as a reggae guitarist while freelancing as a web developer in the off season. From why the source of truth for a design system lives in code, to Hawkins Consumer versus Hawkins Professional, to the UI paved road that changes what freedom and responsibility mean at Netflix, to measuring the team on adoption rate and shipping codemods and agent skills for every breaking change, to what being an informed captain who farms for dissent means in practice, this is the design system conversation for anyone maintaining a platform other engineers have to choose to use.

📖 Read Takeaways
Agentic Systems at Scale with Vilva Athiban
Episode 50
52 minutes

Señors @ Scale host Neciu Dan sits down with Vilva Athiban, Lead AI Engineer at Omio, one of Europe's leading travel platforms, where he architects and ships agentic AI systems in production. Vilva designed and delivered Omio AI, along with the MCP integrations that connect AI agents to the company's systems. He never set out to switch from JavaScript to AI: in June 2024 Omio picked two people to start an AI team reporting to the CEO and CTO, and he learned on the job, from his first API call to an LLM up to a consumer-facing agent whose backend runs on nothing but MCP. From why a bigger model with medium thinking came out cheaper than the mini, to capping tool calls because LLMs are built for token maxing, to the whale hunting request that showed his team guardrails are subjective, this is a conversation about what production agentic systems look like once the tutorials run out.

📖 Read Takeaways
Back to Blog