https://www.youtube.com/watch?v=v4F1gFy-hqg

Note: This is a lot more about the vocal element of speaking rather than pure content. Everything here below is in Matt's voice.

I gave a viral talk recently, and @swyx asked me to put something together to explain how I did it - to help future AIE speakers and anyone who wants to learn.

I am, oddly, extremely qualified to do this because I spent 6 years as a voice coach. So I've not only given countless talks, but also taught people how to do it well.

I've put together a list of things I think about when I'm preparing and giving a talk. These are applicable to literally any situation where you're presenting a deck - but also to most in-person interactions. Enjoy.

Tension vs Anxiety: Flowing and Choking

The thing I think about most when I'm giving a talk is tension. Tension is bodily constriction that interferes with the voice. Tight intercostals, neck muscles, and muscles around the larynx.

Tension is different from anxiety. Anxiety is the nerves, stage fright, the feeling of being watched. Stage fright is curable only through repetition. You get your reps in, you do larger and larger talks, and it goes away. I have negligible anxiety when I do talks, usually because I can always picture a bigger gig I've done.

Anxiety feeds tension. You are nervous, so you get physically tense. Your voice catches, your breathing collapses. Your hand start jerking, face freezing, voice going monotone. This is choking - the failure state of any talk.

Its opposite is flowing - an integrated performance state where voice and body move together without friction. It's not effortless - my heart rate is usually through the roof when I'm giving a talk. But it's a state without tension or anxiety.

swyx comment: when you are comfortable, try injecting some tension via vocal variety:

https://www.youtube.com/watch?v=6fHoN6MR6MI

Clavicular vs Diaphragmatic Breathing

Tension is a physical problem. The wrong muscles are working too hard, and the right muscles aren't working at all.

This manifests as clavicular breathing. This is breathing led from the upper chest and shoulders. It's the natural 'nervous breath'. And it's a recipe for choking. The more clavicular breaths you take, the more tense you become, the more anxious you feel.

Ironically, the advice to 'take a few deep breaths' can fuck you over. If you're not breathing right, you'll immediately breathe into your clavicle, and start choking.

The fix is diaphragmatic breathing. This style of breathing has you relaxing the belly as you breathe in so that the diaphragm can descend. It's the first thing I taught every student who walked through my door. I'll link to an old video of mine where I talk about it.

https://www.youtube.com/watch?v=bs7a5lt1kx4

Breathing this way is totally free of tension. It's invisible to anyone watching - you just look as if you're completely relaxed. So you can do it on-stage to reduce your physical tension and prevent choking. It's the foundation everything else rests on.

Aiming at the room

Most speakers - I would say 95% of tech speakers I've seen - don't aim their talk at their audience. They are not keeping their audience in mind. They're not even thinking about their audience as they speak.

This manifests in two ways. The first is that they're talking past their audience. They are projecting past them to an imaginary audience that they pictured during practice. They are aiming at the world, not the room. This reads as loud, performative, and hollow.

The second is that they're talking inwardly. They're rehearsing their next line. They're monitoring themselves. This is commonly caused by anxiety, but not always - even relaxed speakers do this. They're aiming at themselves, not the room. This reads as disconnected.

Aim at the room. Read the audience in real-time and adjust. Calibrate to their energy levels. Consider what they might be thinking. Ignore the world, focus on the room. Look outwards, not inwards.

Speaker-Led Slides

Let's finally talk about slides. People focus way too much on their slides, but they are worth of some attention.

Your talk should be speaker-led, not deck-led. The deck is there to support you. It is there to emphasise your points and give you reminders where to go next. If the deck is the talk, with the speaker narrating, why did the speaker even bother to show up.

Slides should be bare. Minimal information per slide. A single phrase. A single quote. A single image. The audience reads it quickly and returns attention to the speaker. Cluttered slides mean the audience pulls attention away from you.

Keep your slides paced. Don't rapid-fire through a bunch of them - nothing will stick. Give each slide, each point, time to land.

Summary

Anxiety can only be cured by reps. But tension is the battleground of the speaker. Fix it with diaphragmatic breathing, and notice whenever you do clavicular breathing. Flow, don't choke.

Aim your talk at the room, not yourself or the world. Keep your audience in mind. Make your talk speaker-led, not deck-led. Use bare slides, and pace them well.

I don't make money off teaching voice any more, so if you enjoyed this, then a donation to Oxford Food Hub would be very welcome.

At our monthly Writing meetup in San Francisco, Thariq laid down his framework: the general loop is do good work and then tell people about it. Full video here:

Sowing

• doing good work, even in a niche, is interesting to people not in the niche. (example: best pokemon player talking about his craft)

• use [TOOL] for everything, solve and find all problems

• talk to customers who were using [TOOL] inefficiently. realized that there were basic things they werent doing right, and it felt too basic to write but it reached a wide audience because he solved a pain point that customers had but employees maybe wouldnt experience

Reaping

1. Tell a story. (not simply "how we built x", "how to do x" - more informative/subtle than that)

2. Keep it as simple as possible

3. Don't sell something you don't believe in - if you dont use it, dont write about it.

4. Share secrets - some "real alpha" that you're even a little scared to reveal to competitors

Misc Questions asksed

• Q: How do you write?

  • A: very unstructured... "you have nothing until you have everything"

• Q: how much time do you spend writing for work?

  • A: very spiky - one week a lot, one week just heads down engineering, aim for 50-50 sowing-reaping

• Q: how do you make diagrams?

  • A: Claude Design - make 5 different SVGs, make a concept and choose one. diagrams, code snippets. use principles of claude design, give design system and references.

• Q: how much time you reading articles? too much marketing slop.

  • "i read our slack alot".

• Q: getting feedback before posting

  • use ABCD feedback framework.

• Q: series - Lessons from Claude Code

  • make sales collateral

• Q: did u make something more / less popular than expected?

  • the skills post

TLDR: Build implicit knowledge, and then make it explicit.

The TLDR is that although we’re all grown adults, we regress back to high school behavior as the target audience size grows and attention shrinks. I got this idea from a comedy skit I saw once that said something like “in high school everyone is known by (American) Indian names - and it’s usually the politically incorrect but instantly recognizable version of you - it’s not “Phoebe from Gymnastics”, it is “Short-Girl-who-is-an-arrogant-showoff”. Given that your brand is how people talk about you when you’re not in the room, it is a key part of your job managing your developer brand that you should engineer for what adjectives and descriptions other people refer to you by.

Own A Valuable Superlative

aka Be #1 at Something That Matters

In American high school year books, people get assigned “superlatives” that make them well known/memorable for their thing.

There exist lists and lists of superlatives — but it should be obvious that “Class Clown” and “Most Likely to Trip at Graduation” is not as valuable as “Most Likely To Succeed” and “Best Personality”. The VC version of this superlative is the “Presumptive Winner”, a label that is quite literally drives hundreds of millions of dollars of investment decisionmaking and compounds advantages in market shares (as long as you define the market favorably).

For founders and PMs going Uphill to developers, this means that you probably should be beating people over the head far more than you’re comfortable with the main superlative you’ve decided to own (you -do- have a thing you’re #1 in the world at, right? right?). As in high school, deduct more points the more words (actually, syllables) you need to use to describe your brand. Evaluate your brand by asking your friends (investors, customers etc) to repeat back in their own words what they think you’re good at, and really introspect the difference between what you say you are and what others say you are. If they’re wrong, it is DevRel’s job to fix it. If you’re wrong, it is a deeper product/engineering problem.

Bad Superlatives:

• Most Complete: as mentioned in the podcast, if your primary competitive advantage comes down to “my list of green checkboxes is longer than their list of green checkboxes”, you probably don’t have conviction or market insight that will carry you anywhere meaningful. This is NOT a hard and fast rule; completeness stories do work, but they are usually secondary benefits after nailing a core thing (one of the other Good Superlatives).

• Most Enterprise-Ready: a less bad version of the above but same vagueness

• Most AI Native: a tasteless tell of un-self-aware lack of understanding of differentiation

• Raised a lot of money: cool happy for you but what is it you do and why will you win other than jamming a bunch of sales guys and ads down my throat?

• Best Developer Experience: a controversial one, but usually a cheap win (“my lines of code is less than your lines of code” reliably wins on Twitter) that indicates shallowness because it correlates highly but not perfectly with lack of attention to unhappy paths.

• Cheapest: you get what you pay for

• Most Decentralized: the web3-pilled people don’t seem to understand that this is a niche marketing message to those who have been negatively affected by centralization, and in fact most people usually vote with their wallets and feet and eyeballs for MORE centralization

Good Superlatives:

• Fastest

• Best Value For Money

• Simplest

• Most Capable

• Most Reliable

As mentioned on the pod, “Fastest” is usually an easy one for startups because its easy to be faster with less cruft/competing priorities/singular focus, this was a starting selling point for Bun (now acquired by Anthropic) and ESBuild.

Searches for “developer relations” are at all time highs!

Let’s be real, there’s no way it is 5x’ed in 2 months, but anecdotally, the pings I get from founders trying to hire good devrel has appreciably gone up in recent months so it directionally checks out. Anthropic, arguably the hottest AI lab with the best Developer models and tools and reputation, has had a Head of Developer Relations role open for at least the last 4 months, despite offering a $385,000 - $460,000 USD salary.

Linkedin is filled with posts asking for new devrel folks:

and of course in the last few months in short order Cursor hired LeeRob, Factory hired Ben Tossell, and Cognition hired me.

Some further data points:

1. The Linux Foundation launched their “DevRel Foundation” last month:

2. the first post I referenced above, from Philip van der Merwe, notes that DevRel is going up again

3. when I saw Pedram Navid’s “Reflections on 2 Years Running Developer Relations” show up on the front page of Hacker News today, it was time to write this post and notify all of you who probably signed up a year ago on the DevRel Death post.

Bottoms up is So Back

Something’s in the water. Anonymizing and generalizing from all my industry conversations, I think there’s one overall driving trend - DevRel is synonymous with Bottom-Up Developer Adoption, and I think the desire for Bottom-Up Developer Adoption is stronger than I’ve seen in my career (and my career has included that one weird time in 2017 when Microsoft hired like 100 Cloud Developer Advocates and then let them ~all go 2 years later, oh, we could write a BOOK on that one once statute of limitations expire). For the first time in 5? years I’m even hearing the strong belief that Enterprise sales is helped by having great Bottoms Up Adoption (it’s true, but for a long while people stopped saying it, and it’s noteworthy that people are saying it again).

And if we’re cutting it right to the bone, there’s two main areas of real Bottoms Up Adoption - IRL events (e.g. in San Francisco where people are hiring DevRel the most) and on Twitter. This refreshingly honest take on how OpenAI operates is absolutely how a lot of the top devtools companies you know operate today:

Aka you can get a devrel job just being reliably Good At Twitter (whether Personal or Company Twitter accounts) for a company you work for/believe in. There, of course, the question of DevRel-Company fit comes into play - Will Brown has the best recent take on this:

I’m being pushed by it, not pushing it

Heck, I’m even organizing my Dev Writer’s Retreat again (sign up here!) after a 3 year hiatus. It’s weird stepping out of my own body and recognizing that my own actions (of course done with the illusion of free will) fit a trend and I don’t even really know what is causing it.

In many ways, you have to marvel at how this should be framed up in the Hall of Fame as the perfect professional industry tweet:

1. It is short, fortune cookie length. No linkedin yaps here.

2. It’s true enough:

2. It lets people self promote:

   

3. It leaves enough questions unanswered to require followup questions

   

4. It is open to interpretation, it allows everyone to just say their job is important when they often feel unimportant, even if their statement is actually plainly wrong (in fact being wrong is good for engagement):

   

   

If you are cynically studying how to grow your Twitter following just for the sake of vanity, you could do worse than breaking down how viral tweets like these work and then sprinkling a few of these in each week to see what catches. I don’t have the example live but there are plenty of examples of posting the same content or joke slightly reworded each time and the last attempt finally really taking off.

But enough snarking; My actual answer is that you ALMOST can’t hire these people (for lack of a better word, I’ll call them “creators” just to avoid getting into the job title discussion). I wanted to break down why.

Most companies don’t ACTUALLY want creators, they want sales and marketing

Most startups probably do not have interesting, frontier tech worth explaining. This might sound like a cynical view, and I applaud all founders taking their leaps, but statistically it must be true. Your B2B AI CRM SaaS wrapper of Supabase + OpenAI isn’t intrinsically that compelling, you can’t squeeze blood from a stone.

Yet these startups are often the ones who want most to hire a devrel person to magically make them interesting… in order to sell, not to explain.

The kind of people who see the world in black and white like this cannot comprehend doing a thing for its own intrinsic value; Art only has worth when it can change hands at Sotheby’s. Their words tell you all you need:

Intentions matter. While great technical content can come from anyone and anywhere with any goal, it is much more likely to arise without a CTA or CTR KPI hanging over the writer’s head.

Creators want to horizontally explore, but you need vertical focus

Because of the dearth of actually interesting frontier tech in the world, and specifically, in your company, most creators need to jump from company to company to stay interesting and continue to build their following. Exceptions exist; it’s easy to point to Dan Abramov and React from 2015-2020; and LeeRob and Vercel from 2020-2025 as examples of people who just stayed on topic for a long time, but both they and their employers had rare depth and followthrough that made them the exception to the rule.

For everyone else, you need to react to things and be able to talk Apple one day and CloudFlare the next.

Or to get meta about job market and economics and AI protocols:

You know who’s really good at “understanding and explaining technology in a compelling way"?

MKBHD. Cleo Abram. Mark Rober. Grant Sanderson. They jump from topic to topic to topic and always manage to make it fascinating; but that starts by having the freedom to roam outside of always shilling your company’s product.

You know who they work for?

Themselves.

Creator Economy Made Them Unhireable

The top dev YouTubers currently take charge between 50-100k per sponsor; the top Substackers have tens and hundreds of thousands of paying subscribers. This means instead of working for you, the really good ones can just work for themselves and make >$2m/year just being themselves.

Uphill DevRel vs Downhill DevRel

In my finance days there often a discussion about “value of the seat” vs “value of the trader”. Similarly I think there should be some healthy caution when hiring somebody who is from an already-popular company, coasting on the momentum of the company, vs someone who has had to fight their way up for a comparatively unknown company.

So, what to do?

My normal prognosis is very bleak. If this model of how the devrel industry is accurate, then churn is very high for 2 reasons: 1) there is far more demand than supply for good talent, and 2) good talent “graduates” quickly to working for themselves. The average “good devrel tenure” ends up being 2-3 years as a result (again, we are making crazy generalizations, great devrel folk working for 20+ years at the same company are immensely powerful, I’m not encouraging this state of affairs, merely trying to describe it as accurately as possible).

My constructive suggestions for what to do are repeats of themes already covered on this blog:

• Founders should be the minimal viable devrel

• Make everyone part of the content process as part of their job but not their whole job

• when in doubt, hire Master Builders who can Bill Nye it

More recently, I’ve begun hosting events as part of my role as a growth engineer at Cerebras. I’m nearing my 1 year mark, and thought I’d share some of my favorite parts of hosting a good event.

One of the first events I hosted was LlaMAPALOOZA, hosted at the NASDAQ in NYC.

We had 1025+ RSVPs for a 400 person event.

**Note: LlaMAPALOOZA is a developer event series around using Meta’s Llama models in production.

And here’s what people had to say about LlaMAPALOOZA on socials :)

So first, what is a 'good event'?

The most obvious marker for a good event is are people showing up and are people excited to attend.

I'd say secondary markers are:

1. Is the event memorable?

2. Did it have a high ROI for me/my company? (as measured by my time and $ spent)

And third-tier markers might be:

1. How was the gender ratio?

2. If someone else had hosted this event, would I have attended?

3. Are people coming back to my future events?

The reality is, the competition for a developer or founder’s time is fierce. There’s no shortage of events, just look at Michelle Fang’s weekly list of tech events in SF. The odds are not in your favor.

Rule #1: Make people want to come.

Right now, I host two main event series: Cafe Compute and Barry's w/ Builders. See below for descriptions.

Let’s start with coming up with an event idea. It's sort of cheating, but the best hack is piggybacking on what people already have to do. Sure, "people have to eat," but a VC-sponsored fine dining experience is usually a 3 hour commitment, which is 2.5 hours more than most founders want to spend on dinner.

C’mon guys, we can do better than dinners and happy hours :)

Cafe Compute works because it

1. was highly requested on Twitter (see example) AND

2. solves a real problem: late-night coworking with free coffee (sorry Bryan Johnson), snacks, and other developers.

3. gives people an organic environment to meet cool people, and they get work done

Barry's w/ Builders taps into the fact that founders are busy and want to bundle more fitness into their lives. A group of ~10 of us will do a Barry’s bootcamp workout class, then get smoothies after from the Barry’s fuel bar. Developers get a free workout, and nothing bonds strangers like protein smoothies after getting yelled at by a Barry's instructor for an hour.

Rule #2: Start small

Before you invest large amounts of time into a grand event idea like hosting a city-wide pickleball tournament that's logistically complex, start with an MVP event. Just like you would with a product.

Before Cafe Compute was in a venue with a proper barista, I hosted the first one in my apartment. We had 75 developers sitting on Amazon-ordered floor cushions, and I had GTM friends from different startups (shoutout Lizzie, AJ, Daniel, and Evan) sponsor boba, In-N-Out, and donuts. I do not live in a big apartment….

But anyways, it's good to first validate an idea :)

Rule #3: Host a Series

And once you’ve validated, EXPAND! This is probably the best tip, but I very rarely host one-off events.

Hosting a series gives you three huge advantages:

1. Time saving: If you work at a startup, time is your most precious resource. If done correctly, after the first one or two events, future events require very minimal, playbook planning. I probably spend 15 minutes organizing each Cafe Compute now.

2. Upfront investment in branding/swag: This allows you to properly invest in branding, event-specific swag, logo design, etc. that can be reused for all events. For Cafe Compute, we made logos, custom coffee cups, menus, etc. that really elevate the event.

3. Brand Building: It’s much easier to grow a brand or event series, than continually promote one-off events

   (look how cute our logo is!)

Note*: hosting a series doesn’t mean repeatedly organizing the same event, rather it’s the same event format with a couple of consistent features. For example, each Cafe Compute will be a slightly different theme but we’ll always have a coffee barista and all the branding will be the same. We’ve also hosted Cafe Compute in different cities like SF, NYC, Vancouver, etc.*

Rule #4: The little things matter, and people WILL notice

My future mother-in-law's advice for our engagement party: not everything has to be spectacular, but add details people will remember.

At our Cafe Computes, we added a ‘chip jar’ next to the barista’s table filled with computer chips. It was a play on the traditional ‘tip jar’ and people absolutely loved the attention to detail.

If you’re hosting a dinner, print name cards and assign seats based on who will have the best conversations.

Slater Stich (partner @ BCV) does a great job with this too. At a recent researcher dinner, he had a list of silly but relevant conversation topics prepared. During the Grok waifu Twitter drama, he asked everyone to argue why AI waifus would improve the world. It's preparation disguised as fun, and it’s great for breaking the ice.

Rule #5: Hacks to maximize ROI

If you’re hosting events for work, some of my favorite tricks:

1. Send a follow-up email (in a timely manner) to all attendees thanking them and adding in your CTA (get an API key, checkout this fellowship, talk to me if you’re raising money) whatever it may be. This also helps you not have to shill during the event. Ideally, 20-25% engage.

2. Remember that you’re the (all mighty and powerful) host. When I’m hosting dinners, I love asking everyone to move seats between the main course and dessert, so I get to meet more people. Never be scared to get up mid-dinner and say hi to someone you invited, or someone you don’t know. As host, you set the rules!

3. Pictures or it didn’t happen! The best $ spent is always the $200 spent on a professional photographer. 100 people attended my event and 50,000 people are going to see my Twitter post. So make it a banger post that people will remember you for :)

Rule #6: Bring in partners

I rarely host events without bringing in VCs or other companies to cohost. Personally, I think there are diminishing returns beyond 1-2 event partners. Beyond that, I feel like I'm wasting time with coordination or keeping everyone accountable for driving attendees. With series especially, it's great to have 1-2 partners you've got the playbook down with.

Usually, I reach out to folks already in my network, but if it’s someone you don’t know well, I’d reach out with something like this:

What do you get out of adding partners?

• access to a new network

• split event costs

• potentially access to more organizing manpower

What do partners get out of it?

• VC partners get access to deal flow and new talent. They usually put in $$

• Startup partners get access to more customers. They usually put in $$, promote on socials, or drive a certain # of RSVPs

Rule #7: Be a good host

Lastly, but most importantly…the #1 thing you can do as a good host is make everyone feel welcome. A trick that I like to do is run around with a sharpie and blank name tags, so I have an excuse to approach everyone and be like hey, what’s your name? Not only does it establish you as a host, but it’s a great conversation opener.

Rule #8: Take a shot before your event

Anyways, that’s it. 7 nice rules. A huge shoutout to the folks I’ve cohosted with including Daniel Kim, Amanda Huang, Sophia Luo, James da Costa, Evan Conrad, and Paul Klein. And huge thank you to Swyx for feedback on this post :)

Feel free to DM me (X: @SarahChieng) if you’d ever like to cohost or join one of our events. I’m excited to see what you host!

This year though a lot of AI developer oriented startups have been asking me for stuff specific to them, and I’ve been sending a different link. Per my Three Strikes rule, it’s time to write up the link I’ve been sending.

Specifically, this Lego employee on YouTube:

Look at his channel (1.94M YT subs, 195k Insta, 2m Tiktok at time of writing, but with multiple decimilllionaire shorts) and you can see sometimes coworkers taking over his channel:

and of course you have to wonder at how much Lego is sold because this guy just inspires people about what they can build with Lego.

DevRel is very similar — inspiring and teaching builders what they can build with the things your company sells. Make it short, make it fun, demonstrate mastery, give important bits of advice.

“But my b2b dev api platform is nothing like Lego! we have to Be Serious for the Fortune 500 companies to Take Us Seriously!”

Tell Justin Garrison, the DevRel Guy at AWS:

and of course, these days, you don’t even need to be on-camera talent to be educational and on-brand:

and of course, closer to home, my friend Hassan has built an entire career out of being a master builder at Vercel and at Together AI.

I think this Master Builder short is valuable also because this is a Real Job that has a lot of relatable and translatable activities. I am a fan of taking unconventional business models that work in the “real world” and applying them to tech:

My official job title is Global Master Model Builder for LEGO and LEGOLAND Discovery Centers.
It's a bit of a mouthful, but here's what it really means:

• There are 28 Discovery Centers around the world, and each one has at least one Master Model Builder.

• A Master Model Builder:

  • Designs cool LEGO models

  • Interacts with kids

  • Cares for the big builds on display

  • Runs activities and workshops

  • Designs lessons

  • Talks about the attraction on the news

  • Basically, does a lot of different things to inspire creativity

I was the Master Model Builder in Arizona for 6 years, before Delaney took over that role.
That's when I became the Global Master Builder, which is really just a fancy way of saying an "extra" Master Model Builder who supports all the centers.

In Master Builder Alec’s case, he is also a senior IC, which means functioning as a “player coach” with more enablement and paperwork:

I still live and work in Arizona, but now my work extends to helping all Discovery Centers. Some of what I do includes:

• Making fun, silly YouTube videos for LEGO fans

• Assisting with the hiring and training of new Master Model Builders

• Writing procedures and guidelines used worldwide

• Coordinating brick orders and other logistics

• Handling tasks that aren’t directly about building but help others become better Master Model Builders

At the end of the day, all of us Master Model Builders are trying to do the same thing:
Inspire creativity and fun in others—because that’s what we’re passionate about.

So, if you get a chance, I highly recommend visiting a Discovery Center to meet your city’s Master Model Builder in person!

If I had a oneliner for hiring an AI DevRel today, it’d be this: hire a Master Builder who uses your tools.

• Many devrels can do demos, but few can inspire sharing, excitement, conversation, wonder

• Many devrels can run workshops, but few have the experience/depth to 1) get somewhere interesting, 2) live, 3) under time pressure, 4) make it relatable to customer needs

• Many devrels can do blogposts, but few can set the agenda (blogpost next on How to Thought Lead… subscribe pls)

There are, of course, other kinds of devrel work, with different time horizons of impact and engagement and with a role to play in the overall lifecycle of your customer’s relationship with you, but by the easiest metric, which is view counts on social media, the Master Builder is going to be completely undefeated when you can find them (of course, you should also try to train them up internally, and make it an aspirational position for your fans).

No, I was sad because around about the halfway mark he starts going into the title topic: “Can DevTools Get to $1B ARR?” and (the host) Tim Chen agrees and says basically only Hashicorp, GitHub, and now Vercel “made it”, and everyone else has had disappointing, middling outcomes. (I might add GitLab, Sentry, JetBrains, Atlassian, presumably Linear, but yeah it’s a short list). Entire markets were savaged in that conversation - all API tooling — Kong ($2b), Postman (valued $6b, now $3b), kaput, B grade, thanks for playing.

It reminded me of an observation I once made about the Frontend Ceiling for individual developer careers - Frontend is important and valuable and difficult and noble and challenging and becoming more and more complex — all that is true, and yet, if you only do frontend dev, you will probably never be a CTO because that is not the kind of background that helps you work on valued systems for most businesses:

In other words, if you start off as a frontend person, you’re great, world needs you, thank you for your service, but if you want to be VP Eng/CTO, you’ll have to “grow up” by adding some backend/data to your mix. If you’re new to this line of thinking, read that thread for the debate, or watch the Cascadia JS talk I did that ended my frontend career, I don’t have space to re-litigate here.

In the pod, Max observes somewhat of a Ceiling for devtools businesses too. He observes that most devtools businesses eventually gravitate toward being infra businesses, even to the point of buying their own hardware and building datacenters. In other words, even if you have a great framework or open source developer tool, someday you’ll have to “grow up” by becoming an infra business to make yourself sticky or to serve more of the IT budget of any organization. This already hits some of the “winner” names I listed above - Sentry is (kinda) Open Source, but does well because they famously capture ~66% of users to Sentry’s infrastructure. Next.js is Open Source, but are very much funded by the excellent infrastructure of Vercel. Let’s just say Temporal and Airbyte are the same as well — great open source, but not in themselves valuable businesses until you built up Temporal Cloud and Airbyte Cloud to be competitive infrastructure solutions compared to self hosting. Hashicorp and other COSS companies have rather different/more traditional models - you can replace infra with good lawyers.

Devtools on their own? Great as open source — your users can contribute fixes, github stars go to the moon, it’s a nice virtuous cycle.

But if you want to get paid? Become an infra business ASAP, or run into the devtools ceiling.

Thanks for the HN feature! see what others are saying on @dxtipshq.

I didn’t plan to write this post. I was going to blog about Agent Experience, the new concept coined by my former boss, Matt Biilmann, CEO of Netlify (I think we are on great terms so I can write this haha). I opened up netlify.com to link it and took a huge doubletake.

See anything unusual?

Of course you don’t, you don’t watch Netlify like it’s your second biggest shareholding. Here, let me take you back a whole ass 30 days to the start of 2025:

What’s different today?

No more Gartner banner. No more Composable Web Platform. Composable Architecture.

Hmm. Weird. I remember being told Composable was the future. Let’s look over at Contentful, that other big presumptive winner of the Jamstack/Composable era.

Oh?

OH.

How Gartner Grift Works

The basic business model of Gartner is:

• make up term as The Future

• put a lot of marketing firepower behind it

• make people pay to list on the magic quadrants

This works only as long as CTOs, the dream ICPs of everyone trying to sell into the enterprise, put any credibility into the magic quadrants. Five years ago some “Distinguished VP Analyst” (they are all Distinguished, wow) at Gartner decided Composable was the future:

and so the all the B2B SaaS/IaaS startups with no independent category creation traction suddenly became Composable:

In order to capture the SEO keyword and become Leaders in that Quadrant. This of course feeds on itself - if your major competitor puts Composable all over their landing page, you are going to feel pressure to have it. It’s like that parable about 37 different brands of cereal and putting out a new cereal that is “asbestos-free” on it. Of course the other cereals are asbestos free, but you’re going to wonder if they aren’t.

Accelerating Misses

I am no stranger to category creation and when done right I think it can be a very good harmonizing force for an industry (harmony being the best counter to entropy, which no one wants). But for a Gartner category to be adopted en masse in 2022 and be abandoned by 2024 is a very alarming miss — and it is not the only one.

More recently Databricks has, via Berkeley, tried to make “Compound AI Systems” a thing:

and though it is early days, I have already seen a very short wave of startups speedrun the cycle of wholesale adopting and then wholesale abandoning it. Gartner of course has its own term for it — Composite AI — and as far as I can tell it is going to flop — no real/serious AI player has even heard of it. In an age where we have like counts and subscriber counts and view counts for every itemized idea, the Gartner credibility machine no longer transfers and the idea needs to stand on its own merits.

Of course, Gartner often gives this treatment to ideas it didn’t come up with — the first time it wrote about AI Engineering, having missed its entire first year, it placed it at the peak of its famous hype cycle, despite multiple foundation model companies getting $100m seed rounds with no model and no product.

The most cited authorities in AI are not Gartner. The best claim to “new Gartner” now is Artificial Analysis (which I first called out a year ago and Gartner will probably acknowledge 5 years from now), which backs their analysis with live data because their founders and analysts are themselves engineers, not BA History majors given “Distinguished VP Analyst” titles. When the DeepSeek model dropped last month, Gartner had nothing to say, whereas Artificial Analysis was first out with comprehensive production tests and costing and the data/charts to back it up:

Boomer C-Suites who fancy themselves Enterprise Tech executives and are happy to throw humans at any problem were happy buying off the Gartner catalog and then hitting the golf course. Today, millennial CEOs and CTOs get their analysis and news sources from X, /r/LocalLlama, the All In Podcast, Semianalysis Substacks, any number of YouTubes and Podcasts. Meanwhile, Gartner’s home page is just an incessant amount of increasingly irrelevant Gartner Says:

Gideon Gartner started Gartner Inc in 1979 and it once provided an incredible important service when trusted C-suite buyer information was scarce and Deep Research wasn’t available for $200/month. Its greatest hits were the Magic Quadrant in 1994 and Hype Cycle in 1995. 30 years later, these simple, conveniently subjective and pay to play mental frameworks are showing their age. My college classmates and peers are now the next generation of leaders at {the big companies, VCs, and startups that you know} and none of them put any stock by Gartner.

What happens when you can no longer manufacture credibility for the credulous?

I’ve been dealing with a particularly virulent form of code switching in the simple form of titling blogposts and talks. When you ask the writer face to face what their thing is about, they can give you a perfectly human explanation. And then when they send you their piece, it’s all “Leveraging GenAI with Robust Data Foundations to Transform Businesses”. I’ve left my body by the time I read the first word.

My hope in writing this piece is to put an end to bad titles.

If I sent you this guide, it is not an insult. You just don’t have good title game. That’s ok. You’re great at what you do, title game isn’t your job. I’m the guy that wrote How To Name Things and Two Words. I sent you this guide because your shitty title is the main thing stopping your readers from getting to the good part. If you didn’t have anything good, I wouldn’t bother with a lost cause.

First…

Towards Leveraging Corporate Speak For Maximum Enterprise Synergy

DO NOT:

• Start with “Leveraging” or “Towards” or “Navigating” or “Empowering”

Yeah just stop. There’s no rescuing this when you start there. Just delete meaningless corporate weasel words. Anything >3 syllables is a red flag.

2026 update. Here's some data:

Make It Quotable

If you do not try to make your title roll off the tongue, it probably won’t.

Literally imagine telling your friend about your talk. Telling a new acquaintance to google your blogpost. Having a fan of yours cite it back to you. How much do they stumble? Yeah. This has all happened to me.

There’s an extremely high correlation between what are considered the best talks and the quotability of titles. Simple Made Easy. Inventing on Principle. Our list of best demos/pitches of all time.

Resist colons. It lacks confidence. Why Use Lot Word: When Few Word Do Trick? You’re not High School Musical: The Musical: The Series.

Put the SEO keyword vomit in the description.

Titles are for humans.

Prescribe A Strong Opinion

Here are some real submissions that I see side by side when I review talk titles for the same conference:

• How to Build AI Agents that Actually Work

• Building enterprise LLM agents that work

• Real Agent Evals: Evals that don't suck

• Lessons from building GenAI based applications

• Working with Coding Agents

I am not at all saying that these talks cannot do well. But if they do well, they do well despite their titles. What you’re doing here is offering a vague promise, and then it’s up to the viewer to click through and see if you fulfil that promise. Through no fault of your own, most talks do not fulfil these kinds of promises, so by extension, the viewer does not expect you to fulfil yours, whether or not you actually do.

Ok, what to promise instead?

Have a strong opinion.

Opinions are one of the most quotable things.

But more importantly, a good Opinion Piece is load bearing because it is eminently forwardable, and therefore viral and impactful. Your Job To Be Done is to be the definitive, conclusive, piece on that Opinion. Stake out territory in Opinion Space, list out all the arguments for, counter all the arguments against, provide datapoints, and watch that go further than anything you’ve ever done.

How to know what’s a good opinion? Three Strikes rule: If you repeat yourself three times, ship it. Even if you’re just quoting others, its fine, credit them and make it your own.

Mental Models and Frameworks are more complex opinions that allow others to scaffold their thought around you. My Radiating Circles and Measuring Developer Relations and Third Age of JavaScript did this.

Opinions contrary to an established opinion are the hardest to do well and the best when correct. What Clayton Christensen Got Wrong made Ben Thompson’s career. Rise of AI Engineer countered the prevailing Prompt Engineer -and- GPU Rich Startup/ML Engineer narrative at the time, with room to grow.

Curiosity Gap Dynamics

Marketers know the power of the Curiosity Gap. Here is where we toy closest with clickbait. I’ll be honest that I wasn’t even sure if I wanted to give it its own subheading, but its a very important concept that you should at least be aware exists, even if you’re going to ignore it.

Strong enough opinions create their own curiosity gaps; you won’t have to try very hard to make it interesting if you got my attention in 4 words anyway.

Question-titles are the strongest curiosity gap creators. One of the top AIE talks of 2025 asked an important question, and hinted at its credibility: “Does AI Actually Boost Developer Productivity? (100k Devs Study)”

That’s enough to cause curiosity. Most of the comments on that video aren’t even about the talk, they are just using the title as an excuse to get something off their chest, which works just fine for the youtube algo. Therefore, ask questions everyone not only wants the answer to, but they have an answer from their personal experience as well.

Curiosity gaps done poorly can lead to “burying the lede”, which make your talk less Quotable and you also don’t want to do that.

Simplest way to put it is; if the most interesting thing about your content is your title, and what people take away after having read your post matches what they would have predicted after reading your title, then you’ve probably said too much and could cut.

Play Madlibs

You don’t have to invent your title from scratch (nor should you always do what I’m about to suggest). Here’s some templates that work well:

• {BENEFIT EVERYONE WANTS} without {DOWNSIDE EVERYBODY EXPECTS}

  • e.g. How to Get Rich (Without Getting Lucky), How to Market Yourself (Without Being A Celebrity), How to be more emotionally intelligent (without trying so hard). See also subtitle of this post.

• {PRESCRIPTIVE OPINION}, don’t {THING YOU DO}

  • e.g. Parse, don’t validate

  • alternative prescriptive opinion: Never {THING YOU DO}

  • see also title of this post

• {POPULAR THING} IS DEAD

  • unfortunately this is clickbait that works

  • e.g. Prompt Engineering is Dead, Big Data is Dead

  • a lighter, less confrontational version is YOU MIGHT NOT NEED {THING}

  • when given at a conference for POPULAR THING, this is known as a Heresy Talk

  • opposite also works:

    • The Rise of {THING}

    • The Unreasonable Effectiveness of {THING}

• Fundamentals of {THING}

  • straightforward, people love fundamentals

  • also How {THING} Really Works

  • You can also flip it and go for the Advanced {THING} tier content

• {CONVEY EXPERIENCE/SCALE} with {THING}

  • e.g. What We Learned from a Year of Building with LLMs, Insights from over 10,000 comments on "Ask HN: Who Is Hiring" using GPT-4o

There’s loads more templates that work, please suggest in comments and I can add/review.

You can also browse the masters of microcopy like Steph Smith and Shaan Puri, and if you are worried about clickbait, you can see Veritasium’s take or Simon Willison’s Highlights.

also Andrew Chen senpai:

Understand Buzzword Metagame

Buzzwords work. Because of a mix of human psychology and algorithmic recsys. Don’t avoid them, just use them judiciously. This involves the ability to read the room, which many smart people sadly cannot without significant involvement in the broader community you are trying to speak to. I don’t see any way around it other than trying to authentically immerse, or consult a friendly who does.

Not all buzzwords are created equal. Databricks/Berkeley tried to push Compound AI Systems, Gartner is pushing Composite AI and Composable business — this resonates with their audience, but not more broadly (see my spiel on Gartner’s Grift).

Pick the shibboleths that work for the community you want. AI Engineer worked for reasons that are well understood now. GraphRAG is working outside of the company that coined it. These buzzwords travel, go ahead and put them in there.

You can kill a good buzzword with bad execution. “ with , and <ANOTHER POPULAR OPEN SOURCE>” is a formula that is easy to do and almost guaranteed to age poorly because it is self centered, and not doing enough work to answer “What’s In It For Me?” for the audience. Your pitch should not be about you.

Buzzwords rise and fall. Try to catch them on the rise — go harder than everyone else on the rise up and regularly test their effectiveness, such that by the time your main buzzword has tapped out you’ve got 2-3 others cooking.

Workshopping your titles

I write this post out of frustration, but also to capture my own thought process. I’m currently procrastinating while writing a Latent Space post.

• The original title was Why every AI Engineer needs an AI Gateway. Good, genuine opinion, load bearing. But not super memorable.

• My next iteration was “Stop writing model routers, use an LLM Gateway”. Ok, prescriptive, evocative. But didn’t cover the other elements other than model routing. One could shorten to “Stop writing your own LLM Gateway” but that doesnt quite express what people do.

• My next one is “It's not your job to DIY an LLM Gateway”. No buzzword bc “your job” is implied (for a Latent Space audience), a little curiosity gap, LLM buzzword, strong opinion. But still not strong enough.

• Final one is “LLM Gateway: The One Decision That Removes 100 AI Engineering Decisions”. Leans on Tim Ferriss’ madlbs.

It’s very common for the “tail to wag the dog to wag the tail” - the title is so important to clickthrough and so impactful to the message, that you spend a bunch of time on just the title itself, because that determines the piece you will write, then write the piece, then you go back and tweak the title based on what happened.

Amateur writers think their content has 95% of the value and then spend 5% on the title. Pros will put the value of titles closer to 50% and then act like it.

Make the Talk fit the Title

A very common practice is to word vomit whatever you have on mind into the talk, and then leave it to the end to come up with a title that kinda sorta fits the talk you already decided to give.

No.

Make the biggest, strongest promise you can with your title, and aggressively cut, reformat, flesh out your talk to do justice to that title.

Think about how you can inform, educate, and entertain, and do several rounds back and forth thinking about how the talk should best serve the title you’ve promised, change the title because that’s not quiiiite something you can say yet, change the talk because you changed the title, and so on.

You Should Break The Rules Once You Understand Human Behavior More Intuitively Than Rules Can Model

See title of this post. No better aura than intentional, conspicuous, successful rulebreaking.

What are we maximizing?

First thing to consider is what game we are playing. Usually the choice boils down to:

• Do you want to try to maximize the long term value of the company?

• Do you want to maximize the chances that this announcement gets in front of the most eyeballs today?

Sometimes the two are correlated ("any impactful announcement maximizes the long term value", "increasing personal followership contributes to longterm company value anyway"), sometimes they are not. Most central conflicts in devrel vs management arise when there are unresolved disagreements in the correlation.

Relevant considerations to going personal (PRO) vs going corpo (CON):

• PRO: "People follow people, not companies" - there is inherent bias toward following people and against companies on social media

  • CON: this is generally true, but there are very often exceptions, and the exceptions really stand out as the top tier of companies that suggest that this belief is mostly cope for people who suck at corporate personality

  • NEUTRAL-PRO: the reality is people follow interesting accounts wherever they are and probably most people know how to play the personal account game better (bc of skin in the game and bc of code switch when speaking for the corporate voice)

• CON: Companies are more valuable when they are not too strongly tied to the personal brand of any particular founder/employee

  • CON: so that they can be bought for their corporate brand

  • CON: so that missteps/cancellation or departure of any one founder/employee doesnt damage the company

• NEUTRAL: "Followership" is less and less valuable on social media as they are all incentivized to diminish social graph in place of engagementmaxxing feed algos that only barely register your follow decisions in their decision making

  • NEUTRAL-PRO: so maybe dont even look at followership, the only valid game is winning today's game, tomorrow may not exist so screw long term thinking

  • CON: but it does have nonzero weight, and is still valuable "currency" as hard-to-obtain-legitimately social proof

Net net, this is obviously not a clear cut story given the pros/cons I lay out above but as a company owner I believe building sellable assets long term is the path to liquidity over vanity, and so while I will indulge the personal authenticity especially as an early stage boost, I would communicate clearly that the north star is to build a company brand and voice that is greater than any of its parts.

A: If you chose Personal

The default tactic here is the hands-on project member with the largest followers tweet the announcement, tagging the company. Company can then quote tweet if they wish but it won't really matter since we are choosing the person as the face of the announcement.

If you don't have any project members with decent followership already, go home and work on that, meanwhile for the announcement, go to B.

B: If you chose Company

The default tactic here is to put the announcement on the company twitter, then have employees all quote tweet that tweet to tell personal take. Which ever personal take works will have the company twitter prominently featured, and hopefully enough people click through to the base company tweet so that it accumulates the most likes. This has a 50-50% chance of working depending on the personal influence of your employees vs your company.

to be continued...

These were just initial quick thoughts dashed off for a founder friend who asked for my thoughts.

This is meant as a Meetups oriented complement to How to Do IRL Conferences Good and is a subset of the broader How To Community genre. Read those for fuller context or other ideas! For more social meetups, see also: How to Manifest a Meetup

If you are reading this on email, know that this is a work-in-progress and we will update the live website version as we go along. Just shipping fast to get this out there.

Most companies think of meetups like this:

But this is a meetup:

And this is a meetup:

and this is too:

Rules of meetups

1. Rule 0: Do what you can sustain. Meetups live and die on the organizer's backs and the small core community that keep coming back and making it social and rewarding instead of wave after wave of faceless forgettable names.

   1. This rule is for the recurring, regularly scheduled, community oriented meetups only. Companies do do one-off meetups (sometimes also called "developer days" or "demo days" or "launch parties") but the ones that pull this off usually have a fair amount of social media pull anyway. If you have a company that can do this easily, it is preferable since the organization burden is lower.

2. Naming: you don't have to be too cute with naming. Have a clear name that resonates with your audience and run with it. The more you can definitively own an aspirational category outside your company name the better. E.g:

   1. SF Python Meetup

   2. SF Data Engineering Meetup

   3. SF Open Source AI Meetup

   4. Too "cute": SF "Bits and Bytes" meetup

   5. Too "alcohol tied": SF "Models and Bottles" meetup

3. Theming: The most important thing to nail about the meetup is why people are gathering. There are two main reasons:

   • Famous guest/speakers: that people want to hear from

   • Worthy cause: that is a hot topic at work or people desperately

4. Timing: Thursday nights are very popular in major cities, because "well at least it's not Friday". This leads to overcrowding of meetups on Thursdays. This isnt necessarily a bad thing if you're a big name, but also something to note. Mondays, Tuesdays, Wednesdays are fine. Weekends good for longer events too.

   1. See if you can coincide your event with something bigger going in the city, eg. a major conference going on, where big names from out of town are visiting and therefore easier to snag

5. Format:

   1. Traditional long talks: 25-45mins

   2. Lightning talks: 5-10 mins each - the SF Demos & Chill club has a strict rule against presenting work or selling things and it works well.

      1. Note from Lee Robinson : "If the goal of the meetup is socialization then the 5-7 minute lightning talks are so much better."

   3. Panel Interview - Thursday Nights in AI is often like this - great for the guest because no prep needed, but sometimes could be worse for the audience because of low info density

6. Marketing & Attendance:

   1. Many meetups have the problem of getting people to hear about them. Here the key is to get on local event calendars - make friends with all local influencers and make sure that they either come by or just shout you out in their calendar recaps or so on

   2. Some meetups have the fortune of being by a hot company or in a tech hub, and therefore have the opposite problem of too many people, and therefore:

      1. screening people as they come in is helpful. Often screening out VCs, managing gender balance, just general vibe

      2. Vercel ran an "invite-only" metastrategy for a long time where they would DM people they want to invite and the response rate would be higher because of the exclusivity - not sure this works for non-hot companies

   3. It’s worth recruiting speakers that are diverse across many spectrums, ex. gender, ethnicity, age, education, etc. Diverse speakers attract diverse attendees, or in many subtle ways make it harder to be unintentionally offensive or exclusive of minorities. It may require notable effort but it results in a richer community. (thanks Will Klein)

7. Extending: recording meetup for online consumption basically gives you some extra option value at the cost of a little more work - most recorded meetups dont go anywhere, BUT some go viral because its a good talk or hot topic.

   1. But even if your meetup gets like 300 views, which is low on YouTube, that's still 2-5x what you could get in person, and is nice collateral for inviting future guests to give the "vibe" of the meetup. There are also some folks who will NEVER attend your meetup but will speedrun thru your video at 2x, and these are often high value people you want to reach.

   2. In general I encourage recording unless you really can't manage it. I don't really care about livestreaming except to the extent that it helps you "auto-upload" with no frills instead of fretting about editing and potentially forgetting to upload later on (this has definitely happened to any busy devrel and it sucks - streaming has a nice lack-of-optionality to it where the audience gives you a pass for poorer experience due to lack of editing).

   3. Note from Lee Robinson : "Agree that live streaming isn't really worth it, but +1 to recording. Especially if you can set up a decent camera angle on the speaker". This lightly edited Vercel meetup talk got >100k views.

Recommended related reads

Both of the below are more "community meetup" oriented. If you know any notes/advice from people running more "coporate" oriented meetups, please get in touch.

• Gathering notes from Maggie Appleton: "As an organiser, you have to deal with a mountain of crap... Your challenge is to setup enough systems and structures to shrink this mountain of crap to an acceptable level. My organising impulses are reasonably selfish, so if I'm too busy dealing with unpleasant people, logistics, and literal rubbish to enjoy myself at an event, that's probably the end of that community."

  • includes other organization advice at the end, and some encouragement.

• 12 lessons from 5 years of running a tech meetupfrom Dave Kiss (see also the HN comments)

  • "I always try to host the meetups at a venue where people might be likely to hang out anyway, even if there wasn’t any event going on"

  • "Before the event day even comes, you need to paint the scene of what your guests will experience and what they’ll take home if they choose to spend the evening with your group. Try to think cinematically. Don’t just share the discussion topic — instead, describe the talk in more detail. Tell a story." - use AI art to make nice posters.

  • "If there’s one area where you can’t provide too much information, it’s the event description."

  • "Without fail, for free events, there’s a predictable dropoff of around 30% of all RSVPs." this is more like 40%-60% in San Francisco due to event dilution

  • "Ask each speaker to provide a testimonial about their experience."

  • Send reminder emails leading up to your event. I usually go with around 5 emails total

  • has a nice checklist of meetup supplies at the end.

Obligatory Sports Analogies

As a former tennis player this is something you pick up very early on and then spend the rest of your life mastering - you need to know to serve and drive powerful baseline hits, but you also need to be ready to run up to the net and volley quickly and deftly when the situation (often) arises.

Anyone who has gotten really good thwacks at the golf driving range, and yet gotten frustrated on the green when playing 18 holes, is also intimately familiar that having good long game cannot make up for a horrendous short game in golf:

Playing The DevRel Long Game

All too often, people only talk about "short game" tactical tweaks in devrel:

• running a content calendar or hackathon

• editing and marketing a blogpost/video

• speaking at a conference

• tying releases and products into themes their community is interested in

You can spot a "short game" by how important and time sensitive the activity usually feels at the time, and by how much it feels like it doesn't matter after a month.

I don't mean to minimize "short game" - I'm happy to throw down on suggesting post titles and charts and tweets - and that can be very impactful when the stakes are high, eg you need ONE particular launch/post to go well (so it is worth experimenting when the stakes are low so that you have a muscle for what to do when stakes are high). However the work done in the short game will be significantly boosted if you have a good "long game", and anyone with good enough "long game" can actually start inverting the rules of the short game - visibly breaking the understood conventions for engagement and attention - as a flex (see for example: Mistral choosing to launch with a magnet link and no blogpost because they had confidence/network to make it work).

Some half-formed thoughts on what The Long Game looks like:

• Building product users love

• Building up good companywide DevRel Infrastructure

• Working on positioning/pitch

• Actively participating in your community and the broader industry community beyond it, being perceived as a champion for users and thoughtleader on best practices and the future.

You will notice how little control the typical individual contributor devrel has over many of these. This is the job of the founder, and other company leaders/C-suites, to be actively working with their devrel teams, in order for the long game to actively support the short game.

Why this matters

Ultimately every founder/devrel wants the devrel work to contribute towards the bottom line. The "short" game tends to boost virality, but is usually weak on conversions. The "long" game helps improve conversions, but is usually boring (e.g. repeating the same thing over and over again, not tying into current topics and trends).

Think about the tech that you adopt at work:

• How did you hear about it at first? Probably through word of mouth from friends and influencers.

• How often did you hear about it before deciding to give it a serious look? Probably between 2-20 times, which is what we often experienced at Netlify (the common internet marketing wisdom is you need to hear about a product >12 times before people even register you in their list of options)

• Did you say any of that when you brought it up to your boss for adoption? No, probably not - the messaging you date isn't the same messaging you bring home.

Often people make quick decisions in their gut before then looking for rational reasons why their decisions are/are not correct. DevRel must be structured accordingly. In this way, the Long and Short Games mirror the System 1 and System 2 model of Thinking Fast and Slow.

Reframing the Hackathon

Here's what most people think about hackathons:

• Companies see it as a marketing expense to get early adopter developers (the kind that show up at hackathons) to try them out, and to get feedback on docs/SDK/onboarding pain points

• Developers see it as a fun way to spend a day, maybe win some money, try some new toys, get street cred, make friends

Here are the underappreciated ways to view hackathons:

• The tools that get used by winning teams get all the attention. You want to help them win, and for them to give you credit when they win.

  • What helps teams win? Good starter templates to save time, good ideas (I'll elaborate), good demo presentation (you cant help that much with these, but my friend Sam Larsen-Disney has a good guide for those getting into the game).

  • Ideas that are populist and disproportionately win hackathons: Anything with realtime (audience) participation, anything visual/beautifully designed, and anything with a narrative that people desperately want even if it is unrealistic. People tend to be superficial and judges buy into stories rather than the deep technical depth of the thing. I have won hackathons with basically a CRUD app but I presented the story in a way I knew a judge would love.

• Hackathons are a way to crowdsource a bunch of case studies, content, and starter templates for you to promote/polish/share post-event.

  • Doing a series of hackathons presents cumulative advantage because the output of one hackathon helps feed input for another.

  • Bringing a camera/mic for spot interviews with particularly happy new users can be useful for future video editing needs.

• Hackathons are an opportunity for your engineers to meet their users directly and viscerally feel their pain

  • Also a good way for you to meet good engineers for recruiting

• Hackathons help establish partnerships with other companies

  • a large hackathon can have 20-50 sponsors, and one way to stand out is to build alliances/form a bloc/offer a "set bonus" for using a bunch of tool stogether

  • sometimes you can even end up selling to fellow hackathon sponsors because you are there anyway and there is a somewhat captive audience

Hackathon Playbook

• Months before the hackathon

  • Confirm time, date, location, your intended staffing

  • See if you can get a judge spot - it does sway developer decisions on what tech to pick to try to win

  • Physical material - swag (see conf guide for swag ideas), banners/standees, costumes, etc, whatever that needs more prep

  • Any offsite lunches/happy hours/workshops you want to organize

• Weeks before the hackathon

  • Nice to have: Hackathon website - yourdomain.io/hackathon - with all available resources and materials in one place. Eg https://www.cerebras.net/events/neurips23/ . Dont need to make year-or-event-specific as you might want to reuse this for every hackathon (or not, up to you). Helps in your pitches both verbally and on slide decks.

    • Also prep lead capture things - sign up here with X code for Y bonus?

  • Prep starter templates/resources for people to get going quickly with you

• During hackathon

  • Have ready a 1-2minute pitch (see pitch inspo) for who you are and what you do, for a developer audience already familiar with the field since they are at the hackathon. Be ready to repeat this a bunch in person and maybe on stage too if you can get it.

  • Set clear expectations for when you'll be around - you don't actually have to be at the table through the whole hackathon! Simply having clear times posted for when you'll be at the booth so people can come talk to you is useful.

• After hackathon

  • Recap blogpost/video/tweet thread

This is my initial list off the top of my head. I'll update this if I get more ideas!

This is an easy way for people to onboard onto your platform, and do a tour of the must-know things on your product. It also helps you understand, via email analytics, who is actually engaged in your product (and likes their info in small doses via email). Also note that this was timed to finish right before Thanksgiving break, which gives people time to go through their email and catch up outside of work.

Every course embeds opinions about how the product should be used. Here the implicit recommendation is:

• first use us for debugging

• then collect and share datasets

• then automated evals (prebuilt)

• then manual evals

• then monitoring

• then prompts (because their PromptHub is so new)

LangChain also uses it to push the presumably 10's of thousands of people on their mailing list to their ~10k people youtube, though the clickthrough rate is low right now:

It is unclear if this is due to the very spartan thumbnail or titling or topic choice.

However, I still strongly believe that this work is worth doing because it is an asset that will continue to compound over time passively, as long as LangSmith doesn't change drastically from here.

This email drip content can be repurposed into:

• a learning microsite ("teach me LangSmith in 24 minutes")

• point documentation ("teach me this feature X in 3 minutes")

• a live workshop

• a series of blogposts

• internal training/onboarding

• and so on.

It's not so much about the view count on the video itself as the selection of the overall syllabus and understanding how to teach and demo the platform that is the transferable skill/asset.

Other Examples

• PlanetScale has executed a very hyped MySQL for Developers course that has done very well for their leadgen

• We had https://ecsworkshop.com/ and https://eksworkshop.com/ at AWS - which was very good for self guided and live workshop content

• Of course the people who teach for a living, like https://egghead.io/ and https://frontendmasters.com/, have a higher level of production value and forethought to their content and marketing-for-content game.

• We are also building one for AI Engineers at Latent Space University.

Not over yet

What else is worth learning from here? What could they do better? I will revise this post over the years as I learn about this.

And even the king of AI frameworks, LangChain, outsources it to a third party:

There's Kapa.ai, Kyber, Forethought/SupportGPT, Scrol.ai, and more. If you want open source DIY solutions, there's DocsGPT, and any number of Langchain and Llamaindex tutorials.

And, as far as I can tell, that is it for the docs/support AI crew. However, these approaches have some downsides:

• they are evidently much slower than traditional search, and yet not a lot better than search

• costs are borne by the host company

• most of the bots are run based on automated docs scrapes, which can fall out of sync

• the amount of prompt engineering and extra context you can add to a third party bot is quite limited and likely doesn't fully support your usecase

How Docs must change with AI

Most people in the docs world know about the Divio 2x2:

But I've lately been inspired by Metaphor Systems' approach, which adds a third dimension:

Here it is in the docs:

and how it looks when used:

Docs GPTs bring a number of benefits:

• Here the traditional divisions between Tutorial vs Reference vs Explanation vs How-to's get smashed. The user doesn't have to find what they want, they can just ask their question.

• GPTs can code, especially if you can bring-your-own-interpreter in future, so working code for your exact usecase can be produced from docs GPTs.

• The user runs the GPT on their own OpenAI account, so it doesnt cost the host anything. User also brings information on their own personal chat preferences which immediately makes it a better UX

This is exciting and after trying out the Metaphor GPTs for a while I am wishing that every company offered their docs this way.