Developers show up for webinars that teach them something they can use by Friday, and they skip the ones that are really a sales deck with a webinar label on it. The format that pulls registration and actually converts is a live technical session run by a real engineer: a build-along, office hours, a deep dive into how something works under the hood. The format that dies is the 40-minute slide march with a demo bolted on at minute 35 and a “book a call” slide at the end. I have run events and webinars across more than 30 devtools companies, and the pattern never wavers. Teach them something and they come back for the next one. Pitch them and they drop off around minute six and never register again.
Why do most B2B webinars flop with developers?
Because they are structured as a sales meeting that a stranger has to sit through, and developers can smell that in the registration copy.
The standard B2B webinar is built around the vendor’s funnel, not the attendee’s afternoon. It opens with company history nobody asked for, spends the middle on positioning slides, and saves anything concrete for a demo that conveniently requires a follow-up call to see properly. An engineer who registered because the title promised something technical figures out by the third slide that they got baited. They close the tab. Worse, they remember, and the next webinar you run gets a lower open rate because you already spent the trust.
The other failure is subtler. A lot of “developer webinars” are technically about a real topic but are still performed at the audience instead of with them. One person talks for 45 minutes over slides, the chat is dead, and the whole thing could have been a blog post that respected everyone’s calendar more. If the session works exactly as well as a recording nobody bothers to attend live, a webinar was the wrong format. Write the doc instead.
What format do developers actually show up for?
Live, hands-on, and built around watching someone competent actually do the thing. There are a few shapes that work, and they all share that spine.
- Build-along. You build something real, live, from an empty file to a working result, and attendees follow in their own editor. The appeal is that they leave with working code, not a page of notes about code they still have to write.
- Office hours. Open session, real questions, screen-shared debugging. This works absurdly well once you have any user base, because people bring their actual stuck problems and everyone watching learns from the edge cases.
- Deep dive. One engineer explains how a hard part of your product or domain actually works. Query planner internals, how you do incremental builds, why distributed tracing drops spans. The draw is genuine expertise, generously shared.
- Teardown or comparison. Live, honest walk through how a class of problem gets solved, including approaches that are not yours. You give up some control doing this, and you get an enormous amount of credibility back for it.
Look at what is not on that list: no overview deck, no “about us,” no customer logos slide. The teaching is what does the selling. If your product is good, it shows up naturally in the workflow you are demonstrating, and that is a hundred times more persuasive than a feature grid.
How do you pick a topic that pulls registration?
Pick the problem your best users are actively fighting this quarter, then title the session as the specific outcome, not the theme.
“Observability best practices” gets no signups. “Cut your Datadog bill by dropping high-cardinality tags without losing the dashboards you use” gets signups, because it names a real pain and a concrete result. The title is the whole registration funnel for a developer audience. They decide in about four seconds whether the next hour is worth it, and vague themes read as a coin flip they would rather not take.
A test I use: could this topic be a genuinely good conference talk? If yes, you have a good webinar. If it only holds together as a webinar because the format lets you pitch at the end, you don’t. The same instinct that makes a strong conference CFP submission makes a strong webinar topic, and for the same reason. Both audiences are choosing to spend scarce attention on you.
Steal topics from your own support tickets, your Discord, the questions that come up on every sales call. If ten people asked it, a hundred will register to hear it answered well.
Who should co-host, and do you need a guest?
Put a real engineer on camera, always, and bring a guest when they add credibility you cannot self-supply.
The host has to be someone who can actually do the work live and answer a hard question without deflecting to “great question, let’s take that offline.” That usually means a founder, a devrel engineer, or a senior engineer who can talk. A marketer hosting a technical session and reading engineer-written notes gets found out in the Q&A every single time. Your job as the marketing person is to produce the thing, drive registration, run the follow-up, and stay off the mic unless you genuinely know the material.
Guests are worth it in two cases. One, a customer who solved a real problem with you and will talk honestly about it, which is a live version of the customer story engineers trust because it is unscripted and specific. Two, a respected outside voice whose audience overlaps yours, which doubles your reach and borrows their credibility. Skip the guest if they are just a warm body or a partner logo. A padded panel of four people who each get eight minutes is worse than one person who knows their stuff.
How do you handle the live demo risk?
Assume the demo will break, and build the session so that when it does, the break turns into the most useful few minutes of the hour.
Live demos fail. The API times out, the build hangs, a typo surfaces in front of 200 people. The good news is that a developer audience finds a real failure more credible than a suspiciously smooth one, as long as you handle it like an engineer instead of panicking. Debug it out loud. Show how you would actually diagnose it. That moment often teaches more than the happy path would have.
Practical hedges: run the whole thing end to end at least twice beforehand on the exact machine and network you will use. Keep a recorded backup of the working flow so you can cut to tape if something is truly dead. Have a co-pilot in the chat handling questions so you are not context-switching mid-command. Pin the repo or gist at the start so people can follow even if your screen chokes. And never demo against a flaky staging environment when a stable local setup will do.
What follow-up turns attendance into pipeline?
The follow-up is where nearly all the pipeline actually lives, and it is the part everyone half-asses.
Send the recording and the resources within 24 hours, to everyone who registered, not just attendees. Most of your registrants could not make the live slot. They signed up because the topic hit, and the replay email is often your highest-intent touch. Include the actual artifacts: the repo, the gist, the commands, the slides if there were any, timestamps to the good parts. Make the email itself useful so it gets opened and forwarded.
Then segment by behavior instead of blasting one “thanks for attending” to the whole list. Someone who stayed the full hour and asked a question is a different human from someone who watched ten minutes of the replay. Route the engaged ones to a genuinely relevant next step, which is usually a resource or a low-pressure office-hours invite, not a demo request from an SDR who never watched the session. Feed the recording into your developer newsletter and clip the best three minutes for social, because one live hour should produce a month of content.
Measure it honestly. Registration and attendance are vanity if nothing moves after. Track replay opens, resource clicks, and how many attended-then-activated or attended-then-booked on their own. If a webinar teaches something real, those numbers hold up. If it was really a pitch dressed up as a lesson, they won’t, and the data will tell you that well before your audience does by quietly tuning out.
