Your title is doing more work than you think

There's an uncomfortable truth about your CFP submission: the title carries more weight than the abstract, and it carries far more weight than the bio. The reviewers who have actually sat on selection committees and written about it don't disagree on much.

Shawn Wang (swyx), who reviewed CFPs for the AI Engineer Summit and wrote one of the most-shared CFP guides on the internet, puts it bluntly: your title is twice as important as your abstract. Reviewers see both. Attendees mostly just see the title.

Steven Hicks, writing from the same side of the table, adds an important wrinkle. Talks don't get accepted or rejected by organizers on title alone, but attendees absolutely choose or skip based on title alone.

And Kavisha Mathur, writing in 2026 after working through several major tech CFP cycles, observes that conference committees often sort proposals by title before reading the abstract.

If you spent an hour polishing your abstract and ten minutes on your title, you optimized the wrong asset.

This post is the field guide we wish more first-time submitters had. It's opinionated. It won't make everyone happy. But it should save the next CFP cycle from a few hundred titles that don't deserve to be on a multi-track program.

The titles we see most, and reject most

A few patterns repeat in every CFP cycle.

"The Future of [X]." The most overused construct in tech CFPs. Future-of titles promise prophecy and deliver vague pontification. If your talk has a defensible prediction about the future of X, lead with the prediction.

• "The Future of Distributed Systems" lands flat.
• "Distributed systems will get smaller, not bigger: what the next decade of databases tells us" makes a claim worth hearing.

"Building Better [X]." Better than what? Better how? The title commits to nothing.

• "Building Better APIs" says nothing.
• "We rewrote our payments API three times. Here's what we learned about API design under load." says everything.

"Introduction to [X]." Code Europe doesn't run intro content. Even at conferences that do, intro talks compete with the entire internet (and lose). Your differentiator isn't that you can explain a thing. It's that you can explain a thing from a perspective the audience can't get from documentation.

"[X] in the Era of AI." Hype-stapled titles. The committee can tell you added "AI" because it's the trend, not because the talk is about AI. If your talk is about AI, name what specifically. If it isn't, drop the term.

"Lessons Learned from [X]." Lessons learned is fine as a frame. As a title, it leaves the audience asking which lessons, and from how big a system, and what the stakes were. Spoil at least one.

• "Lessons Learned from Our Kubernetes Migration" is everywhere.
• "From bare metal to 300 services on Kubernetes: the three migrations we got wrong before we got it right" is the one people will show up for.

The compound-buzzword title. "AI-Powered Cloud-Native Observability for Distributed Edge Workloads." This is what happens when someone runs every conference theme through a buzzword blender. Pick the topic closest to your actual content and name that.

What good titles do

The titles that earn slots tend to have some combination of these traits.

Specificity over abstraction. "How Discord shards its message database" works because it commits to a company and a specific problem. The generic version, "Database scaling strategies for high-throughput applications," doesn't.

A claim, not a topic. Topics are coverage. Claims are content. "We rebuilt our auth system without downtime" makes a claim. "Modern Authentication Systems" describes a shelf.

Numbers and stakes. Numbers signal real systems. "Cutting our cloud bill by 60% in three months" beats "Cloud cost optimization." The number creates the stakes. The stakes earn the click.

A surprising angle. Liran Tal at Snyk points to a Dominik Kundel talk from JSHeroes 2018, "Don't be afraid of Symbol(JavaScript)," as an example. A niche language feature, given personality. You don't need wordplay. You need a hook.

The colon structure. A working pattern: bold claim, then specific delivery.

• "We deleted 40% of our microservices: a year-long retrospective"
• "Rust without the rewrite: incrementally adopting Rust in a Go codebase"
• "Observability is an architecture problem: what OpenTelemetry doesn't fix"

The first half earns attention. The second half signals that the talk is concrete.

The iteration process

Claire Giordano, who has organized PgDaySF and reviewed Postgres community CFPs, has a rule worth borrowing: write down ten bad titles before you find a good one. Restricting yourself to only good ideas, she argues, stifles the creativity that produces the great ones. Her working ratio is roughly ten bad titles per good title.

She also borrows a line from Dimitri Fontaine, author of The Art of PostgreSQL, who compares title writing to writing code. The first version is rarely better than a rough draft. You write it anyway, to figure out what you're really aiming for.

The implication is uncomfortable but useful. If your title came to you instantly and you've never iterated on it, you probably haven't found the title yet. You have a draft.

The other reviewer-side recommendation, from Snyk's CFP guide, is to write the abstract first, then return to the title with fresh eyes. By the time you've finished the abstract, you know what the talk is actually about. Your first title was guessing.

A 10-minute checklist before you hit submit

Run your title through these questions before submitting.

1. Is it specific? If you replaced the technologies in your title with different technologies, would the title still mostly work? If yes, it's too generic.
2. Does it commit to a claim? Or is it just a topic label?
3. Would you scroll past it on a busy multi-track schedule? Be honest.
4. Have you read it aloud? If it doesn't roll off the tongue, the audience won't recommend the talk to a colleague afterwards.
5. Have you A/B tested it? Mathur recommends saying your title to a colleague. If they ask what you mean by it, you have something. If they nod politely and change the subject, you don't.

A final thought

If you're submitting to the Code Europe CFP, your title is the first thing the committee will see.

Give it the time it deserves, and please submit your talk.