Episode 540: Joe Nash on DevRel

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org and include the episode number and URL.

Felienne 00:00:16 Hello everyone, my name is Felienne Hermans for Software Engineering Radio, and today with me on the show we have Joe Nash. Joe is a developer educator at Twillio where he helps students to learn with TwillioQuest, Twillio’s educational game. Previously, he was a program manager for GitHub education and developer advocate at PayPal. Welcome to the show, Joe.

Joe Nash 00:00:37 Hi there. Thank you so much for having me.

Felienne 00:00:39 The topic of today’s show is developer relations, and this is of course a role from your biography we know that you are familiar with, but not everyone might actually know what developer relation, what it even means. So, what does that mean? What relations do developers have with whom?

Joe Nash 00:00:58 Yeah, sure. So, I mean, this is a bit of a complicated answer, which pretty the best way to start, but I guess most simply put developer relations is business function, which helps companies reach developers — whether those developers be customers of the company, say in a developer-facing product or stakeholders; for example, if you have a developer platform like Slack, for example, where they want developers to build apps. So, in both of those cases, people who do the developer relations role are trying to help that company reach and build relationships with developers.

Felienne 00:01:27 And I think there are two terms here that might play a role. Sometimes people call themselves developer advocate, but also, we hear the term developer evangelist. Is that the same thing?

Joe Nash 00:01:38 Yes. So, this is another area where the answer is complicated. Developer evangelist was kind of the original title, and that meant someone who would go out into software communities on behalf of a company and advocate to developers and talk to developers and spread the word of the product to developers. And over the years there’s kind of been a trend change to developer advocate and that is largely honestly in my view because the word evangelist has some religious connotations that not are not necessarily appropriate for every community. But there’s also kind of been — and Twillio is an example of this — an idea that actually those are two different roles where evangelists are more about outward messaging and advocates more about bringing developers’ concerns back into the company. So, some companies do operate evangelists and advocates as two separate roles. Other places it’s just kind of a trend change where they’ve wanted to keep up with the times and choose a globally applicable word.

Felienne 00:02:32 So if we are in a situation where we have those two roles, is it an evangelist is more pre-sales and maybe a developer advocate is more helping people to actually use the product?

Joe Nash 00:02:42 Yeah, I’d say that’s pretty accurate. Yeah. Evangelists tend to be about awareness. They tend to be top of the funnel. So, helping developers understand that this company exists, and it has developer products, and what they can do with the tools. And then advocates are very often very integrated into the product feedback life cycle. So, they’ll be out with developers ensuring that their feedback gets incorporated into future integrations of the product, making sure the developer experience is good. There will often still be some — both roles will have a big education component. So, both roles will support developers in implementing the company’s solution. But yes, I think that where they play into the sales lifecycle is a very good way of looking at the difference.

Felienne 00:03:20 So why does this role exist? What do companies typically need developer advocates for?

Joe Nash 00:03:27 So mostly the — I guess the meme, the popular conception of why developer relations exist is that developers are often thought of as hard to market to. I don’t necessarily agree with this, personally, but that is the popular conception. The idea is that if you are marketing to technical people where ‘technical’ means that they’re into software, they’re into software development, you need people who have some understanding of that domain in order to speak their language in order to communicate effectively with them. And so, you end up with essentially technical marketing. And so, that is kind of where developer relations comes in. Over time, developer relations has taken on lots of other roles, and you kind of often see it essentially acting as the glue for an organization that needs to address developers where developer relations will interface with every department that interfaces with those developers and act as kind of the technical spokesperson.

Joe Nash 00:04:19 So, developer relations may get involved in marketing, they may get involved in sales, they’ll get involved in content and in product, and where they are acting as the ‘developer’ within the company. And so, it pops up in lots of places, lots of different roles, and so the main reasons a company will need developer relations is if they are pursuing developers as either a customer or as part of a platform play. So if you’re selling to developers, you need to be able to — often selling to developers or marketing to developers means empowering developers to build on top of your APIs, or your software, your SDKs. And so that means technical content. And equally, if you are doing a platform play, you want developers to build on top of your product, you need a lot of you need to inspire them to say that ‘hey, this is a place you can build your business. This is the place you can build your app on top of.’ And so that also requires a developer in the seat.

Felienne 00:05:09 So the type of companies that will typically have such a role are companies that allow developers to build upon their platforms. So, they might have, as already said, an API or an SDK. There is a place for developers to interact with their tooling, and therefore, you want to support them in doing that effectively and with joy.

Joe Nash 00:05:29 That is correct. Yeah, there is some nuance there in that we are increasingly seeing companies that target developers as a consumer also have developer relations. So, GitHub is quite an interesting example of this. GitHub is a product, obviously, developers use as a product. We come and put our code on GitHub, and that’s not really a platform play, right? That is us using it as a consumer, but then they also have an API and they also have things GitHub actions and a way to build apps on GitHub. And so, GitHub developer relations kind of plays between both where they’re encouraging developers to target GitHub as a platform for their own applications, but then also they are just evangelizing the use of GitHub as a product with developers. So, you do kind of get both ends of that now. And there are typically a DevRel falls on the spectrum between are you a product or are you a platform, and what you need from a DevRel depends on where on that spectrum you fall.

Felienne 00:06:20 Yeah, interesting. So sometimes you might mainly be wanting developers to use your tools even if they might not customize the tools with APIs. Something like GitHub or maybe also Slack could be an example of that or Discord where you also want developers to be your customers. So, you want to make sure your product looks cool and has features that developers want, but also you want to support them in billing on your platform.

Joe Nash 00:06:46 Exactly. JetBrains is another really interesting example of that, actually.

Felienne 00:06:50 Let’s move on to what the job actually looks like. So, I think most of the audience would know if you want to be a programmer, or if you want to be an architect, these are the skills that you might have. But how does that work for a developer relations person? What type of skills — are you like a programmer, are you like a salesperson? How do you define yourself, and what are the skills that you would need if some people that are listening might consider becoming such a role? What are the skills you need for that?

Joe Nash 00:07:19 Sure. So, I think it’s probably easiest to start with the developer advocate, the developer evangelist role. This is the role I think most people have experienced in DevRel. And when you’re looking at those roles, a lot of skills — depending on the company — come into it, but often said there is that aspect of communication, being out there in developer communities; it’s a big prominent part of those roles. So, public speaking will often be part of that ability to not only be confident and communicate a message well on stage but to be able to craft a narrative. So, to take your company’s product and think of stories you can tell around that. And that doesn’t always necessarily need to be product-focused. Lots of developer advocates — for example, I had a talk I used to do at PayPal, which was about some cool engineering that was happening within PayPal that was completely your orthogonal to use of the product for a developer.

Joe Nash 00:08:04 But it was an interesting story and showed that we were doing some really cool technical stuff, and so that’s interesting to developers. So, the ability to build narratives and tells compelling stories is really important. Often developer advocates will be involved in content creation of all kinds. So, traditionally that’s been blog posts and social media content. And so again, being able to tell amazing stories in a written format is really useful in being able to make it entertaining. But the educational content piece is very important for blog work. And over the course of the pandemic video work has taken a more important place as especially live streaming has taken on a lot of importance versus where we used to do a lot of in person stuff. So that’s develop advocacy. Lots of other roles depending on the size and sophistication of develop relations department will fall into DevRel so, know you’ve read out program management, it’s the title I’ve had in the past. There’s increasingly developer focused programs that get run by DevRel. Some departments incorporate documentation and other technical education roles, but I think those are probably more familiar to a lot of folks. I think the one that will probably be most novel is the developer advocate role. And so the ability to note, take your development skills and share those is primarily what you’re looking at.

Felienne 00:09:16 What does a job look like day-to-day? It seems like it’s a very, very exciting job where you do many different things: blogging, going to conferences, doing live streams. How does that work? How do you organize the work you do?

Joe Nash 00:09:30 There’s no avoiding it. It is chaotic often in the peak of my times and developer advocate, my day to day has been defined by the conference seasons. So, you get very used to for example, Octobers and Novembers are doomed. That’s when all the big conferences are, you just get used to living out living on a plane. Again, that’s changed in more recent years. But yeah, it’s very driven by the community and the community’s needs. I’d say it’s a very reactive role. You will often be responding not only to what your developers need and what the developers in your community need and what they’re doing with conferences and events, but also what’s coming out of your company. So, developer advocates are very busy this time of year because lots of big developer facing companies tend to do their big product conference in this time, right?

Joe Nash 00:10:12 We’ve got GitHub Universe, Twillio Signal, all these kinds of things. And, and that’s when the big announcements come out. And so that’s when the blog posts and the talks need to be done. And so, it is a very reactive role. One of the tensions I think, and I imagine we’ll talk about this, is keeping up your proficiency as a developer yourself. That’s something that a lot of developer advocates worry about honestly. Because there isn’t necessarily always time to sit down and churn out a lot of code. You’ll often be working on samples and demos, and bits and pieces for blog posts. But when you are on the content production pipeline and traveling so much, it can be, can be hard to find that time. And so that’s something that you’ll often try and make for time for depending on the season. So earlier in the year, it’s easier to make time to sit down and work on an SDK and that kind of stuff, right? Yeah. It’s chaos.

Felienne 00:10:56 Yeah, that sounds really challenging. And how do you know, especially given all those different tasks you have, how do you know if you’re doing well, right? If you’re a developer and at least there’s so metrics we have so many users, or we have so much traffic or so many request close or features adds. When are you doing well? How do you know that?

Joe Nash 00:11:16 This is, again, another question that DevRel loves to ask itself all the time, which any dev people listening to this will know is a particular sore point of mind. There’s lots of ways of measuring DevRel, depending on what your product slash platform is, it can be a little bit easier. So, if you’re a developer advocate, there are all kinds of quote-unquote vanity metrics that you can use just to get a rough idea of how things are going day to day. How many people were in my talk, how’s my views on my YouTube video going? That kind of thing. But ultimately, actual success is going to depend on the instrumentation you have around the actual product and the funnel for the product. If you work on a, if you’re a DevRel working on a product that has a free trial mechanism or a promo code-driven mechanism where you can give, where you can have attribution for a developer that signs up due to something you’ve done, that’s obviously a far less stressful situation to be in.

Joe Nash 00:12:07 It’s much easier to point to your results. Unfortunately, that’s not the nature for a lot of products. There’s some really cool tooling out, and there’s some really cool measurement out there. I think one I always quote is the Microsoft Azure team have really good tracking on their documentation. And so, they actually know at a very granular level — or have known in the past, I don’t know if this is still true — have known in the past at a very granular level, how many signups to Microsoft Azure come from documentation written by their developer advocacy team, right? And so, they have that level of detail. And so yeah, the approaches vary. One of the things you read out my bio was the GitHub role and get student developer pack, that was kind of a dream role from a metric perspective because we had a student focused product, it was a student discount and that was the primary number, right? Everything we did funneled down to that number. And so, what we were always looking for was, hey, here’s the mechanism by which we moved that number forward. And so, everything comes down to this north star metric. Finding that north star metric where you go is kind of the defining difficulty of a developer relations role internally, I would say.

Felienne 00:13:07 Yeah, that was going to be my next question, right? But this is also a question that matters for developers. They’re also, you might think, are we counting the number of users, or are we counting the number of users that stick with us for more than one month? So, I understand in general it’s really hard, but I do still want to know from you, what is the process to define the northern star? Is this a thing you do, you do together with the board of the company, or with developers? How does that work, that process of deciding this?

Joe Nash 00:13:37 Sure. Yeah. And it’s going to hopefully be a very collaborative process in practice. It’s often not, but again, it comes down to what is the company building and how do developers factor into that sales cycle, right? So, if you want to talk about a platform company — say you’re talking about a Slack or a Discord, as we said — the ultimate goal there is that developers build an application on top of that platform. That’s a decision that’s very driven by the developer, right? It might be a company that’s building the application, but the choice to implement against Slack is probably very driven by a developer. And so, developers are very important in that sales cycle. And so, in that case you might find that you can, that metrics number of developers reached are slightly more impactful and powerful because the developer has an outsized impact on adoption in that case. In other cases, if you have a more enterprise-focused product, you might find that the developer actually has less say in the adoption.

Joe Nash 00:14:35 So actually a good example, this is video games. So, video games really technically intensive development process, but they have very long development cycles, and once they’ve locked into technology they can’t readily change that technology. And there’s a period of time where they need to choose what they’re going to build the next game on. And once that’s done, it’s a short period of time. Once that’s done, that’s done. It’s not so useful to market to developers in video games because they don’t have a lot of influence on the technology being used. You can’t, your window of opportunity to get to a developer and influence them is very, very small. And so, in that case reaching developers or number of developers reached isn’t a super useful metric, right? So really — and this is I think where a lot of companies have their first stumbling blocks with DevRel — is they don’t often ask or don’t often analyze very intensely, like what is the role developers actually play in a potential adoption or go or no go on our products.

Joe Nash 00:15:25 Developer relation is very trendy. So, it’s very easy to say, hey, everyone has developers, everyone hires developers, but developers don’t have equal power in every company, right? The web, I think the web and APIs that industry, that part of tech has really popularized developer relations because building websites, developers do have a lot of say in adoption just generally speaking, but that doesn’t necessarily apply to everywhere where you might be looking at employing developer relations. And so, when it comes to actually working out how do we define success? Really the question is what is the value of an individual developer coming to your platform? And then you have, whether success is more developers or deeper relationships with developers all comes from that, right? If it’s a slow, if it’s high, if developers have a lot of power in adoption, going for many developers and just getting the word out as wide as possible is a pretty viable strategy. If you need to reach a high-level person in the company you might want to establish close relationships and work for more CTOs or architects than individual front-end devs. Right? Does that make sense?

Felienne 00:16:27 Yeah. So, it’s very much tied also to what the mission of the company is, right? Because indeed you might attract many developers, oh, I make this very fun balloon to Slack or something but is that going to lead to a paying customer, or are you just spending energy of the advocates on hobbyists that are making fun things but are not necessarily leading to more customers? So, I imagine that it’s also very, very tied to what your business model is.

Joe Nash 00:16:54 Yes, exactly. Yeah. And I think a really actually fascinating example of this is Spotify, so Spotify have an API platform; you can use the Spotify API, you can do a bunch cool stuff with it, but what are the businesses actually building on top of Spotify as — you know, building their business on top of Spotify, its things integrated smart speakers and dashboards for cars and in those industries I mean, first of all, they’re adopting Spotify for reasons that are completely orthoganal to the developer experience. They have to integrate Spotify regardless, right? So, whether a developer likes the API or not is irrelevant. The legal situation, the legal and copyright surroundings of integrating a music provider into those systems again, also removes a lot of power from the developer making that choice.

Joe Nash 00:17:45 And then hardware and automotive are both industries where a developer doesn’t have a lot of decision-making power. So that’s a great one where I think a really interesting example of like Spotify investing in DevRel and they have a public API and the DevRel folks can go and get a bunch of developers building on it, but does it necessarily enable more people to build with Spotify, right? Ordoes it influence the type of companies that are building with Spotify? Probably actually not. Still a good thing for them to be doing. It’s still, DevRel can having a good public facing API can do wonders for all kinds of things for a company, especially hiring. If you are seen to be a developer friendly company, it’s a lot higher, a lot easier to hire developers. So that’s never another part of it, but yeah, it’s a difficult question.

Felienne 00:18:35 Yeah, that is interesting, that perspective of hiring, this might be another reason, right? Why companies have developer relationships — not necessarily to show this is how you build on a platform, or this is how cool our platform is, but more to show we are a company that cares about developers and therefore come work for us, right? Is this also something that is generally seen as the responsibility of DevRel, or is this like, in the HR department and this is entirely out of your scope typically?

Joe Nash 00:19:04 Yeah, again, it can vary. It’s enough of like overlap with talent is another thing that some DevRel teams do — and some DevRel teams are built around this principle. So, I just mentioned Spotify there and their API; Spotify have a developer-facing product called Backstage, which is an internal tool that they built for their own usage and then they started evangelizing outside in a similar way to Facebook and React, and they’ve got a DevRel team for Backstage. And that’s nothing to do with Spotify’s product. That’s purely, we’ve built a cool developer tool; we think it’s good, it’s good for the company, for developers to think it’s good, so let’s help advocate it. So, that’s a developer relations team that has kind of been founded with that idea that there is, they are probably mostly a brand positioning thing, right?

Joe Nash 00:19:49 And you can arguably say the same in many ways about any developer who works on something. Like React. React is not related to Facebook’s business as a social media company, right? It doesn’t get more people to log into Facebook and upload photos of their dogs. But Facebook needs a lot of developers. React is very, very popular and has had a huge impact on the developer ecosystem. So being a developer advocate working on React, you are primarily working on Facebook, the brand. And so, you will have developer relations teams where that is the core premise, that is what you are doing. And it’s pretty clear from the outside when you go to work on a team like that, that’s, oh, I’m not working on the product that pays the bills. I’m working on a product that helps us build the company that pays the bills. Right?

Felienne 00:20:38 Imagine people want to become a developer relations person. How do you do that? And maybe we can start with your path. Did you go from being a programmer to being an advocate? How is your process, and how is the typical process in so far as you know that?

Joe Nash 00:20:54 My path is really weird and probably not generally applicable. My path is via hackathons, which isn’t itself uncommon. So folks who aren’t aware, hackathon is kind of a programming adventure marathons. So typically, you’ll spend multiple days in a room with a couple of hundred other people just building cool stuff. There may be prizes, there may not be. There’s community-driven hackathons, company-driven hackathons. I was very involved in student hackathons when I was in university, but also used to go to some professional hackathons, and one of those was PayPal’s hackathon, which no longer exists, but it was called Battle Hack. And Battle Hack was kind of a World Cup setup, so they’d hold it in every city and then they’d fly the winners out to their office in Silicon Valley where you’d compete for some silly prize money.

Joe Nash 00:21:37 My team won in London and so we went to the finals. We were one of two student teams there, and then we got absolutely demolished. We had no chance of winning whatsoever. But after that I said to the PayPal developer relations team, hey, this is the best hackathon I’ve ever been to. I organize hackathons myself as a student, how do I join this team? And so, they opened an internship position for me, and I joined as an intern. And yeah, then after I graduated and I went on to start doing a PhD in essentially programming language design, because I had this feeling that being a developer was far harder than it should be, and I wanted to work on that. And then I was up there in remote Scotland working on this PhD and was kind of like, oh wait, I can get paid to help developers instead, I’m going to go join PayPal full time.

Joe Nash 00:22:30 And so, my path was very, very weird. Yes. So not a lot that’s applicable there, but generally speaking, I would say the commonalities there that I would really recommend is interfacing with developer communities. So, I think one of, and I don’t necessarily think this is a widely held belief, but I think one of the most important things about developer relations and why it exists, and why developer communities look they do, and why we go to all these conferences and this kind of thing, is ultimately that software engineering is a profession with an unusual degree of lifelong learning, right? Because of the pace of technology, software engineers need to update their skills and learn new skills at a pace that is probably not seen necessarily in other industries and other roles. And we turn to community to help us do that.

Joe Nash 00:23:23 Where else are you going to learn about all this new stuff? Well, we’ve got the experts speaking on the onstage at a conference, right? You don’t get, you don’t necessarily get hackathons for carpenters with hundreds of people sitting in a room for 24 hours to learn how to use a new chisel, right? That’s something that’s fairly unique to software engineering. And ultimately that’s kind of the, it’s a very unique part about being a software engineer. And participating in those communities I think is really important for our growth as software engineers. But also provides a really great launching off point for a developer relations person. Go find your local meetup. Go find, go tune into a stream for a product you’re interested in, find an Open-Source developer and read that blog. Get to know developers around you, learn new skills and work out how you can contribute.

Joe Nash 00:24:10 And I think that’s probably the best path into developer relations. Lots of companies hiring for early-stage developer advocates will be interested in your technical proficiency. And your ability to communicate that technology and what other, what writing and what speaking you’ve already done, but ultimately they’re looking for people who understand that technology and understand the community around that technology who is confident in talking to others in that community and distributing a message through that community. So just go hang out with other devs in your area is the easiest way.

Felienne 00:24:45 Nice. That’s great advice for people that want to maybe explore this path. But you hinted at this in the beginning of the episode already, like what is the role of programming? and how do you keep your skill in programming up-to-date? So let’s first start with this first question: How important part of your job is programming? Do you ever still program? Do you build prototypes? Do you actually develop the products that you work on?

Joe Nash 00:25:09 Yeah, so again, this will vary super widely depending on the skew of the DevRel team, but generally speaking for a developer advocate, developer evangelist, being technically proficient is probably fairly important because it’s going to drive a lot of the content. Some developer advocates will write more code as part of their outreach efforts than others. So, some might have live coding or demo-driven content or talks. Some may get directly involved in things like the maintenance of SDKs or documentation. But there are definitely roles within developer relations departments to suit kind of all levels of technical proficiency, I would say. So, as a lot of developer relations teams are more and more encompassing things documentation and developer experience. So, there’s a number of DevRel teams where it’s actually the developer relations team that owns the SDKs or the developer-facing parts of the product as products. And they maintain those as products.

Joe Nash 00:26:16 And so there will be engineers who are focused on engineering within developer relations, and they’ll get to experience some of what makes developer relations unique in terms of the positioning to the customer and being in touch with developers and incorporating developer feedback more directly, but they’re still doing engineering. So generally I would say working out how much a role requires, a role will allow you to code or not allow you to code is going to come down to the job listing and asking some prudent questions in the interview process. I would say developer relations, if you can find a role that is on — if you are wanting to code more, finding a role where the developer relations team is involved in the development of SDKs or client- or developer-facing products is going to be really important. But there’s also a lot of fun and joy in working on demos and stuff. I think that’s, I definitely, I said it’s very rare that you’ll get to really plow into some scaled application level code, but being able to just work on fun products and churn them out and find narratives to — to find inspiring things to build on your company’s products is very fun.

Felienne 00:27:30 And that does lead to the question, of course, of how to keep your skills updated because your customer ultimately also is a programmer. So, you have to understand what are the challenges of programmers today, both in general in working with programming systems, but also specifically in the tool that you want to market to developers. How do you keep that skill up-to-date? Specifically, you’re already referring to our field being a field in which there’s lots of learning going on. How do you manage that?

Joe Nash 00:27:58 Yeah, I think it’s very easy to become a T-shaped person in DevRel. So, because you’re always at these community events, you’re always experimenting with new things to build content. It’s very easy to get very shallow experience of lots of things and to not necessarily have the depth to go support an implementation at scale in a company. So, I think that’s the bit that a lot of DevRel folks struggle with. I think the best way of dealing with that for a lot of folks is — well, I say “deal with that.” I mean, part of it you can accept that you’re just not, that’s not your role; that there’s a point where you hand that relationship off to an architect or sales engineer within the organization.

Joe Nash 00:28:43 But there are other ways where folks engage in open source, or they have their pet projects. For example, in my current role, my role is primarily teaching new students about Twillio. And that means a lot of doing the basics. I teach them what rest APIs are and or all this kind of stuff. And I certainly learn a lot myself there, but I don’t get to go super in-depth. So I also have my pet product within our — well, not ‘product,’ my pet project — which started as a demo but is now starting to get quite big, and I keep adding to it and it’s growing in technical complexity, which I do just to make sure that I do still know how to do this stuff, right? And I think that’s the way a lot of things go. You’ll often find actually, like Brian Douglas at GitHub is a good example of this, where he’s a developer advocate, but he’s built an incredible side project around helping people get into open source. But that itself is an app that he’s building that uses a lot of the technologies he’s advocating, and has a lot of users. And so, he’s getting to it’s serving his advocacy needs while also giving him an avenue to build skills.

Felienne 00:29:49 Yeah. So, the tip maybe there might be to have some sort of pet project, big or small, where you can still continue to be a developer sort of on the side, probably not on the main project, so you can keep your skill set up-to-date.

Joe Nash 00:30:03 Yeah, that and I would say if you are concerned about not writing enough code, keep an eye on what the overlap between the DevRel team and product is. You want to look for teams that are involved in SDK development. And ultimately, if you are super concerned about not writing enough code, it’s possible that have developer advocate is not a role you’ll enjoy.

Felienne 00:30:24 Yeah. So, what you are saying is that programming is only a small part of the job, and it might be hard to even keep enough skill to properly do your job, let alone keep your programming skills alive for if you want to go back, if that’s where you’re coming from to programming.

Joe Nash 00:30:39 I think I’d say it’s a very good job for people who enjoy coding but who would not enjoy coding nine-to-five full time.

Felienne 00:30:49 Yeah, that makes sense. Let’s move on to the next topic that we want to talk about. We talked about programming, we talked about the skills that you have as a developer advocate, but what about content development? You talked about that early in the episode, I would write blogs and videos and talks. How much of the job is this content creation? And also there, how do you know you’re on the right track? Is there a number of blog posts you have to write or a number of followers you have to acquire on Twitter? How does that part of the job look like?

Joe Nash 00:31:22 Sure. And again, sorry to keep saying it depends, but it does depend.

Felienne 00:31:25 We understand, we can hear some examples of what it might look like?

Joe Nash 00:31:29 So for a developer advocate it’s going to depend, it’s going to be a fairly large part of the role. So, that outreach-driven side of develop relations content as said is a very effective tactic to reach developers. Developers need to constantly be looking stuff up. They need to constantly be refreshing their skills. So, creating content and getting content in the prominent places, being visible on Slack Overflow, on Hacker News, on dev.to, those kind of things, is a great tactic. Blog posts also serve as really useful entry point to a more technical documentation. So, it’s often a lot easier to find blogs just due to nature of SEO than it is to find precise technical documentation. And so, having folks working on blog posts can really help developers in the lifecycle of using your products.

Joe Nash 00:32:27 So it does tend to take up quite a lot. Where you will see it having a more prominent role will definitely be in platform companies where they are trying to serve wide swathes of the developer ecosystems. Again, Twillio’s an interesting example where any company can use Twillio, your tech stack doesn’t really matter. We’re a REST API, we have wrappers for all kinds of languages. And so you end up with lots of build X with Y, right? How to use Twillio if you’re a Ruby on Rails app, and how to use this product with this language. And so those kind of companies where you have, you can have that X with Y formulation, you’ll have a lot of, probably a lot of blog content being made.

Joe Nash 00:33:17 In terms of success and measuring that success, again there’s the standard measures: hey, is this blog post being viewed? Is this blog post appearing in places? Is it being successful in ranked feeds? But it’s hard to translate vanity metrics into actual business value unless you have an attribution mechanism. So, do you have a way of — like, do you have a free trial or a credit-based system where you can say, hey, we know that some developers signed up to us for the first time because of this blog post. Or can we see, hey, this blog post is talking about a particular demo application, and we can see that a bunch of developers are using that demo application, right? So, you really need to actually have a mechanism of looking for actual developer activity, actual engage developers, developers actually building with the product developers, hitting your API endpoint, developers integrating the product. And that has to be quite a holistic part of the content. You can’t just, if you want to see actual product usage, it’s hard to just kind of write a high-level blog and then throw in at the end and here’s a demo, you could check tat out if you wanted to. The demo needs to be useful, needs to be something that they’d actually use experimenting with the product, needs to be on the critical path.

Felienne 00:34:37 And then the next question would be, how do you know these things? How do you know what the critical path is? Do you have some sort of group of user developers around you that give you feedback? I know sometimes these blog posts have this little thumbs up, thumb down, was this content helpful to you? How do you even know if you’re on the right path? I mean, very often I look for tutorials and I’m like none of this is what would help me to get started. But this is really hard to know because you’re such an expert of your own products, writing stuff for people that are not at all knowledgeable in anything. How do you think that?

Joe Nash 00:35:14 Yes, I think this is one of the, I guess one of the reasons why develop relations exists as its kind of own thing rather than just being a technical writer in marketing, right? It’s that embedding of a person who’s responsible for that content in the developer community at large. You have the developer community who is aware of you, who is aware of your work, that you can go and say, hey, is this useful? Is this what you need? That I think is the easiest and best way to do that. I do think that developer relations folks don’t necessarily focus on the educational outcomes as much — or don’t consider the educational outcomes as important to the success of the role as they should do. That’s my personal’s, my personal soapbox, which I go to DevRelCon with on a regular basis and is why I work on things on papers we love.

Joe Nash 00:36:11 So I do think that that can sometimes be neglected, but in general, being in conversation with the developer community is a core function of the role. And so, if you, if a developer relations person is writing content without feedback from the community, some part of the cycle is not working as intended there. So, I definitely think that’s, whether you call it a focus group or whether it’s just a group of folks you trust on Twitter who happen to go to the same conferences as you, that group, that input does need to exist for the role to function.

Felienne 00:36:49 And probably that very much depends as you’re saying, you’ve said a bunch of times, right? It depends. It depends on the type of company or products, whether indeed that is a focus group or people that you hang out with naturally or that you share in Discord with, right?

Joe Nash 00:37:02 Yeah. So, the more enterprise-focused things, for example, will have customer advisory boards and they will have more intentionally structured focus group-like setups. Again, open source has that as well. Open source you’ll often have like a council, for lack of a better word, larger users of the open-source project to, when a company has an open source project that they use, that they maintain, they will often have — not saying if you’re an open source maintainer, you’re not running your own council, the people use your product — but if you’re a company using open source, you will often have an open-source guiding steering body, who may also input as well.

Felienne 00:37:44 Let’s move on to the public speaking part of the job, right? So that is a different form of content creation, but also its own thing. How do you go about finding conferences? Do you, like regular people, do you submit to a call for papers or sessions, or is there a different process if you’re a developer advocate that you use to get yourself or your products into conferences?

Joe Nash 00:38:09 So, how do you find conferences is definitely something that’s changed over time. Like, the halcyon days of Lanyard, which were honestly probably the best time for finding conferences. There are all kinds of aggregators. Often and again, every developer relations person has their kind of pet conferences that they know from their community. Often people get into DevRel through being visible in the community and that will be through these events. And then there is a part of the cycle where it’s, okay it’s time to go do my CFPs for the year. I’m going to go find conferences that are addressing these themes, these topics, and you submit to them. The actual strategy for submitting talks. lots of people go about it in different ways. So, for example, to put it bluntly, submitting to CFPs is a numbers game, right?

Joe Nash 00:38:52 CFP, so calls for papers, the way that conferences take talk submissions and the way that they accept them, those processes can be driven differently in lots of different ways. But there’s fundamentally going to be someone reviewing them. You’re going to be up against other really talented speakers and there’s so much content out there and so many conferences out there. So generally, to make sure that you can stay busy throughout the year, you’re going to be submitting to a lot of them, and you’re going to be looking at probably getting accepted to a lot fewer than you submit to. So, people can approach that in different ways. I think this is one of the earliest points of stress or frustration or burnout that developer relations people hit where they look at a conference and they craft of a bespoke talk for that conference, and they do those 30 times and then 10% get accepted.

Joe Nash 00:39:43 And that’s very sad and stressful, and you’ve put a lot of work in. So, I think what tends to happen is people will kind of work on their talks for the year to three talks for the year. They’ll find appropriate forums for those talks, and they’ll submit them, and they’ll see what happens. How you submit as a developer advocate, and what role the product has in that is, again, always a tension point. We are embedded in our communities, we are part of those communities, we want our content we do to be valuable. We don’t just want to go do ads everywhere, but bills need to be paid. So, working out how you can represent your company in a way that’s useful for developers is always tricky. Lots of conferences will have sponsored tracks and often that is just the best thing to do, right?

Joe Nash 00:40:21 If you need to communicate company message, you need to do the product demo, and there’s a way where you can clearly say ‘this is a product demo.’ No one is being tricked into attending this. Everyone knows what they’re getting when they come here. If they’re interested, they can come here, but they know we’ve paid for this slot. This is going to be about the company, that’s great. If you’re a developer advocate who works on a product that has interesting parallel things to talk about. So, you get to talk about your products, your company’s technology, and how they build the things they do, and it’s not just like, use our product, that’s also really great. Well sometimes you could just be really lucky, and you work on a product that’s just interesting to developers regardless of whether it’s a demo, right?

Joe Nash 00:40:56 Like Kubernetes and React are good examples where you can just go talk about how to do something in Kubernetes, and if you happen to work for someone who sells Kubernetes, okay that’s fine, you can do that talk, right? I think the key to submitting talks is make sure you’re actually contributing value. Make sure it’s a scalable process because you need to be doing it a lot, and make sure that you are not going to be surprising the attendees at the conference that they are expecting to see what they’re going to see, and that they’re not going to think there’s been a rug pull with the content they’ve seen and what you’ve actually presented.

Felienne 00:41:28 Yeah, not I can feel so them they accidentally run into an ad, oh right, this isn’t I’m not learning just I’m being sold something.

Joe Nash 00:41:36 Yeah absolutely. And that’s a really hard line to walk.

Felienne 00:41:39 Yeah, of course.

Joe Nash 00:41:40 And some folks do it better than others.

Felienne 00:41:41 And I think this is even true for developers talking about products if they’re not developer relations persons, right? Sometimes people get really excited about, look this cool thing I built, then it also might sound like an ad even though they’re not literally selling something. It’s like, oh I built this platform and well …

Joe Nash 00:41:57 If it’s a technology they’re using that they really like, it can be really easy to accidentally derail your conference talk into just kind of selling a technology that, like, whether it’s appropriate for someone else it’s going to depend. And it’s not really the useful part of the talk, but yeah.

Felienne 00:42:12 Yeah. So, and then that process does to me sound a lot like other people that are submitting conference talks, right? You have to develop it a little bit. Yes, it’ll be a bit too sad if it’s rejected. So, it doesn’t sound too different from — we have had other episodes that we will link to about public speaking and how to get into public speaking more in general. And that seems to talk about a quite similar process. So far, we’ve very much talked about the outside, the outgoing part of being a developer relationships person, but what about the inward part, right? Within the company, I imagine you have interactions with everyone, with developers in the company, with marketing, with sales, with HR maybe even if you’re also doing this hiring-facing part of the job. What does that look for you, and what does that look like in general, the type of collaborations you have within your own company?

Joe Nash 00:43:04 Sure. So yeah, in an ideal situation, there’ll be lots of these overlaps. So, these overlaps tend to come into play when you have a business function in the company that needs to be in touch with developers in some way. It’s really useful to have a developer relations person in the room because that developer relations person is going to be a representative of the developers. They are in those communities, they know what they want, they know how they feel about the company, and they are a good vibe-check and steering body. So that plays out in different ways in different companies, and in some companies only some departments overlap, some won’t. The biggest way you’ll see this play out if you’re trying to get into DevRel is when you see what is the reporting structure for developer relations?

Joe Nash 00:43:43 Is it a standalone department? Very rarely. It will often report into marketing or into engineering, and where it sits in the company can tell you a lot about those overlaps. The most common overlaps are definitely marketing. Marketing is probably, Marketing and Engineering are the most significant ones. Marketing will be because, as we’ve spoken about a lot with some of the most prominent roles in developer relations, there’s a lot of outward-facing outreach and awareness building and you have a role in the funnel. Engineering will come around from the other end of the feedback loop. So, developer relations will have an overlap with engineering because they’re just getting a lot of feedback directly from developers. They’re talking to the people using the product. And so, it’s important to have a way that that makes it into engineering.

Joe Nash 00:44:26 Sales will often be involved for a very similar reason. I’ve had roles, particularly at GitHub, where I got involved in the sales cycle just because I happened to be a technical public-facing person in the region, right? So, I quite often ended up talking to, oh well I was particularly focused on educational use cases, and I was focused on students, but because I knew the educational use case, I’d get brought in to chat to a university that wanted to buy GitHub enterprise, right? And that kind of thing. And so that’s also fairly common. The other, I think as we’ve spoken a little bit about talent as well, that will often come into play just because again, develop errelations people are in the community so they know that people are looking for jobs; they’re going to places where people are looking for jobs.

Joe Nash 00:45:07 People look for jobs at these events. And so, if you have jobs, if your company’s hiring jobs and you enjoy where you work, it’s always very nice to be able to say, hey, you’ve just watched me do a talk. If you liked this talk, come work with us. Right? It’s very easy to do that. I think where it can get most tricky is with ownership and attribution though, because you overlap with so many departments, you end up having a stake in lots of things, but though it can be difficult to integrate that overlap into your own measures for success or how you are evaluated, right? So, if I’m evaluated on number of developers that sign up to the platform, my relationship with talent probably isn’t helping that, right? So, anything I do for talent isn’t necessarily helping, or if I spend a lot of time supporting an individual customer that’s not necessarily contributing to the numbers. So, I think this is where the overlap, where there is some tension for DevRel in building relationships. Lots of departments is, they often are a service provider internally, they provide something lots of departments want, but it’s hard to quantify that value with all these different — you might get thanked, you might get recognized for those departments, but just lots of little tidbits here and there doesn’t necessarily make a cohesive internal narrative.

Felienne 00:46:22 Yeah. So everyone might like you as an employee because you’re helping everyone, right? But that might not be an effective one.

Joe Nash 00:46:28 Effect of that.

Felienne 00:46:29 Yeah,

Joe Nash 00:46:30 Yeah, exactly.

Felienne 00:46:31 So we talked about, sales and marketing, but you also briefly mentioned engineering. And I want to go a little bit deeper there because in a sense maybe you are also sometimes the first customer of some products that your company is building, right? If they build an API, maybe you are the first one to try the API in the process of working against it, making a blog post about using the API. That is, maybe you are there as the first customer, maybe also fixing bugs. What typically is the relationship that all of you have within engineering in companies or within programming or developers?

Joe Nash 00:47:07 So, what you just described would be the ideal situation. I’ll tell you that does not often play out and that’s mostly just because the pressure to ship. So, we spoke about increasingly developer-facing companies want to do the big splashy launch at the annual conference, and in those cases, things are always against the deadline. The conference date is the target. And so, there’s often not as long an internal period to play with things as you would hope, or as a developer relations person needs. But in an ideal world, that is the situation. If developer relations gets involved in the content for a product launch, and this is actually, I’d actually say this is probably more an overlap with product marketing than is with engineering. Because that will usually be how that relationship happens, right?

Joe Nash 00:47:49 So for the blog post to end up being written by developer relations, the pre-launch blog post or the pre-launch demos to be written by developer relations, they’re probably being involved in a product marketing effort, right? But yeah, having that avenue into product managers and being able to say, hey, I played with the pre-release version, here’s the friction I had. It’s very valuable. I think, nowadays especially, and I do think companies GitHub have kind of made this commonplace. Nowadays, you will often have protracted public alphas that deal with that part, the internal pre-release cycle of it. So often site will go live in the public alpha and developer experience issues will get ironed out then and develop relations people will be very important in that cycle. Because again, they’re an avenue for feedback. They’ll probably be promoting the alpha; they’ll be communicating with folks during the alpha. But in terms of being the first customer, I think that is relatively uncommon for the reasons I mentioned.

Felienne 00:48:43 Ah, that is a pity because yeah, as you were saying, that would be a nice trajectory where first you test it sort of internally and maybe some of the fixes you can even make yourself, whereas regular customers outside of the company of course it would be harder for them to iron out little issues in an alpha.

Joe Nash 00:48:58 Yeah. It often comes — and again, someone will hear this and say that they are contrary to the point, and that they are the first customer — but I think the engineering collaborations tend to come after first exposure to the public. It’ll be a developer has gotten hold of the API and has feedback and that will get back in to engineering via a developer advocate. That will often be the relationship with engineering. It’ll be the other end of the feedback cycle, and it’ll be the people who the first customers come to rather than be in the first customers themselves.

Felienne 00:49:29 Yeah, that makes total sense. Suppose people that are listening are interested in exploring such a career. What are some of the resources, I guess if you want to learn a new programming language, we sort of all know what are the paths to that. One thing I think you already mentioned was something called DevRelCon, like a conference specifically? Is that a good place to get started or do you have books, blogs, videos to explore this path?

Joe Nash 00:49:55 So DevRelCon is a developer operations conference organized by a consultancy called Hoopy. It’s Matthew Ravel. It is wonderful. It’s a conference for DevRel practitioners. I would not necessarily recommend shelling out and attending it if you are not yet in DevRel, but if you’re interested in DevRel. But what I would recommend doing is going over to the YouTube channel, going to developerrelations.com and checking out the enormous backlog of videos. All the talks have been recorded. You can find them all, there have been the conference has been running a long time now and it is for DevRel practitioners, so there’s a lot of stuff in-depth there that’s probably not super useful if you’re just starting out. But there have been additions of the conference focused on early-in-career developer relations folks and getting into industry. So you’ll definitely find those talks.

Joe Nash 00:50:37 I think another really great resource is Mary Thengvall’s newsletter. Mary Thengvall has a wonderful newsletter that also often includes job posts. Ultimately, I think the best thing you can do though is to go and choose a developer product you like, choose an API you like, choose a tool you like, and hit the landing page and pretend you’ve never seen it before. And put yourself in the mindset of a developer who is assessing this tool to see if they should use it at work, and go through that journey and see what you think, see how quick it takes you to make your first API request, see what friction you hit, see what docs you think aren’t quite clear enough. And having done that process, distill those thoughts, write something down and then reflect and say, hey, did I enjoy doing that? I might be a developer relations person. That would be what I would recommend.

Felienne 00:51:25 That’s a great way to get started. And of course, some of the skills that we talked about also, as I already said, have been covered in other episodes. So technical writing or becoming a public speaker, if you would want to work on some of those subskills, some of our older episodes might also help and other resources to work specifically on those different skills.

Joe Nash 00:51:44 One thing I’d caution on that a little — well, sorry, I’d say caution — it’s, I think getting into developer relations sometimes can fall into the same trap as getting into software engineering. Lots of people say, oh go contribute to loads of open source. That’s a good way to get into software engineering, right? And I think the same can kind of happen to DevRel where it’s very easy to say ‘go give a load of talks,’ but they take a lot of time and work, and not everyone can afford to do that as part of their career change. There are definitely, there will be job listings out there that say, hey, we want you to have this many Twitter followers and have done this many talks. But there are job roles out there for early-in-career DevRel people where they will just look at the experience you have as a software engineer and won’t have required you to do the job of a DevRel before you are a DevRel, right? So, if you see job postings that require you to do a load of labor you don’t have time to do in the career switch, don’t be discouraged. Jobs do exist for early, early-career DevRel jobs do exist.

Felienne 00:52:42 Ah, great. Well, this is a very good advice. I think that’s most of the things I wanted to talk about. Do you think there’s anything we missed? Any angle about this part of the job that you still want to talk about?

Joe Nash 00:52:53 I don’t think so. I think your questions are very far. Thank you.

Felienne 00:52:56 Yeah. Fantastic. Thank you so much. So, then what about you? Suppose the audience wants to follow you? What are the best places to stay up to date with the work that you are doing?

Joe Nash 00:53:05 Sure. So, I’m @jna_sh on Twitter, and you’ll probably find me if you just search Joe Nash.

Felienne 00:53:11 We will add it to the show notes as well.

Joe Nash 00:53:13 Perfect. If you are interested in developer education, that’s where I spend a lot of my time nowadays. I run a meetup called Papers We Love Education, which is a paper reading group for computer science education papers, and I work on an educational game called TwillioQuest, so I recommend checking those out as well.

Felienne 00:53:29 Yeah, so we’ll definitely add all those links to the show notes so people can check them out. Thanks for being on the show today.

Joe Nash 00:53:35 Thank you so much for having me.

[End of Audio]