The future of DevRel, with "Danger" Keith Casey
In early 2013, Twilio's head of sales told the team that three-quarters of inbound leads said they'd met a developer evangelist in the field — and half of those could name which one. Keith "Danger" Casey thinks DevRel lost that thread, and now can't prove it's worth keeping.
Keith Casey — known to most of the industry as Danger Casey — was employee 18 at Twilio, one of DevRel's founding era, and later worked in product marketing at Okta, ngrok, and now Pangea. He wrote a widely-discussed article arguing developer relations has failed the organizations that fund it, and this conversation is the case for that argument in detail.
We get into what actually changed in DevRel over the last decade, why attaching yourself to marketing attribution is one of the riskiest career moves in the industry, what conference content is actually worth attending, and his genuinely contrarian take on why companies should delete their SDKs.
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.
What's the core argument in your article about DevRel failing organizations?
DevRel got less focused on being developers and more focused on marketing skills — measuring things, presentation counts — which are valuable, but that's no longer developer relations, that's straight marketing. I was early DevRel at Twilio, employee 18, back when it was our primary go-to-market strategy: every one of us had eight to ten years of development experience plus presentation skills, and we'd go out and show people how to actually build things. What I've watched happen since, accelerating around and after COVID, is that DevRel forgot how to provide value to their organizations. Instead of talking about the company's problems and how the product solves them, people got evaluated on how many conference talks they gave — and some figured out that talking about, say, their own experience with mental health was easier than a hard technical topic they didn't actually have the credibility to speak on. That's an important topic, but it's not a topic I want to pay to send my engineers to a conference to hear.
Isn't that more a failure of incentives set by the company than by DevRel itself?
Absolutely — the company didn't put good controls in place, and that's part of the picture. But most of these are professionals who've been in the field a while, and they should be able to see that what they're doing doesn't map back to any metric that makes the company successful. Back in the day we had the mindset of 'act like the money is yours' — would you spend your own budget on this? So there's blame on both sides, but I still put some of it back on the person in the field asking whether what they're doing is providing value to whoever's paying their bills.
Why is it risky for DevRel to attach itself to marketing attribution specifically?
When you can connect your choices directly to revenue, you have a lot more leeway — sales teams grossly overspend on things like flying an engineer out to close a deal, and nobody questions it, because the connection to revenue is obvious. DevRel has specifically detached itself from sales, which is fair, but then attached itself to marketing attribution instead — and attribution is the hardest problem in any marketing organization. A customer who signs nine months from now might have first met you at a conference booth, gotten a demo from a DevRel person, gone through a drip campaign, read some blog posts, talked to support, then finally closed with a sales engineer. There's no way to say which one thing closed that deal. DevRel has staked its career on a metric that nobody measures well and everyone argues about constantly — that's a genuinely risky place to be.
How expensive is DevRel, in concrete terms?
A mid-tier DevRel person in the US runs $120,000 to $150,000, more for someone senior, plus roughly 50% on top for benefits. Then add conferences — sponsorships aren't getting cheaper, you can easily drop $15,000 to $20,000 on a given event, and something like re:Invent is a different world entirely. Just walking in the door at KubeCon can run $25,000 to $30,000. There was a lot of fat in the industry, it's been cut hard in the recent round of layoffs, and honestly I think in some cases it's been cut too far.
Was there ever real evidence that DevRel worked, in a way you could actually point to?
The last sales kickoff I was at, at Twilio, early 2013 — the head of sales said that of the inbound leads we were getting, three-quarters said they'd met a developer evangelist in the field. Even better, he said half of those could name which evangelist. That's the mindset DevRel needs to get back to: at the end of the day, is this changing the business in a positive way, driving signups, driving sales, driving upgrades? We got very good at the compelling five-minute demo — that's genuinely valuable — but we've fallen down on what comes after that: getting someone from a functional demo to a real, non-toy use case.
What conference content do you think is actually worth attending now?
I actively avoid intro-to-whatever talks now — that's served just as well by a blog post or a YouTube video. What I want is '12 months of running this framework in production — here's what we learned.' If I can take things you learned the hard way and, in an hour, absorb two of them and save myself weeks, that value is immeasurable. If DevRel wants to persist, that's the material: here are the pitfalls, here's where you're probably going to screw up, here's how to fix it. The hard part is that DevRel work atrophies your actual technical skills, since it isn't your day job to run something in production for a year. One thing I did at Twilio was check in with the support team every month or so — what patterns are you seeing, what are people struggling with — and build content off that. It's not as deep as having done it yourself, but it's a way to get some of that signal at scale.
What should DevRel actually turn into, if the current model isn't working?
I'd advocate for DevRel moving toward product marketing specifically, because product marketing is fundamentally about understanding your customers' problems and telling that story at scale — which is a lot of what DevRel already is. When I moved into product marketing at Okta, I realized pretty quickly it was effectively DevRel at scale: instead of talking to one developer at a time, we were figuring out how to express the company's message so a sales rep could handle tier-one technical questions. Good product marketers also tend to have real technical expertise, which is exactly where DevRel people can shine. The other viable path is becoming an excellent sales engineer — I've met plenty of DevRel people who are naturally suited to going deep technically with a specific customer's problem, and salespeople fight to keep good sales engineers around because their value to closing deals is obvious.
For an early-stage devtools founder, what should come before hiring any DevRel?
Figure out your ideal customer profile and how you describe their problem before anything else. When I joined ngrok, I spent my first two weeks just working out who would buy this without hesitation and what problem we actually solve for them — that makes the website easier to write and customer conversations easier to have. I'd say the first hire after an engineer should be someone who can craft that message, often part-time or contract, and go deep on the specific niche you're in. There's a book called Traction that lays out roughly 19 different marketing channels — try three or four, kill what doesn't work, double down on what does, and keep iterating as your company grows. If you hire a DevRel team before you know where you're already getting traction, that's the expensive way to find out, and it's genuinely miserable for the DevRel person, because writing a great blog post that nobody reads because there's no existing traffic is deeply unsatisfying.
You've written that companies should kill their SDKs. What's the argument?
When a company writes an SDK, the goal is to make their API easier to use in your language, but it bakes in that company's assumptions and patterns, which may not map to how you actually build things. I think companies should delete their SDKs and instead document the API exceptionally well — OpenAPI specs, genuinely good docs — and let the consuming side auto-generate what they need with generative AI, trained on the documented patterns rather than some generic off-the-shelf client. Beyond the flexibility argument, there's a real security case: every SDK you install drags in a chain of dependencies, and each of those has its own dependencies, and at some point there's a real risk somewhere in that chain, whether malicious or just an accident like left-pad breaking half the internet. Nobody can honestly say they have full confidence in everything sitting in that dependency tree.
What's your one takeaway for devtools founders?
Get in front of people as soon as humanly possible. You have your own assumptions and biases about what you're building, and you might be completely right or almost entirely wrong — you need to find out which as fast as you can. If you spend three months building something and then find out it's not it, you'll be kicking yourself. If you spend three days on it and you're wrong, that's fine, you can iterate on that many times over. The cost of being wrong scales with how long you waited to find out.