Developer relations is a strategy, not a role

Chris Riley, Senior Manager of Developer Relations at HubSpot, is a "bad coder turned technology advocate", who has a passion for modern development and how code is changing the world.

We sat down with Chris to talk about how there isn't a one-size-fits-all approach when it comes to developer relations, as well as what the developer journey entails.

You can listen to the full podcast interview on Spotify and Apple or enjoy the highlights of our convo in this article.

My journey into developer advocacy and tech evangelism

I like to tell the story not of my career history, but of the history of advocacy and DevRel because there are lots of folks getting into DevRel today that don't fully understand the genesis. And that's important and that's where I see a lot of misconceptions.

I've officially been in advocacy and tech evangelism for 15 years. But when I started my technical career, I started as a software developer and moved my way into sales, engineering, product management, and marketing for a while. But I was always at a company that was selling to developers.

What organizations have realized was that the traditional approaches and each of those categories wasn't going to cut it. So it took the original tech evangelist, Guy Kawasaki, to publish content around tech evangelism. And then it was a combination of Microsoft and Sequoia who pushed their portfolio companies to build out this new tech evangelist role.

It went crazy in the startup world, and I was a part of that. I was part of a Sequoia company and was brought in as one of the first tech evangelists out there in the industry. And that's where I've been ever since.

The title of ‘tech evangelism’ has greatly evolved. I went through several startup SaaS companies, and for a fairly long stint, I was actually a co-founder of a developer marketing agency that was exposed to about 120-150 DevRel practices. And that's really where I got my playbook. That's where I understood what works and what doesn't work.

Around that same time, the term ‘DevRel’ came out. As far as I can tell, DevRel was just building on the idea of tech evangelists and taking it one step further into other disciplines, documentation, events, communities, etc.

Developer relations is a strategy, not a specific role, and that's where I see the biggest misconception today.

When I left the agency, I created a playbook, and I've been running off that playbook for several years now. It’s been tremendously successful. And when I say playbook, I don’t mean a checklist guide, it's a framework.

I love being a part of the growth of the industry. I'm authoring a book on it currently. It's really exciting to participate in this evolution, and hopefully, in a small way, this helps people understand where it all came from.

I was never a very good developer. I was more of a hacker. Although, when I was part of building an OCR engine, it was a category of technology that I was extremely passionate about, which was recognition technology. I dove into that and built some really cool things.

What I struggled with was all of the logistics around building applications versus the code itself.

What was interesting was that I really wanted to write blogs. I really wanted to speak. I had this aptitude to communicate and engage with developer audiences beyond putting my head down and writing the code.

The first iteration of that was sales. Folks noticed that and said, “You know, when we get Chris on the phone, things go really well.” So I was put in a sales role.

I didn't like the comp structure of sales, but I really enjoyed engaging with the developers and being able to talk about tech, but not being the one responsible for the tech. I got to communicate it, but not be on the hook to make sure they got it done and it was bug-free.

That was really where the jump happened. Again, the role didn't exist at that time, so I poked around because I knew that this was what I was interested in. I went into product management, which had some elements of it, went into product marketing, which also had some elements of it, and then eventually arrived at where I am today.

Removing the stigma of neurodiversity in tech

Neurodiversity is a very uncomfortable topic for folks. And of course, when I say the word neurodiversity, there’s a wide range of things within it. You don't have to be diagnosed.

You can self-identify as neurodiverse. You're not breaking any rules if you do that. The reason we use the term is to distinguish behaviors that are different than what society has told us is acceptable or unacceptable.

I've been in tech my whole life, so this could be an availability bias, but I’ve noticed that there’s a more abundant amount of neurodiversity, autism, ADHD, etc., within the tech field than there is in other spaces.

I'm really passionate about folks being allowed to be themselves, not just because it’s right, but also because it promotes efficiency. Work gets done faster and it's more effective if you’re able to get things out on the table that are always lingering in the back of peoples’ minds.

My journey in neurodiversity started when I was 17, and I continue on to almost 42 now. It's been extremely important to me. My current diagnosis is ADHD, dyslexia, and potentially high-functioning autism.

One of the things that I was born with is the ability to be vulnerable without being too afraid of it. And I feel a responsibility to leverage that to give a voice to folks that don't yet feel comfortable being vulnerable and are forced to mask their entire careers because they don't think it's healthy or good for the company.

I’d rather think about it as, how do we maximize the power of our neurodiverse folks? They have superpowers and they can do amazing things that every organization can leverage and grow on.

I've seen a lot of really disturbing neurodiversity content out there. There are organizations that produce presentations on how you should communicate, how you should respond, how you should behave, etc. I think that's completely missing the point. The primary point is awareness and allowing the conversation to happen. You shouldn't pander to somebody.

I assume that a lot of this content has been created by folks that would consider themselves neurotypical. But I don't like that. I think it's dangerous and offensive in a lot of cases. So, what I'm trying to do is just make the conversation okay.

I’d personally never want my life to be different. I don't call it a disorder. Instead, I say, ‘living with ADHD’ because there are a lot of challenging aspects of ADHD, especially in personal relationships. But also, I wouldn't have my job without it. I wouldn't have gravitated toward advocacy. All of these things are the direct result of living with this, and so it's also my benefit as well.

The 3 different types of developer journey

There are many traits or characteristics that the developer audience tends to share, in particular, how this audience gets information, consumes that information, and what they do with it.

This journey splits up into three general categories. The first journey is, “I need an answer to a specific question.”

Number two is, I’ve heard there’s something new and cool and I want to know more about it.”

Journey number three is, “I think I can use this tool to do what I want to do, but I'm not 100% sure.”

Within each of those journeys, I think the behavior of the developer audience is pretty consistent. For example, the pure question and answer is going to be documentation, usually starting with a Google search. The second journey will focus on YouTube videos and blog posts.

And then the art of the possible is going to be scanning a wide range of technical resources, including blogs.

Documentation is probably the only use case where a developer might go directly to the site versus going to Google.

Why does that matter? It allows you to create a really good framework and optimize around those journeys. But for somebody who comes from a more traditional marketing background, it also means there are a lot of tools that you're used to using that don't matter at all.

Things like ads and email drip campaigns are useful, but they're not necessarily useful for enticing somebody to take action.

The other thing is that it's very problem-solution focused. Developers tend to be very problem-solution focused unless they're tinkering. So, you have to know when they're doing one of those two things.

If they're tinkering, that's when it's more fun and when more traditional marketing efforts work. But if it's problem-solution and you get in their way and impede expectations of what they hope to get when they click the button, that can backfire in a very public way sometimes.

It's important to know that, and I haven't really seen that change over the years. Even when I was building SDKs, it was the same way, but just a little bit harder to get to the information.

We want to be able to identify those moments, but it doesn't mean we should or have to. There’s a bit of, “If you do the right thing here, it’ll work out for you.” But that takes a little bit of faith.

If you focus your attention on reducing friction, filling gaps, and making sure that each one of those journeys is as seamless as possible, you're doing the right thing.

I know it's uncomfortable to say, but we’ve got to go out and find them. And I can tell you where that comes from - it comes from metrics and it comes from a data explanation inside of the business on how this is supposed to work.

If you do the right thing and you have a good product, they’ll come. And they’ll demonstrate the behavior that you want them to demonstrate.

Choose which one you want to optimize because you can't choose them all at once. That’s a different kind of business decision. This motivation of needing to find them might not be the right way. Just as we see in product-led growth, it's the same thing when engaging with developer audiences. It's a pull versus a push.

Targeting developers through relevant technical content

I don't think I've worked at any company where I didn't have the marketing team come to me and ask, “What are the blog posts that developers read? What gets their attention?”

There aren’t many places out there. Of course. there are the foundational places like Stack Overflow, and dev.to is a popular blog, but it's not generally tied to the workflow or life cycle of a developer. You need to be a part of the workflow and the life cycle.

I'd say there are two things that are hard truths. First, your product isn’t the only product that developers are working with. That's really important to know because you need to think of your persona as somebody who’s dealing with a lot of things all at once, really complex challenges, and it's not your product. That's why getting things pushed in their face can be extremely frustrating.

So, what do you do? Part of it comes from your org structure and what type of business you are. Are you tech for tech? Are you selling technologies to techies? Or are you tech for the purpose of expanding and accelerating your customers' adoption of your product?

For example, at HubSpot, our API is used to expand the capabilities for the specific use cases of a company. It takes a developer to customize to do that, but the developer isn’t the direct customer in this case. Whereas at Splunk, another place I worked at, the developer is the direct customer. Your behavior’s going to change in those two scenarios.

When I say org structure, where does DevRel lie within your organization? How do they partner with marketing if marketing isn't a part of developer relations? Maybe it shouldn't be a part of it.

Is the marketing org tethered to leads? Is it traditional marketing metrics? Or are they tethered to more appropriate metrics like share of conversation, which is different than share of voice? Or adoption of API? Or interactions on the newsletter? Newsletters are very powerful.

That's a hard question to answer because for the vast majority of organizations, the first thing I’d probably do is switch up how things were organized.

However, things like newsletters are really good. Driving sign-ups to newsletters is really good as long as that newsletter meets the expectations of what developers want.

Make sure that your dev portal is seamless. I'm going to use the word ‘findability’ here. That’s not SEO. That's one of the biggest misconceptions.

For most organizations, if you look at your developer portal and your documentation site, it’s probably the number one source for inbound organic traffic. You want to make sure that if a developer asks Google a question, they get the right answer, which is via content on your site.

What you can do as a marketer is try and make sure that there isn't another site out there that’s doing a better job than you are of having technical content. Focus on appropriate and useful blogs and make sure you have taxonomies in your portal that are intuitive in aligning with those journeys that I mentioned. All of this is super critical.

And again, it's not SEO. Yes, keywords are important, but that's not what you're optimizing for. That’ll actually lead you down a bad path.

Don't try to out-tech developers

How I see developer marketing is more akin to a product marketing role. Sometimes DevRel is a part of it, and sometimes it's not. But I've never been in an organization where the developer marketing component wasn't my primary stakeholder. That relationship is absolutely critical.

And it has to go both ways. What you rely on marketing to do is to give the high-level messaging that ties the business value of the product to why development for that product is needed, or why developers should care. It shouldn't be super fluffy.

But why is that important? While product marketing is important, you want consistency across your message. Otherwise, it just gets confusing.

Then you rely on developer marketing to be your conduit for your distribution of content, getting it out there, getting in front of the right people, and ensuring consistency. It’d be very hard for advocates to worry about the consistency of content as it goes out.

One of the biggest mistakes that I've seen a lot of organizations make is trying to out-tech the techie. They don't need to learn new technical concepts from you. And especially if you're a marketer, don't try to out-tech a developer.

It's just not worth your time. You want to make sure that they get to the information you want them to get to as quickly as possible.

Do developer marketers need to have technical knowledge?

I think it's really important for a marketer to have that technical knowledge. Anytime I've been a part of hiring panels for the marketing side, it's been a chief thing that I've looked for. I'm on the panel for that very reason, to vet the technical competencies.

Do you need to have had a history as a developer like I’d require in advocacy? No, not necessarily. But you need to have a strong understanding beyond the perspective of how these technologies come together, why they're used, and what they're used for.

That can seem intimidating, but it really isn't. There isn't a lot of technology out there that you can't reduce down to some simple analogy.

Take containers for example. Talk about containers in containers, essentially. It's easy to move containers, and it's easy to copy containers. It's not that hard to synthesize this stuff.

Something very subtle and nuanced in an email can trigger a developer. I know this because it's been done to me plenty of times.

I've had previous employers where I was part of vetting emails after I left, and I saw an email and just hated it. So I went back to them and said, “You can't do this. You can't talk like this to a developer. It's pandering.” It came from this place of trying to teach tech to the people who do it all day.

Understanding when and why you need DevRel

Most organizations know that they want DevRel, but they don't know why. They know it's important, but they haven't established why.

Having that ‘why’ matters a lot. The current world of developer relations professionals have been their own worst enemies in some ways. It's a role that's been around for a long time, but it still feels new. It feels new because there hasn't been a lot of strategy, and DevRel folks are generally not very good at communicating to the business.

By doing that, they shoot themselves in the foot and they allow the business to control their destiny versus the way it should be. They’re the professionals, so they should be controlling their destiny.

If you have a public API and public API docs, you probably need a DevRel practice. Unless your community is so small that your sales engineers essentially end up being your DevRel, you probably need a DevRel practice.

If you're selling to developers, then you already know this. I don't need to tell you that you need DevRel. If developers are in the decision-making tree for your product, you need DevRel.

Now, how you assimilate that is interesting. Do you start with advocacy? Do you start with community? Do you start with developer marketing only? I think that has a lot to do with the business.

I'd say advocacy is probably the best place to start because the typical developer advocate can influence and direct all of those components. They touch all of those, whereas community may not be as involved in marketing and documentation teams, which I feel should be a part of DevRel but may not be as involved in marketing.

Then, once you address that and say it's advocacy, the next thing you need to know is what your primary goal is right now.

If you're a startup, it's usually that you want to make a lot of noise. In that case, maybe you don't build out a whole function and you just hire one advocate who’s very loud. But that won't last long. It’ll last about one or two years. You have to start thinking about a framework and a strategy, and I think that's where the DevRel industry’s fallen short.

The loudest developer advocate is probably the worst thing for your organization long term. I've seen brands live and wither based on a single developer advocate because they're not going to be at your company forever.

When I hire developer advocates, I don't hire based on followers and popularity and all of that stuff because I can teach all of that. There’s a formula for doing that. It's not rocket science.

What I can't teach is the inspiration for creating good content, the empathy for developers, and understanding those developer journeys that I mentioned before. You have to be inspired in wanting to do that and getting in front of people in a public way.

But I don't need popularity because that’s really hard to scale. You can't keep on hiring the lead A-list movie star every two years. You just can't do that.

Creating authentic DevRel content

When I was in the developer marketing agency, I was part of establishing the de facto standard of curating, authoring, reviewing, and publishing developer-related content. And you've seen it emulated over and over again now, so there is a formula there.

Curation is sometimes underestimated in terms of how important it is, how long it takes, and how much effort needs to be put into it. Invest in a really strong curation process that’s informed by the business and your target personas. I know we use the term developer, but there are a lot of different types of developers out there.

Also, make sure it’s informed by which journey you want to optimize. There's a list of questions you should be able to answer for every single topic you think you're going to create content around.

And also think about the type of content. Is it a tutorial? Is it a blog post? Is it thought leadership? Is it a white paper? Is it an eBook? A landing page? A technical article? There’s a list of questions you should be able to answer that tell you whether a topic is appropriate and a type of content is appropriate or not.

At a high level, if you're focused on solving problems, answering questions, and being a steward, you're doing the right thing.

There’s always the question of, “How do I convince them to do this next thing?” Well, developers can smell you trying to convince them to do something from a mile away. Sometimes they're okay with it. Sometimes they're not okay with it. So, investing effort in saying you want to convince them is the wrong goal.

The way you can walk the fine line is this: in your content, you very clearly make a correlation between whatever that topic is and the product or trial.

Sometimes it’s already there because you're writing content about the product itself. But if you're starting at the first part of the journey, which is, “I heard about this thing, it sounds cool and I want to know more,” as long as you're transparent, you make a direct connection to the post, and it doesn't look like you just put it in there for fun, then that's fine. That's totally acceptable.

Unless it's thought leadership, marketers probably shouldn't be writing this content. They should be facilitating the creation of the content. It should be written by technical audiences, and it's not just because of the topic matter, it's how techies communicate.

I don't know what it is, but a techie can spot a techie very easily. They know if you know your stuff or don't know your stuff. So it's important to have proper representation. They want to see their peers show up in the content, whether they're internal or external.

Take a human-centered approach when engaging with developers

When engaging with developers, you have to come off as human.

Personally, I won’t follow brands on Twitter unless I'm working for the company or I’m specifically interested in a certain product. But if you do have a brand handle on your Twitter, your tweets should feel like a human, not like a company. The human element has to come across.

The thing that’s the most scary for folks in the tech field is that techies can be critical. They can be very curmudgeonly, and that can be scary. But you just have to accept it.

You could write the best technically accurate blog post on Earth that gets a lot of traffic and goes viral, and somebody will always complain about it. It's almost a measure of success if somebody complains about it because you know that it got enough traffic that somebody complained about it.

So, you can't worry about that. You just need to make sure that the personality and character of the company comes through because techies like to engage with people, not companies. And I think that's true for everybody.

Those cold messages you put out there will land with a thud or an eye roll and it’s not going to get the reaction you want. The best-case scenario is that you just wasted your time.

Understanding what the developer audience wants

If you're a marketer and you ask, “How do I find developers?” And then you start looking at broad developer events, it's not going to serve you well. Focus on the developers that are using your product today and the ones that are being successful with it.

There’s a risk here that you over-optimize for today's audience and sacrifice your future audience, but you need to know that.

You should be persona focused. A persona is more than just a developer’s title and what they do. It’s things like, what are their motivators? What are they building? Why are they building it? How are they trying to advance their career? Where do they fit in the developer world? How engaged are they in your community?

The best way to understand those things is to look at your current developer audience. If you don't have that luxury, that can be challenging. But if you already have a developer audience, even if it's 10 people, understanding why they’re committed is crucial because developers usually become very committed to the tools that they use. Once they're in, they're in.

So, you probably have that audience. Figure out where they came from, what they're doing, how they got there, what they liked and didn't like, and what they’re passionate about. And you'll be very surprised that the answer is that none of it’s going to relate to an email or an ad that they received.

I have an asterisk here, and that asterisk is open-source developer communities. With open source communities that have a commercial aspect, either a SaaS-hosted offering or a commercial version and it's actually open core, your approach has to be radically different.

If you're thinking, If we just convert 2% of the open source community, we’re going to be rich, then you're doing it wrong. And that’s a dangerous place to be because open source communities need to be respected. The boundaries are very clear and dry, and actually, you have two DevRel strategies. You have one DevRel strategy for the open source community, and you have another strategy for the commercial product.

On the open-source side, I'd say that your priority is scale. If you have an open source community today, you already have the seed. Don't ruin that. Don't try to create a new one. Let it be; your job is scale.

It's a community effort, which means you want to help create more peer-to-peer connections. You also want to help make the work more visible. So you push that envelope out to be bigger and bigger and bigger.

But you don't interfere with the conversations or interfere with the content. You don’t put anything in front of them that looks like you're trying to sell a commercial product. Often, the active open source user isn’t a commercial customer anyway, so it's not the best use of your effort to go down that path.

I think you draw a very clear line. How do you get them to make the jump over the fence so that you can have the commercial conversation? They need to elect to do that on their own.

And again, scale and connections. If you expand the awareness, reach, and breadth of the open-source community, not only are you going to help the deals that are happening that were initiated on the commercial side, but you’ll eventually have somebody in the community realize when they've hit a wall.

When it's become too complicated, when they need more scale, or when they need better performance, whatever your value prop is over the open source, they’ll realize it for themselves.

I know there's a bit of confidence and trust that has to come with it. But I've seen organizations do this very well. I've also seen the vast majority of organizations do this very poorly.

Best practices for success in DevRel: Key takeaways

DevRel folks need to get better at communicating with the business and controlling their own destiny because the business doesn't understand DevRel as much as they understand it.

Also, understand that DevRel is a strategy. It's not a role. It has a lot of different components to it. There’s a whole history associated with how DevRel came to be, and it's worth understanding that.

A lot of people get wrapped up in being loud and tweeting and using Instagram, and end up neglecting strategy as a result.

Marketers, whether DevRel’s a part of your org or not, leverage them as a resource. They're not going to understand all the mechanics of marketing, but they can benefit from it. You're also not going to understand all the technical details, and you shouldn't pretend that you do. Try to get a deep technical understanding of your product and the developer persona.

Don't try to out-tech the techie. The best-case scenario is that they just don't listen, but they’ll continue not to listen into the future as well. So it's important not to go down that rabbit hole.

Join our growing community of developers and marketers to forge long-lasting relationships, connect with your peers, discuss topics like DevRel, and so much more!

DevRel is a strategy, not a role

Teresa Garanhel

Chris Riley