How we participate in 99 IRL events in a year

Every developer marketing team I've ever talked to struggles to get the people actually building their products to go out IRL (in real life) and demo them. Even though it's a clear way to help drive retention and expansion, it's only a small subset of internal yappers who prioritize this.

Since joining PostHog in summer 2025 we've gone from doing one IRL event to over 100 in a fiscal year and roughly 95% of those events involved an engineer (or other team member) speaking, demoing, mentoring, and conversing with existing and prospective customers. We intentionally only do events where we get to contribute this way and over 50% of the company has gone out and demoed in cities around the world, and that percentage keeps growing.

This post is about how the builder relations team has enabled this without twisting any arms.

At previous places I've worked (and this is similar at many dev tools companies) engineers were not motivated by being closer to customers or demoing their work, so speaking opportunities were favors made or obligations felt.

Product engineers FTW

As the old adage in developer relations circles goes, "ship stuff, show people" and like many other companies building products at a fast clip, we have plenty to talk about. The tenet that accelerates the desire to share is our company's value of make it public.

The problem usually arises if engineers in your org need convincing to share what they've made better for customers. This is painless at PostHog because most of our engineers are product engineers:

Product engineers talk to users. They decide what to build. They own pricing, revenue, and user experience. They support customers directly. They're accountable primarily to their users and paying customers. They own product decisions. Source: our Product engineering handbook

So the lesson is, with more ownership, engineers will naturally desire to demo the products they work on which will lead to more customer-centricity and therefore a desire to get out and demo.

An event recap after Meikel did a talk at a dev meetup in Milan earlier this summer.

Culture of demoing

You can't get far on any given work day at PostHog without seeing a demo of what people are working on internally. How we live and breathe demos:

• Weekly all-hands meetings end with 15-20 minutes of people across the company sharing screens and praying to demo gods that what they built works.
• To keep demos going all week long (not just at the all-hands) we have the #demo-posthog-anything channel where people post at all times of day.
• We love hackathons and they always (whether it's a small-team offsite or the all-company offsite) conclude with each team demoing what they worked on.

Keep in mind the demo !== PPT presentation. More substance comes from showing something working than talking about it. Many of the latest AI meetups are prioritizing demos over talks and it's contributing to better attendance and more people getting out and talking. There are exceptions to this – mainly deeper topics that are beyond a product, feature, or tool – still showcasing actual solutions.

Interested in getting in on the demo train? Here's a guide for giving S-tier demos.

Get out of the way

Because we work so asynchronously, the events team has tried our best to propose speaking opportunities and then just get out of the way. We're always available to answer questions and give feedback but ideally even that's not necessary.

What does a speaker need in order to attend and speak at an IRL event?

1. Who/What/Where/When – the event details are the first thing we share with all speakers
2. Merch to give out to attendees – event team ships merch for speakers to give out
3. Budget to travel, if necessary – a subset of the events budget is allocated to travel
4. Official branded slides, logos, hogs – anything brand asset related is readily available
5. Guide on how to do optimal demos / talks – we've got the team covered if they need it

Even before reaching out to speakers with opportunities, we use a speaker-expertise skill that fellow builder relations teammate, Kliment created, that takes that employee's GitHub handle, researches their merged PRs across the PostHog org over the last 6 months and then produces an outline of their work, candidate tech-talk topics with detail, and a /10 talk-worthiness score per topic. This helps us come to the table with starting ideas rather than putting that on the employee.

A recent anecdote: Lizzie joined as our PMM on context warehouse on a mission to bring attention to the work of the team to more users. When she went to see who from the data stack engineering group wants to speak at events, she got an 80% positive response. Thanks to this, you'll now be seeing PostHog at more data engineering events big and small in 2026.

Some engineers organize their own events (dinners and meetups mostly) and speak at events without us even being involved. We love that and it's the epitome of our you are the driver company value.

Once people demo they're hooked

Disclaimer: No one is required to do any of this at PostHog and at least 20% of the company has let me or my team know they have no interest in demoing at events or public speaking. It's not for everyone nor should it be. Because of this, it's always fine when speaking asks are declined.

We also hear some yappers (nickname for posthog team members who speak at events) looking forward to the next opportunity. If a product is a high priority, we will look for more at bats for the people building those. Still, you can always have too much of a good thing so we try to toe the line to avoid overwhelming with speaking ops.

Recap from Dylan after he demoed self-driving and we sponsored the Seattle dev tools edition of AI Tinkerers. Thanks, Dylan.