How to Give Your 1st Conference Talk!

The Goldmine Nobody Told You About

Here is something nobody tells you on day one of a new job: every role, at every company, with a bit of curiosity, quietly turns into a research project.

You get handed a ticket. The ticket asks a small, boring question. And if you actually chase the answer instead of just closing the ticket, that question drags you sideways into a rabbit hole you did not know existed. Suddenly you are managing 30 chrome tabs and you are three headings deep into a spec, then a mailing list thread from 2019, then someone’s changelog, then you are debugging something that was never really your job, purely because you have to know.

That is not scope creep. That is curiosity doing its job.

And if you follow it far enough, you eventually hit the end of the tunnel, the goldmine, the point where you actually understand the thing. Not “know enough to pass a review” understand it, but own it. At that point something has quietly happened to you: you have not just solved a problem. You have lived a story.

And here is the part that matters for this post. Anyone can Google the information. A search engine will happily hand someone the facts, the syntax, the steps. What it will not hand them is the story: the wrong turns, the moment it clicked, the “wait, that’s why it does that” realization. A story carries momentum. It is the difference between reading a recipe and watching someone actually cook, sweat, taste, adjust, and get it right in front of you. Information tells you what happened. A story makes people want to go try it themselves.

That momentum is exactly what a conference talk could be. And it is the whole reason you should give one.

Every Job Is a Rabbit Hole in Disguise

Think about the last time you got genuinely annoyed by not understanding something at work. Not annoyed enough to give up, annoyed enough to open one more tab. That feeling is the raw material every good talk is made of.

The trap most engineers fall into is assuming a talk needs a groundbreaking discovery, some novel framework, a first-of-its-kind result. It does not. It needs a real rabbit hole you actually went down, and the honesty to show people what you found down there, including the parts where you were wrong.

From Rabbit Hole to Story

Somewhere between “I have no idea why this is broken” and “oh, that’s why this is broken,” you cross an invisible line. Before the line, you have information. After the line, you have a story, because now there is a you in it: the confusion, the wrong hypothesis, the moment it clicked.

That is the ingredient a search engine(or LLM chats :-) can never give someone. It can hand them the syntax. It cannot hand them the feeling of finally getting it, or the confidence that comes after. That feeling is contagious when you tell it well, and it is exactly what makes someone in the audience open their own laptop that night and try the thing themselves.

That is the story you owe the world. And a conference stage is where you tell it.

How I Ended Up Talking About a Tool I Had Never Heard Of

My own first talk was about Juju, a tool I genuinely had no idea about a couple of months ago, while it was managing the bulk of the deployments for our apps. Somewhere beyond the PR merges things turned into a black box for me and I wouldn’t know why what worked locally suddenly gets stuck on prod. Why a supposed cache layer is not caching a service and we are constantly hitting rate limits!?

That question was the rabbit hole. It led to relation protocols, charm hooks, debugging sessions that ran way later than they should have, and eventually to a level of understanding I did not expect to reach. By the time I got to the bottom of it, I was not just someone who could operate the tool. I was someone with a story about becoming someone who could operate the tool. And that story, not the tool itself, is what ended up on stage.

Taipei, the Room, and What Actually Landed

That thread eventually led me to UbuCon Asia in Taipei, where I gave that talk in front of a room that, refreshingly, actually cared about the answer. I wrote about the talk itself in Juju Does Everything. Here Is What That Is Like., but a few things from that experience are worth pulling out here specifically for anyone eyeing their own first talk:

• The questions were the best part, not the slides. The Q&A after was where the real conversation happened, people comparing notes on their own infra headaches, poking holes in my mental model, sharing how they solve the same problem differently.
• Nobody expected perfection. The room was full of engineers who have all stood exactly where I was standing. The bar is “did you teach me something true,” not “did you deliver a flawless TED talk.”
• The story travelled further than the syntax. People did not come up to me afterward quoting my command line examples. They came up telling me about their version of the same rabbit hole.

Why Bother? The Case for Conferences

It is fair to ask why you should go through the trouble at all. A few honest reasons, from someone who was skeptical too:

• Forced clarity. Explaining something on a stage, under a clock, in front of strangers, is the fastest way to discover the 20% of your own understanding that was actually fuzzy.
• Networking that does not feel like networking. Nobody at a conference hallway is there to exchange business cards. They are there because they are curious about the same weird corner of the industry you are. Those conversations turn into collaborators, job offers, and friends faster than any LinkedIn message ever will.
• A permanent record of your growth. A talk is a timestamped artifact. Years later, you can point at it and see exactly how far you have come, and other people can find it and learn from it long after the room has emptied.
• You give the next nervous first-timer permission to try. Someone in that audience is having the exact thought you had before your first talk: could I actually do this? Watching you do it, imperfectly and honestly, is the answer they needed.
• It gives you ideas for your next talk or project. Listening to such a wide variety of speakers and their rabbit holes gives you dimensions and perspectives you would never know existed about your work and ideas.

Cracking the CFP Code

Here is the part nobody explains clearly enough, so let’s fix that.

CFP stands for Call For Proposals. It is the open invitation a conference puts out asking people like you to submit a talk idea. You do not need to be invited, you do not need to already be “a speaker,” you just need to submit. Somewhere between a handful and a few hundred other proposals get submitted, an organizing or program committee reads through them, and they pick the lineup for the event.

A CFP submission usually asks for:

• A title that is specific enough to be interesting, not so clever that nobody knows what the talk is actually about.
• An abstract (a few sentences, public-facing) describing what the audience will walk away knowing.
• An outline (private, for reviewers only) showing you actually have a structure, not just a vibe.
• The audience level (beginner, intermediate, advanced) and a short bio.

The timing catches people off guard. CFPs for a conference almost always close three to six months before the event itself. If you are thinking about speaking at something happening in the fall, the CFP window was probably open in the spring. The lesson: do not wait for the “right” idea to feel finished. Submit the idea you are currently in the middle of, the CFP deadline will likely land before you have fully finished digging anyway.

Where to actually find them:

• Dev Events: a platform I use regularly to browse upcoming conferences.
• confs.tech: a curated, filterable list of tech conferences and their CFP deadlines.
• Your own company’s events or developer relations team, they often track relevant CFPs and can help you shape a first draft.

What makes a proposal stand out, once you are actually writing one:

• Lead with the problem, not the tool. “Why does infrastructure ownership keep breaking for growing teams” pulls more reviewers in than “An Introduction to Juju.”
• Be honest about the takeaway. One clear sentence a reviewer can repeat to their co-organizer: “attendees will leave knowing how to X.”
• Do not oversell scope. A tightly scoped, well-told 20 minutes beats a sprawling, unfocused hour every time.
• Let a little of your actual voice into the abstract. Reviewers read hundreds of these. A human sentence stands out.

Your Turn

You already have the raw material. Somewhere in your last six months of work is a ticket that turned into a rabbit hole, a bug that turned into an obsession, a “wait, how does that even work” that you chased further than your job description asked you to.

That is not just a war story to tell at lunch. That is a conference talk waiting for a CFP deadline. Go find one, and submit before you feel ready. Nobody ever feels fully ready, they just go anyway, and it turns out that is the whole trick.

Resources

• confs.tech: curated conference and CFP deadline list
• Juju Does Everything. Here Is What That Is Like.: the talk referenced in this post