Hey {{first name | there}}. Two weeks ago, I wrote about “speaking isn't invite-only” to tell you that it is possible to take the stage at the biggest developer conference in the world no matter where you are.

Based on popular demand, I'm making it a series. And the next logical part is how to get your talk accepted now that you know where to look.

In today’s career notes:

  • your first audience isn't who you think

  • the 4-paragraph abstract that does the reviewer's job for them

  • the field everyone leaves blank (and why it's your edge)

🧗THE EDGE: The Winning CFP Template

Here's the mistake almost everyone makes.

They think the CFP gets rejected because the idea wasn't good enough.

It's usually not that.

I've reviewed CFPs of the biggest cloud native conference (KubeCon + CloudNativeCon).

So let me tell you what actually happens on the other side. A reviewer opens your proposal with a checklist and about 90 seconds of patience. They're scanning for three things:

  • Does this solve a real problem for our audience?

  • Is it clear, specific, and free of typos?

  • Can this person actually deliver it?

That's it. And here's the part that changes everything:

The reviewer is often not an expert in your niche topic.

Now wait!!

I am not saying that they don’t understand your topic. Let me give you an example. 

I've reviewed Data on Kubernetes tracks and have experience with it, but do I know as much about Container Storage Interfaces (CSI) as someone who works full time building one? 

Absolutely not!

That's normal. So if your CFP assumes the reader already gets it, you lose. 

You're writing for an audience that wants your knowledge. That's why people go to conferences to learn. 

So treat reviewers as your audience. Because they are. 

Make their job easy, and something quietly shifts. They start rooting for you.

Start with the title

Your title is doing more work than your abstract. It's the first thing that gets read.

The formula:

[Action-oriented] + [specific technology/practice] + [clear outcome]

Good:

  • "From 4-Hour Deploys to 4 Minutes: How We Automated Our Kubernetes Pipeline"

  • "Debugging Production Without Losing Your Mind: An SRE's Survival Guide"

Rejected-on-sight:

  • "Cloud-native Best Practices" (too vague)

  • "My Journey with Containers" (nobody's outcome but yours)

If your title could be a blog post from 2016, rewrite it.

Then the abstract — four paragraphs, 200–300 words

Not a wall of text. Four moves, in order.

1. The Hook (2–3 sentences). State the pain. Make it specific enough that the right person feels seen.

"Your team just got paged at 2 AM. Again. The same service that went down last week is down again, and you have no idea why. Sound familiar?"

2. The Promise (2–3 sentences). What will they learn? What can they do Monday morning? Use real numbers if you have them.

"In this talk, I'll share the exact observability strategy we implemented that reduced our MTTR from 3 hours to 15 minutes, and how you can do the same."

3. The Content (3–4 sentences). What you'll actually cover. Name the tools. Specificity reads as competence.

"We'll cover: implementing distributed tracing with OpenTelemetry, setting up meaningful SLOs without drowning in metrics, and building runbooks that actually help during incidents."

4. The Credentials (1–2 sentences). Why you. Brief. Relevant. No résumé.

"As a platform engineer at [Company], I've been on-call for 3 years managing 200+ microservices."

The part almost nobody does (this is your edge)

Most CFPs have an "additional notes" field. Most people leave it blank.

Don't.

DON’T

I REPEAT DON’T!!!

Use it to tell the reviewer why you are the person to give this talk. 

And then link your LinkedIn, your past talks, books, and any other evidence out there that shows your experience.

Here's why that's not optional. Reviewer guidelines literally tell us to look speakers up, see for yourself here

When I have to search your name myself, that's friction. 

When the link is right there. I trust you faster. You just did my job for me.

That's the whole game: reduce the reviewer's effort at every step, and you tilt the decision your way.

What gets you auto-rejected

Yes!! These are just a small batch of my rejections 😭😭😭😭

Before you submit, kill these:

  • It's a sales pitch. Marketing your closed-source company's product? Rejected. You can sell subtly once you're good, not before.

  • It's closed-source. Most community conferences require open source. Read the rules.

  • It's a rerun. Same talk you gave last quarter with no updates.

And remember what part 1 taught you

One brilliant CFP, submitted to one conference, is still a coin flip.

The people who speak at six conferences a year aren't six times more talented. They took two or three strong ideas and submitted them, tailored to many events. More than half won't land. That's the job.

A great template raises your hit rate. Volume does the rest.

ACTION ITEMS FOR YOU

Your homework:

  1. Take one talk idea you've been sitting on.

  2. Write the title using the formula. Then the four-paragraph abstract.

  3. Fill in the additional notes with all your evidence.

  4. Submit it to two events this week.

Worst case, they say no. You've lost nothing. Best case, you're on a stage.

Your move!

🔭VISIBILITY STACK

Stay sharp. Stay visible.

Divine Odazie

P.S. — This whole framework, plus talk structure, slide design, and demo survival, lives in the Speaker's Toolkit. [Want it? Reply "TOOLKIT" and I'll send it over.]

HOW DID WE DO?

Login or Subscribe to participate