From idea to abstract: Writing a conference talk proposal

You’ve been to a conference, listened to a great talk, and thought: Hey, I could talk about that, too.

Or perhaps you’ve solved a particularly tricky problem at work, learned something the hard way, or found yourself explaining the same thing to colleagues for the fifth time. Maybe you’ve even caught yourself thinking that other people could benefit from what you’ve learned.

And then someone mentions a call for proposals (CFP), and suddenly things get complicated.

What should you talk about? How do you write an abstract? What if you’re not an expert? And how do you know whether your idea is even good enough for a conference?

Let’s break it down. You don’t need a groundbreaking discovery or years of public speaking experience to propose a conference talk. You need an idea worth sharing, a sense of who might benefit from it, and a way to explain what people will get out of listening to you.

Find your idea

One of the biggest misconceptions about conference talks is that you need to be an expert on something nobody else has ever done. You don’t.

Some of the most useful talks come from ordinary work experiences: solving a problem, making a mistake, trying a new approach, or figuring out how something actually works. You might have learned how to debug a particularly stubborn Kubernetes workload, migrated an application without taking everything down, or discovered that a process everyone considered obvious wasn’t obvious to anyone.

All of these can be the starting point for a talk.

If you’re struggling to find an idea, try asking yourself:

• What have I learned recently that I wish I’d known earlier?
• What problem have I solved that other people might be facing, too?
• What do colleagues regularly ask me for help with?
• What did I get wrong, and what did I learn from it?
• What do I have a strong opinion about, and why?
• What have I tried that worked differently than I expected?

Don’t worry about writing an abstract just yet. Start by collecting ideas. Write them down, even if they seem too small, too obvious, or not quite interesting enough. You can decide what to do with them later.

And remember: you don’t have to be the world’s leading expert on a subject to talk about it. Sometimes the person who figured something out last month is in a better position to explain it to someone who is struggling with it today than the person who has been doing it for twenty years.

Turn your topic into a talk

You’ve got an idea. Great! Now comes the next challenge: figuring out what your talk is actually about. And there’s a difference between a topic and a talk.

“Kubernetes security” is a topic. It’s also enormous. You could fill several days with it and still leave things out.

“How we discovered that our Kubernetes security assumptions were wrong” is closer to a talk. It suggests a story, a specific perspective, and something the audience might learn.

You don’t need to cover an entire subject. You need to give people a reason to spend 20, 30, or 45 minutes listening to you talk about one part of it.

Try finishing this sentence: After listening to my talk, people will understand how to…

Or perhaps: I want to show people why…

If you can’t finish either sentence without writing a paragraph, your idea might still be too broad. That’s perfectly fine. Narrow it down.

Think about what you can realistically cover in the available time. A short lightning talk might focus on one surprising lesson, while a longer session can explore a problem in more depth. Neither format requires you to explain everything you know.

Think about your audience

Once you know what you want to talk about, consider who might want to listen. You don’t have to appeal to everyone at a conference. In fact, trying to do so often makes a proposal less clear. Instead, imagine a particular person who would benefit from your talk.

Are they new to a technology? Have they been working with it for years but haven’t encountered your particular problem? Are they trying to convince their team to change something? Do they need practical instructions, a new perspective, or reassurance that they’re not the only ones struggling?

The more clearly you can picture your audience, the easier it becomes to decide what belongs in your talk and what doesn’t.

For example, a talk about debugging Kubernetes workloads could be aimed at people who are completely new to Kubernetes. Or it could be aimed at experienced engineers who understand the basics but struggle when a workload looks healthy and the application still doesn’t work.Both are valid audiences. They simply need different talks.

You don’t necessarily have to spell out your entire target audience in the abstract. But you should know who you’re speaking to, and your proposal should give the programme team enough information to understand that, too.

Write the abstract

Now that you have an idea and an audience, it’s time to put the idea into words.

The abstract is often the most intimidating part of a conference proposal. It needs to be short enough to fit the CFP requirements, but detailed enough to help someone understand what your talk is about.

The good news? You don’t have to make it perfect on the first attempt.

A useful starting structure is:

The hook: Why should someone care about this topic?

The context: What problem, question, or experience will you explore?

The approach: What will you actually discuss, demonstrate, or explain?

The takeaways: What will the audience understand, learn, or be able to do afterwards?

These aren’t rigid rules. You don’t need four separate paragraphs or to label every element. Think of them as questions your abstract should answer.

Let’s look at an example.

Before: A topic, but not much of a story

Title: Kubernetes Debugging

“This talk covers common Kubernetes problems and explains how to debug applications running in Kubernetes. We will look at Pods, deployments, events, and logs, and discuss useful troubleshooting techniques.”

There’s nothing fundamentally wrong with this description. It tells us the general topic and mentions some relevant tools. But it doesn’t give us much reason to choose this particular talk over another session about Kubernetes debugging.

What problems will we investigate? What makes this approach useful? What will we be able to do afterwards?

Let’s try again.

After: A clearer idea of what to expect

Title: Your Pod Is Running. So Why Is Your Application Broken?

“Your Kubernetes workload is running, the Pods are green, and yet the application still doesn’t work. Sound familiar?

In this talk, we’ll follow a broken workload through the debugging process, from recognising symptoms and reading events to identifying the underlying problem. Along the way, we’ll explore how to approach troubleshooting systematically instead of randomly changing configuration and hoping for the best.

You’ll leave with a repeatable approach to investigating common workload failures and a better idea of where to look the next time Kubernetes says everything is fine — but your users disagree.”

The second abstract gives the audience a problem they might recognise, explains what the session will cover, and makes the expected learning outcomes clearer.

Notice that it doesn’t promise to solve every possible Kubernetes problem. It describes one useful approach and sets realistic expectations.

That’s what you’re aiming for: not the most impressive-sounding abstract, but an honest, clear description of a talk people might want to attend.

Tell people why you’re giving this talk

Many CFPs also ask for a speaker bio or a short explanation of why you’re the right person to give the talk.

This is where people sometimes get stuck. They assume they need an impressive job title, a long list of certifications, or years of experience speaking at conferences. You don’t.

Your bio should help the programme team understand your relevant experience and perspective. It doesn’t have to be a complete account of your professional life.

If you’re proposing a talk about a problem you solved, explain your connection to that problem. If you’re sharing lessons from an experiment, describe what you tried and what you learned. If you’re exploring a subject you’re passionate about, that can be relevant, too.

Be honest about what you’ve done and what you’re bringing to the audience. You don’t need to claim expertise you don’t have, and you don’t need to apologise for being at a particular stage in your career.

A useful question to ask yourself is: What makes my perspective on this topic worth hearing?

You might have hands-on experience, a different way of approaching a familiar problem, or a story that helps other people understand something more clearly. You don’t have to be the only person who could give this talk. You just have to be able to give the talk you’re proposing.

Read the CFP carefully

You’ve got an idea, written an abstract, and put together a speaker bio. Before you submit, take a step back and look at the actual call for proposals.

Every conference has its own requirements and priorities. Some ask for a short abstract; others want a detailed outline. Some request explicit learning objectives, while others ask about the intended audience or the format of the session.

Read the instructions and answer the questions the organisers actually ask.

A few things worth checking:

• The format: Are you proposing a lightning talk, a standard session, a workshop, or something else? Does your idea fit the available time?
• The audience: Is the event aimed at beginners, experienced practitioners, or a mixture? Does your proposal fit?
• The abstract requirements: Is there a word limit? Are there specific questions you need to answer?
• The title and description: Do they accurately describe the same talk?
• The practical details: Have you completed all required fields and removed anything that shouldn’t be part of the public-facing description?

Also, take a look at the conference programme and its previous editions if they’re available. This can help you understand the event’s focus and the kinds of sessions it offers.

You don’t need to guess what the organisers want to hear or rewrite your idea to sound like every other talk on the programme. You do need to show how your idea fits the event and why its audience might care.

Get feedback before you submit

If possible, ask someone else to read your proposal before you send it off.

Ideally, choose someone who can give you honest, constructive feedback. They don’t have to be an expert in your topic. In fact, someone outside your immediate area of expertise can be particularly helpful: if they can’t understand what your talk is about, you might need to explain it more clearly.

Ask them questions such as:

• Can you tell what this talk is about?
• Who do you think would benefit from attending?
• What do you expect to learn from it?
• Is anything unclear or unnecessarily complicated?
• What questions do you still have after reading the abstract?

Listen to their feedback, but remember that it’s your talk. You don’t have to incorporate every suggestion, and different people may have different opinions about how to present the same idea. The point is to find out whether your proposal communicates what you intended.

And if you don’t have someone to ask, don’t let that stop you from submitting. Feedback is useful, but a proposal doesn’t need to pass through a committee of friends before it’s ready to leave your hands.

Submit the proposal

At some point, you have to stop editing. You could spend another three hours adjusting the title, replacing one adjective, and moving a sentence around. Sometimes that helps. Often, you’re just finding new ways to procrastinate.

If your proposal explains the idea, gives the audience a reason to care, and meets the CFP requirements, it may be ready. Submit it.

And then comes the difficult part: waiting. Your proposal might be accepted. It might be rejected. You might receive feedback, or you might hear nothing beyond the final decision.

A rejection doesn’t automatically mean your idea was bad or that you’re not ready to speak. Conference programmes have limited space, and decisions depend on many factors, including the event’s focus, the mix of sessions, and the other proposals submitted.

If your talk isn’t selected, you can revise it, submit it to another conference, or try again next time. If feedback is available, use it. If it isn’t, you can still ask someone to review the proposal with you.

Your first submission doesn’t have to be your last, and you don’t need to wait until you feel completely confident to start.

Before you hit submit: a final checklist

Take one last look at your proposal and ask yourself:

• Can someone understand the central idea without additional explanation?
• Is it clear who might benefit from this talk?
• Does the abstract explain what I’ll actually cover?
• Have I described concrete, realistic takeaways?
• Does the title give people a useful idea of what to expect?
• Does the proposal fit the CFP’s requirements?
• Have I asked for feedback if that was available to me?
• Am I still editing because something needs fixing, or because submitting feels scary?

If you’ve worked through these questions, you’ve already done something valuable: you’ve taken an idea that existed in your head and turned it into something you can share with other people.

And that’s a meaningful step, whether this is your first proposal or your fiftieth.

Your idea deserves a chance

You don’t need to have everything figured out before you propose a talk. You can learn as you go, refine your ideas, and get better at explaining them with practice.

Start with something you know, something you’ve experienced, or something you want to explore. Find the part that might be useful to someone else. Then tell them why.

And if you’d like a little help along the way, that’s what reher*sal is here for. We’re building spaces where FLINTA* folks in tech can develop their ideas, practise their talks, and become more comfortable sharing their knowledge on stage.

You don’t have to do everything alone. Sometimes, all you need is someone to read your abstract and ask the right questions.

Now, go find that CFP. And if you need a sparring partner, feel free to ping us :)