My 20+ tips as a conference organiser
By
Mathias Verraes
Published on 10 June 2025
I’ve reviewed conference talk submissions for 10 years, for Domain-Driven Design Europe and other events. Here are my assorted tips for writing your own submissions.
(I’ve spoken at conferences for much longer, and I’ve sinned against all these myself. 🙃)
Writing is thinking. If you outsource your thinking and submit an AI generated talk, then I’m not interested. We don’t need you, we could just invite the machine to do the talk. (Of course, talks about AI can be valuable.)
If the number of years you’ve been a programmer really is the most interesting fact about you, then by all means, open your bio with that. For everybody else, make your bio about the good stuff.
“[Topic] can be challenging. In this talk, we’ll look at some techniques/patterns/approaches to deal with [topic].” When you do this, tell us something about those approaches, because if you don’t, it’s hard to evaluate if it’s going to be worth watching.
Teasers are for movies. If you are worried about spoiling your talk in a two-paragraph abstract, maybe it wasn’t interesting enough to begin with? If you have great ideas, tell us in the abstract. Spoil the solution, the secret, the idea, the closing argument. The talk is for explaining it.
Often I read a 2-paragraph abstract, and have no clue what it’s about. Then I read your 4-paragraph blog post, and it’s all very clear. Abstracts shouldn’t be mysterious puzzles.
“We’ll use [tech] to implement an example” → Unless [tech] can be assumed to be widely known, add a few words about what it is. “We’ll use [tech] (a new graph database) to implement…”
Your audience includes people who have been doing the thing you’re talking about way longer than you. They want to know if they’re going to learn some radical new insights, or if it’s an introduction to the basics. You do them a service by helping them evaluate that.
The goal of your abstract is not to draw in as many people as possible. It’s to draw in the people who need the topic, and filter out the ones who don’t. (Also, you’ll get better reviews.)
Storytelling! Stories have people, context, motivation, stakes, flow, movement, emotions, heroes … (But don’t force a storytelling style if the topic doesn’t deserve it, it can be cringe.)
I can sometimes tell from the abstract that the submitter only knows one programming language. Often, something that is hard or new in your tech stack was long solved in others. If you submit to a general conference, look around at other communities first.
Your abstract and bio are not the only thing we consider. We search for stuff you’ve written and talked about. It helps if you have relevant content out there. If not: write, speak at local meetups, …
Read your own writing out loud. It’s some of the best advice I’ve ever got when it comes to writing.
Expose your ideas to daylight. A conference shouldn’t be the first place you ever talk about this. Explain your ideas to colleagues and friends, then strangers at meetups. Be open to feedback. Then submit it to conferences.
If you’re going to pitch your product or company, at least be honest about it. Covert pitches give your brand and yourself a bad reputation. Many conferences accept pitches, but it’s called sponsoring. (And conferences should label sponsored talks as such!)
I think that a 30-second pitch at the start or end of a 45-minute talk is perfectly fine. Longer pitches, or pitches in the middle of a talk, are annoying (unless the program indicated that it was a sponsored session.)
Often, a definition makes more sense after you’ve explained the concept to the audience, not before. That’s more of a teaching advice, but in any case, don’t open your abstract with “Wikipedia defines [thing] as…” because your audience can read Wikipedia without you.
The modern version of that is “Let’s ask AI”. We’re not here to watch you parrot a mediocre definition that was generated from averages. We want to know how you define this concept, in this context, explained to this particular audience.
Don’t submit a talk because you’re against something, because it makes you angry, because everybody is wrong but you…
Your idea may be valid, but it’s not very nice. Sleep on it, find a brighter angle, rewrite. Watching you talk about something good is way more attractive than watching you rant against something bad.
Many talks are premised on “Everybody does [thing] wrong”. Do you actually know if everybody does it that way? Or do you have one colleague who annoyingly did this thing wrong? Don’t assume something is everywhere because you’ve seen it twice.
If your hobby is, say, rock climbing, and your job is data governance, you could do a talk called “What Rock Climbing Taught Me About Data”. But I often feel this leads to half-baked metaphors and truisms. There’s rarely anything that deeply connects your hobby and your topic. Metaphors should serve the topic, not drive the talk.
A lot of the advice I give to speakers is simply about clarity. You must write from the readers’ point of view, not just yours. You live in your context, but they don’t have the background. They read your abstract among many, and each abstract is a context switch.
And finally: conferences are having a hard time right now. Companies are less likely to invest in sending people. If a generation is never exposed to IRL conferences, they will disappear. But meeting real 3D people with similar interests, debating ideas, forming communities, is how a lot of deep learning happens. Bring your colleagues to conferences, especially if they’ve never been.