Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

Today I have the very great pleasure of talking to Carter Rabasa, who founded the CascadiaJS conference. Carter learned his developer relations trade at Twilio, but as you listen to our conversation, I’m sure you’ll agree that this was always something he was destined for.  We talk about the history of developer relations and we talk about measurement, and how maybe measurement is something more for yourself than for anybody else. 

‍

All righty, let's talk. [0:00:44] 

‍

Main Interview

Carter Rabasa

‍

Richard Rodger:  [0:00:44] Carter, welcome. It is great to have you here on the Fireside with Voxgig podcast, talking about developer relations. And we were just chatting and you told me that you were at a meetup recently. You met someone who was like, “Developer what now?” [0:01:01] 

‍

Carter Rabasa:  [0:01:02] That’s right. I organize – this is unsurprising for people who work in dev rel, but I organize a meetup. Some folks organize multiple meetups, but I organize the Seattle JavaScript meetup. I’ve been organizing it on and off for years. And it’s funny; I’m continually surprised at how many new people show up every month. It’s – people keep discovering us. 

‍

But anyway, someone came up to me towards the end of the meetup. It was a new person; she was new to tech, new to Seattle. And generally, I’m the organizer, so I’m very approachable. And we start to talk and she asks me what I do, and I tell her that I’m in dev rel, and she does not know what that word means. It’s not really a word; it’s an acronym or something. 

‍

But she’s like, “You’re a developer?” And I’m like, “No, I’m in developer relations,” and she clearly did not understand what I’m talking about. So, I walk her through what dev rel is, and she was surprised and very curious, and had lots of follow-up questions. But it’s pretty wild in 2023 to encounter people in the industry, even people who are new to the industry, that are not aware that this is a thing. [0:02:17]

‍

Richard Rodger:  [0:02:17] Yeah, although I suppose we are a little introspective. People who work in developer relations tend to think about developers a lot. And we tend to self-organize, so we’re talking. Look at us now, two dev rel dudes talking to each other – let’s get outside the building. Maybe you role modelled; maybe that’s a future developer advocate. [0:02:41] 

‍

Carter Rabasa:  [0:02:43] That happens all the time. Once you get past what is this and what do you do, people – not everybody, but a lot of people find themselves in what they hear about the role. They find – a lot of people who are new to tech are coming from other kinds of roles, other kinds of industries. These are generally non-technical people who have decided for – whether it’s their passion or whether it’s about compensation, they want to get into tech. 

‍

And they go to a bootcamp and they emerge with a set of highly technical skills. But these are full people that had interests that lie – that lay outside of tech. and that’s one of the things that’s fun about dev rel. It’s this role that needs to be fairly highly technical, but provides so much room for non-technical work and non-technical things to happen. Oftentimes when I’m talking to people about what I do for a living, their eyes perk up a little bit and they’re like, “That’s interesting. I wonder if I could do that.” Those are always interesting conversations to have. [0:03:56]

‍

Richard Rodger:  [0:03:58] Both of us are a little bit lucky in that we started off as devs. You also did Java at the start, into EE and all that fun stuff. Java beans and all that sort of fun stuff. And then through various accidents fell into that role where you’re externally facing. And maybe you’re organizing meetups or talking at conferences or writing articles. But that was a long time before it had a name – it was just ambassadors, that type of thing. And now it has an official title. How did that happen? [0:03:58]

‍

Carter Rabasa:  [0:03:58] That’s a really great question. I don’t know. I remember learning that one of the first evangelists was a guy named Guy Kawasaki, who worked for Apple. Guy Kawasaki, he’s famous; you can look him up on Wikipedia. But he was one of the first. Technically, he called himself a technical evangelist or a technologist evangelist or something like that. 

‍

And he – you can see a lot of what dev rel people do in what he did. He was running around, evangelizing Apple, technologies, products, platforms, talking to people interacting with them. And this was happening back in the – I don’t even know, the late 80s, the 90s or something. And- [0:05:24] 

‍

Richard Rodger:  [0:05:24] He’s the OG, right? He is the OG. [0:05:26] 

‍

Carter Rabasa:  [0:05:27] I think he is, but then there’s a gap. There’s this – for me, there is. You can educate me. But as far as I’m concerned, I don’t know who the first proper modern – in the era of the cloud. Who’s the first API/cloud developer evangelist. I don’t know who that person was. [0:05:51] 

‍

Richard Rodger:  [0:05:51] The next step would have been – you work for Microsoft, right? Microsoft had this- [0:05:54] 

‍

Carter Rabasa:  [0:05:54] Sure. PCs and- [0:05:56] 

‍

Richard Rodger:  [0:05:56] Microsoft had this program. [0:05:57]

‍

Carter Rabasa:  [0:05:57] -Windows. Yeah, you’re right, but still, it’s interesting about – what’s interesting about all those – and this is maybe less about the company and more about how the world moved on. Apple – I don’t – Apple Events were first-party events owned and operated by Apple; Apple developers would go to these events. Same with Microsoft; Microsoft had a powerful ecosystem of first-party events across all of their platforms, whether it was PC or mobile or Xbox or whatever. 

‍

And Microsoft would employ evangelists that would interact with their community, but it’s a community that they owned. And when I came into dev rel, the place that I spent almost all of my time was at community events. Once again, I don’t know when community events took off and emerged from the shadows and became the predominant way that developers got out in real life and met other developers or uplevelled their skills. 

‍

But that’s where me and my fellow dev rel folks spent almost all of our time. And I think – and that was a big shift in terms of what did it mean to be in dev rel. In the old days, the notion of supporting communities was probably not something that ranked very highly, in terms of the responsibilities of older- [0:07:35] 

‍

Richard Rodger:  [0:07:35] If it even existed. 

‍

Carter Rabasa:  [0:07:36] If it even existed. It wasn’t – it simply wasn’t something that people even though about, because what do you even mean to support the community. But once you get to 2010 and beyond, you have real meaningful communities springing up online. GitHub is a huge catalyst for this, open source. It completely changes how developers organized, communicated, networked and dealt – and met and interacted with one another. And that changed how dev rel people felt that they needed to operate. [0:08:18] 

‍

Richard Rodger:  [0:08:20] Carter, you’re right. The emergence of GitHub is concurrent with developer relations, the genesis of what it is now, and the meetups and all that sort of stuff. I’m trying to think, going back a little bit earlier. Was it – maybe it was Sun Microsystems. And then there were those bloggers, people like Tim Bray, who evangelized XML and someone that was – maybe you could trace back through that, right? [0:08:47] 

‍

Carter Rabasa:  [0:08:49] You could. Folks like Tim Bray and Dave Winer, they were – sure. That is – I do think that is absolutely evangelism. And by the way, evangelism can trigger people negatively, some people negatively. My job title when I joined Twilio was developer evangelist. [0:09:13] 

‍

Richard Rodger:  [0:09:13] Old school! 

‍

Carter Rabasa:  [0:09:13] And I very rarely see people with that job title today, because that word has connotations that people don’t care for. But the idea of evangelizing something is a totally neutral word and a neutral idea. And evangelizing RSS, evangelizing XML. But there’s – those people – there is a difference between doing that in the context of a true passion project, a true - something that you’re pure passion ate about. 

‍

It’s completely open source; there isn’t – there aren’t the concerns or the – the concerns of a corporation behind what you’re trying to accomplish. That’s where it differs. The kind of things that dev rel professionals need to understand and need to get good at is a little bit different than what Tim or Dave needed to do on a regular basis with the things they were trying to advocate for. [0:10:21]

‍

Richard Rodger:  [0:10:22] Yeah. And again, this goes back to something we mentioned before we came on, which was empathy. Maybe an evangelist has an agenda; they don’t have – it’s not coming from a place of empathy. Maybe that’s what legitimizes developer relations as it evolved, in that it was by developers, for developers. [0:10:46] 

‍

Carter Rabasa:  [0:10:46] I think so. It’s interesting. When I think about my job and when I think about the things that I do, that I did at Twilio and I do today at Courier, so much of it is functioning as this bridge between the product and engineering organizations inside of the company and the developers outside of the company that are trying to accomplish their goal. 

‍

They’re trying to build something; they’re trying to solve a problem. So, I’m – dev rel is often this connective tissue between two sets of people. And once again, thinking back to someone like Dave Winer and Tim Bray, I don’t know that they – that that was something that they had to worry about. They were – Dave was his own company; Dave was- [0:11:45] 

‍

Richard Rodger:  [0:11:45] That’s right. 

‍

Carter Rabasa:  [0:11:45] -hand coding his own RSS parsers and generators. He didn’t have to worry about mediating between two groups. He worried about mediating- [0:11:58] 

‍

Richard Rodger:  [0:11:58] He was everything. 

‍

Carter Rabasa:  -[ 0:11:58] between himself-

‍

Richard Rodger:  [0:11:59] He was the whole thing. 

‍

Carter Rabasa:  [0:12:00] Himself. That’s right. But those people are incredibly inspirational. And by the way, I’ll say I think both sets of people have tremendous sets of empathy. Dave – and we keep using Dave Winer as an example, but there’s so many other people. I would say this is about anybody who’s created really meaningful open source. Trying to – Ryan Dahl, the guy who fed- [0:12:28] 

‍

Richard Rodger:  [0:12:28] Yeah, that amazing talk. [0:12:29] 

‍

Carter Rabasa:  [0:12:29] I don’t-

‍

Richard Rodger:  [0:12:30] That amazing talk where he introduces Node, right? [0:12:32] 

‍

Carter Rabasa:  [0:12:33] I just don’t think that you can invent something like Node and not have it come from a deep place of empathy for developers that are trying to solve certain problems, but are maybe being inhibited by the tooling that they’re being given. So, I think those folks have – anyone who’s in open source almost by default is probably a very empathic person, and that’s what helps them build these amazing products. 

‍

And folks that are in dev rel are not themselves building the products, that they are a conduit. They’re – they need to have a similar level of empathy for developers that are evaluating the product or trying to use the product or are incredibly frustrated with the product. And by the way, the empathy goes the other way too. 

‍

Developers will tell me constantly about what’s wrong with an API or what they – how they wish it worked for whatever. And how I communicate that feedback back to product and engineering also needs to be handled with care. Because these are people who are – we’re all trying to do our best. 

‍

And I’ve seen people succeed in dev rel and I’ve seen people discover that it isn’t for them. And the people who discover that it isn’t for them usually fail or opt out for one of two reasons. One, it’s too technical for them, which is completely fine; there are many other great roles and ways to be involved in tech. Or they find out that they – the level of empathy that’s required is too much, and it feels burdensome and stressful. And then those people just opt out and usually fall back into traditional technical roles. [0:14:24] 

‍

Richard Rodger:  [0:14:26] It’s interesting that you say that. The developer relations role is really suitable for a generalist. And if, like me, maybe your coding isn’t that great – I know coders who are machines. They can handle vast amounts of context, and I was never that good. I like my clean code; I like my good architectures, but I was never that machine level of awesome. [0:14:57] 

‍

Carter Rabasa:  [0:14:57] What I would say is, whether I was ever good or not at coding, the thing is that what I cared most about coding was the creative, creation part, the hacking, the oh, I wonder if I can do this – I was great at the first few days of coding. Everything after that, the unit tests and the hardening and the secure – all the – unfortunately, that’s incredibly critical, a critical part of what it means to be an engineer and to build products that users can trust and rely on. I hated that stuff. [0:15:36] 

‍

Richard Rodger:  [0:15:38] Developer relations! 

‍

Carter Rabasa:  [0:15:40] Absolutely. And being in a role where your job is to build demos and see what’s possible and inspire people. Don’t – whatever your product does, whatever your API does, find a way to make it fun; find a way to inspire people. Help developers. Developers often get a negative rap for not being creative. 

‍

I don’t think that’s true. People can be creative, but sometimes some people need extra inspiration. And good dev rel does inspire them, to think outside of the box that they are living in or the box that they’ve created for themselves, and imagine what else they could do with these tools. [0:16:27] 

‍

Richard Rodger:  [0:16:28] Yeah. We’ll return to the subject of what makes a good dev rel, how you measure it and all that kind of stuff, in a little while. I’m a history nerd, so I’m just going to go back to the history thing because it’s a fascinating topic. And speaking of creation, CascadiaJS, how did that happen? Because I’m fascinated by the story of how these community events, community supported events – their genesis and how they sustain themselves. [0:16:56] 

‍

Carter Rabasa:  [0:16:58] For folks who are listening, CascadiaJS is a regional JavaScript conference, full stack JavaScript conference that takes place in the Pacific Northwest, so Seattle, Portland, Vancouver.  Cascadia is a nickname for this area. It started because I was a person – I’m old enough to have been to some really awful IT conferences back in the 90s. And they were – and I was exposed to what really awful technology conferences can look and feel like, and it made me never want to attend them again. 

‍

And then later in my life, I think right around 2011, I was lucky enough to attend a conference called JSConf, taking place in the US and taking place in Portland, Oregon, run by the most wonderful person, Chris Williams. And I went to this event having heard good things, but not understanding what to expect, because I was used to all these corporate events from the past. 

‍

And I was – I dropped into this lovely place with all these kind people who were being nice to each other, not taking themselves seriously. Not – it wasn’t littered with enterprise sales people trying to get you to sign a contract. It was obvious that the speakers were selected on merit and not based on whether their company was sponsoring the event or not. I had never experienced anything like that before, and it’s almost like – it’s like eating ice cream for the first time in your life. You’re like, “What is this amazing thing, and how can I have more of it?” 

‍

So, without babbling on too much longer, the problem is that JSConf bounces around. They were in Portland that year, but they’d moved on to other places. And it became clear that for me and all my fellow web developers, of which there are hundreds of thousands across the Pacific Northwest, why is it that we have to fly to San Francisco or New York or Ireland or Berlin, to go to a good, community driven full stack JavaScript conference? Anyway, the answer to that question is, we shouldn’t have to. So, I decided to create CascadiaJS, and that was probably a pretty insane thing to do, but- [0:19:26] 

‍

Richard Rodger:  [0:19:25] It is totally insane. Do not start conferences; trust me. [0:19:27] 

‍

Carter Rabasa:  [0:19:28] Yeah, for anyone who’s listening, do not do this. It was – but honestly, one thing that helped me – and I don’t know if this is helpful for anyone who is listening. I had the full support of Twilio, which is the company that I was working for at the time.  They didn’t bankroll the event, but in terms of giving me time and space to work on it- [0:19:49] 

‍

Richard Rodger:  [0:19:50] Moral support. 

‍

Carter Rabasa:  [0:19:51] Absolutely. And not just the company in a – as an anonymous entity. My colleagues, my co-workers, it was – I felt very supported. It was- [0:19:51] 

‍

Richard Rodger:  [0:19:51] Did that go all the way up to the CEO? Was that – did the leadership recognize- [0:20:05] 

‍

Carter Rabasa:  [0:20:05] Yeah, absolutely. It was – this is – it was – Twilio was a much smaller company back in 2012. Having – running – Twilio was a) one of the sponsors for the event. So, the opportunity to get in front of all of these developers in Settle in this way, in this JSConf style of way, with the feel of, this is a community driven event. We’re all here to learn and meet each other and have fun. That was huge for Twilio. 

‍

Twilio had only just started to operate its own first-party conference, TwilioCon, so having someone who worked at Twilio operating a third-party event and learning. There’s a lot of stuff that we did at Cascadia that found its way back into TwilioCon which then turned into Signal. The whole company supported the effort, and we made it. 

‍

It was – I will say I do not think that anyone should start a conference unless you really understand what you’re getting into, but I will say this. The first one is always the hardest, because you don’t have a brand. Nobody knows who you are; nobody knows if they can trust you. You’re asking people to spend hundreds of dollars on the internet for something that they’ve never experienced. [0:21:29] 

‍

Richard Rodger:  [0:21:29] And is it going to be Fire Festival? [0:21:30] 

‍

Carter Rabasa:  [0:21:32] Of course. But the subsequent events are all – they get easier every year. And now, jeez, that was – next year is going to be our 12th year running Cascadia JS, and it’s still a lot of work, but you build a lot of equity with people over time. If you treat- [0:21:54] 

‍

Richard Rodger:  [0:21:54] 12 years, wow. 

‍

Carter Rabasa:  [0:21:55] 12 years, and-

‍

Richard Rodger:  [0:21:55] Congratulations, that’s amazing. [0:21:57] 

‍

Carter Rabasa:  [0:21:57] Thanks. It’s awesome. Every – I’ll tell you this. The day before every Cascadia, I wish I had never done this. But then the day after every Cascadia, I can’t wait to do the next one, because it’s just such a positive experience, for everybody, I hope. [0:22:16] 

‍

Richard Rodger:  [0:22:17] Yeah, you can’t beat that adrenalin rush, when the audience claps for the last time and it’s all done. Would you agree? I notice the sponsors, especially for community events. For me, it identifies companies that have that developer empathy. But on the other side, it’s always a struggle getting sponsors. Do you think it’s easier? [0:22:45] 

‍

Carter Rabasa:  [0:22:47] No. It depends on what we’re talking about. It’s gotten easier over long stretch es of time. However, we all understand that we’re operating in a bit of a tech recession right now. Unfortunately, right now, things are very difficult. A lot of companies are scaling back their budgets. They’re scaling back their budgets across multiple dimensions, they’re scaling back their marketing budgets, which hurts sponsorships. 

‍

Companies are also scaling back their travel and learning budgets for their engineers, so if you’re a conference organizer, you’re getting hit in both places. You’re getting hit in terms of – it’s harder to bring on sponsors, but it’s also harder to sell tickets, because it’s very expensive to put on a conference, which means that the tickets are very expensive. Which means that if the company isn’t paying for it, it’s very difficult to ask someone to pay $6-7-8-900 for a ticket. 

‍

But that’s the truth of how things are right now, but in terms of the trends, the trends are very positive. Overall, companies understand that in general, the ROI on doing sponsorships with high-quality events – and then making sure that their engagement and their involvement with the event is also high quality – that there’s a ton of ROI there. So, I’m very bullish on the long term; we’re just unfortunately in a short-term place that’s not great for everybody. [0:24:34]

‍

Richard Rodger:  [0:24:35] Yeah, it’s one of those years, but software is eating the world, right, so shut up; we’re coming back. [0:24:40] 

‍

Carter Rabasa:  [0:24:40] Yeah, exactly. 

‍

Richard Rodger:  [0:24:43] To close out – this has been super interesting and somewhat more philosophical than I had planned, but very interesting nonetheless. On your journey working for different companies – let’s structure it as in, what are the most interesting things you learned in each company? 

‍

Or what was the most surprising thing about – I’m going to change the way that I’m going to do developer relations, because I’ve learned this new thing. And maybe we won’t restrict it to one per company, because some companies might have more of an impact. But going back to that sort of 2011, 2012 time period, take us forward. [0:25:27] 

‍

Carter Rabasa:  [0:25:27] I’ll be – yeah, sure. First of all, I’ve only done this twice. I did it – I was at Twilio from 2012 to 2017, almost six-year stretch. And then I was on my own, self-employed, raising my family, working on a bunch of interesting side projects, running things like CascadiaJS and some other events. 

‍

And I recently joined Courier as their head of dev rel, just this past April. So, I’ve only had – I’ve only worked at two companies from a dev rel perspective. I would say the thing that I learned, that will stay with me for the rest of my life – and frankly, this is not a dev rel thing, but it’s unbelievably helpful. 

‍

At Twilio, there was this pervasive idea and value at the company about starting with the why. We were – it was explained to us over and over again that there is not an instruction guide for this. We don’t know – there isn’t an instruction guide for how to be a venture backed startup. Even if you think there is, if you can go on Hacker News and read all the blog posts, that’s not true; there’s no instruction guide. 

‍

And in particular with dev rel – developer evangelism, developer relations, whatever you want to call it – there’s no instruction guide. There are no – there’s no examples of other companies back in this time period that are absolutely killing it, and gosh, we should just copy what they’re doing. Stripe was a contemporary of Twilio back then. They effectively didn’t do or have dev rel, and they were incredibly successful. And there’s a lot of interesting questions about why was that and – but it doesn’t matter, right? [0:27:19] 

‍

Richard Rodger:  [0:27:19] Because Patrick would grab your laptop and install his stuff. There isn’t any choice. [0:27:24] 

‍

Carter Rabasa:  [0:27:25] But it teaches you; it teaches you that this is not a recipe. Just because you’re building a developer tool or an API doesn’t mean that you have to have this thing called dev rel, or even break dev rel down into developer advocates and developer educators. It’s just not true. You have to fundamentally understand what your product is, what people are trying to accomplish, how does it work, how do people use it?  What are the problems that they’re trying to solve? 

‍

And then experiment.  Start with the why; start to build some ideas about how can we accelerate people; how can we help people? Is it valuable to have the – to have people build affinity with your product or your brand. These are things that we experimented with and that we played with. 

‍

I’ll say right now about Stripe. The reason that, at that time at least, it wasn’t terribly relevant to Stripe is that there aren’t very many creative things that you can do with Stripe at the top. It’s a – it’s like you type in some credit card information, you hit pay and it works. It works. Twilio was different. 

‍

Twilio was this communications API, primarily voice and text. But with those two primitive little bits of telecommunications, there were hundreds or thousands of amazing experiences and use cases.  And just cool thing of group texting and two-factor authentication and I’ll be – there’s all this stuff that you could build on top of these Legos. And because of that, it dictated what dev rel meant to Twilio and what our job was. How – what did we need to do to help people, to help developers imagine new things and unlock these possibilities. [0:29:33] 

‍

Richard Rodger:  [0:29:34] I wonder is-

‍

Carter Rabasa:  [0:29:34] And – yeah, and that’s just – so, starting with the why. [0:29:37] 

‍

Richard Rodger:  [0:29:39] It’s obvious – you didn’t actually use the word, but the way that you answer why is with empathy. [0:29:47] 

‍

Carter Rabasa:  [0:29:47] Yes. 

‍

Richard Rodger:  [0:29:50] If I just think about all the stuff you’ve said, you’re starting from a place of empathy and that helps you answer the why question. That’s quite inspirational. Working in this field, you often have to deal with leadership that might treat dev rel as just another lead generation engine. And it isn’t quite that, but it sort of is a bit. But it’s- [0:30:22] 

‍

Carter Rabasa:  [0:30:22] Sure. 

‍

Richard Rodger:  [0:30:25] And it’s hard to-

‍

Carter Rabasa:  [0:30:25] I can tell you how I think about it. The word marketing gets a bad rap, because we’ve all encountered really slimy, icky marketing people or marketing campaigns. Phishing is a really evil form of marketing, right? Anyway, my attitude is that out there in the world are people that are having a problem. 

‍

And it would be a wonderful service to them if we could connect them with something that would help them with their problem. It's – the best kind of marketing is the kind of marketing where you’re finding the right person at the right time and showing them the thing that can help them. That is what good, non-evil marketing looks like. [0:31:16] 

‍

Richard Rodger:  [0:31:16] Yeah, and it’s value on both sides; both sides have good value, right? [0:31:19] 

‍

Carter Rabasa:  [0:31:20] But honestly, it’s so – it’s almost silly to imagine anything else. We don’t live in a world of contracts. If I trick someone into signing up for Courier and then a week later or a month later, they’re like, “This is not helpful for me at all,” they will simply stop using the product. 

‍

So, in terms of what I even think is rational for API companies or businesses to do, it’s like, yeah, you want to find people that really will benefit greatly from what your company has built. And dev rel people are responsible for having some ideas on how to reach those people, to be smart about where do developers have these conversations and where do they congregate? That’s part of what our subject matter expertise is. [0:32:06]

‍

Richard Rodger:  [0:32:08] Does that then – to get a little bit technical about it, does that put developer relations above the funnel, above the marketing funnel? Is that – or is it an extra dimension? It’s an extra – is- [0:32:22] 

‍

Carter Rabasa:  [0:32:22] No.  I don’t know. I think- 0:32:24] 

‍

Richard Rodger:  [0:32:22] You dump it all into a funnel. I don’t know. [0:32:25]

‍

Carter Rabasa:  [0:32:26] I just think that – yeah. I don’t personally think so. Part of what folks in dev rel do is contribute to top of funnel, and it’s an important part of what they do. If you spent a year as a dev rel professional in some company and nothing you did led to anybody signing up for your company’s service or product, there’s something – you’re not doing your job right. There’s – that can’t be possible. 

‍

So, I think that – but however, that cannot be all that you do. It is a multidisciplinary role. Most – I’d say most dev rel people that work at small enough companies not to be hyper-verticalized or specialized, are going to – on a weekly basis, are going to be interacting with engineering leadership. Are going to be interacting with support people; are going to be out in the world talking to developers. It’s incredibly multidisciplinary, what you’re going to do over the course of a single week. 

‍

So, part of what you do needs to contribute to what your company is trying to accomplish from a marketing perspective, but it cannot be all of what you’re supposed to be doing. And one thing I’ll say very quickly, because I hear this all the time. It depends on what kind of company you’re doing dev rel for. 

‍

If you are a dev rel professional for Google Chrome, guess what? They don’t need you to get people to install Google Chrome. There are certain companies for whom growth and brand awareness are completely irrelevant. So, if you do dev rel for those companies, that is not something you’re going to need to worry about. 

‍

But you have to have your eyes open. If you go join a series B – series A, series B, series C startup, awareness and signups are absolutely critical to the journey that that company is on. So, the expectation is that some percentage of your time is going to be allocated to helping that company be successful and driving awareness about what they’re building. [0:34:37] 

‍

Richard Rodger:  [0:34:38] I like that, Carter; that’s a really great observation. A lot of guests that we’ve spoken to – and we’ve gone backwards and forwards on this, myself and the guests. How do you measure dev rel and what do you do? And various ideas and various metrics. But this is the first time somebody’s actually said, “Hold on a sec. What’s the company? What stage is it at? How do you” – you can’t just say, “Here are the global universal dev rel metrics best practices.  Off you go.” That’s a fool’s errand. Depends on where you are. [0:35:13] 

‍

Carter Rabasa:  [0:35:13] You have to know what your suite of responsibilities are. And for every one of those individual responsibilities, there are very reasonable ways to measure the performance. And it is – people are fooling themselves if they say or believe that these things cannot be measured. Everything can be measured in some kind of way.  Doesn’t have to be analytics; you can have conversations; you can do surveys. There are lots of ways to get data points. And once again, I have these conversations all the time.  

‍

Don’t – honestly, I had a really bad experience at Twilio, in the first six months that I was working there, where I went to my manager and I said, “I’m not sure I’m happy with this job.” And my manager asked me why, and I said, “I keep doing the work. I keep going to these meetups and sponsoring these meetups and giving these talks. And I’m putting so much effort into it. I’m burning myself out, and I can’t tell if I’m making a difference here at Twilio.” 

‍

My manager’s soliton to the problem was to help work with me to figure out how to tell if I was making a difference. And I’m sharing this story because once I figured out how to measure the impact of what I was having. I didn’t do it so that I could report up to the management chain in order to justify my employment. I did it for me. I did it so that I felt that what I was doing mattered. 

‍

And I would ask people to take that approach to this problem. Don’t worry about justifying your employment. You’ve already been hired. There’s some optimism that you’re going to make a difference. But always make sure that whatever you’re working on, you can convince yourself that it mattered. [0:37:22] 

‍

Richard Rodger:  [0:37:24] Yeah, and if you have that confidence that what you’re doing does make a difference, when you communicate that to leadership it’s going to show. It’s going to be clear that you believe you are- [0:37:36.] 

‍

Carter Rabasa:  [0:37:37] For sure, but you have to do the work. It has to be – it can’t be – I don’t know; I think it worked. You have to do the work to convince yourself. If you can convince yourself that this is making a difference. Or by the way, the other thing that is completely valid is, this is not making a difference and I’m going to stop doing it. Both answers are great answers, just the fact that you figured it out. 

‍

And so, you can put more fuel behind the thing that is working and you can stop doing whatever the thing was that wasn’t working. These are good, healthy things for people who are doing dev rel, and it will help you with all of the conversations that you’ll have with the company about why are we doing this. Should we add more head count to – all of those things. [0:38:26] 

‍

Richard Rodger:  [0:38:28] Carter, I asked you what was – what were the important things that you learned? That’s the most important one. Measure for yourself; you know it matters. Awesome. Thank you so much. This was super philosophical, which I love, and historical, which is great. So, it’s all for the – this is one for the nerds. Thank you so much, this has been super fun. [0:38:51] 

‍

Carter Rabasa:  [0:38:52] Of course. No, thank you so much for having me. I’m – I got into dev rel later in my life. I was in my mid – my early 30s when I discovered dev rel. And in the previous 22 years of my career, I wasn’t happy. I was a person who was good at a few, good at some stuff, but casting around, looking for something that felt like it was the right thing. And I’m really glad I found it, and I definitely hope that more people discover dev rel and give it a chance. Because it’s a really special kind of job to have. [0:39:31] 

‍

Richard Rodger:  [0:39:32] Yeah, it is. It’s a fabulous career. If it works for you, it really works. Carter, thank you so much. Take care, bye-bye. [0:39:38] 

‍

Carter Rabasa:  [0:39:38] Awesome, take care. Bye-bye. [0:39:40] 

‍

Endnote

‍

Richard Rodger:  [0:39:41] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0.40.10]