The anxiety, the excitement, and everything in between
So I did it. I actually did it.
After months of telling myself "maybe next year" and approximately one thousand browser tabs open on "how to write a CFP proposal," I finally hit submit on my first conference talk — not once, but twice. Two different conferences. Two shots at the big stage.
Now I wait. And if you've ever pushed code on a Friday afternoon, you know this specific flavor of dread.
The CFP Process: More Terrifying Than a 3 AM PagerDuty Alert
Writing a Call for Papers (CFP) submission is a strange experience. You spend years accumulating knowledge — debugging things nobody else can reproduce, surviving incidents that aged you five years in five hours, building systems you're genuinely proud of — and then someone asks you to summarize why anyone should care in 300 words or less.
It's like being asked to write a README.md for your entire career. With a catchy title. And a compelling abstract. And a clear takeaway for the audience. No pressure.
Here's what the process actually looked like for me:
Draft 1: A brain dump. Think of it as git commit -m "stuff" — technically committed, completely useless to anyone including yourself.
Draft 2: Better structure, cleaner idea, still somehow 800 words over the limit.
Draft 3: Trimmed, focused, and agonized over every sentence like it was a production Terraform change.
Final submit: Eyes closed, finger hovered over the button, submitted before I could talk myself out of it. No going back — just like git push --force on main (don't do this at home, kids).
Why Two Conferences?
Honestly? Redundancy.
As any good DevOps engineer knows, you never rely on a single point of failure. You build in resilience. You plan for the happy path and the sad path. You set up retries.
Submitting to two conferences was just applying the same logic to my speaking career. If one rejects me, the other might not. If both reject me... well, that's what retrospectives are for.
The two conferences have different audiences, different vibes, and slightly different angles on the same core topic. So rather than copy-pasting (we don't copy-paste in production, and we don't copy-paste CFPs either), I tailored each submission. Same underlying idea, different framing — kind of like deploying the same app to staging and prod, but actually making sure the configs are right for each environment.
What the Talk Is Actually About
I'm keeping the full details close to my chest until there's an acceptance to celebrate — no point in spoiling the plot of a movie that hasn't been greenlit yet.
What I can say is that it's something I've lived. Not a talk built from blog posts I read or documentation I skimmed. This is stuff I've debugged at 2 AM, argued about in Slack threads, and slowly built an opinion on through trial, error, and the occasional kubectl delete pod --all moment of desperation.
The best tech talks aren't the ones where someone recites documentation at you. They're the ones where you can tell the speaker has been there — where the scars are real and the lessons are hard-won. That's what I'm aiming for.
The Imposter Syndrome Is Real (But So Is the Courage)
Let's be honest about something: submitting a conference talk feels wildly presumptuous.
Who am I to stand on a stage and talk to hundreds of engineers? There are people in this industry who have forgotten more than I currently know. Entire conference lineups filled with people who've built things I've only read about.
And yet.
Every single one of those speakers submitted a CFP once for the first time. Every keynote speaker was once a nervous first-timer who hit submit and then immediately wanted to un-submit. The only people who never get rejected from conferences are the people who never apply.
So I applied. Twice. Aggressively, even.
The way I see it: the worst possible outcome is a rejection email, and rejection emails don't crash production. They don't wake you up at 3 AM. They don't require a postmortem. They're just... emails. You read them, you learn from the feedback if there is any, and you resubmit somewhere else.
Two Real Examples of "Just Doing the Thing"
This isn't unique to conference speaking. The pattern of "wait until I'm ready → realize I'm never ready → do it anyway" shows up everywhere in tech:
Example 1: Open Source Contributions
There's a running joke that your first pull request to an open source project is 90% anxiety and 10% code. You read the contributing guide four times. You lint your code manually even though there's a linter. You rewrite your PR description six times.
And then you submit it. And usually? The maintainers are kind. They leave some feedback, you iterate, it gets merged. Or it doesn't, and you learned something. The project doesn't collapse. The maintainers don't laugh at you. You just... contributed. And then it gets easier every time after that.
Example 2: Running Your First Incident Retrospective
The first time you facilitate a blameless postmortem, it feels incredibly high stakes. What if people get defensive? What if I miss something important? What if the timeline is wrong and someone calls it out?
But you run it anyway, because the team needs it and someone has to step up. And it turns out — humans are mostly reasonable in a structured environment. You find the contributing factors, you write the action items, you close the loop. Next time, you're faster and more confident. The time after that, you're teaching someone else how to run one.
The pattern is always the same: the thing feels bigger before you do it than after.
What Happens If I Get Accepted
Chaos. Controlled, exciting chaos.
First, I'll need to actually build the full talk — CFP submissions are more like architectural diagrams than working systems. The real work is in the implementation. Slide decks, demos, timing runs, the inevitable moment where I realize my "20-minute talk" is actually 47 minutes and needs serious pruning.
Then there's the practice. The awkward solo run-throughs in your home office. The friends-and-family beta test where they nod supportively but you can't tell if they understood anything. The first time you do it in front of people who will actually push back with questions.
And then, if everything works — you're standing at a podium, clicker in hand, first slide up, and you realize this is exactly where all those late nights and incident reports and hard-won lessons were always going.
No pressure.
What Happens If I Don't
I resubmit. I write better abstracts. I collect feedback where I can get it, iterate like it's a sprint, and try again.
Conference speaking isn't a merge-or-close binary. It's a pipeline with retries, and the only way to actually fail is to stop running it.
Wish Me Luck 🤞
Two submissions. Two chances. One very anxious engineer hitting refresh on their email more than they'd like to admit.
If you've been thinking about submitting a talk yourself — to a local meetup, a regional conference, anywhere — consider this your sign. The CFP isn't waiting for you to be the world's foremost expert. It's waiting for your perspective, your experience, and your willingness to show up.
Write the abstract. Submit the thing. Push to main.
We'll figure out the rest in the retro.
Have you ever submitted a conference talk? I'd love to hear about your experience — first submissions, rejections, acceptances, and everything in between. Drop a comment below.
Comments ()