The field of developer relations or DevRel is rapidly increasing in popularity, with roles for developer advocates, evangelists, program managers, and directors appearing seemingly everywhere. It could very well be that you too have colleagues who work in the field. DevRel is a unique discipline aligned with every part of the business from engineering and product, to marketing, and even sales, and acts as a bridge between the company and the wider developer community. Our aligned incentives with engineering leadership are especially obvious in the fact that we exist to serve and enable developer audiences, whether external or internal.
For engineering teams, working closely with your DevRel teams provides a great opportunity to better understand your developer audiences, raise the profiles and skills of your colleagues, and make your company more attractive for hiring. Yet, despite many DevRel teams being highly technical, because of DevRel’s perceived lack of focus, our departments are often dismissed as “just marketing” by engineering.
In this talk I will answer the question of “what is it that DevRel people do”, and present some approaches for how DevRel and engineering can best collaborate and break down silos to benefit everyone, from the company to the wider developer community.
Transcription
Hello everyone at Tech Lead Conference. It's a great pleasure to be here and share a couple of things I know or have picked up in my career about DevRel. The first thing I'm going to share is a little story or a thought exercise. Basically we have two people, Sally and Ben. One is a developer advocate, the other one is an engineering manager. And it's your job to identify who is who. So Sally's job is to make developers' lives better. She loves to make their lives easier and developers more productive. She really finds joy in helping others do their best work. She works in a really dynamic environment where none of the two days of hers are really the same. So maybe on Monday she's speaking to a number of platform and infrastructure engineers on an individual basis, getting feedback from them, learning about their issues, helping them out if she can. On Tuesday she's supposed to be making a presentation that she's already late for, for a group of stakeholders, for a large group of people. And yeah, she just gets dragged into firefighting instead. She basically pushes back what she was supposed to do on Wednesday, so writing a blog post for the company. So that's obviously pushed back. And on Friday, she doesn't know where the week has gone and there is no chance she'll get the chance to learn about the new APIs that Amazon AWS have just released or announced. So yeah, that's Sally. What do you think she is? Developer advocate or engineer manager? I'll help you slightly because I'll tell you what Ben does. So Ben is a developer advocate. So yeah, if you thought that Sally was a developer advocate, obviously because I lured you that way. If you knew where I was going, good for you. I am that good as building suspense. Anyway, I wrote that way on purpose just to give you a little bit of a think that our jobs developer advocate here, tech leads, managers over there might actually be very similar and they are. That's all this talk is about. So yeah, speaking of jobs, I work as a developer advocate at CircleCI. My name is Zan or Zan, however you want to pronounce it, based in London. And yeah, I landed into developer relations proper doing it for pay basically about six ish years ago after finding my own startup, being a developer in an enterprise, being a developer at another startup and just kind of picking up new skills as I went. So when I had my startup, I was doing like a lot of product development, I was doing a lot of stakeholder management as you do, all the marketing, all the everything really because small startups. Anyway, when I was working at a corporation, we were going through this kind of digital transformation, which is a great time to experiment with, with kind of new things because these organizations tend to have quite a lot of capability to let you experiment. So yeah, I discovered there was a distinct lack in skills from graduates coming in, in our kind of graduate program. So I started this bootcamp program for them where they got to learn in hands-on sessions, hands-on workshops about things like Git, command line masteries like Bash and POSIX stuff, test-driven development, et cetera. Also recruited a bunch of others, other senior engineers in the company to kind of come and help out. And I started doing also blogging and public speaking at meetups, conferences in Europe and the UK. And a couple of years later, when I was working at a startup in the developer tool space, we had an opening for developer advocates or developer evangelists, they took it and it was a very, very easy transition. I also discovered one thing that engineers who knew me as an engineer from before, they interacted with me in a completely different way. They saw me as one of their peers, whereas engineers, engineering leaders who came in after I had moved into developer relations, they didn't quite see me as a peer and I had to kind of prove myself much more to them. And that's part of the reason why I'm giving this talk to you today, to kind of give you this idea of why and how you should trust your DevRel teams, they're your peers and yeah, how you can best collaborate with them. So with DevRel, as with everything, it's all about the people you have in the audience. What is your company's audience? Who is your company addressing? Could it be that your company is addressing developers? In my case, I work for CircleCI, we're a CI CD platform. Our customers, our users are all developers from platform engineers to infrastructure engineers to developer engineers to development teams. They're all developers, they're all technical. And it's very obvious to see that obviously people like me bringing feedback, bringing insights from the developer community back to the company, they tend to be very often listened to. And that's how DevRel actually got started in these kinds of companies. Then you have different types of companies that are like developer adjacent or developer plus, where they might have an aspect like an API or SDK that they provide to their customers that are not necessarily developers, but developers can use it to integrate with their tools, their products and whatnot to extend their functionality. And that's the remit of the developer relations team. So it's like much smaller slice of the whole cake. Last group of companies, probably the biggest of them all, by the way, are companies that don't really work with external developers because they have just internal teams and they don't really sell developer products. They don't have an API that they kind of see as a product, but they can still have like hundreds if not thousands of developers on their own, but they need to be up-skilled. They need to be kept up to date with the latest technologies. And that's where developer relations comes in. Just kind of like making sure that everyone is on the same page and everyone is able to contribute at their best capability. That's kind of where we are with audience, but we can also look at DevRel from where we are within the company. So we can sit in many different departments from marketing, product engineering, less so sales, just because incentives are a bit different with sales and they're kind of targets to sell versus our targets to kind of engage your developer communities in a kind of more authentic manner. Me, myself, I work in marketing, so I'm going to start with this. This is actually one of our booths at one of our events. What we do is we build brand, we build awareness. We stand on booths, we talk to folks coming to hear about us, learning what kind of tools they use, et cetera. I also give talks, I also give workshops, sit on podcasts, write blog posts, write tutorials, et cetera. So a lot of stuff that's geared around user acquisition, user engagement, bringing feedback from the communities back to our teams, from our marketing team, for example, hey, there's this new technology we need to write about, there's this new way of thinking we need to kind of adopt, or even the whole organization really. And we're also kind of this kind of bouncing ground for ideas on the marketing team. Someone can just go and say, hey, I have this idea, do you think this would work? And say, yes, you could do even better if you word it slightly differently, if you're going to address it better, you're going to resonate with your audience better, that kind of stuff we can do because we're engineering stuff on the marketing team, so we're kind of closer together with them. Product, it's pretty obvious. So you want to kind of make sure that what gets to the users is the best fit for the actual users. So we help with rapid ideation and getting feedback back, whether that's kind of prototyping ourselves, whether that's kind of going to the actual users, kind of demoing things, and kind of getting that feedback to immediately get acted on, that kind of stuff, through user research, through just kind of like interviews, etc. That could be product management. Again, lots of docs, lots of content, probably going to be written. And that's kind of the most common thread here, which is like content. And by content, I don't mean just written. It could be videos, it could be talks, it could be podcasts, it could be many ways of doing content. And then we have engineering. So obviously, there's going to be some development involved, there might be some development involved, like you might have an API, someone needs to maintain it, someone needs to write the docs for it, someone needs to run the open source GitHub community that we have, control the contributors, that kind of stuff happen within engineering. There's also recruitment. So kind of obviously, you want someone to talk to the audiences at various events, etc. And act as this kind of liaison. And that's obviously what DevRel people sometimes do, in some cases, not too often, not too many times. But anyway, we've kind of established that DevRel is a lot of things to a lot of different companies, a lot of different people. Techniques change, approaches change, kind of tactics, strategies, they change. But the main objective is the same. We're kind of there to liaise between developer communities, present the company to the developer communities, present developer communities to the company. And yeah, we work on a very hectic schedule. No two days are the same. We need to prioritize ruthlessly, we need to deal with a bunch of stakeholders. And yeah, a bunch of that actually sounds like tech leadership, to be honest. To go back to my story originally, DevRel is many things, but so is engineering and especially engineering leadership. You're working in this kind of weird schedule. People are much more important than pure tech output. And yeah, we're two sides of the same coin, you could say. That's the only gif I had, by the way. Let's look at examples. In this part of the talk, I'm going to just talk about a few areas where you could collaborate with DevRel, where you could get the most value out of us. And for us also, vice versa, where you could provide most value to the DevRel team. So yeah, let's get technical, because trust me, we are technical. We might not all be engineers. I have an engineering background personally. A lot of dev advocates do have an engineering background, but a lot of us don't. And that's completely fine, because our job is essentially to be able to have a technical conversation with people, but not necessarily we don't need to output code on a daily basis. So yeah, we are technical. I can have a conversation about any technology that you want. I can also help you distill it down to a slightly less technical audience or a slightly more technical audience or a different audience. Anyway, that's what we're really good at. And yeah, you could also say it's bridging things. So bridging gaps between areas. For example, you're in engineering, I'm in marketing. You want to know how things are. You want to change something on the website that you saw. I can connect you to the right person. You want to have someone write a blog post about a technology, maybe for hiring. I can connect to the right person, or I can help you write it. That's completely fine. That's like the gaps bridging we do. Also obviously the community bridging gap. So you want to hear what people are really saying about your product. You want to hear what they're talking about it on the streets or I mean, conference hallways or meetup rooms or whatever you want to call it. We can provide that because we are out there. We can also try things out ourselves. If you have a preview version of an API that you're building or a product we're building, we would gladly have a first go at it, give you some feedback, tell you, hey, your docs are missing a couple of things here, a couple of things there. These things are wrong. These things are out of date. Because obviously if we catch them before the community does, we don't have to deal with the support aspect of it. So that's good for us as well. So yeah, it's kind of getting that feedback from the streets and from the actual people using it. And not just from the ground level, but also on the industry level, we can provide you feedback on what new trends we are seeing in the industry. That's what we do in marketing, for example. We say, oh, this is platform engineering has been a thing for the last two, three years. It's been growing steadily. Maybe we could talk about them. We could see how we're addressing this audience. And for you, maybe there's like, oh, there's new AI APIs coming out on a daily basis. Do we use them in some ways? Maybe let's poke around. Let's see. Let's do something. I'm telling you, before something gets to this kind of public knowledge level, like AI tools nowadays, there has been people writing blog posts, doing conference talks about them for like a year or two. And that's constantly a trend. And lastly, we can have you raise your team's profile. Your profile personally as an engineering leader or your team's. For example, you want to hire more people, you want to get your face out there, right? Whether it's talking at a meetup or presenting a conference talk or writing a blog post, we can help you edit it. We can help you kind of distill down the idea so it reads better. We can help you get on a podcast, for example, because we probably have some peers doing something. We might help you kind of write abstracts for conferences, for meetups, etc. So all sorts of stuff to kind of get you and your team better out there. And to be honest, if someone is doing a talk on our behalf as an organization, you're doing my job and I'm going to be thankful for it. If I need to sit through a couple of dry runs and read through a couple of abstracts, yeah, I'll gladly take that trade. Anyway, in this kind of very brief, brief, brief overview, we kind of established what DevRel really is, to me at least, and to a few different organizations. It's a lot of things. We do a bunch of stuff. Anyway, we have a bunch of focuses, but our goal essentially is to make engineers, developers successful. Exactly like engineering leadership. Successful team, more productive team. You're more successful. So that's where we are pretty much the same, in the light. And we established a couple of ways and means where you can establish collaboration. And that's all I really have time for at the moment. But I do invite you to ask me some more questions in the Q&A. I'll be lingering on in the chats for another half hour or so. So thank you very much. I hope you enjoyed it. I hope you have a lovely day. And I hope you hear some questions.
