One of your engineers just won a CFP. They beat out a hundred other submissions. The conference organizer loved their abstract and now they're in!

Your engineer is about to put 40+ hours of effort into this talk. It's our job in marketing and DevRel to turn that into a durable asset that has 10X the impact.

A conference talk captures an audience of 50-100 people. Maybe 75% of them pay attention (there are always negative Nancy's in every room). Of that, maybe 10% visit your website. Of that, maybe 3% sign up for your product. So, 100 people in the room becomes 1 signup, at best.

That's a terrible ROI, unless you turn one talk into a dozen pieces of content that reach tens of thousands.

What should you do before the talk?

The key is treating the talk as raw material, not the final product. Write the blog post first, document the demo as a tutorial, pre-record a clean video, and design slides that work as standalone social graphics.

Most speakers start with the slides. They open Keynote or Google Slides and start laying out bullet points. Then they rehearse, travel, speak, and call it a victory.

To me, that's a losing proposition. As a company, we just wasted 40+ hours of an in-demand engineer's time and got nothing in return.

You need to do better, and you need to enforce these rules in your company.

Write the blog post first

Sit down with the speaker and write a detailed blog post that covers the topic in full. All of it. The argument, the evidence, the examples, the code, the references. This post becomes the outline, the script, and the research document all at once.

Then derive the talk from the blog post. Cut it down to the 25-minute highlights. Pull the three or four most interesting points. Build slides around those points.

Why this order? Because the blog post has permanence. It lives on your site forever. It gets indexed by Google and LLMs. It gets discovered by developers searching for solutions six months from now. The talk is ephemeral. One room, one afternoon, one audience. Optimize for the thing that lasts.

I wrote about this in my post on writing an effective conference keynote. The best talks come from deep thinking, and deep thinking produces writing. When the speaker writes the full argument first, the talk gets sharper. They know which parts matter most because they've already worked through the whole thing.

The blog post also gives you something to hand to the audience. More on that later.

Plan the demo as a standalone tutorial

If the talk includes a live demo, build it so it works outside the talk context. Don't build a demo that only makes sense when someone is narrating it on stage.

Write it up as a step-by-step getting-started guide or tutorial. Document every step. Add it to your docs or your blog. Make the code available on GitHub.

Now the demo has two lives. A dramatic moment during the talk. And a permanent tutorial that helps every developer who finds it, not just the ones who happened to be in the room.

If you're building for a developer audience, you already know how much good tutorials matter. Conference demos are tutorials waiting to be documented. Don't waste the work.

Pre-record a polished video version

Conference recordings are almost always terrible. Bad audio. Audience coughing. A camera angle that shows the back of someone's head for half the talk. The recording gets posted months after the event, and by then nobody remembers your session.

Have the speaker record the talk in a quiet room before the conference. Good microphone. Clean screen capture. Proper lighting. No audience noise. This is your polished artifact.

Post it to YouTube on your own schedule. Embed it in the blog post. Own the distribution.

The conference recording, if and when it appears, becomes a backup. You already have the good version.

Design shareable slides

Most slides are designed for one purpose: supporting the speaker on stage. But slides have a second life as social media content.

Design key slides so they work as standalone images. One insight per slide. Clean typography. Readable without context. These become the graphics you post to LinkedIn and Twitter over the following weeks.

Not the entire deck. Five or six of the best points, designed to work on their own. Build them with that second life in mind from the start.

What should you capture during the talk?

The 25 minutes on stage are a live research session. Treat them that way.

Get photographed on stage

Get a photo of the speaker on stage, mid-sentence, with the slides visible behind them. Ideally from someone with a good camera who knows what they're doing. But if not, a phone will do.

This photo will appear on LinkedIn. Twitter. Your company's social media. The next CFP proposal. The speaker's bio page. One good photo of someone speaking at a conference is worth more than you'd expect. Ask the conference organizers if they're shooting photos. Get copies.

Record the audience questions

Have someone take notes on every question asked during Q&A. If the speaker is alone, they should write them down immediately after the session while they're fresh.

Audience questions tell you what people actually care about. They reveal the gaps in your material. They tell you where your explanation was unclear or where the topic sparks follow-up curiosity.

These questions become FAQ sections in your blog post. They become follow-up content. They might become entirely new blog posts. The audience is giving you a content roadmap for free.

Note the reactions

Which parts got nods? Which parts got laughs? Which parts produced confused looks? Which parts made people reach for their phones to take a photo of a slide?

This feedback is invaluable for every piece of content you produce from the talk. Double down on what resonated. Rework what confused people. Cut what got blank stares.

What content do you produce after the talk?

You've done the hard work. You have the raw material. Now turn one talk into a dozen pieces of content.

Publish the blog post

You already wrote it. Now publish it, or update it based on what you learned from the audience. Did their questions reveal a gap? Fill it. Did a particular example land better than expected? Expand it.

The blog post is the anchor. Everything else points back to it. With good SEO practices, that post will generate traffic for months or years. Long after the conference fades from memory.

Build a landing page with everything

Create a simple page on your site. Include: the embedded slides (or a download link), the blog post link, the video link, demo links, the GitHub repo, and any resources you mentioned during the talk.

Put a QR code on the final slide that points to this page. When the speaker says "everything I showed today is available at this URL," a good chunk of the room will scan that code. Now they're on your site. Now they're a lead. Now you can follow up.

This landing page serves another purpose. Every future piece of content you produce from the talk links back to it. It becomes the hub. And that hub captures leads indefinitely.

Take the best one-liners from the talk and turn them into social posts. The lines that got rehearsed. The ones that got the nods.

Post them over the following days and weeks. One per day. Attribute them to the talk for context: "From our talk at [Conference Name] on [topic]." Include a link to the landing page or the blog post.

These posts are easy to produce because the hard thinking is already done. You're just repackaging.

Upload video and cut clips

Post the full pre-recorded version to YouTube. Write a strong title and description with relevant keywords. Add timestamps for each section so viewers can jump to what interests them.

Then cut 60 to 90 second clips of the best moments. The boldest claim. The clearest explanation. The most surprising data point. The demo highlight.

Post these clips to LinkedIn, Twitter/X, and wherever your audience hangs out. Short clips consistently outperform full-length conference videos on social media. Most developers won't watch a 25-minute talk. Most developers will watch a 60-second clip that delivers one clear insight.

Publish the demo as a tutorial

Take the demo you built, the one you already documented as a standalone tutorial, and publish it to your blog or docs site. Reference it in the blog post. Link to the GitHub repo.

The demo now serves every developer, not just the 100 in the room. And as I wrote in the 12 types of content that work for developers, tutorials are some of the highest-performing developer content you can produce. They have a natural call to action: sign up and follow along.

Write a follow-up post about audience questions

If Q&A surfaced interesting questions, and it usually does, write a follow-up post that addresses them. Title it something straightforward: "Answering questions from our [Conference Name] talk on [topic]."

Or weave the best questions and answers into an update to your original blog post. Either way, the audience's curiosity becomes your content.

Post slides on SlideShare or Speaker Deck

Some people prefer reading slides to watching videos or reading long posts. Different formats reach different audiences. Post the deck. It takes two minutes.

The slides also become a reference that other speakers and writers can cite and share. Slides get embedded in other people's blog posts. That's free distribution.

If you have a newsletter, and you should, dedicate an edition to the talk. Share the core insight. Link to the video and blog post. Include one or two of the best audience questions. Give your subscribers something they can't get from the public posts, like behind-the-scenes observations or what surprised you about the audience reaction.

Newsletters are also excellent for building your content strategy over time. Each edition that references your talks reinforces your authority on the topic.

How do you amplify the content?

Creating content is half the job. Getting it in front of people is the other half. This is where most speakers drop the ball. They post once and move on. That's leaving reach on the table. I wrote about how to produce and amplify developer content at length, and the same principles apply here.

Coordinate with your team

Before the talk, prepare a shared document with pre-written social posts, graphics, and links. Ask your colleagues to share them during and after the talk.

Five people amplifying your content reaches five times the audience. Ten people reaches ten times. If you work at a company, this is free distribution. Use it.

Give your teammates the exact copy and images. Don't make them write their own posts. Make it effortless to share. The easier you make it, the more people will do it.

Tag the conference and organizers

When posting about the talk, tag the conference's social media account. Tag the organizers. They'll often reshare, and that gives you access to their entire follower base.

Conference organizers want their speakers to promote the event. It's a mutual benefit. They amplify you; you amplify them.

Create quotable graphics

Take your best one-liners, overlay them on a clean branded template, and post as images. Text-only posts get scrolled past. A clean graphic with a bold statement gets people to stop.

You designed some of the slides with this in mind, remember? Now use them.

Post across platforms

LinkedIn for professional reach. Twitter/X for developer reach. Your company blog for SEO permanence. Dev.to, Hashnode, or Medium for distribution into those communities. Reddit or Hacker News if the content is genuinely valuable. Don't spam those; developers will eat you alive.

Each platform is a different audience with different expectations. A LinkedIn post is not a tweet is not a Reddit submission. Adjust your framing for each, but the core content stays the same. One set of ideas, multiple channels.

Time the releases

Don't dump everything on one day. Spread it over two to four weeks. Give yourself a month of content from one talk.

Here's a schedule that works:

Talk day: Social posts with the on-stage photo. Tag the conference. Share the best one-liner.
Day 2-3: Publish the blog post. Share it everywhere.
Week 2: Upload the video. Post the first short clip.
Week 3: Publish the tutorial. Post a second clip. Share slides on Speaker Deck.
Week 4: Write the follow-up post about audience questions. Send the newsletter edition.

That's four weeks of content from one period of concentrated effort. Four weeks where your name and ideas stay visible.

From 100 to 100,000

Let's do the math.

The talk: 50 to 100 people in the room.
The blog post: 2,000 to 10,000 readers over its lifetime, assuming decent SEO.
YouTube video: 500 to 5,000 views, depending on your channel and topic.
Social clips: 5,000 to 50,000 impressions across platforms.
Tutorial: Ongoing traffic as long as it's maintained and the technology stays relevant.
Landing page: Captures leads indefinitely.
Newsletter: Direct reach to your subscriber base.
Slides on Speaker Deck: A few hundred to a few thousand views.

Total potential reach: 10,000 to 100,000 or more. From one talk. From one period of hard work that you were going to do anyway.

I cover this principle of content reuse throughout Picks and Shovels. One of the book's recurring themes is that developer marketing succeeds when you invest once and distribute many times. A conference talk is the perfect example.

The content reuse checklist

Pin this somewhere. Use it for every talk.

Before the talk:

Blog post written and ready to publish
Demo documented as a standalone tutorial
Video pre-recorded with good audio and screen capture
Key slides designed to work as standalone social graphics
Landing page drafted with QR code for final slide
Team amplification document prepared with pre-written posts and images

During the talk:

Photographer arranged (colleague, friend, or front-row stranger)
Q&A notes being taken by someone in the audience
Reactions and engagement observed

After the talk:

How to turn conference talks into marketing content