DevRel is unbelievably back - with swyx
Shawn "swyx" Wang points out that Anthropic — a company doing over a billion dollars of revenue through Claude Code — still can't fill its head of DevRel role. He explains why DevRel died out for years, why it's back now, and the one gut-check question he uses to tell if a company is actually mission-driven.
In his third appearance on the podcast, Shawn "swyx" Wang — who coined the term "AI engineer," founded the AI Engineer conference series, co-hosts the Latent Space podcast, writes the DX Tips newsletter, and now works at Cognition, the creator of Devin — joins Jack to talk about why developer relations is suddenly back after years of being unfashionable.
They get into the difference between "uphill" and "downhill" DevRel, why cheap AI money is fueling a new DevRel hiring wave, what makes a company genuinely mission-driven versus just competitive, and why owning a single superlative (like speed) matters more than vague claims of being "more complete." swyx also gives Jack some pointed advice on where Scaling DevTools itself should go next.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You've been saying DevRel is unbelievably back. What actually convinced you of that?
It really came to a head for me with Anthropic — the hottest developer AI company in the world, doing a billion dollars of revenue through Claude Code, and they still can't fill their head of DevRel position. It's still open, they're still hiring, I chatted with the hiring manager last week. And anecdotally, founders I've invested in or I'm friends with are pinging me a lot more asking who's good at DevRel, and the standard answer is all the good ones are already taken. The last time I felt this way was early Netlify, around 2017, when really good DevRel was clearly driving adoption and landing big companies.
Why did DevRel die out in the first place?
For a long time the philosophy was: just work on the product. If the product isn't good enough, adding more DevRel on top doesn't matter anyway, so put all your people on product. DevRel drives bottom-up sales mostly, not top-down, and for a long time bottom-up was kind of dead. You could see engagement on DevRel topics going down. Even at Temporal, our first sale was four million dollars, and it wasn't from developer relations — it came from a long period of open source plus top-down sales.
What's changed to bring it back now?
A couple of things. One, there's more of a shift toward platform plays rather than pure products — and whenever your product is an API, you have to tell people how to use it, which is where DevRel comes back in. Two, money is a lot cheaper now than it was three years ago. There are two-hundred-million-dollar seed rounds out there. It's a kind of localized zero-interest-rate environment in AI — the money is meant to be spent, so even if you can't cleanly attribute ROI, people think it's generally a good idea to spend some of it on DevRel and good vibes.
You've written about "uphill DevRel" versus "downhill DevRel." What's the difference?
Downhill is when you're already popular — that's typically who people point to when they say someone is good at DevRel, but it's unclear how much of that is them versus just the value of the seat they're sitting in. Most people are uphill: by default you're not winning, by default nobody gives a shit. When you're uphill, you probably don't have the product or the social proof yet, so what you engage people on is the mission — you're selling the idea of something, even when there's no money or purchasing department involved, because that's what you need for hiring and fundraising, not just sales.
What's your litmus test for whether a company is actually mission-driven, versus just competitive?
It's very simple: if someone else reaches the mission before you, are you happy? If you don't accomplish it yourself but someone else does, and you're genuinely happy about it — my work was wasted, but humanity is saved, and I care more about that — then you're actually mission-driven. Very few companies are, and that's okay. A lot of the best startup founders are just competitors who want to be faster than the next horse. That's fine, but it's harder for people to get behind you purely on that, because they want to believe in something bigger than themselves.
What does great developer relations actually look like, in your view?
If you tell your customer everything about how you work — no secret sauce, no proprietary mystery — and they still buy you, that means you're solving a genuinely hard problem. They look at it and think, there's no way I'd build that myself, let me just pay twenty dollars a month instead. That's also literally how you do great DevRel: open up the box, demystify the system, give people a good working mental model of the tool, because when someone hires your startup they're effectively hiring you onto their team.
You've talked about the importance of owning a superlative. What do you mean?
Being number one at something in an important category actually matters, and a lot of people fail to do it — they say things like "we're more complete" or "I have fifteen years of experience," and nobody cares. Prove you're number one at something. Speed is usually the easiest, most reliable one for a startup to own, because you have less bloat than the incumbents and you're simpler. Bun's early success was basically just speed — then it added Node compatibility, then other APIs, then broader developer experience. "Better developer experience" on its own isn't measurable or provable. Being fastest is.
What's your take on MCP as a standard, in hindsight?
It took a really good run, but I think it's kind of died out a little. It'll be around for a good long time just because it's so prevalent everywhere, and it's really hard to get a new standard adopted, but it definitely didn't solve all the problems it set out to, and people are looking for the next thing. A good example: at the AI Engineer workshop in March we were all excited about the official MCP gateway Anthropic was going to launch. By August, they actually launched it — and no one really cared.
You've done this podcast a hundred-plus episodes now — what would you actually change about Scaling DevTools?
I think the recap you did of a hundred episodes was good and could be developed further. The path that makes the most sense is probably something like what Lenny's done with product management: write resources, not just episodes, because writing consolidates your knowledge and builds you up as a domain expert, and it's easier to consume than an hour of audio. I think of this as a stream-versus-particle duality — a podcast is a continuous stream of guests with overlapping ideas, but you can convert that stream into a solid, consumable particle, like a wiki entry, so someone in a specific role can go straight to it. A lot of content creation is a sawtooth that resets to zero every time; what you want instead is compounding assets that keep building. I maintained a chart of model pricing for a year on Latent Space — easy work once it existed, but a genuinely useful resource for everyone every time a new model came out.
Links & references
- Uphill DevRel article ↗
- DevRel is unbelievably back article ↗
- Particle/wave duality article ↗
- The Economics of Superstars ↗
- AI Engineer conference videos ↗
- Swyx's LinkedIn ↗
This episode is brought to you by WorkOS.