What even is a DevRel?

Alright, we have Lee Robinson here from Next.js, from Vercel…

Hey.

What’s up, Lee?

Thanks for having me. I’m really excited to come on and chat.

We’re excited to have you. Now, I only ever have known you online as @leeerob, which is a bunch of e’s… And I’m curious if Leerob is just your online handle, or has it trickled into the real world?

[laughs] It’s really funny, the first time I heard someone call me Leerob in real life was kind of funny. The breakdown of your online persona into your real persona actually happened…

True.

The context there is, you know, my name is Lee Robinson, LeeRob is the combination of first and last name. I tried to find some kind of online handle that was unique, and it also related back to the domain name I was trying to grab. I have leerob.io. My friends call me Lee, my co-workers all call me LeeRob, but it really doesn’t matter ot me.

It doesn’t matter. So Adam, do people call you AdamStack?

I think there’s a few, yeah…

I think I’ve called you that before probably…

Yeah. They don’t often call me AdamStack, they’ll call me like Stack; something with Stack. My nickname will either be Stack, or Stacks… In the military it was Stacks.

Does anybody call you Daddy Fat Stacks?

Um, no…

[laughs]

I might like that thought.

That’s kind of a cool nickname, I think.

Daddy Fat Stacks…

I might start calling you that.

Does that mean I’ve got mad money, or what?

That’s the hope, yeah.

[04:12] You’ve got fat stacks.

I’ll take it, yeah. Whatever the stack I’m stacking, it’ll be fat.

Well, we’ll just leave that right there, where it sits…

So LeeeRob is with three e’s, is that right? That’s your Twitter handle, at least. LeeRob.io is not three e’s, it’s just two e’s.

Oh…

Yeah… Somebody on Twitter scooped up the –

There’s a chink in the armor.

Yeah. That’s the only one that I don’t have it. And the person who has it with two e’s, the account is suspended too, so I can’t even…

You can’t even get it.

You could petition for that, I’m sure.

Maybe there’s a way.

If you get that blue checkmark, you could do whatever you want.

That’s right.

Yeah… I don’t know. We’ll see.

You’re on your way. Listen up, if you’re a Twitter employee, hook up Lee. Let’s get rid of that third e. It’s just –

It’s cleaner.

Let’s compress that thing.

That’s right. It’s like dropping the “the”. We’ve been there before.

Why we have you here today - we should mention that you are not just a DevRel at Vercel, you’re director of DevRel, which I assume is even cooler… And we wanna talk about DevRel. We had a listener write in - now, I believe his name is Gustav [unintelligible 00:05:13.22], but I’m gonna give Gustav a little bit of a hard time, because on our form where you request a show we have another section for on-air credit, where you can actually put the pronunciation of your name. And Gustav just put his name twice, so… [laughter]

“They’ll get it. They’ll get it, don’t worry.”

So I’ll usually apologize for mispronunciations… I’m not gonna apologize this time, Gustav. You had an opportunity to help me out, but you didn’t. Nonetheless, he asked to have you on the show; he wanted us to talk about DevRel. We talk to DevRels a lot; we talk around DevRel a lot. We never talked about developer relations as a thing… So that’s why you’re here, Lee.

Ever.

No.

I mean, ever. 13 years of history. Zero discussion of the actual title/anything. I mean, nothing.

Right.

Really.

So we’ll ask you, and you can open it up - what even is a DevRel?

Yeah, the meta conversation of what is DevRel, yeah. So the way that I run my developer relations team focuses on three different things. The first is around education, the second is around community, and the third is around the product. Now, the way DevRel teams or organizations are structured at companies kind of depends on where it falls in that company’s priorities… So for a developer tooling company, where their bread and butter, their main focus is talking to developers, it’s probably gonna have an elevated position in the company, because it’s incredibly important to their business and to their community. Maybe if the company is just – like, they have an API as part of their products, but that’s not the main thing they do, they might have a developer relations team who’s helping with the adoption of that API, and ensuring that people are successful with it… But it’s not the main thing.

I like to give that caveat, because it’s hard to give a singular definition of what DevRel is, but there’s multiple flavors we can be inspired from for teams who are trying to figure out “Okay, how do I wanna get into this space, or how do I wanna structure my organization to support developer communities?”

I talk to a lot of startup founders, early-stage companies who are talking to me about “When should I hire a DevRel? When should I hire these people to build our communities or to help educate developers” And it gets tricky, because not all companies are the same. It requires a little bit of nuance to dive into there.

[07:54] So to reel it just a little bit back to the three pillars I talked about, of education, community and product - I can dive into each one of those independently. Let’s start with the first one, of education.

Vercel is a company that’s like a frontend platform; you can deploy your code, build and deploy code, host it around the world. And because of that, we also have frameworks like Next.js, that allow you to write your code. So the nature of the products requires education. We have to teach developers how to use these tools. It’s not always immediately obvious how you would build a global application. Maybe you need some guidance along the way. And I think that education for developers is deeply rooted in basically everything we do.

As we got started learning how to code, education was important, and being a lifelong learner or a continual learner is so rooted in the development journey, especially for web developers, where the types of technology go through cycles, and you’re learning new things over the years, and kind of iterating on your knowledge and learning new techniques…

So it’s important that you’re helping guide developers along the journey, and teaching them the tools and the tricks that they need to be successful with the product.

The second pillar I think a lot about is community, because it’s harder to replicate a community. You can purchase a product, you can acquire an audience, but that doesn’t automatically mean you have a community. Community-building requires dedicated effort and attention, and I think it’s one of the highest-leveraged things a developer-focused company can have.

If you have a community of developers who love your product, they kind of do the job for you. They advocate for your product for you. They’re your outsourced DevRel team at that point; they’re talking to the community about “Wow, this product is amazing. You should be using it.” And they love it so much that maybe they go talk to other developers about it. And being very intentional about growing that community is a very important part of what a lot of DevRel teams focus on.

And then the third, in just a quick summary… The third one is really how it all relates back to the product. And I think it’s important that developer relations roles, or developer experience, or developer advocate - there’s multiple titles; we can get into that nuance… All of these roles play some part in giving feedback on what works well, and maybe what’s not very good on the product. And I think it’s important to get that feedback internally before you hear it from your customers. For example, if we’re releasing a new product or a new feature, I would rather have some engineers internally who have this critical eye for what a good developer experience looks like walk through the product, try to figure out how things could be broken, where beginners might struggle, where advanced people might struggle, and get that feedback before we release it to everybody. And there’s this continuous feedback loop of community pain point, how do we solve it, and the product. Community struggle - how do we better create educational material to help prevent that from happening in the future?

Mm-hm. In a lot of ways it’s a very nuanced dance between how to innovate and iterate, and how to literally educate, but then also take that feedback. Because that feedback assumes, and sort of requires this person or many people to have empathy for the direction the community is trying to go.

Yeah.

And I think in particular - because we kind of know Vercel’s story, and we should also say we have Vercel as a sponsor of JS Party… Not a sponsor of this show in particular; that’s not why you’re on this show. We truly are deeply – I’ve know Guillermo for many years… Guillermo. I’ve been recently told that’s exactly how you say his name, but I’ve been calling him Guillermo for many years, incorrectly of course… Now I’m just gonna say Guillermo every single time.

[12:09] But I’ve known him many years… Jerod, you and I met up with him in San Francisco years ago when we went out to just meet up, and we shared the early days of our website, and the direction… So he’s been in the community forever, for a very long time, and I’ve been tracking his career, and we have, as an organization… But when you have the inertia of Vercel being “Make the web faster”, that’s the direction of your product. So you’re gonna kind of pull community, because you’re trying to innovate and iterate the literal web, and the way you do it is with your platform, and the way you also do it is with your software, that enables a platform… And the community that wants to build for the web.

The point I’m trying to make though is just that it’s pretty interesting how you have to have this dance, and this empathy, and this sort of middle ground people that care, to enable that feedback loop; it’s necessary. What gets challenging is when – and in your case, the organization is set up right. The way you’re directing is right. What gets sort of like hard to believe or hard to trust is when there’s KPIs, and OKRs, and sort of like salesy things attached to that organization. Where do you sit with that? What has been your experience with other DevRels that have these ambiguous, weird attachments, like OKRs, and KPIs, and sales-related goals attached to that feedback loop that’s so necessary for a dev-focused organization like Vercel?

Yeah, going back to the first part of your question, around empathy - that’s actually one of the most critical things that I look for when I’m trying to hire people… And I think it’s what separates great developer relations teams from maybe those who are just okay… Is that you have to really care about the product that you’re advocating for, and the community that you’re a part of.

When I see people struggling with the product, I genuinely wanna know what we can do better and how we could take that feedback and use it to provide a better experience. And you have to address that with an empathetic, beginner’s mindset, because not everybody has the context that you might have on years of using the product, or years of being a frontend developer or a backend developer. You have to embrace that “This is my first time learning how to code. Somebody told me I needed to learn Next.js. Now I’m reading the docs. What is this thing? I’ve never heard this term before?” And trying to solve for that case as well, too.

Mm-hm.

But then coming back to your question about how do you define and measure success for developer relations - there’s a few good resources out there right now that I’m fond of, and I think part of this question ties back to the organizational structure that sets up a DevRel team for success. For example, if a DevRel team is under product, if they’re under marketing, if they’re under sales, if they’re under their own organization, those KPIs and metrics might all be a little bit dfferent. I think Swyx has a good blog post about measuring developer relations, taht I recommend checking out for those listening in.

My view is that I’m not a big fan of the vanity metrics, like “This got 10,000 blog post views.” Or “This got 200 retweets.” Those are a by-product of making a good product and fostering a good community. So if you invest in listening to your customers and where they’re succeeding and maybe where they’re not, taking that negative feedback and incorporating it into building another product and a better experience for those developers - the by-product of that is the attribution towards more blog post views, more tweets, more engagement on Facebook, or LinkedIn, or whatever social platform you want.

[16:01] So personally, I don’t think it makes as much sense for me as the North Star of the metrics to look towards those traditional marketing-focused KPIs, I guess. I do think it is interesting to think about some of the sales goals, because at the end of the day, you’re building a community of developers who are excited about a product. And that product is probably something that you pay for, and I don’t think that you should be too abstracted from the reality of “This is a product that people pay for.”

I think if you go too far in the other direction, you’re actually doing a disservice to your community, because you’re almost being disingenuous about the reality of what makes the business sustainable.

So in the content of like a Vercel or a hosting platform, we have a free tier. There’s always a free tier. It’s always gonna enable developers to get started, build applications, and be able to put content basically online, around the globe, really fast. And that works really great for many, many developers.

But then there’s also a part of our business that’s catering to teams that pay, whether that’s customers on like our pro tier, or enterprise customers. And I think you’re also enabling those developers, because they’re also part of your community. Just because they’re on an enterprise deal doesn’t mean that they’re not deeply embedded and care a lot about the community’s success.

It’s interesting to see this role formalized, so much so that you have a director of the role, and so you have a fleet of DevRels. I’m sure Vercel is not the only organization that has multiple DevRels, fleets of DevRels.

Yeah.

It feels like a new(ish) thing. I went to Wikipedia, did some reading, and it turns out no; Apple invented this back in the ‘80s. They called them software evangelists back then, and it was kind of this thing that’s evolved and changed over time, and become more formal, become more obviously valuable for organizations to employ this type of a role or this set of roles, which really is, like you said, community, education and product, three distinct things that all work together.

I’m curious of your history though… How did you get into DevRel, and what made you attracted to this kind of a role, and then also good at it? Why would you get moved up to director of DevRel unless you were good at it? …so I assume you are.

Yeah, so what got me into DevRel was actually a long journey. Prior to joining DevRel I had been working as a product engineer for many years, and primarily focused on the frontend. And I’ve always really loved frontend development. When I Was learning how to code in college or university, I didn’t really enjoy it until we started to use web development, and that was when I had this light bulb moment of “I can put code online and share it with anybody behind this URL.” I looked at mobile apps and I was like “Wow, this process is overly complex, versus just deploying and getting a URL and having it out there.”

And for the first good chunk of my career I was really focused on just becoming the best frontend developer I could possibly be. So that was going from individual contributor, to leading a team of developers working on an e-commerce site… And at the same time, I’ve always really enjoyed the intersection between development and everything else that needs to happen at the company… Which is ironic, because I haven’t worked at a startup until I worked at Vercel.

So I had seen some examples of how it doesn’t work well, when the development team is so siloed away from the other parts of the business. I get a lot of enjoyment out of the intersection between development, and marketing, and sales, and product, and all of these pieces that actually enable an end-to-end great experience.

[20:04] So that’s some of my history that’s led to me exploring what was DevRel before I knew it was DevRel. Because of my enjoyment of the intersection between these things, and just a general enjoyment of helping teach others, whether that was writing, or in-person, helping pair with other developers - I started to kind of just create content and put it out there as my own person, as LeeRob. I put out content online to help developers succeed with React, or frontend CSS, Next.js, whatever they wanted to use.

And it was towards the relative beginning of Next.js… I think Next.js was created in 2016, and in about 2018 is when I was starting to use Next.js at my previous company to help them build out their e-commerce experience. And at the time - you know, with any new tool there’s just not that much information out there, or educational material to help developers succeed… And I thought “Well, I enjoy doing this stuff. I like writing. I like teaching developers how to succeed with this stuff. If this content isn’t out there, why don’t I just make it?”

That’s the great thing about the internet, is that it’s permissionless. I can publish that blog post if I want to. I can create that resource. So I did. I started making content, YouTube videos, blog posts, all sorts of stuff, courses to enable developers to really succeed… And eventually, that wound its way towards me getting a job at Vercel to kind of further continue that goal.

Mm-hm. A keyword you’ve said there a couple times is “succeed”, which I think is kind of critical to defining that DevRel role well, because – like you had said, you can’t hide the metrics of let’s say a sales goal, or something like that. Maybe that’s where it can get a little bit tricky, but being able to succeed in terms of helping the developers succeed. That’s kind of key, right?

Yeah.

Which is naturally gonna lead to a business success. Succeed again. Because that’s a natural feedback loop to positive outcomes. That’s kind of critical to the role.

If you think about it like this - it doesn’t matter if you spend millions of dollars on marketing; if the developer goes to the blog post and they say “Alright, click here to try it out”, and they go try out the product and it just doesn’t work, then what are we doing here? What was the point of all this?

Precisely.

What was the point of all this work? It has to be in service of the success of the developer. And that’s a very nuanced thing too, because it’s not always just “Was I able to get X thing done?” It also might be “Did I understand what I’m doing? Do I understand the context of this? Am I actually using it for the right thing? Am I providing the right resources to help this developer succeed with what they’re trying to get done?”

It kind of reminds me too of this inspiration of curiosity. There’s times I’ll have this really cool tool - I’ll be ambiguous in this case - and I have no idea what to do with it. I know it has lots of capabilities, but I’ve got my own use cases, but I’m sort of like siloed and minimized by my own dreams, I suppose. And I almost need somebody else to help me dream bigger about the possibility. “Oh, did you know this, this and this could enable THAT?”

Yeah.

So you’re almost like a curiosity inspirer, and I almost think of it like – a good analogy might be a box of Lego. You can get a box of Lego and you can watch Lego masters on TV, and what they do with Lego may be way different than what you would do with the same box.

Yeah.

And it might be that rel person, the DevRel, or the LegoRel, or somebody Relling in there, this inspiration, this curiosity. “Here’s the possibility, what you could do with this thing.”

And then also - and that might be the sort of community content piece of it… But also, how do we learn from what you’ve done with it and hit those roadblocks, or hit those anti-successes, those failures, and how can we improve the flow, so that you don’t have that hurdle, that roadblock anymore your next try?”

Yeah, absolutely.

Let’s go back a bit and talk about how this role has evolved… So not Wikipedia, 19-whatever; I can’t go back that far personally. But we’ve been around as an organization since 2009. Changelog began around then, we’ve been doing this 13+ years, so our lens is around 13(ish) years or more; not 25 or more. So I would say early DevRels that I’m aware of, the earliest might be - and this is by no means an exhaustive list. These are just closer friends. Steve Klabnik was part of the Changelog way back in the day. He used to be a host, he used to be a contributor to the blog. The same with Kenneth Reitz, who was also a contributor, a host on the show etc. And my experience with those two in particular was this level of burnout, because the role kind of – it did what you said, but it also kind of required a lot of speaking, a lot of real direct IRL engagement; that meant flying, that meant international flying in lots of cases…

And then when JS Party came around, we had Rachel White on the show, @ohhoe, as she’s called on Twitter. She’s also a DevRel. I don’t know if she still is anymore; I haven’t caught up with her in a bit… But similar - this sentiment of burnout, like always going kind of thing. Let’s kind of go back and maybe share what your experience might be with this role and how it’s evolved. It seems to have matured, and maybe thanks in a spiteful way to Covid, that now we don’t travel as much; we’re kind of getting back to travel. This role sort of calmed down a bit, and maybe even had a chance to even reshuffle. What is your experience of old days DevRel, to current, modern-day DevRel, and how has it changed?

[28:01] Yeah, so to first set the stage, I have been officially, by my job, doing DevRel now for two years, and then unofficially probably since 2016, I guess. But if we go back to 2011, 2012 – so I started to learn how to code in 2011. And at the time, the DevRel that I really remember was from the new API companies. It felt like a generational change, or a big enough shift in the industry that it required education and awareness to tell people about a different way of doing things. And from my eyes, that was like 2011 to 2015. I feel like there was a massive rise in the number of API companies, or companies providing things as a service. And to do that, they had these members of their community, whether it was called DevRel or not at the time, actually go out, go to in-person conferences, go to meetups, go to anywhere around the world and tell people about how the product works, how the thing works, do a workshop on how to actually use the thing.

And at the time too, another thing I’ve realized in talking to a lot of teams is a lot of DevRel actually came from founders back in the day. The early employees that companies were essentially doing the majority of the product and community side of DevRel. And then eventually, it scales to a point where they have a full-time job to do that.

At some companies that actually turns into the product org; the PMs are just very good about that outreach, and then at some developer-focused companies they really lean into DevRel for that stuff.

So if we fast-forward a little bit and get closer to today, I think the thing that’s been really interested kind of pre-Covid/post-Covid that I’ve seen was the community understanding that virtual or online has a place, if done right. And I think the distinction there is it has to be done tasteful and respectful of people’s time.

I’ll give you an example of where maybe people are a little burnt out about online… Of course, everyone was sick of going to many virtual events, many conferences online in the past few years, and if you were going to do any sort of developer outreach or socializing with your community, it had to be something unique to make them feel like it was not just another Zoom call. And an interesting side effect of this, looking at purely from the viewership or the amount of traffic that you got, a lot of teams realized “Wow, we can actually get more traffic by doing this online. We have a global community. Instead of doing just this one event in New York, or San Francisco, or London, we can actually broadcast this everywhere and be inclusive of our entire global community. We don’t necessarily need to do 57 meetups to get this community activated and engaged.”

And also, you mentioned burnout, I guess, of developer advocates or people who were traveling for their job - it could definitely be a strenuous position to have to basically just go around all year, living on the road, giving conference talks, going to meetups, interacting with the community… Especially – a lot of those people too, maybe that was a viable thing for them to do at that point in their life, in the 2012 era… I think a lot of the original DevRellians, the DevRel folk have kind of evolved into something else.

[32:00] A good example - somebody that I look up to a lot is Kelsey Hightower. I think that he has a very interesting role now, where he is kind of like – he’s evolved from DevRel, and he had obviously done a lot of stuff before doing DevRel, too… But to somebody who really holistically thinks about an incredible product experience. And I think if you look around the industry, some of the other people who were well-known in DevRel - a lot of them have transitioned to do other related things, still in the same arena, but with a little bit more focus.

So the summary of all this is that when I look at DevRel in 2022, you don’t necessarily have to fly to every conference in the world, you don’t necessarily have to do a hundred meetups. You can be a little bit more strategic about when and where you want to do those things, but as we start to now get back to doing in-person events, which I’ve now spoke at (I think) four this year so far, and I have a few more coming up here in the next couple months… So it’s definitely picking up.

There is a reappreciation of just getting people in a room together too, that 1) I think people just missed because of not being around others, in a setting, for some time… But also, there’s something to be said about getting together and just having a casual chat about development stuff. Just talking about tech, talking about development. Sometimes it’s hard to recreate that spontaneity when you’re in an online event.

So I guess my philosophy and where I’m kind of taking our DevRel team is that I wanna do both. I still think there’s a place for – you know, when we have a global community of developers, it’s not feasible for me or others on my team to be flying around the world all the time, to go to a bunch of events. And I know that some really large DevRel teams solved this by having lots of employees all around the world. We’re not there yet. But I think there’s still a place for in-person as well, too. So we can have online, and we can also still go to some events and conferences.

My experience with the online events - and I only took part in a handful of them throughout the two years starting at lockdown - was you get big numbers, you get big sign-ups, you might even get big numbers in the actual room… But the level of attention and engagement, even for myself personally; I’m in the room, I’m signed up, I’m there… It’s just another tab in my browser, or it’s just another Zoom window… I’m also playing Wordle or something… I just don’t feel any connection, really. Even less so than this three-person call right here. Because I don’t have to participate, or maybe I can, I can raise a hand… I don’t know. It was very superficial. But obviously, it was necessary. And the point you spoke to with the accessibility of everybody - the lower barrier of entry for people who live halfway around the world from where a real-life event would be help, or whatever reason; the timing, their lives… It allowed everybody to come, which was awesome, but once we were all there, for me it was kind of like “Meh…”

It fell flat.

So I’m very excited about getting back out. And obviously, I think what we learned is hybrid is awesome moving forward; trying to find the best from both circumstances to bring them together for better events… And then I liked your idea of like “Hey, make it when you can. Don’t kill yourself to be there at every conference”, right?

Because I think that’s what really burned out a lot of folks in the beforetimes, was this desire to be at everything, and speak at everything, and blog all the time, and there was just no end, in their mind, of the workload.

[36:01] I think also too a tricky conversation to understand in the world of DevRel is the distinction between the individuals and the companies.

Yes.

And we can really go in-depth on this. The way I think DevRel is evolving is the people who are taking these roles are almost like knowledge athletes. I’ve heard these analogies made in other places. I don’t really have the best way to describe it, but basically, they have their own thing going. They have their own brand, or whatever you wanna call that, of their own community, of people who care about what they say and how they act. And part of that affiliation is also representing a company sometimes.

So if you give a sports analogy - maybe I am a professional basketball player who happens to play for the Atlanta team right now. But then maybe in the future I get drafted by, or I change teams to New York. That happens. That’s just the nature of how people change jobs.

And I think it’s interesting when you think about DevRel, because the role is so public-facing. These are people who are advocating for your company. They’re out talking on podcasts, they’re out interacting with communities. So for that person to be kind of like a professional athlete for a company, it requires a little bit of nuance in how you work.

Because you kind of care about their opinion, right?

Yeah.

Like, they’re good at what they do because they can curate the possibility and whittle it down to a point of focus… And that’s kind of the employment. The employment is sort of the point of focus. “I care so much about the future of the web that I decide to put my focus and my attention on the Vercel platform”, as your direct example. In Kelsey’s case maybe it’s Google with GCP, or the direction of Kubernetes… And as you had said, he kind of transcended, and I think he has as well.

What I love most about Kelsey is his ability just to look, like you said, holistically at the scenario, and not think like “Should you buy Google or should you buy a direction?”

Exactly.

“Here’s how software is evolving, here’s the way I think it makes sense for you to use it, and we happen to be putting products in place that help you use it that way”, kind of thing.

Yeah. And I think what’s important about that is when you start to get in situations where – like, people will ask me my opinion on something because of my experience with the frontend. And sometimes that answer is Vercel, because it is the best choice for what they wanna use. And sometimes it’s not, and it’s disingenuous if I were to not give that response to people.

Right…

But I think it’s hard for some companies to realize that’s the type of role that this position is. It’s not necessarily a paid spokesperson that’s gonna advocate only good things for the company. I’m very well aware of what’s great about our product, and what needs improvement. And I hear that feedback from the community, and I take that and I try to translate that into making the best product. But if somebody asks me “What’s the best way to do this, this or this?” I try to be as honest as I can, because that’s how you build trust with the community.

Do you personally struggle or wrestle with that relationship where your work is so much tied up into your identity or your personal brand, so to speak?

Yeah.

Because some of us are out there, coding for a healthcare company, and it’s like, “I care about my work, I’m a craftsperson etc. I’m a software developer, I do my 8-to-5, or maybe I work harder, or whatever it is… And I care about my work, and I take pride in it, but at the end of the day it’s like a healthcare company, I want it to do well, but it’s not my identity.” And I think as a DevRel almost necessarily it gets tied up in your identity, because you are promoting this thing…

[40:07] Yes!

…or representing, I should say, maybe more so than promoting… And so like you said, it’s very gray lines, and I wonder if you struggle, like “Where does Lee end and the director of DevRel at Vercel begin?”

Yeah, I think that this is why DevRel requires a very specific type of person, and why I also would recommend for anybody listening thinking about wanting to get into DevRel - you should be picky about the thing that you wanna advocate for. I don’t think that people wanting to get into DevRel will be satisfied trying to advocate for something they don’t genuinely care about. Or for a space that they’re not really interested in.

If I went and did developer relations work for some other kind of unrelated part of the development workflow, I could probably do it, but I wouldn’t have as much enjoyment out of it, and I wouldn’t feel as aligned with the frontend. I just love the frontend, that’s what I’ve always enjoyed doing - the intersection between frontend and design.

But to your point about the barrier or the line between Lee as a person and Lee as a representative of the company - it can be tricky when people will send me a tweet asking for something… “Hey, why does this Vercel feature not work?” or “Why does this Next.js thing happen? Can you help me figure that out?” It can be tricky to –

You’re like, “I’m watching Stranger Things, y’know? I’m trying to take my dog for a walk”, or these other things, right?

Yeah. Especially when I talk – my wife comes home from work, and just never thinks about it again. I’m like, “That’s awesome.” Sometimes I’m thinking about something, maybe before I go to bed, I’m thinking about “Hm… You know, I wonder if we could do this thing better.” It makes it a little harder to turn off, so that I have to be very intentional about how I do turn off. I have to make sure that I take time to step away and to close the laptop, close the tweets, and just have separation, too. Because you have to be intentional about it, so that you don’t burn out.

Right.

Because having that healthy breakdown is important.

What you sound like right now, Lee, is you sound like a business owner. Because as a person who’s owned businesses - Adam, you can speak to this… The turning it off part is the part that we all as business owners struggle with… Just because you’re not 9-to-5 doesn’t mean you’re not thinking about the business. And that’s very much what you’re talking about.

Now, as business owners we also own the business, and so in that sense – I mean, I’m sure you have access to/part ownership in these companies, but it sounds like maybe that leads to some of the burnout, because there’s a lot of the downsides of being attached, first and foremost or in the front of an entity, without some of the perks of the ownership… Which we could also speak to as well. But you definitely sound like a business owner when you’re talking about this.

That’s why I think that the best DevRel for early-stage companies has to start with the founder. It has to start there.

Totally.

They have to learn – whether they do consulting or they learn themselves, they have to figure out how to be that person first, before they replicate themselves with somebody else.

But to your point - yeah, it would be harder, in my opinion, to do DevRel, to be a DevRel leader at a company where you didn’t have a stake in its success. That’s one of the nice things about a startup and getting alignment in that regard. Granted - sure, you could have a lot of stock in a public company, but it feels like you have a little bit more say in the startup ownership.

[44:04] But you make a valid point, which is it doesn’t always have to be like that for individuals in DevRel. So maybe not a DevRel leader, but to somebody who is doing advocacy work, they maybe can not think about it as much, because they’re not defining direction for how we talk about our products.

Right. I’ve been thinking about your athlete technology, because this definitely lines up, to a certain extent… Where it starts to break down, especially with like an NBA player, is a lot of the places where they play - okay, there’s contractual agreements and stuff, but it’s kind of over their head; it’s like, “Well, I landed here. I play here. I’m gonna speak well of the place, maybe.” But it’s just like “This is where I play now. I’m gonna go play my best game.” Whereas as contracted, self-governed entities humans that we are, it’s like, you’re there because you wanna be there 100% etc.

My point there is I think the mobility for a DevRel is even more fraught than it would be for a professional athlete, whose job is to play the game. Because your job is not just to play the game, it’s actually to pick what’s good and represent what’s good. People trust your opinion, your taste, your curation, your focus… And so I think the mobility is troublesome, because like if Lee was at five different businesses in five years… It’s like, “Well, are these all amazing, or is it just tough to hold a spot, or…?” We know that in software the best way to move up oftentimes is to not go vertically in your same org, but actually switch companies. You’re gonna get more money, more benefits etc. It’s the smarter play. But for DevRels maybe that backfires.

Well, there’s two things there. One, because DevRel is such a public role – it’s kind of hilarious, I didn’t really think about it until I was actually involved with it… But it’s “How would you discretely talk about your job hiring process?” I’ve talked to a bunch of people in DevRel - it’s really hard to do. A lot of these companies talk to each other, too. So they’re gonna know if you’re interviewing at another company for the public spokesperson of that role.

Right. Yeah, good point.

It’s kind of obvious at that point. So it does make it tricky, I think, for DevRel leaders who are looking to move around, depending on what level they’re at at the company…

It’s a challenge.

Yeah.

So Lee, obviously, it’s been a journey for the role, it’s been a journey for you… And I think one thing that we’re very keyed in on is listeners-first. So listeners - hey, we love you, by the way… But we do this show because we know our listeners have a curiosity for certain aspects of the process of creating software, the direction it goes in the future, how to innovate, how to iterate… But we also have to adopt great tooling. And as part of that, we have to listen to certain people a.k.a. DevRels and folks like you. The question it becomes is how do we trust those people? How do we trust who we’re hearing from? I don’t even know what question to really ask you, but more like just the layer of trust - how do we trust folks like you? How does that work?

Well, when you’re hired to say a thing, and then you say the thing, and then it’s like “Well, are you just saying that because you’re hired, or not?”

Precisely.

And I think good DevRels - they earn trust, and other ones we’re like “I don’t know if I trust this person.” So your angle into that, Lee. Let us know what you’re thinking.

Yeah, there’s an observed pattern of someone in DevRel where you can kind of get an understanding of “Is this somebody that I can trust?” And I think it comes back to “Are you willing to admit when you’re wrong, publicly? Are you willing to admit when your product might not be the best case for something? And are you willing to advocate for something else, if necessary?”

[50:24] And that last one is painful. It’s painful for a company to think that you would hire somebody that might not always preach for your product. But great DevRel teams with great founders, who have trust in their DevRel teams, understand that the best product should win. If our product isn’t better, I don’t want somebody selling me snake oil for something that’s supposed to solve all of my problems. That’s disingenuous to the company itself and to the product itself.

Something that I’ve noticed really great DevRel leaders and teams do is they are very aware of when you should use the product, and they can also give just as compelling of a pitch of when you should not use the product. Because so much of software evaluation and purchasing comes down to knowing what trade-offs you’re making and knowing the constraints of how you’re building your system. And if you arm developers with the confidence to know when it’s the right tool and when it’s not the right tool, you’re passing along the knowledge they need to advocate for your tool.

This has been observed with Guillermo in particular. He’s been on Founders Talk, he’s been on this show before, he’s been on JS Party before…

Yeah.

…and we’ve had many conversations with him way before it was even Vercel. Before it was even ZEIT. Like LearnBoost days, back in the day. Early tools for Guillermo, for example.

Mongoose, right?

Yeah, just lots of different history with Guillermo.

HyperTerminal.

HyperTerminal… Yeah, that was ZEIT days.

Still around. It’s still being used.

It’s still out there?

Yeah.

I thought that might have been pre-ZEIT, but okay. Fair enough.

Yeah. It was early days of ZEIT. I think maybe even early Next days even, too. It was a while back. The point is, I think he’s a great example of a founder who has done the role, just by nature. He wasn’t even DevRel, he was just founder. He was just idea creator, inspirer, “Follow me, this is the way to go. I believe in this way”, that kind of thing. And many people have obviously followed him through to make Vercel the success that it is today, to employ you and many others to do the role you do; a lot of engineers making Vercel what it is today.

I think Guillermo is a great example of someone who has done the role by necessity, and then also being able to pass that trust on to you all… That’s challenging. It’s not like you get that every day. But Guillermo began as developer, turned CEO, which is also (I guess) more common these days… But I would say that Guillermo is more of a unique individual, let’s just say.

Yeah.

Very unique, because he’s so capable, and so well-spoken as well.

A developer to CEO, but also a developer who really understands how to build a great product. And the core theme of DevRel I talked about, of being empathetic - I think he exemplifies that as well, too.

Totally.

You’ll see him in the trenches, talking to customers. “How can we make this better? We wanna know your feedback on how we can make this product the best it possibly can be.” I think that transcends throughout the entire company. We want our entire company to be thinking customer-first. How do we do everything at Vercel in the service of our customers being successful?

That word “success” keeps coming up, and I think that’s kind of core, because you said the reason why you got into it was because you saw lack of documentation, lack of education to enable developers to have success on the frontend. And that obviously is just sort of part of it, but this word success means like you care. And this role is very similar in nature to sales. If sales is done right, it’s to help.

[54:06] Yes.

One of the things I get to do here in our organization is I get to really help us partner with the right brands. That means selling ads, basically, at the very basic premise, but really, it’s like choosing the right horses to attach ourselves to. It’s maybe a bad analogy; Jerod, help me out if I’m butchering this… But you know, there’s certain brands you wanna work with, and there’s certain brands we don’t, because we see where they’re trying to go, what they’re trying to do for developers, the kind of future they care about, the way they involve themselves in the community… And we do choose. We say no often. And it’s back to that “I can trust a DevRel if they know when to tell me it’s the right thing to use or not.” But this idea of success really is rooted at desiring to help people, which is crucial to having trust.

If I can trust Lee to be someone who wants to help me… Maybe you should make that a shirt, “Lee can help me…” [laughter] You know, just truly want to help me. Because that’s what it comes down to. In our business, when I speak to the different folks who wanna partner with our brand, and do what we do, and share their brand with our audience and whatnot, it comes down to “Can we actually help them? Do we wanna help them? Do they speak the right way? Can we actually truly help them?” And really, it’s like, if we can help them, I want to help them. And I didn’t say “Sell them”, I said “Help them.” If we can help them, I wanna help them. The word “help” and success kind of go hand in hand there.

Yeah. Help them succeed.

Yeah.

So obviously, this empathetic desire to help others succeed in a specific domain is key here to being a good DevRel. What are other things you look for now that you’re probably hiring DevRels? If a listener is out there thinking “This sounds like a pretty cool thing to do, lots of fame and fortune to be had, maybe I could be a DevRel.”

True.

What are the traits? I assume some sort of technical writing skills… Give us some of the basics of like “Well, you would be a good DevRel if…”

Yeah, I like that Jeff Foxworthy “You might be a DevRel if…”

There you go.

Yeah. You mentioned technical writing, and I would rank that up there as one of the most important things, close to empathy. Specifically, it’s writing and communication, because so much of our role is interfacing virtually and in-person through written communication, that the more succinctly, the more clear you can deliver your message, the better off you’re gonna be. And that’s just in the comms, that’s not even talking about the educational material.

If you’re creating educational material - of course, it’s blog posts, video scripts, any of this stuff. The more well-written and polished and clear that can be, the better your content is gonna be. So the written element is extremely important, because great writing usually comes from great thinking and good, refined thoughts, and working through the drafts that maybe weren’t as good. So that’s something I definitely look for a lot.

An up-and-coming one is people who are great with video. I think in the past video didn’t play as much of a role in DevRel positions, but video is so important to how the world works today that those who have been involved with some aspect of video succeed pretty well. It’s definitely something that can be learned, but it’s something to look for as well, too.

I think with engineering and with being a developer it’s a desire to want to learn and explore new tools that is a good fit for developers, and wanting to dive in just a little bit further than just the surface level. You try out some new tool… “Wow, this seems really interesting. But why did they make this choice? Why is it set up in this way?” Going a step further, so that you have enough understanding that you can relay back the value to others who are curious, more than just the tagline, more than just the boilerplate. Like, tell me really why it matters. Those are a couple things I look for.

[58:07] As you’ve been talking about this, I was reminded of our conversation with Jessica Kerr, who’s DevRel now at Honeycomb… And she was mentioning some pitfalls or blind spots DevRels have. Specifically one that she mentioned - I’m curious if this resonates with you, and I wonder if you have others as well - is that they rarely go through, for instance, the purchasing process of their product or service, because they have staff accounts. And a lot of times your first run experience actually is “How do I actually onboard? My onboard experience is my experience first time on.” Unless we have free trial etc. Even that’s part of it. And she said people who work in this domain - they should put their credit card into the website and just purchase an account, because now they have empathy with the people how to do that; whereas you’re used to having this staff account that kind of goes through these other subsections.

That was one that she mentioned. The other one that I think happens - I’m not doing it, but I would imagine it happens - is like you spend most of your time building toy apps, experiments, examples, and you can live in that land of like throw-away things, versus big products that would be built with a tool.

So those are two that I thought of… First of all, do those resonate? And then secondly, are there other areas where DevRels can be blinded to what their customers are actually doing?

Yeah, I love this topic… And that first one on billing is so accurate. You just reminded that after this I’m gonna go spin up a new Vercel account and throw my credit card on there.

[laughs] There you go.

Because yeah, it’s the little errors you might get with the billing message that can really, really destroy customer trust.

Yeah. Or stop them dead in their tracks.

Right.

Yes, yes. That’s a great one. I love that one. I think that – to combat your point about maybe some developer advocates are building a lot of Hello World, starter applications, not really getting into the larger applications… A good way to offset this, I’ve found, is I try to make a point of spending time talking to our largest customers. And these are people who are building really large applications. Their needs and pains are quite different than the rest of the customers on our platform. They’re an order of magnitude in difference in how they construct their app. They might have an order of magnitude more engineers as well, too. And you just uncover different insights that might be rooted back in fundamental product deficiencies elsewhere.

For example, maybe one of your really large customers is struggling with a specific way of how they wanna organize their codebase. And what you realize in really digging into this customer feedback and getting involved in the actual product experience when you’re out in the field, talking to these people, is that there’s a common thread between all of this other feedback you’ve been hearing about the getting started experience. But because you weren’t paying attention to the day 500 experience, and you were only looking at the day 2 experience, you might have missed that along the journey.

So you can’t take for granted or lose track of those customers who have grown with you and been around for a while. And part of that is a good relationship between the developer relations team, and then what a customer success team or whatever you wanna call that in an organization. But the team responsible for interfacing with the actual customers, the accounts that they manage.

[01:01:47.25] Jerod, something that you had said there reminded me of something else that we talked about with Jessica. And then Lee, in the first segment you mentioned DevRel teams and which org they’re under. Something that Jessica talked about was that her org is under marketing. And in the first segment you mentioned how that can kind of play a role in how they are successful, I assume, to some degree, with their roles or their mission for the brand. It seems like you know what you’re talking about, basically; you know how to operate an organization, you know how to direct an organization that’s doing DevRel for a Vercel or a large organization like that… When it comes to setting up a DevRel organization, whether it’s one person or many - and let’s just say tech-focused brands, because obviously, healthcare might be different. What are the right ways to organize the hierarchy? Do you put it under marketing, do you put it under sales? How do you attach OKRs and KPIs? We talked about metrics a little bit, but how do you set it up right, so that listeners of this show do trust them, and products can get adopted, and be useful, and enable success, and help, and all these fun things we’re talking about? How does that work, how do you make it work?

Yeah, I wish there was a great, simple answer for this… Unfortunately, there’s not really… Because I think my next question following up to this would be “How large is the company? What’s the current focus?” Is the current focus they’re just getting started with product-market fit? Is the current focus they’re just getting into enterprise sales? Are they already at a hundred million ARR and now they’re trying to move into the next phase of the company? All of those different phases of the company’s lifespan might require different outreach.

For context, when I joined Vercel, I was employee 34, and we were a much different company than we are today. And the type of outreach I was doing is a little bit different today than it was at the start, but the core values are all the way.

So if you hire the right people, which - that’s kind of handwavy, right? But if you hire people that are empathetic, that are great writers, that are passionate about tech, then a lot of that can translate back to “Well, it doesn’t really matter what org or what KPI”, because they’re going to thrive in whatever environment or what stage the company is at.

So that’s some of the things that organizations can think about with regards to successful DevRel. What about the content specifically? If you were gonna define what’s a good piece of promotional content… Surely, you’ve had lots of wins, lots of losses, things that have blown up, things that have been ignored…

Yeah.

Are there attributes of good content that DevRel people can create, that’s sticky, or interesting, or viral, that you’ve found is reproducible?

Yeah, I’ll segment this into two buckets of content, because I’ve seen DevRel get involved in both buckets. Let’s say on one hand it’s the traditional marketing content. This is like the press release, this is the announcement of the thing… It’s more targeted towards a larger audience. And then there’s the engineering developer-focused content. This is targeted directly at the individual developers, whether some kind of how-to, or tutorial, or guide, or some kind of explainer on how something works.

The separation of audiences there is really important on what makes the content great, because if we start talking with the engineering content, developers don’t want you to skimp on the details. They wanna know behind the scenes what is making this thing work. Otherwise, it feels like a sales pitch, it feels like a marketing pitch. Like, “You’re telling me about this thing but you’re not giving me any of the underworkings of how the system works. Now I have questions. Now I don’t feel like you’re being truthful with me. This seems too good to be true.” If you read something and it’s like “Hm… This feels like a silver bullet. This feels like there were no trade-offs discussed at all.” It’s only good, but it’s probably not a very good engineering blog post.

[01:05:58.20] Some of the best engineering blog posts actually document “Here’s what worked, here’s what didn’t work, and why it didn’t work, and here’s what we learned from it and actually improved on that.” And that’s how you can do engineering content really well, focused for individual developers.

Then there’s also the press release, announcement-style material, and I think where DevRel can play a role in that is making sure you’re doing justice to your community. So let’s say you’re announcing a new feature for your product. In how you talk about this feature, you should try to tie it back to the actual customers using it, the community involved around it… Maybe they have surfaced some feedback that’s helped make it successful. Maybe you’ve actually surfaced this with them ahead of time, so you can get feedback on the announcement or on the feature that you’re launching.

And I think the DevRel persona can help bring the lens of maybe this is a first-time viewer of the product, maybe this is somebody really advanced. How do we make sure that this content lands with all of the developers in our community?

I’m curious about specific social platforms and what y’all are investing in. Is Instagram – we have them, they are all stealing each other’s features…

So many. [laughs]

Are you going heavy into TikTok, are you ignoring this? What as a team do you guys look at and say “Here’s where we’re gonna reach our people.” Because you’ve gotta reach them.

Yeah, one hundred percent. I feel like we’re involved in almost all the major social platforms. And I’ll say that I do think that video is just continuing to get more and more popular, which I think is why TikTok is so popular. It’s interesting though, the type of content that does well on different platforms is quite different. People don’t wanna see the YouTube video, just copy-paste it and repost it on TikTok. It needs to feel like it’s built for that platform.

And strangely enough - I don’t know if this is a generational thing, but some of the content that does best on platforms like TikTok, it feels like it was just shot on your iPhone. It’s actually better when it was just shot on your iPhone, and it’s not super-professional. They don’t wanna see the super-polished press release style announcement keynote video. They wanna see Lee doing a dance to a song. [laughs]

Are you doing that stuff?

Um, no. [laughter]

“They wanna see it, but I’m not giving it to them.”

Well, I’d like to see that as well. [laughs]

Nobody wants to see me do dances. I have seen some people do it well; some people who use TikTok as an educational tool. And I think that’s what it comes back down to - find your audience, whether they’re on TikTok, or LinkedIn, or on Facebook, the black hole of developers… There’s so many developers on Facebook; they’re just waiting for you to talk to them, but a lot of people don’t engage with those groups.

And as long as you make educational resources, they will listen. Because all developers are always trying to learn something new. And even experts wanna hear something explained like a beginner can understand it.

Well, said.

There’s somebody out there that’s thinking “I’m a DevRel. I’ve got my singular org, or I wanna evolve my organization… I want the business side to help me evolve it…” Where do you get – what resources do you look to? …blog posts, YouTubes, whatever it might be. Talks… What resources do you use to become wise? I think you’re pretty wise… Where do you get your wisdom, where can you point some of the folks who might wanna evolve or upgrade their DevRel organizations to become a bit more like yours, or just have some of the attributes you’ve been talking about today?

Yeah, I’m very fortunate to have people on the Vercel team who’ve helped our organization grow and provide a lot of good feedback. I think outside of the Vercel team I try to connect with other folks leading DevRel at developer-focused companies.

[01:10:07.10] So my recommendation for people wanting to get kind of a pulse on how DevRel is going is to connect with the individuals. It’s more about the people than it is the brand or the company, because that’s where you’re gonna gain insights on how their worldview is shaping, how they interface with their communities.

So I would find some of the tools that you’re interested in, maybe the tools that you use, that help make your life easier, and see who those developers are who are leading the communities there, and DM them. They might be more open to your outreach than you might imagine.

There you go. Are your DMs open?

They are, yeah.

There you go.

I have people DM me about all different types of stuff. I believe it’s helpful; I acknowledge it can be difficult for certain people to have DMs open, just due to the way the internet is, so it doesn’t work for everyone, but… Yeah, it’s a good venue for feedback sometimes.

Gotcha. What about things unsaid? I’m sure we’ve talked a lot about the process, the history, the do’s and don’ts, codesmells, for a lack of better terms, of good and bad organizations/individuals you can trust or not trust, and reasons you can… Is there anything we haven’t asked you that you’re like “Man, I really wish I could talk about this” before we close out the show?

Um, I think you all have done a great job. This has been really fun. Lots of thought-provoking questions. I don’t usually get to talk about DevRel in the meta sense, so it’s been interesting to reflect on why we do the things we do.

There you go. Well said.

One thing we didn’t talk about, which we wanna talk about, but we’ll probably have to do it on JS Party, is I wanna talk more about Next.js, where it’s at, where it’s headed… We completely sidelined that. That’s a big part of what you do. And so we’ll have to have you on JS Party where you’re gonna hit the audience right on the head.

Oh, yeah.

Don’t actually hit our audience on the head, but you know, metaphorically, the nail and the hammer.

The nail head. He’s the hammer.

So we’ll have to bring you on JS Party to talk about that, so we can give its full time. Sound good?

Yeah, that’d be great. I think it’d be fun.

Cool.

Cool. Well, Lee, thank you so much for your time, your leadership, your wisdom, and just showing up here and just being real. We really appreciate that. thank you so much.

Yeah, thank you. This has been fun.