I've Spoken at ISC, Supercomputing, and NASA. Here's How CFPs Actually Work.

Nobody Tapped Me on the Shoulder

I've spoken at ISC High Performance in Frankfurt, Supercomputing in the US, Open Infrastructure Summit, ARM Dev Summit, Operator Day, and NASA Cybersecurity Day. I've sat on technical panels and served on Intel's Cloud Board of Advisors.

None of that happened because someone invited me. It happened because I submitted CFPs, got rejected a lot, and kept submitting.

The barrier to conference speaking isn't talent or pedigree. It's knowing how the system works and being willing to do the work. I'm an Icelandic engineer without a CS degree. That's not the standard ISC speaker profile. It didn't matter.

The Career ROI Is Non-Linear

I'll skip the motivational platitudes and get to concrete outcomes.

My conference speaking at ISC and Supercomputing while CTO of HPCFLOW established me as a voice in the HPC community. That reputation led directly to the Canonical role — I was hired to lead HPC product strategy partly because I was already a known quantity in the space. The Canonical conference circuit expanded the network further. When Millennium was looking for someone to build their HPC platform from scratch, the industry visibility didn't hurt.

The HPE Centre of Excellence collaboration in Grenoble — a five-year partnership that shaped my understanding of enterprise HPC — started from conference connections. Intel's Cloud Board of Advisors was a direct result of being visible in the right rooms.

Speaking also creates serendipity you can't plan for. A blog post becomes a talk becomes a hallway conversation becomes a collaboration becomes the next blog post. Content compounds. Each piece makes the next more credible.

None of this was planned as a linear career strategy. But the pattern is clear: speaking creates visibility, visibility creates opportunity, opportunity compounds.

How CFPs Actually Work

Most engineers treat conference CFPs like job applications: submit and hope. That's wrong.

A major conference like ISC or KubeCon gets 500+ submissions for 50-80 talk slots. The programme committee reads each one for maybe 90 seconds on the first pass. Your abstract needs to communicate value immediately. Not in the third paragraph. In the first sentence.

Committees want talks that fill seats and get good feedback scores. A practical tutorial that helps 200 attendees solve a real problem beats a brilliant theoretical talk relevant to 15 people.

Novelty matters less than you think. You don't need a breakthrough. You need a perspective the audience hasn't heard. "How we migrated 1,000 GPU nodes from PBS to SLURM" is novel enough because almost nobody has written about it. Your day job is full of talks that haven't been given yet.

If you're a first-time speaker, say so. Many conferences actively want new voices. Being from an underrepresented geography or background can work in your favour.

Writing CFPs That Get Past the First Pass

Lead with the problem, not the solution. "SLURM cluster management relies on CLI tools designed in the 2000s. As clusters scale past 1,000 nodes with heterogeneous GPU resources, operators need real-time visibility that squeue and sinfo can't provide." That's a hook. "I built a terminal UI in Go" is not.

Be specific about what the audience will learn. "Attendees will leave with a working understanding of how to implement multi-version API adapters in Go, deploy a Prometheus monitoring stack for SLURM, and configure AlertManager rules for GPU utilisation anomalies." Specificity signals you've thought about the audience, not just yourself.

Include your credibility in one sentence. "The speaker has built and operated SLURM platforms serving 1,000+ GPU nodes across three organisations including a global quantitative hedge fund." That's enough. Don't write a paragraph about yourself.

Start with short formats. A 15-minute lightning talk is easier to get accepted than a 45-minute keynote. Panels and BoFs are even easier entry points. My early conference appearances included panels, which require less solo preparation and give you stage experience.

Submit to multiple conferences. I treat CFP season like a pipeline. The same core idea adapts for different audiences. A talk about SLURM monitoring for ISC becomes a talk about Prometheus exporter patterns for KubeCon becomes a talk about Go SDK design for GopherCon. Same work, different angle.

Write First, Speak Second

The most efficient path is the content-to-talk pipeline. Write a blog post about something you built. The post does well. You submit a CFP based on it. The CFP gets accepted because you've already proven the idea has an audience.

At Canonical, I published technical content about HPC on Ubuntu, which became the foundation for conference submissions to OpenInfra and ARM Dev Summit. The published content served as proof to programme committees that I could articulate complex ideas clearly.

The pipeline also solves the biggest first-timer problem: "What do I talk about?" Look at your last three months of work. What problem did you solve that made you think "I wish someone had written about this"?

That's your talk.

Write the blog post. If people respond, submit the CFP. If nobody reads the post, the talk probably wasn't going to work either. The blog post is a cheap test of the idea.

Delivering the Talk

Preparation is where most engineer-speakers over-invest in the wrong things.

Slides are not the talk. I've seen brilliant engineers build 80-slide decks packed with architecture diagrams and then read them aloud. That's a document, not a presentation. If the audience can get the full value from your slides alone, you didn't need to be there.

Practice the opening and closing. The first 60 seconds determine whether the audience pays attention. The last 60 seconds determine what they remember. Script those. The middle can be more flexible. I don't memorise talks, but I always know exactly how I'm starting and exactly how I'm finishing.

Time yourself. Going over time is the most common and most disrespectful failure mode. If you have 30 minutes, prepare 25. The remaining 5 will be absorbed by setup, questions, and the fact that you talk slower with an audience than in practice.

Tell stories, not specifications. "We evaluated three approaches to multi-version API support" is boring. "At 2am, our monitoring dashboard went dark because SLURM upgraded from v0.0.41 to v0.0.42 and every API call started returning 400 errors" is interesting. Same technical content. Different delivery.

Handle questions honestly. "I don't know" is a perfectly good answer. Bluffing through a question you can't answer damages credibility more than admitting ignorance.

What I'd Do Differently

I should have started writing blog posts earlier. My first conference talks came before I had any published writing, which meant I was pitching ideas cold to programme committees who'd never heard of me. If I'd had three or four solid blog posts already circulating, the first CFP acceptances would have come faster.

I also wish I'd recorded more talks. Several of my early presentations at smaller events weren't recorded, and having video of previous talks makes future CFP submissions dramatically stronger. If the event doesn't provide recording, bring your own phone on a tripod. It's worth it.

The other mistake: I didn't network deliberately enough at my first few conferences. I gave the talk, answered questions, and left. The hallway track — the conversations between sessions, the speaker dinners, the impromptu meetups — is where the real value lives. The talk gets you into the room. What you do in the hallway determines whether the room remembers you.

The Practical Starting Point

If you haven't spoken at a conference: write a blog post this month about something you built at work. Give that talk at a local meetup next month. Record yourself. Watch it. Cringe. Improve.

This quarter, identify three conferences with open CFPs and submit to all three. Adapt the abstract for each audience. Expect rejection from at least two. That's normal.

This year, get one talk accepted. Deliver it. Have hallway conversations. Write a follow-up post incorporating the questions you received. Submit to the next round with "Previously presented at [conference]" in your bio.

The hardest part is submitting the first CFP. Everything after that is iteration.