The future of DevRel, with "Danger" Keith Casey

Is dev rel over? Or is it more needed than ever? Or is it somewhere in between? Today, I'm asking Keith, Danger, Casey that question. Keith is a senior product manager at Pangea and has previously worked at some dev tools you might have heard of, Twilio, ngrok, and Okta.

Yeah. So my my name, is d Keith Casey junior. So I'm a junior, so my father uses the the d name. And so I just never used it. And then a few times people misread it as doctor. And so I got introduced as doctor at a Health 2 Point O conference like 10 years ago in front of 400 doctors. I was like, Oh, wow, this is awkward. So I didn't correct them because it's just really weird.

And I

was like, I need something to fill that. So I started joking and I said, you know, D stands for danger, you know, like Austin Powers. Yeah. Yeah. Just having a little bit of fun.

That's so funny.

Which is an awesome way to close out a presentation. It's like people just go, Wow, that's fun. And so I did that once in an all hands. So this was probably 3 or 4 months after our IPO and our CEO sitting in the front row. And I said, You know, if you need to find me, look for danger. I'll be there. And like 2 hours later, I get an email from him. He said, So I looked for danger and you were there. And I'm like, oh my god. So I checked, and I could still log into things.

Yeah. That's great. I mean, it's great, I think, to, like, to stand out. And, also, you're kind of embodying danger a little bit with some of your articles recently.

You you could say that, but things are getting a little spicy at times.

This episode is brought to you by WorkOS. If you're building a dev tool, at some point, your customers are gonna start asking you for enterprise features. WorkOS offers you single sign on, skin provisioning, and audit logs out the box. WorkOS is trusted by Perplexity and Vercel as well as Workbrew, a home brew management startup that I recently interviewed. I just told Mike that WorkOS is the sponsor and this is what Mike said.

Yeah. So WorkOS isn't paying me any money for this. I I pay WorkOS money for this, but WorkOS is like one of the best developer tools I've, like, ever used. It's it's the documentation and the experience with building with them is so, so good. Like, I initially was almost like, okay.

the developer team are at GitHub and therefore are very good at the job. Go to workos.com to learn more. So you wrote this article about DevRel?

Yeah. So little bit of background into it. I was, early DevRel at Twilio. I was employee number 18 over there. So way, way back in the day. May 2011 is when I started. So, people didn't know what Twilio was at that point. It was very much a new thing. And DevRel was our primary go to market strategy of getting out there, boots on the ground, showing people how it works and everything like that. And I adored that level of dev rel.

So how yeah. So tell us how how has DevRel failed organizations?

DevRel didn't keep up with how to provide value to their organizations. And I mean, DevRel as as a whole, there's always exceptions to it. So let's just take this as the 80%. Whenever I say that a gross generalization say 80%.

Yeah. Yeah.

So DevRel as a whole forgot how to provide value to their organizations. Instead of focusing on here's what my company is doing, here's what our problems are. Our product solves. Here's how to solve them. Here's how to make your systems, your applications, your practices better with our tools.

Yeah.

So a lot of them make a hard shift into what we'd normally call soft skills. And some of them aren't even soft skills. Some of them are just, here's here's my experience with mental health. And it's like, you know what? That that is an important topic.

Yeah.

And that's when we have a big problem, because at that point, that dev real person is no longer building up that the credibility or the prestige or the presence of their company. They're building up their own reputation. And you always need some of that. But to go that hard into the topic, to be known as you're the expert on mental health within this community. That that's not a value prop that serves the company well.

Yeah. I agree.

At some point, the DevRel mindset shifted. And instead of talking about here are the skills that make us better in our craft of here's presentation skills, here's speaking skills, here's how to write better, here's how to tell a better, more compelling story. I can't count how many conversations I've been in at conferences where the the conversation turns to, here's the credit card you should get to optimize your airline miles. Yeah. And I'm like, woah, woah, woah, wait, wait, wait, wait.

Yeah. One one thing I would, put back to you on this, danger, is that, you know, I think you said, like, you know, that DevRel has, like, failed the organizations, but, you know, this sounds like a kind of, ad like, misaligned incentives, and couldn't you argue that this is actually the founder's responsibility that they've kind of set up these kind of, like, adverse incentives where someone feels that they can progress in their career and they can further the company by going to lots of conferences and talking about their mental health.

Yeah. Yeah. Absolutely. So the company didn't put good controls in place. They didn't say, here's what we need you doing, And that that's absolutely part of the picture. The problem is several most of them are are professionals. Most of them have been in the field for a while, and they should be able to see, hey. Look. What I'm doing doesn't map back back to any metric that makes my company successful. And so there is some there is some blame on both sides.

Thank you

for your budgets and everything like that. And are you would you buy this on your own? Are you spending responsibly? And so I definitely still put it back on the people in the field saying, well, wait a minute. How is this? Providing value to the person paying my bills to be here?

Yep. Yep. Yeah. I I I think that that for me, that's the that's the big root issue is that, like, you know, Endeavor is so broad, and there's so many different things that you could do. And if you're not thinking like a founder and you're not thinking about, like, what what is actually useful for me to do that drives results. It's like it's just destined to to fail.

And and it's an expensive failure. I mean, DevRel people are expensive. Once you start throwing in travel and conference sponsorships and swag and, like, all those things, it's DevRel is exceptionally expensive.

How how much to be specific, how much would, like, a fully kind of factored in, like, cost of a DevRel person in the US cost typically?

Yeah. That that's a hotly debated con conversation. At this point, it looks like a, like, mid tier DevRelP person would go for, I don't know, 120 to 150. It's pretty broad in there. A senior, more accomplished person would be higher, but then you assume, benefits on top of that, which is another 50%.

Yeah.

But there there's number that are smaller. But if you go to something, I think, CubeCon is this week. You know, you could easily spend 25, 30 k just to walk in the door.

But that would also be the kind of that would be marketing budget as well, partially. Right? Like, if, like Yes. The kind of

That that would be marketing budget. But when you go to an event like a a KubeCon, you definitely want DevRel type people in the mix Yep. To be able to do that. So, and and frankly, if if we are a little bit smarter about where we are spending money and how we are spending things, I think you we as an an industry would get a lot better. Unfortunately, I think there was a lot of fat in the industry, and it's been cut, and it's been cut hard. And in some ways, I think it's been cut too far.

And do you think that this is so one of the things that I've seen I don't think this was actually on criticism on your article, but, Swyx, who I know kind of, like, led us to pick this up, I saw some kind of criticism of his article that was around, like, you're picking on DevRel. Like, you know, this the kind of statements that we're making about, like, the ZURB stuff applies to, like, every, every job title. So, like, you know, software engineers that aren't, like, amazing software engineers, like, are maybe not that valuable now because people can just use, you know, ChargebeeT and Cursor and do a lot more, and this kind of general, like, overhiring. Do you think this is different to other cases?

So I I think yes in a couple different ways. I think, if if you look at sales, for example, most sales teams grossly overspend. You know, they would jump on a plane for, basically no reason. I had, I can't count how many times at Okta, like, a sales rep would fly me somewhere because they're like, we need to close this deal. We need to have you meet with the customer. And I was always happy to do that.

A cool person.

Yeah. And I was always happy to do that because I could always connect my decision, my choices, my actions to revenue. Yeah. And I think that's the big distinction there. When you can when you can connect your choices directly to revenue, you've got a lot more leeway.

Yeah. And I guess you're also fighting against so let's say there's a big customer lands. Right? And Endeavor wants to take credit for it. But marketing is probably a more senior organization, you know, bigger budget, probably representation at a higher level.

Well, go back to a scenario like re Invent. So this this huge customer that signs 9 months from now met you for the first time at re:Invent. They saw your booth. They got some swag. Maybe they talked to a dev real person. They got a demo. They said, okay, this cool. They signed up next week. During that sign up process, they got a drip onboarding campaign of, Hey, don't forget this. Don't forget this.

Yeah. I remember when I worked in sales, we used to think that the marketing team did nothing. And we were like

Yes.

They it's like, there was such a we'd be like, what are they doing? Like, what do they even do over there? Like, we're here, we're, like, calling people up, we're, like, really following up, we're getting them over the line, like, and they wanna take credit for this deal. It's like, what did they do? And it's I could imagine it's like maybe there's a similar dynamic that's like, you know, if you're not there at the finishing line, it's really hard to take credit for for instance, which I think is something that markets can struggle with.

Well, DevRel has that challenge, and it's even worse because if you think about the the person that the DevRel person spoke to, it wasn't the, the VP of whatever that actually signed the deal. It wasn't their senior advisers that the, you know, the engineering manager who said, yes, this is a good product. Odds are it was that line developer who had veto power but not decision power. Yeah. And so that that dev real person might have been a pivotal person in getting that engineer across the line for that engineer to go to their boss and go, Yep, works for this.

I I feel like there's 2 issues here, which is and they're pretty distinct of, like, there's the, is DevRel, like, useful to furthering the needs of the company, And then there's, will it get enough credit for it to be a viable, to get budget, to get hires, to not lay them off? And those things might be, like, quite separate where they actually are very valuable. There's scenarios there where they're very valuable, but they're not valued by the organization.

Yeah. And and that that's a legitimate concern. And I think that's a really good way to put it is they're valuable, but not valued. And and several needs to figure out how to express that value, because if they're not if they're not advocating for themselves, like to have good, useful measures, it's going to be effectively impossible for them to be successful, which is almost funny because when we were in dev rel at Twilio back in the day, we are developer evangelists. You know, we are spreading the good news.

Yeah. That makes sense. To just, also just linger on, like, the value because obviously there's, like, a lot of layoffs and stuff and reductions. But for me, I always think that there is, you know, salespeople when it comes to, like, the product, they don't really understand. I I know that.

Yes. I agree a 100%. That need is there. There needs to be somebody with technical credibility that can ignore the sales rep, ignore the senior managers on the other side and sit down with the developer and go, What problems do you have? What are you building? How can we do this better? Yes, there needs to be somebody that can do that. And I think what DevRel can morph into can address that. When I. Let's see.

Yeah. We we had a when I was working at Stack Overflow, there was a guy on my team called Matt Champion, which amazing name. And he was just he was probably the most popular guy in the whole company, and he was a sales engineer, and everyone wanted him on their calls. And when it came to, like, budget for sales engineers, I'm sure there was never any issues with, like there would have been uproar if he'd have been sacked because everyone wanted him. Everyone knew the value, and it was like and and these salespeople are powerful within the organization.

Well and to go back to what I said earlier, the more you can connect your actions and choices to revenue, the stronger your position is. So when you have a sales engineer who is loved by the sales reps and the customers have great interactions with them, you don't necessarily need to put a dollar value on that, but you can go, okay, this person is deeply valued by people inside and outside the organization. We we we need to keep them around.

What is the difference between what's going on now and what you kind of, you've written about versus, you know, what should be happening?

Well, so if we if we rewind a little bit to, the last sales kickoff I was at at Twilio was early 2013, and I'll never forget the head of sales at that point said, of the inbound leads we get, 3 quarters of them say they made they met a developer evangelist in the field.

Wow.

I was

like, oh, 3 quarters. That's awesome. It's unbelievable. 3 quarters 3 quarters of the inbound leads. Even better, he said. And half of those can name the evangelist. Really? So this is, oh, I saw Keith at this event. He told me about this thing. This is great.

That matches up with what Gonzo, you I guess you know Gonzo. Right?

Is he Auth0?

Yeah. Yeah. Yeah.

Okay. We we didn't overlap. He I left days before Auth0 joined.

Oh, wow.

Okay. He never overlapped, but I I read his stuff regularly.

Yeah. So he was saying that there's this kind of trend, which matches up what you're saying, which is, like, production production y insights. So not just, like, how to build this hello world app, but actually, like, how to run this in a production thing environment. Like, the the gotchas that might come if you're running this at scale, like, if you're trying to you know, the the complex stuff that's a lot that comes from, like, battle tested stuff.

Yeah. So I'll I'll tell you at when I attend conferences right now, I actively avoid the intro to whatever talks. I don't care. That could be served by YouTube, by blog post, whatever the the talks I want to see is 12 months of framework. What we learned. Yeah, that is gold. That is absolutely gold. If I can take the things you've learned the hard way. In an hour, learn 2 of them, and it saves me weeks of time. The value on that is immeasurable.

And how but how how does that happen? Because I think you talk about this as, like, you know, DevRel tends to be, like, really good at, like, the demos that they're kind of, like, you know, how to how to build this. But, obviously, your job is not software engineering, so you're not digging into actually running it for 12 months and stuff. So how can they kinda create this kinda content without doing that job?

Yeah. And I I said that in the initial blog post of, fundamentally Deborah works the developers, technical skills and atrophies those muscles. Other than running projects and doing side things and, like, actually having an active role on things, it's really hard to do. One of the things I figured out back in the day at Twilio is I would go to the support team, every month or so and say, hey. Are you seeing any patterns?

Yeah.

So you can get some of it by kind of going with a wisdom of crowds approach to be able to say, at scale, what's happening here? It's not ideal. It's not the same as I'm doing this, and therefore, I have a really deep understanding of it, but it's a way to get some of it.

Yeah. That's a that's a real challenge. Okay. So flipping that, like, let's say you're, you know, you're the founder of a new start up. Right? New dev tool. What is your team kind of structure looking like? And maybe you can do, like, a slightly dynamic answer because as it changes over time.

Yeah. Absolutely. So, I I'm very much in the mindset of, it's called a go to market strategy because you have to go to your market. So if you're a solo founder getting off the ground, there are so many moving pieces. It's almost impossible to get everything done.

And do you think there's I guess, would you hire someone under the veil of DevRel at some point? Or

If if you're potentially, but I think that's a a more downstream sort of thing. I think you can you can have a lot of value from developer relations without having somebody in the role. So I think especially when you're small, the CEO, the senior level engineers, whatever, like, they can provide some of that value. I think if your marketing message is tight and it it's descriptive, I think you can have a lot of, positive impact in those spaces to be able to say, you have this problem. Here's how we're solving it.

I see a lot of start ups doing that. That's I see a lot of people just, like, you know, making do and just getting, like, the team to contribute and stuff. It seems like it gets harder as you scale up.

Oh, yeah. Absolutely. And, I mean, like, yesterday, I had 2 different calls with people. Okta alumni, they're working on different things where, you know, 45 minutes to an hour, it's like, okay. We can lay out some, like, bullet points here and at least, like, sketch out a draft marketing message that now you can test with people.

I think, Swyx put it quite well where it was like, not not everyone needs HR, and a a lot of it can be done by the rest of the team. Does it mean HR is dead? No.

Yeah. It it it goes back to the the patchwork kind of situation of, yes, there are a number of functions that we need. What is the best, most effective way to get them addressed? And in a lot of cases, it's by taking this piece and handing it to this person and this piece and handing it to this person. And as long as you've got like a unifying message, a unifying voice, then that can work out well.

Yeah. I do see, a lot of startups. I wanna say a lot, but I speak to startups that I say, tell me they're hiring DevRel, and sometimes it's like, you know, why are you hiring DevRel? Because we need growth. It's time to kind of, like, turn on the growth.

Well, you hit on the the key fundamentally vital issue to understand there is where you already having success. I've had people that are like, oh, I need to hire a dev rel team. I'm like, what are they gonna do? Well, okay. Forget that. Where have you been successful so far? Where should they double down on? And they're like, well, we we don't know yet. So then this is the expensive way to go about it. There's a great book.

I think that's such a good way to put it. Yeah. A frustrating and kind of impossible task because it always seems like, I you know, I've spoken to a lot of people now and, like, the stuff that companies end up being good at is almost always, like, the founder is good at it or, like, interested in it or, like, got it started. Right? So let's take SuperBase as an example, like memes.

You you want people to be a little hesitant about writing spicy memes for their employer. I get that. But once once the CEO or the the senior level people, whoever that is, set that direction, knowing, okay, here's what I can double down on is awesome. Like, that's that's amazing. That's exactly what you want. But again, it gets back to they experimented early on, figured out something that works, and now they can run with it.

Exactly. Yeah. That's that's a really cool way to to put it. Yeah. And so I wanna ask you I wanna ask you about SDKs in a second before we run out of time. Oh, yeah. Do you wanna just wrap this up in terms of, like, what what would what would be, like, your takeaways to people from on on DevRel?

Yeah. So I I think firing your DevRel team is the wrong approach. Let me just say that really bluntly. I think figuring out where and how they could be productive is the best approach. And so a lot of people are like, oh, they should be part of sales.

Yeah. Yeah. That's, it's a very interesting article. Everyone should read it.

Thank you.

Okay. So we're gonna just do a very lightning run on this one, because we're running out of time. But you've written another another spicy article, danger, and it's how to kill your SDKs. Yes. Why should people kill their SDKs?

So, fundamentally, organizations when they write SDKs, the goal was to make their tools, their APIs, their product, whatever easier to use from your language and your framework. The problem that we have is that that company had a bunch of assumptions going into it and patterns that they baked into their thing that may not map to your view of the world and the way you build stuff. So I'm of the opinion that companies should kill their SDKs, delete their SDKs, r m minus r f, get rid of those suckers and instead document them exceptionally well. Open API, good docs and everything like that. And then the companies that need to consume them can auto generate them with generative AI now.

That is, it's a very spicy take.

Yeah. Well, I I think we're getting there. I I think we're going to get there sooner rather than later because there are so many supply chain attacks happening at this point that if you install an SDK, it has all these dependencies and those has dependencies and all these things happen. You're going to, at some point, have a risk somewhere in that chain. And it could be malicious.

Yeah. I so in terms of, like, I I kind of agree. And so it makes it way easier to from my perspective, it makes it much easier. The surface level surface area of the of the dev tool is, like, way less. So, you know, everyone hates it when an SDK is out of date or, like, all this sort of stuff, and it's it sucks.

Yeah. Yeah. What so I think what's going to have to happen for it to bridge the gap is I think our IDEs are going to have to do that more and more. So if like, to do the actual generation. So you say, I want an API that does, you know, SMS.

But do you think that you would pick, like let's say, an SMS provider. Like, do you think that you would pick this within your ID? Because I feel like a lot of it is, like, how do I trust them? Who else uses them? You know, you're gonna go to the website and then I feel like it comes back to it. It's like, I don't know. Like, you know, you wanna see some code that you understand. I don't know. It's,

potentially. Yeah. Potentially. And I and that's where I think we're we're in this weird spot right now where the vast majority of developers don't care, though. I when I was at Okta, I developed the phrase, developers have 2 goals of life, build something useful and go home.

So it's almost like you're not even using an external. It's almost like there's no difference between using an external tool, in a sense. Like, maybe you could even generate, like, the API keys within your ID ID or something. Like

Oh, yeah. Absolutely. And and I think that's where some things are moving to. If you look at, the whole, like, developer productivity movement, I think a lot of that is will be coming to the surface. It used to be, was it centers of excellence? And now they're shifting mindset to become centers of enablement of how do we get a blessed set of tools that you as a developer and organization you just pick up and run with, and you don't have to go out and find on your own.

Does blessed slow you down though if, like, you you know, blessed is great when it the tool exists, but then if you wanna do something that no one's done before.

Yep. It's that is going to be a hard one because rewinding 12, 14 years ago at this point going into Twilio, At that point, nobody thought us sending SMS was an important thing. And in fact, anyone doing at that point, I'd been with an SMS aggregator before. Getting a short code to send a message was $10,000. Then that was just the registration.

Yeah. Yeah. That's, Yeah. That's tough. Exciting. Okay. Danger, this was awesome. Could you tell us a bit about, we didn't really talk about Pangaea, but do you wanna tell us about Pangaea, the way you're working?

Yeah. Absolutely. So I'm with a company called Pangaea dot cloud. We have been building a series of composable security APIs. Things have taken a shift in the last few months because, as we start doing more and more stuff in the AI space, we realized that we witnessed in the ecosystem that, AI security sucks.

Super, super cool. Okay. And then finally, 2 more questions, and then I'll I promise I'll let you go. First one is, one final takeaway that you have for, dev tools founders, dev tools, startup people.

Single most important thing you can do as a dev role or sorry, as a dev tool founder, as a developer, is get in front of people as soon as humanly possible. You have your own assumptions, your own biases, your own view of the world. You might be a 100% correct or you might be 1% correct. You need to figure that out as quickly as possible, Because if you spend 3 months working on something and get out there, people like, no, that's not it. You're going to kick yourself and be super frustrated.

Amazing. And then final question is, are there any dev tools, besides Pangaea that you're, like, really excited about right now?

Yeah. I'm I'm doing a ton in the the AI space. So I'm definitely, you know, chat GPT and Grok and Claude and all that fun sort of stuff. I'm starting to do more and more cogeneration, so I'm having lots of fun on that front. Beyond that, I've started.

Stuff. Alright.

Yeah. It's some pretty cool stuff. Yeah.

That's cool.

Read my blog. I'll probably do it right up.

That's amazing. Okay. Igentic stuff. It's funny because, like, I feel like everyone and this would be my answer is just cursor, and I think everyone right now is just like, what are you excited about? Well, actually, it's just code Jetta Casa and all these. It's so such a crazy advance.

Well and I have this this high level hypothesis that the vast majority of applications we build, it it we can abstract them to the idea of it's a set of code to do a particular task. And so that's a very abstract take on it. But if we could build agents that have access to the logic that we would apply to that task, and the data we need to execute that task, I suspect there's a lot of like, very boring simple applications. They're just going to disappear in favor of domain specific agents. Yeah.

It's it's a very exciting time. Well, thank you very much, Danger KC. I really appreciate your time, and, thanks everyone for listening.