PostHog · Zaltsman · Aug 28, 2026 · jina-yoon · Sep 1, 2026 · jina-yoon
diff --git a/contents/blog/how-we-participate-in-99-irl-events-a-year.md b/contents/blog/how-we-participate-in-99-irl-events-a-year.md
@@ -0,0 +1,89 @@
+---
+title: "How we participate in 99 IRL events in a year"
+date: 2026-08-28
+rootPage: /blog
+sidebar: Blog
+showTitle: true
+hideAnchor: true
+author:
+    - daniel-zaltsman
+featuredImage: >-
+    https://res.cloudinary.com/dmukukwp6/image/upload/f_webp,h_630,w_1200,c_fill,g_auto,q_auto/v1/posthog.com/contents/images/blog/posthog-company-culture-blog
+featuredImageType: full
+category: Inside PostHog
+tags:
+    - Inside PostHog
+    - Marketing
+    - Culture
+seo:
+    metaTitle: "How we participate in 99 IRL events in a year"
+    metaDescription: "How PostHog's builder relations team gets product engineers out to over 100 IRL events a year to speak, demo, and talk to customers – without twisting any arms."
+---
+
+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.
-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.
+Since I joined PostHog in summer 2025, we've gone from doing one IRL event to over 100 in a year. Roughly 95% of those events involve speaking to customers, and over 50% of the company has gone out and demoed in cities around the world – and that percentage keeps growing.
-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.
+Since I joined PostHog in summer 2025, we've gone from doing one IRL event to over 100 in a year. Roughly 95% of those events involve speaking to customers, 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.
-This post is about how the builder relations team has enabled this without twisting any arms.
-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.
-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.
+This is crazy compared to previous places I've worked where speaking opportunities were seen as favors or obligations, and many other dev tool companies will tell you the same.
+
+Here's how our IRL events team at PostHog makes it happen (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.
+This is crazy compared to previous places I've worked where speaking opportunities were seen as favors or obligations, and many other dev tool companies will tell you the same.
+
+Here's how our IRL events team at PostHog makes it happen (without twisting any arms). 
+
+## 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. <!-- TODO: original doc linked "plenty" — add link (e.g. /changelog) --> The tenet that accelerates the desire to share is our company's value of [make it public](/handbook/values#make-it-public).
-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. <!-- TODO: original doc linked "plenty" — add link (e.g. /changelog) --> The tenet that accelerates the desire to share is our company's value of [make it public](/handbook/values#make-it-public).
+There's an old adage in developer relations circles that goes, "Ship stuff, show people." And we have plenty to talk about.
+
+But so do many other companies building products at a fast pace. <!-- TODO: original doc linked "plenty" — add link (e.g. /changelog) --> What makes us different is that one of our company's values is to [make it public](/handbook/values#make-it-public). Everything we do is open source, and we've always loved writing about what we're working on. Some of our earliest marketing was just James posting stuff he learned about [being a founder](https://posthog.com/founders/first-1000-users) that went viral on HackerNews. 
+
+Making it public isn't just for views, though. Whether in written form or a demo format, sharing helps others take advantage of what we're learning, builds trust, and also forces us to be clear about our thinking. All of that becomes a self-reinforcing loop:
-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. <!-- TODO: original doc linked "plenty" — add link (e.g. /changelog) --> The tenet that accelerates the desire to share is our company's value of [make it public](/handbook/values#make-it-public).
+There's an old adage in developer relations circles that goes, "Ship stuff, show people." And we have plenty to talk about.
+
+But so do many other companies building products at a fast pace. <!-- TODO: original doc linked "plenty" — add link (e.g. /changelog) --> What makes us different is that one of our company's values is to [make it public](/handbook/values#make-it-public). Everything we do is open source, and we've always loved writing about what we're working on. Some of our earliest marketing was just James posting stuff he learned about [being a founder](https://posthog.com/founders/first-1000-users) that went viral on HackerNews. 
+
+Making it public isn't just for views, though. Whether in written form or a demo format, sharing helps others take advantage of what we're learning, builds trust, and also forces us to be clear about our thinking. All of that becomes a self-reinforcing loop:
+
+![A flow diagram: engineers build stuff, share what they built (and what they learned along the way), which flows into written word (blogs and social) and spoken word and visuals (talks and video), all feeding back into feedback and learning](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_1_fdceac63cb.png)
+
+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:
-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:
+The problem I see at other companies is if engineers in your org need convincing to share what they've made is actually better for customers. This is painless at PostHog because most of our engineers are product engineers:
-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:
+The problem I see at other companies is if engineers in your org need convincing to share what they've made is actually 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](/handbook/engineering/product-engineering)
+
+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.
-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.
+So the lesson is that with more ownership and transparency, engineers will naturally _want_ to demo the products what they've built. This leads to more customer interaction, which leads to curiosity and empathy for users, which leads to more demos, interviews, and blogs. And it all loops back into itself.
-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.
+So the lesson is that with more ownership and transparency, engineers will naturally _want_ to demo the products what they've built. This leads to more customer interaction, which leads to curiosity and empathy for users, which leads to more demos, interviews, and blogs. And it all loops back into itself.
+
+![A Slack recap from Meikel after speaking at a dev meetup in Milan, encouraging others to get out to IRL events](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_2_3145536574.png)
-![A Slack recap from Meikel after speaking at a dev meetup in Milan, encouraging others to get out to IRL events](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_2_3145536574.png)
+
+For example, 
+
+![A Slack recap from Meikel after speaking at a dev meetup in Milan, encouraging others to get out to IRL events](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_2_3145536574.png)
-![A Slack recap from Meikel after speaking at a dev meetup in Milan, encouraging others to get out to IRL events](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_2_3145536574.png)
+
+For example, 
+
+![A Slack recap from Meikel after speaking at a dev meetup in Milan, encouraging others to get out to IRL events](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_2_3145536574.png)
+
+*An event recap after [Meikel](https://posthog.com/community/profiles/32489) did a talk at a [dev meetup in Milan](/events/186) earlier this summer.*
-*An event recap after [Meikel](https://posthog.com/community/profiles/32489) did a talk at a [dev meetup in Milan](/events/186) earlier this summer.*
+*An event recap after [Meikel](/community/profiles/32489) did a talk at a [dev meetup in Milan](/events/186) earlier this summer.*
-*An event recap after [Meikel](https://posthog.com/community/profiles/32489) did a talk at a [dev meetup in Milan](/events/186) earlier this summer.*
+*An event recap after [Meikel](/community/profiles/32489) did a talk at a [dev meetup in Milan](/events/186) 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:
-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:
+It also helps that demoing is second-nature here. You can't get far on any given work day at PostHog without seeing a demo of what people are working on internally thanks to:
-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:
+It also helps that demoing is second-nature here. You can't get far on any given work day at PostHog without seeing a demo of what people are working on internally thanks to:
+
+- 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.
- 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.
+- Our weekly all-hands meetings. These end with 15-20 minutes of people across the company sharing screens (while praying to the demo gods).
- 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.
+- Our weekly all-hands meetings. These end with 15-20 minutes of people across the company sharing screens (while praying to the demo gods).
+- 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.
- 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.
+- Our #demo-posthog-anything channel. People post here at any time to keep demos going all week long, rather than waiting for the next all-hands.
- 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.
+- Our #demo-posthog-anything channel. People post here at any time to keep demos going all week long, rather than waiting for the next all-hands.
+- 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.
- 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.
+- Our many [hackathons](/newsletter/hackathons). Whether it's at a small team gathering or the annual all-hands company offsite, our hackathons _always_ end with each team demoing what they worked on.
- 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.
+- Our many [hackathons](/newsletter/hackathons). Whether it's at a small team gathering or the annual all-hands company offsite, our hackathons _always_ end with each team demoing what they worked on.
+
+![A screenshot of the #demo-posthog-anything Slack channel showing an engineer demoing a new scatter plot in SQL insights](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_3_fc79500b73.png)
-![A screenshot of the #demo-posthog-anything Slack channel showing an engineer demoing a new scatter plot in SQL insights](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_3_fc79500b73.png)
+
+Here's an example of ... 
+
+![A screenshot of the #demo-posthog-anything Slack channel showing an engineer demoing a new scatter plot in SQL insights](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_3_fc79500b73.png)
-![A screenshot of the #demo-posthog-anything Slack channel showing an engineer demoing a new scatter plot in SQL insights](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_3_fc79500b73.png)
+
+Here's an example of ... 
+
+![A screenshot of the #demo-posthog-anything Slack channel showing an engineer demoing a new scatter plot in SQL insights](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_3_fc79500b73.png)
+
+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.
-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.
+Keep in mind that a demo != a slide deck. We care about showing the thing working, not just talking about it. Many of the latest AI community meetups around the world prioritize the same because it contributes to better attendance, participation, and enthusiasm. 
+
+Of course, there are exceptions to this – mainly deeper topics that are beyond a product, feature, or tool – but we emphasize presenting actual solutions, not just sales pitches or conceptual frameworks. Ew.
-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.
+Keep in mind the demo !== PPT presentation. The substance of a demo comes from showing something you actually built that works rather 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.
-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.
+Keep in mind that a demo != a slide deck. We care about showing the thing working, not just talking about it. Many of the latest AI community meetups around the world prioritize the same because it contributes to better attendance, participation, and enthusiasm. 
+
+Of course, there are exceptions to this – mainly deeper topics that are beyond a product, feature, or tool – but we emphasize presenting actual solutions, not just sales pitches or conceptual frameworks. Ew.
-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.
+Keep in mind the demo !== PPT presentation. The substance of a demo comes from showing something you actually built that works rather 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](/newsletter/how-to-demo).
-Interested in getting in on the demo train? Here's a [guide for giving S-tier demos](/newsletter/how-to-demo).
-Interested in getting in on the demo train? Here's a [guide for giving S-tier demos](/newsletter/how-to-demo).
+
+## 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.
-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.
+Because we work [asynchronously](/handbook/company/communication#golden-rules), the event's team role is 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.
+
+We trust that our engineers know [how to give demos](/newsletter/how-to-demo#setup-and-delivery), and they're the experts at their topic since, well, they built it. We don't make slides for them, we don't do run-throughs, we just let them do their thing. This is also related to one of our other values called ["you're the driver"](/handbook/values#youre-the-driver). No one is here to tell you what to do.
-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.
+Because we work [asynchronously](/handbook/company/communication#golden-rules), the event's team role is 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.
+
+We trust that our engineers know [how to give demos](/newsletter/how-to-demo#setup-and-delivery), and they're the experts at their topic since, well, they built it. We don't make slides for them, we don't do run-throughs, we just let them do their thing. This is also related to one of our other values called ["you're the driver"](/handbook/values#youre-the-driver). No one is here to tell you what to do.
+
+What does a speaker need in order to attend and speak at an IRL event?
-What does a speaker need in order to attend and speak at an IRL event?
+We do provide some guidelines, resources, and assets from the brand team. For example, here's what someone will need in order to attend and speak at an IRL event:
-What does a speaker need in order to attend and speak at an IRL event?
+We do provide some guidelines, resources, and assets from the brand team. For example, here's what someone will 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
-1. Who/What/Where/When – the event details are the first thing we share with all speakers
+1. Who, what, where, when – the event details are the first thing we share with all speakers.
-1. Who/What/Where/When – the event details are the first thing we share with all speakers
+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](/merch) for speakers to give out
-2. Merch to give out to attendees – event team ships [merch](/merch) for speakers to give out
+2. Merch to give out to attendees – the event teams ships [merch](/merch) for speakers to give out in person.
-2. Merch to give out to attendees – event team ships [merch](/merch) for speakers to give out
+2. Merch to give out to attendees – the event teams ships [merch](/merch) for speakers to give out in person.
+3. Budget to travel, if necessary – a subset of the events budget is allocated to travel
-3. Budget to travel, if necessary – a subset of the events budget is allocated to travel
+3. Budget to travel, if necessary – a subset of the events budget is allocated to travel.
-3. Budget to travel, if necessary – a subset of the events budget is allocated to travel
+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](/handbook/brand/assets) related is readily available
+5. Guide on how to do optimal demos / talks – we've got the team [covered](/newsletter/how-to-demo) if they need it
+
+Even before reaching out to speakers with opportunities, we use a speaker-expertise skill that fellow builder relations teammate, [Kliment](https://posthog.com/community/profiles/42638) 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.
-Even before reaching out to speakers with opportunities, we use a speaker-expertise skill that fellow builder relations teammate, [Kliment](https://posthog.com/community/profiles/42638) 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.
+Even before we reach out to teammates about potential speaking opportunities, we use a `speaker-expertise` skill that [Kliment](/community/profiles/42638) created to help them out. It takes that employee's GitHub handle and researches their merged PRs across the PostHog org over the last 6 months to then produce an outline of their work. The output includes a list of tech-talk topic candidates in detail, with a N/10 talk-worthiness score per topic. This helps us come to the table with starting ideas rather than putting that on the employee.
-Even before reaching out to speakers with opportunities, we use a speaker-expertise skill that fellow builder relations teammate, [Kliment](https://posthog.com/community/profiles/42638) 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.
+Even before we reach out to teammates about potential speaking opportunities, we use a `speaker-expertise` skill that [Kliment](/community/profiles/42638) created to help them out. It takes that employee's GitHub handle and researches their merged PRs across the PostHog org over the last 6 months to then produce an outline of their work. The output includes a list of tech-talk topic candidates in detail, with a N/10 talk-worthiness score per topic. This helps us come to the table with starting ideas rather than putting that on the employee.
+
+![Photos and a Slack recap from WAWTECH in Warsaw, where PostHog spoke about Self-driving to a packed room](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_4_285b1afa5c.png)
+
+A recent anecdote: Lizzie joined as our PMM on [context warehouse](/blog/what-is-a-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](/handbook/values#youre-the-driver) company value.
-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](/handbook/values#youre-the-driver) company value.
+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 yet another example of our ["you're the driver"](/handbook/values#youre-the-driver) company value.
-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](/handbook/values#youre-the-driver) company value.
+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 yet another example of our ["you're the driver"](/handbook/values#youre-the-driver) company value.
+
+## Once people demo they're hooked
-## Once people demo they're hooked
+## Once people demo, they're hooked
-## Once people demo they're hooked
+## 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.
-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.
+As a disclaimer, no one is required to do _any_ of this at PostHog, and at least 20% of the company has let the events team know that they have no interest in demoing at events or public speaking. It's not for everyone, nor should it be expected. Because of this, it's always fine when speaking asks are declined – no questions asked.
-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.
+As a disclaimer, no one is required to do _any_ of this at PostHog, and at least 20% of the company has let the events team know that they have no interest in demoing at events or public speaking. It's not for everyone, nor should it be expected. Because of this, it's always fine when speaking asks are declined – no questions asked.
+
+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.
-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.
+That said, we find that once an engineer does a speaking opportunity, they get hooked. Some of our yappers actually look forward to the next event and reach out proactively. This is especially great if a product is a high priority; we look for more chances to bat for people building those. 
+
+Still, you can always have too much of a good thing, so we try to toe the line to avoid overwhelming any single person or team with events.
-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.
+That said, we find that once an engineer does a speaking opportunity, they get hooked. Some of our yappers actually look forward to the next event and reach out proactively. This is especially great if a product is a high priority; we look for more chances to bat for people building those. 
+
+Still, you can always have too much of a good thing, so we try to toe the line to avoid overwhelming any single person or team with events.
+
+![A Slack recap from Dylan after demoing Self-driving at AI Tinkerers, sharing takes on the event and the community](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/event_blog_post_image_5_f01f403da1.png)
+
+*Recap from [Dylan](https://posthog.com/community/profiles/30455) after he demoed self-driving and we sponsored the [Seattle dev tools edition](https://seattle.aitinkerers.org/talks/rsvp_AOTRq88tjJo) of AI Tinkerers. Thanks, Dylan.*
diff --git a/src/data/authors.json b/src/data/authors.json
@@ -782,5 +782,11 @@
         "link_type": "linkedin",
         "link_url": "https://www.linkedin.com/in/georgis-andonis/",
         "profile_id": 35171
+    },
+    {
+        "handle": "daniel-zaltsman",
+        "name": "Daniel Zaltsman",
+        "role": "Builder relations team lead",
+        "profile_id": 34023
     }
 ]