(Updated 6/24/24)

To quote just about every single founding team in developer and data tools right now: “how do I hire a developer advocate?”

This is unfortunately not the type of question with a quick answer. Hiring a developer advocate is hard, and may take you longer to fill than a traditionally structured role like software engineer or account executive. While what we’d call DevRel today has been around in one form or another for years, experienced practitioners are far and few in between; the hybrid skill set of technical prowess combined with marketing firepower is rare indeed. And to make it even more complicated, most companies I talk to who think they need DevRel actually just need marketing.

This post will walk through a few tips for how to hire your first developer advocate, with some practical examples from companies like Retool, Hex, Warp, and PlanetScale. Thoughts or comments? Tweet at us to get the discussion started.

The developer advocate taxonomy

What do developer advocates actually do? What different types are there? And do you really need to hire one?

5 or 10 years ago, selling technical tools involved writing PDF whitepapers and sending several long emails to some CIO in Florida. Today, most technical startups are paying at least some attention to bottoms up or product led growth – building an awesome (maybe self-serve) product experience, along with a powerful community and portfolio of content. Community and content bring in leads that can eventually be worth a lot to the company. The new marketing is a great product experience, as they say (well, someone probably said it).

This shift has led to a newfound respect for creating content and building community, two job functions that haven’t always been particularly in vogue. How do we write blog posts that are interesting to developers? What should the quickstart in our docs look like? Should we use Slack or Discord for our community? What even is community?!

Jarod Reyes ran marketing at PlanetScale and has managed several teams of developer advocates over the course of his career. We chatted about a few DevRel related topics, and he believes that the role of a developer relations in the early stages is primarily growth related:

“If you are early stage – just trying to get the product into the hands of developers – you really should be driving growth (signups, downloads, installs, etc.) and surfacing product feedback – which means building a very tactic-oriented team. Do a lot of stuff, measure it and worry later if it’s the right stuff.

Normally, creating content and building community would fall under traditional marketing responsibilities. But when your audience is technical – developers, data teams, IT, etc. – it’s hard to create interesting content and build community without the requisite technical background. Hell, it’s hard even with the requisite background. This context – and these needs – are usually what spur founders (perhaps you too, dear reader) to consider hiring their first DevRel person.

Content-focused vs. community-focused advocates

Some developer advocates shine when creating content, while others like to focus more on community building, events, and shuttling product feedback between the community and EPD teams. If you hire a community-focused advocate and expect them to spend most of their time creating content, you will have an unhappy camper. Content-focused DevRel has significant overlap with traditional marketing; community-focused DevRel does not.

So spend some time thinking about where your needs are as a company. Are you looking to drive top-of-funnel and awareness? Do you need someone to work with customers and build demos to help close deals? Or maybe you want someone to jumpstart your community and run your first few events?

Your sourcing and hiring efforts will change based on which profile you’re looking for. When I talk to founders about why they’re hiring a developer advocate, it usually boils down to either (a) growing top of funnel, or (b) making the existing developer audience more successful. These are completely different goals and it’s unlikely you’ll find someone good at both. Aligning the team on what you really want is the first step in the hiring process – in the many failed processes I've been a part of, the culprit is usually that the team isn't really on the same page about who they're looking for.

Content marketers and community managers vs. DevRel

The two main roles of DevRel – creating content and building community – often go by other titles. If your primary need is content creation, in theory you should be hiring a content marketer; the problem is that it’s almost impossible to find any with the requisite technical expertise to create content that’s genuinely interesting to technical teams. Developers who want to create content full time usually call themselves developer advocates, and even if that title isn’t exactly what you need, you might not get it anywhere else.

Similarly, the title of community manager has existed for decades. If your primary need is building community, in theory you should be hiring a community manager; the problem is that it’s hard to build a community of technical users if you yourself are not technical. If you aren't deep in the product, you won't be able to build community (at least in the early stages) around said product. Hence, teams look to hire developer advocates.

Be open to hiring from these more traditional profiles! You should think in terms of needs and problem solving, not titles or roles; if you need content created, hire someone who is good at creating content. If you find that it’s more effective to use a different title, then don’t hire a developer advocate! Like we covered above: the first step of the hiring process is figuring out what you actually want. You don't need a DevRel person, you need specific problems solved. If DevRel can solve those problems, great, and if other people can, then that's just as great.

Ownership vs. contributions

Developer advocacy, especially in the early stages, is going to be a fairly open ended role that requires a good degree of independence. Some candidates will be better at this than others. Some people want to own, while others are more content doing good work directed by a leader.

If you’re hiring someone to own content instead of just producing content your bar for experience should be higher, e.g. an engineer transitioning to advocacy is probably not a good fit. When interviewing (see sample questions below), you should be asking higher level questions like:

• How would you build a content strategy?
• How do you measure the success of the content you’re producing?
• How do you think about hiring a team around you?

Throwing individual contributors into situations where they’re given no direction and are expected to figure out their own roadmap is a recipe for failure. If you need this person to be a “self starter” as they say, make sure you’re screening for that in your interview process.

Sourcing developer advocates

As with any role at an early stage startup, expect that most of your quality candidates will not be applying on your site; instead, you'll need to actively source them yourself. The theme here is that you’ll need to get creative – unlike other roles, a great developer advocate for your company might have never been a developer advocate before. They might be a contractor. They might be based in a country you’ve never hired from before.

Where to source developer advocates from

The next section focuses on different profiles to source from. At the early stages though, it can be more effective to focus on finding people who have genuine expertise and empathy for your audience. They can come from any number of different backgrounds, and you may miss them if you’re looking for a specific profile. I've seen teams have success with hiring someone who is really deep in the product and passionate about it, even if they don't have a DevRel background.

Here are some ideas:

1. Source from your community

If you have your product out in the wild and some early subset of users (this is a spectrum obviously), your first developer advocate might be one of them. Keep in touch with your power users and don’t be afraid to ask if they’d be interested in joining the team.

Chris Smith was a developer advocate (and former sales engineer) at Retool. Before joining Retool as an employee, he was actually a power user and one of the more active members in their Slack community. We asked Chris about his journey from community member to community builder:

“I fell in love with the Retool product and started wanting to connect with other Retool users and learn from them. I joined the Retool power user community to do this and it was a great entry point into meeting people at the company. After a couple of chats with people on the Retool team, it was an easy career move to join a great company that I already knew and enjoyed using the product and sharing about it.”

Sourcing from the community means that your candidates will already understand the product and audience; they’ll be knee deep in the pain point your company is going after, which is a huge plus.

Concerned readers may note that it’s dangerous to poach your power users early on, and this is certainly true. You can start, though, by building a relationship with them and seeing where it goes; this is standard practice for community building anyway. Ask them for their feedback on the product, send notes / tokens of appreciation, etc.

2. Work backwards from content

Any time you read an interesting piece of technical writing or watch a quality video, pay attention to who wrote it and see if they might be someone who could be a good developer advocate for your company. Ask your engineering team who they read consistently. About a quarter of what gets to the front page of HackerNews is from personal engineering blogs; read them and see who you like.

If you aren’t regularly consuming content from the broader technical community, you really should start doing so; otherwise sourcing this way is going to be hard. And you also need to develop your own sense of taste for this stuff. Check HackerNews periodically, subscribe to newsletters like Console.dev and Materialized View, and follow some developers on X.

3. Good ole LinkedIn and email outreach

Once you’ve put together a list of potential candidates, nothing substitutes for just reaching out to them cold. Writing intentional, non-bulk emails or LinkedIn messages will help your case. Consider referencing specific pieces of content of a candidate’s that you’ve read and adding a thoughtful comment. If someone emailed me and told me that they liked a particular sentence or paragraph in a blog post I wrote recently, I can tell you for sure I will be responding to that email.

The best candidates will be getting a lot of cold inbound, and most of it is going to be generic, so taking the time to personalize things can go a long way.

4. Referrals

While you probably have already thought of this (I get many, many texts asking me for good DevRel candidates), looking at referrals through the lens of community might give you some new ideas. Because sourcing DevRel ends up being a lot about finding someone who understands your audience, consider asking your early users if they know anyone who really gets the space and who they respect. You can even ask your VCs who they talked to when they did their diligence; whatever way you can find people who are thinking about the problem in the same way.

Profiles for sourcing

Who makes good developer advocates? And who should you look for?

1. Engineers looking to transition

There are developers out there who enjoy writing and community building, and might be interested in doing it full time. They’ll likely already have a personal blog, or authored an open source package they’ve built a community around. For example, react-native-vision-camera (a library for building camera functionality into your React Native apps) appears to be built and maintained by an individual developer, Marc. Marc may not be interested in DevRel work at the moment, but he probably knows a lot about it by now given the work he’s done.

Be wary of developers who say they’re ready to transition to advocate, but haven’t taken the time to start publishing or community building. If they're passionate about this, it's fair to expect they've taken some initiative towards it. A safer path for these folks is to hire them as engineers (assuming they meet your bar), give them the chance to write and build community as part of their day to day, and see how they perform.

Also, keep in mind that developers looking to transition will command developer-level salaries, and you should be ready and willing to pay those salaries given how important this role is.

2. Technical community managers

This is a role that’s most likely to exist at a bigger company, but there’s a lot of overlap with responsibilities of a developer advocate. Technical community managers may work on documentation, communicating with users and bringing that feedback to the product team, and building useful demos.

For example, Izzy is a developer advocate at Hex who focuses on building community. Before Hex, Izzy was a technical community manager at Looker; the job titles were different, but the experience overlaps more than you might think. We spoke about his experience at Looker and how it translated to Hex:

​​“I like to think of developer advocates as really, really excited and skilled users of their product that simply can’t contain themselves— they have to write about it, have to post their latest examples, and have to help as many people as possible build awesome things with it.

At Looker, I was responsible for building and growing a community from the ground up in a “program manager” role. But after initial scaffolding, my job started to look more like just being a really, really excited and skilled user. I simply couldn’t contain myself— I had to post about this new LookML pattern, I had to answer someone’s question, I had to make sure someone got their hello world app running. That’s… developer advocacy! Being a key contributing member of a technical community, even in a ‘management’ role, translated perfectly to full-time DevRel work.”

Community is a key part of what a developer advocate does, so finding community builders with technical chops can be a good wedge to get started.

3. Solutions engineers / architects

They're often overlooked (in several ways), but SEs have technical backgrounds and direct experience working with customers. Some even contribute to documentation or occasionally write for the blog. Why wouldn't you try and hire them?

4. Developer advocates (of course)

This is the first place you’d probably look, but it’s not first on the list. That’s because there aren’t that many of these people around, they’re very expensive, and many of them just aren’t that good.

For whatever reason (I'll speculate in another post one day), there has been a proliferation over the past few years of inexperienced, low quality developer advocacy. I've interviewed dozens of candidates with only a year or two of professional software engineering experience, no meaningful domain expertise, and poor writing and communication skills – they are more akin to a YouTuber or a content creator than they are to what startups really need from their DevRel people.

In the same way that not all engineers are good engineers, you’ll need to exercise a discerning eye; is the content that this advocate has produced any good? Are they technical enough to really understand and work with your community?

Evaluating content quality is beyond the scope of this post, but some top level things to look for, across both writing and video:

• Is the content technical? Does it demonstrate true domain expertise?
• Is the writing fluid and easy to follow? Does the writer tell a story?
• For technical tutorials, do the steps actually flow into one another? You’d be shocked how often they do not, and there are critical pieces missing.
• Are the topics they’ve chosen interesting? If they aren’t novel, is the content good enough to make it worth reading?

When your job is creating content, it’s obviously not all going to be excellent: but you should be able to get a good sense of what they’re capable of.

5. Developers in education

Developers who are educators in the ecosystem can be interesting candidates for developer advocate roles. You can find these people teaching at bootcamps, running internal developer education at larger companies, or doing sales enablement at technical companies.

Interviewing developer advocates

What makes a good developer advocate? And how do you screen for that in interviews?

“I think a good advocate is someone who can operate with autonomy (entrepreneurial, handle crisis well), is empathic (can anticipate someone’s needs, educate), and is technically hungry (which means they are always learning and going deeper in their tech skills). On our team we make sure we identify the empathy and entrepreneurship first. The hard skills – the technical piece – is much easier to train. The soft skills really need to be present before I have confidence this person can execute.”

Jarod’s focus when interviewing is making sure the candidate cares about the audience in a meaningful way, and has the entrepreneurial “spirit” so to say to go and find opportunities instead of waiting for them to show up. This is of course something that would be nice to see in every hire you make, but especially important here since this role is unstructured and will likely report into a manager doing something completely different than them.

Sample interview questions

When you’re interviewing, focus on sussing out the candidate’s autonomy, empathy, and technical background (these sound like buzzwords, but they’re not). Here are some questions that the team at Warp uses:

Autonomy – will this person find opportunities by themselves?‍

• How would you describe our current brand and community? What would you change about it?
• Who do you think our target audience should be?
• How would you approach growing our community?
• How would you approach thinking about what kinds of content we should be creating?
• Walk us through a project that you directed. How did you come up with the idea? What impact did it have?

Empathy – does this person deeply care about our audience and the problem we’re solving?

• What about the problem we’re solving resonates with you?
• What makes you excited about the product we’re building?
• Do you have any constructive feedback about the product?
• Note: if the product is generally available and the candidate hasn’t taken the time to try it out, this is not a good sign

Technical background – does this person understand technical audiences? (the “developer” part of developer advocate)

• What’s one of your favorite tools you use as a developer? What’s good about it, and what’s not so great?
• What are important elements of good developer documentation? What companies do you think have good developer documentation?

As you think about which questions you’re going to ask, try and put together a healthy mix of forward looking ones (“how would you do x,y,z”) and backwards looking ones (“what’s an impactful project you worked on”).

And once you’ve got conviction of course, don’t lose candidates to bad offers. It’s a crazy market out there, and if you find someone good, chances are they have an offer from someone else already. Pay your developer advocates at a similar level to what you’re paying engineers, or you will get rejected more than not.

Try a take home

We spoke to the teams at Warp and Retool about how they interview developer advocates. Beyond the standard interview loop, one thing that stood out was the use of a take home assignment (controversial, I know). Especially if you’re interviewing candidates who haven’t been developer advocates before, this can be a good way to figure out how they’d approach things. Don’t expect polished, finished work; look for the thought process instead.

Your take home exercise should match your hiring goal. If you’re looking for a developer advocate to primarily focus on content, ask about how they’d decide what content to produce, and how they’d go about producing it. If your focus is on community, ask them to put together a plan for growing the community. For example, Retool’s take home exercise asks candidates to consider how they’d approach figuring out what topics to write about:

“How would you strategically approach figuring out what topics to write about? What sources of data might you consult?”

The more ownership you’re looking for in this role, the more important the take home is. If you’re looking for someone who can just produce the content you tell them to (don’t do this), you should be able to evaluate their existing writing; a take home won’t give you much information you don’t already have.

The sequence of the take home in the interview loop deserves special attention. I’ve seen teams use it right after an initial screen as a low touch way of adding an additional filter before the effortful and time consuming onsite. I’ve also seen teams use it after an onsite because they still don’t quite have conviction in the candidate. And finally, some teams will use it selectively, and only use it with certain candidates. For your loop, think of the take home as an added layer of fidelity around the candidate’s work, and apply it only if and when you need it.

This should go without saying, but make sure to pay your candidates for their work!