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

Rate this content
Bookmark

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.




21 min
09 Mar, 2023

Video Summary and Transcription

DevRel is about understanding the audience and collaborating with different departments. Dev Advocates bridge gaps between engineering and marketing, provide feedback, and stay updated on industry trends. DevRel helps raise team profiles, assists with editing and getting on podcasts, and aims to make engineers successful. Collaboration is key in DevRel.

Available in Español

1. Introduction to Developer Relations

Short description:

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

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.

2. Transition to Developer Relations

Short description:

I started a bootcamp program to address the lack of skills in graduates. I recruited senior engineers, blogged, and spoke at events. Transitioning to developer relations was easy, but I had to prove myself to some colleagues. Trust your DevRel teams and collaborate with them.

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.

3. Understanding the Audience and Internal Placement

Short description:

DevRel is all about understanding your company's audience. In my case, at CircleCI, our users are developers from various technical backgrounds. DevRel started by bringing feedback and insights from the developer community to the company. There are different types of companies, including those that provide APIs or SDKs for developers to integrate with their tools. Some companies have internal teams that need to be up-skilled and kept up-to-date with the latest technologies. DevRel ensures that everyone is on the same page and able to contribute at their best capability. DevRel teams can sit in various departments, such as marketing and product engineering.

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.

4. Collaboration and Value with DevRel

Short description:

In marketing, we build brand awareness, engage with users, and bring feedback to our teams. Product management ensures the best fit for users, rapid ideation, and feedback through user research. Engineering involves development, maintenance of APIs, and recruitment. DevRel liaises between developer communities and the company, working on a hectic schedule and prioritizing ruthlessly. Tech leadership and engineering leadership are two sides of the same coin. Let's explore areas of collaboration and value with DevRel.

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.

5. The Role of Dev Advocates

Short description:

We are technical and can have conversations about any technology. We bridge gaps between different areas, such as engineering and marketing. We connect people, provide feedback, and gather insights from the community. We can try out new products and provide feedback before they are released. We also stay updated on industry trends.

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.

6. The Role of DevRel

Short description:

DevRel helps address new AI APIs and raise your team's profile. We assist with editing, distilling ideas, and getting you on podcasts. We aim to make engineers and developers successful, just like engineering leadership. Collaboration is key. Feel free to ask questions in the Q&A.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.