Speaking at a tech conference is one of those career milestones that seems impossibly far away until someone tells you the actual submission process, at which point it becomes merely uncomfortable. The secret most conference speakers won’t tell you: getting accepted has less to do with your credentials and more to do with how well you explain your idea to a program committee that’s reading 200 proposals in one sitting.

Why You’re More Qualified Than You Think

---

The mental block most developers hit is “I’m not senior enough” or “I don’t know enough about this topic.” Both of these misread what conference audiences actually want.

A senior developer explaining something you already know is less useful than a developer who just figured something out explaining it to people who haven’t yet. The freshness of perspective — the “I was confused, then I wasn’t, here’s why” arc — is genuinely valuable. Conference talks aren’t peer-reviewed papers. They’re structured sharing.

The talks that get submitted and rejected most often are the credential-driven ones: “I have 15 years of experience in distributed systems and I’ll give an overview of…” Nobody wants an overview. They want a specific insight they can take back to their codebase.

Picking the Right Topic

---

The best conference talk topic you can pitch right now is the thing you explained to a colleague last month that made them say “oh, that’s clever.” Not the biggest thing you’ve ever done. Not your company’s architecture. The specific, bounded thing that clicked for someone when you explained it.

Good talk topics share these traits:

• Specific enough to be useful. “Debugging in Rails” is too broad. “How I used TracePoint to hunt down a race condition in production” is a talk.
• Transferable. The audience should be able to apply something after they leave. An experience report is interesting; an experience report with a takeaway is a talk.
• Honest about scope. “Here’s everything you need to know about Kubernetes” is a lie. “Here’s the one Kubernetes concept that unlocked everything else for me” is credible.
• Yours. You should be able to answer follow-up questions without preparation. If the topic requires you to become an expert to speak on it, pick something you’re already expert in.

Writing a Proposal That Gets Read

---

Program committees read abstracts quickly. Your proposal needs to do one thing in the first two sentences: make it obvious who benefits from this talk and what they’ll take away.

This fails:

“In this talk, we’ll explore Ruby’s pattern matching features, introduced in Ruby 2.7 and expanded in Ruby 3.x, examining the syntax and semantic model as well as use cases in production code.”

This works:

“You’ve seen the pattern matching syntax. You haven’t shipped it in production because you’re not sure when it’s the right tool. This talk gives you three specific decision points — situations where pattern matching makes code meaningfully cleaner — and the code to prove it.”

The second version tells the committee exactly who this is for (developers who know the feature but haven’t committed to it) and what they get (three actionable decision points). It’s submittable.

The proposal structure that works

• First sentence: Who is this for and what problem do they have?
• Second sentence: What will they be able to do or understand after this talk?
• Rest of abstract: The argument for why your angle is the right angle (not a table of contents)
• Bio: One sentence on why you specifically are the right person to give this talk

Start Small — Meetups First

---

If a major conference feels too big, start with local meetups. Most tech meetups are actively searching for speakers — a 20-minute slot at your local Ruby or Rails meetup is a low-stakes environment to discover what works about your material and what doesn’t.

Speaking once at a meetup also gives you something concrete to put in your conference bio: “Presented at [Meetup Name].” It’s a small credential, but it signals that you’ve done this before and aren’t a complete unknown quantity to the committee.

One meetup talk → refine the material → submit to a regional conference → refine again → submit to a larger conference. The path isn’t immediate, but it’s not mystical either.

Pro-Tip: Record yourself doing a dry run. Not to critique every “um” — to check whether your talk has a clear narrative arc. If you can’t tell a stranger in 30 seconds what the talk is about and what they’ll leave with, the abstract isn’t ready yet. The recording reveals this faster than any amount of internal self-assessment.

Handling the Rejection (Because It Happens)

---

Most proposals get rejected. At popular conferences, acceptance rates run 10–20% even for experienced speakers. This is not a referendum on your worth as an engineer or a speaker.

When you get rejected, ask for feedback if the conference offers it — some do. If not, look at the talks that were accepted and compare their abstracts to yours. Usually the pattern is obvious in retrospect: they were more specific, more clearly audience-targeted, or tackled a topic the committee prioritized this year.

Resubmit the same talk to a different conference. The material doesn’t expire. A rejection from one program committee is data, not a verdict.

Conclusion

---

Getting your first conference talk accepted comes down to two things: picking something specific you genuinely understand, and explaining it in a proposal that makes the benefit obvious in the first two sentences. The speaking part — the actual standing up in front of people — comes later, and it’s learnable. The submission is the gate. Clear the gate first, then worry about the slides.

FAQs

---

Q1: Do I need to have a blog or public presence to get accepted?
It helps but isn’t required for smaller conferences and meetups. A strong abstract can get you in without a public profile. That said, a blog post on the same topic as your talk gives the committee evidence that you’ve thought it through. Worth writing if the talk matters to you.

Q2: How long should a conference talk proposal be?
Most conferences ask for 200–400 words in the abstract. Don’t pad to fill space. A crisp 200-word proposal is better than a meandering 400-word one. Some also ask for a longer “for the committee” section — that’s where you can include talk structure, speaker notes, or prior speaking experience.

Q3: Should I pitch multiple talks to the same conference?
Some conferences allow it; most cap submissions at two or three. If you pitch multiple, make sure they’re meaningfully different — two variations of the same topic reduces your chances for both. Your strongest proposal should go in first.

Q4: What if I get accepted and then panic about actually doing it?
Welcome to the experience of nearly every first-time speaker. Preparation is the cure, not courage. Know your first three sentences cold. Have your slides done a week early. Do at least one full dry run. The adrenaline is real on the day; preparation gives it somewhere useful to go.

Q5: Which conferences are good targets for first-time speakers?
Regional Ruby, Rails, and general software conferences are more accessible than large international ones. RailsConf, RubyConf, regional RubyKaigi chapters, and local developer conferences often actively encourage first-time speaker submissions. Check their CFP (Call for Proposals) pages for language like “we welcome first-time speakers.”