What Engineering Leaders Should Know About DevRel (But Were Too Busy to Ask)

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 dev rel.

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 it's 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, kind of 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, she gets dragged into firefighting instead. She basically pushes back what she was supposed to do on Wednesday, so writing a blog post for their, 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 at 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 a lot of product development, I was doing a lot of stakeholder management as you do, all the marketing, 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 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 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, etc.

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, and 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 development 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 often listened to, and that's how DevRel actually got started in these kind 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 an 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 Raymond of the developer relations team. So it's like much smaller slice of the whole cake. The 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 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 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 dev-rel from where we are within the company. So we can sit in many different departments, from marketing, product engineering, less sales just because incentives are a bit different with sales and their 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 actually one of our booths at one of our events, what we do is we build brand. We build awareness. We stand on booth, we talk to folks coming to hear about us, learning what kind of tools they use, etc. I also give talks, I also give workshops, sit on podcasts, write blog posts, write tutorials, etc. 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, there's this new technology we need to write about, there's this new way of thinking we need to adopt, or even the whole organization really. And we're also 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 will work? And say, yes. You could do even better if you word it slightly differently, 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 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 going to the actual users, kind of demoing things, and getting that feedback to immediately get acted on, that kind of stuff through user research, through just kind of 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 threat 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 to run the open source GitHub community that we have, manage all 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, et cetera, 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, we present the company to 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, there are always 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 outputs, and yeah, we're two sides of the same coin, you could say. That's the only gif I had, by the way. Anyway, 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 also don't. And that's completely fine, because our job is essentially to be able to have a technical conversation with people, but 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. Or you want to have someone write a blog post about a technology maybe for hiring. I can connect you to the right person or I can help you write it. That's completely fine. That's like the gaps bridging will do. Also obviously the community bridging gap. 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 conference hallways or meet-up 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 it. 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. If we say, oh, 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 it's like, oh, there's new AI APIs coming out on a daily basis. Could 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 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 engineer or 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 alignment. 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 chat for another half hour or so. So thank you very much. I hope you enjoyed it. I hope you have a lovely day.