How to Start Speaking at Tech Conferences as a DevOps Engineer (2026)

Speaking at a conference is one of the most visible things you can do for your engineering career. A single talk at KubeCon, DevOpsDays, or HashiConf can result in job offers, consulting inquiries, and speaking invitations for years.

Most engineers assume this is only for principal engineers at big companies. It's not. Conference organizers are actively looking for practitioners with real stories — not polished executives.

Here's how to get started.

---

Why Speak at Conferences

Career visibility: Your talk goes on YouTube. Your name goes on the schedule. Google-able forever.

Job opportunities: Multiple engineers I know landed senior roles directly from conference talks — the hiring manager watched the recording before reaching out.

Community standing: Being a recognized face in your community (Kubernetes, Terraform, observability) pays dividends for years. You become someone people follow, refer, and invite.

Forces deeper expertise: Preparing a conference talk forces you to understand your topic at a depth you rarely achieve otherwise.

---

Where to Start: Not KubeCon

Most engineers think "conference talk" means KubeCon or AWS re:Invent. Those are hard to get into and nerve-wracking to speak at. Start here instead:

Tier 1 (Start here):

• DevOpsDays (local chapters, 100-400 attendees) — very community-friendly, actively seek new speakers
• Your company's internal tech talks — zero risk, real practice
• Local meetups (Kubernetes User Group, HashiCorp User Group) — 20-50 people, informal format

Tier 2 (6-12 months in):

• KubeCon EU/NA (lightning talks — 5 min, easier to get in)
• HashiConf
• GitOpsCon
• SREcon
• Platform Engineering Day (co-located with KubeCon)

Tier 3 (once you have speaking experience):

• AWS re:Invent
• Google Cloud Next
• KubeCon keynote-adjacent sessions

Start at DevOpsDays. Get accepted. Speak. Get better. Repeat.

---

What to Talk About

The biggest mistake: proposing abstract topics. "Observability best practices" is not a talk. Conference organizers get hundreds of those.

What gets accepted:

1. A Real Problem You Solved

"How we reduced Kubernetes costs 60% using Karpenter — what worked and what didn't"

This is specific, has a concrete outcome, and clearly comes from real experience. Organizers know you'll have real content, not recycled blog posts.

2. A Tool You Built or Implemented in Production

"Building an internal developer platform on Backstage for 200 engineers"

Implementation stories with lessons learned are gold. Especially failures.

3. A Comparison Based on Real Experience

"Why we migrated from ELK to Loki — 18 months later"

Time-boxed retrospectives on technology decisions are credible and useful.

4. A Controversial or Non-Obvious Take

"Kubernetes is too complex for 90% of teams — here's when not to use it"

Contrarian talks get attention. Be prepared to defend your position with data.

What doesn't get accepted:

• "Introduction to Docker" (been done a thousand times)
• Vendor product pitches disguised as talks
• Theoretical content without production experience
• Talks that are basically your company's blog post read aloud

---

Writing a Talk Proposal

Most CFPs (Call for Papers) ask for:

• Title
• Abstract (150-300 words)
• Outline
• Speaker bio

Title formula: [Specific Action/Result] + [Tool/Technology] + [Context]

Good: "Cutting Kubernetes costs by 70% with Spot instances and Karpenter" Bad: "Kubernetes Cost Optimization"

Abstract formula:

1. State the problem (1-2 sentences)
2. What you did about it (2-3 sentences)
3. What the audience will learn (2-3 bullet points)
4. Why your perspective is credible (1 sentence)

Example:

Production Kubernetes clusters are expensive. After our monthly bill hit $40K, we spent 6 months systematically reducing waste — from right-sizing pods to migrating 70% of workloads to spot instances with Karpenter.

Attendees will learn:

• How to identify the top 3 cost sources in any Kubernetes cluster
• The exact Karpenter configuration that handles spot interruptions gracefully
• What not to do (we lost production traffic twice — here's why)

Shubham is a platform engineer who manages 15 production clusters across 3 cloud providers.

Speaker bio: Third person, 3-4 sentences. Your role, what you work on, relevant experience. Not your life story.

---

Preparing Your Talk

Once accepted, the real work begins.

Structure (40-minute talk):

• 0-5 min: Problem framing — what was broken, why it mattered
• 5-10 min: Context — your team/company/scale (helps audience calibrate)
• 10-30 min: What you did — the actual content, with specifics
• 30-35 min: What you'd do differently — this is often the most valuable part
• 35-40 min: Q&A

Slide principles:

• One idea per slide
• More diagrams, less bullet lists
• Show actual dashboards, terminal output, code (real screenshots > mockups)
• Dark theme with large fonts (rooms are often bright and some attendees view remotely)

The golden rule: If you're reading your slides, you haven't prepared enough. The slides are prompts, not your script.

Practice:

1. Record yourself once. Watch it. It's uncomfortable. Do it anyway.
2. Present to 2-3 colleagues before the actual talk
3. Time yourself — 40 minutes goes faster than you think
4. Have someone ask questions during practice

---

The Talk Itself

First 60 seconds matter most. Don't open with "Hi my name is X and I work at Y." Open with the problem, a surprising stat, or a story. Get the audience interested before you introduce yourself.

Handle nerves: Everyone is nervous. The audience wants you to succeed — they chose your talk out of multiple concurrent sessions. Channel the energy.

Questions you can't answer: "That's a great question — I haven't seen that specific scenario. If you want to talk through it, find me after the session." Honest beats bullshitting.

Pace: Slow down. Engineers speak too fast when nervous. Pause between sections.

---

After Your Talk

Post it online: Your slides on Speakerdeck. Recording on YouTube (most conferences post it automatically but sometimes slowly — make your own recording if needed).

Write a companion blog post: "I gave a talk at DevOpsDays about X — here's the full writeup." This gets the content indexed and lives forever.

Connect with attendees: People who approach you after talks are warm connections. Exchange LinkedIn, reply to emails, help where you can.

Apply to more CFPs: Once you have one talk, the second is easier. Conference committees like known speakers — they know you can deliver.

---

2026 Conference Calendar (Major DevOps)

• KubeCon EU (March/April) — CFP opens ~6 months before
• DevOpsDays (year-round, local chapters) — cfp.devopsdays.org
• HashiConf (usually October) — speak.hashicorp.com
• SREcon Americas (March) — usenix.org/srecon
• Platform Engineering Day (co-located with KubeCon) — CNCF CFP
• AWS re:Invent (November) — CFP opens in April

Set calendar reminders 6 months before each conference. CFP windows close fast.

---

Your first talk will be imperfect. Give it anyway. The second will be better. By the fifth, you'll wonder why you waited.

Related: How to Start a Technical Blog as a DevOps Engineer | DevOps Switching Companies Guide | DevOps Skills Employers Want