You’re Doing It Wrong — Recruiting a DevRel

This article was co-written with Wesley Faulkner.

Wesley Faulkner is a first-generation American, public speaker, and podcaster. He is a founding member of the government transparency group Open Austin and a staunch supporter of racial justice, workplace equity, and neurodiversity. His professional experience spans technology from AMD, Atlassian, Dell, IBM, and MongoDB. Wesley currently works as a head of community at SingleStore, and in addition, co-hosts the developer relations-focused podcast Community Pulse and serves on the board for SXSW.

The DevRel collective is a community where people in the developer relations field can chat and help each other out. But this post isn’t about that group… We’ll get to that. This is an article about you: the startup founder or manager who’s trying to hire your first developer relations person. This article is here to help you by example.

I’m not the first to write about this problem. Taylor Barnett wrote a great piece on this as well. Be sure to check it out!

But first, let’s make sure we have the terminology right:

Developer Relations is a field that encapsulates all the different roles that facilitate the communication between an organization and third-party developers. That can include a developer advocate (such as myself), a developer evangelist, community manager and much more. But getting started is pretty hard.

How It Started

Wesley Faulkner started this by opening this thread on the DevRel collective community Slack:

“Hey y’all I need a temperature check. I’m getting a lot of LinkedIn solicitations for ‘first developer advocate’ roles. Here’s just a snippet of the last one I got: 'With that, we are looking for our first Developer Advocate* to create our Developer Relations strategy from scratch. There’s no set playbook, but you’ll thrive in this role if you’re passionate about educating developers.'”

His response to this was:

“Thank you for reaching out, but I’m not interested at this time. Hiring someone to execute and do strategy is really hard. Time and time again, I’ve seen this go south in a hurry, and no one wins in that situation. If you review the job description, it is heavily biased towards action. With a first role, there’s a lot to do, and without focus and direction, the results will not only seem scattered externally but internally as well. It’s as if you wake up in a field and want to get out, so you bolt off in a direction. Then it feels like you’re going nowhere, so you turn around and go in the opposite direction. All that work and time gets wasted. My suggestion is to create a solid strategy and direction before getting someone to execute it. You could even hire a contractor or consultant to help with that. Better yet, make that the first role you hire. You wouldn’t open a restaurant with just servers on staff, would you? You would get a manager to make sure that all tasks are delegated responsibly. Why wouldn’t you take that same approach with DevRel?”

I (Shai) have been the first developer advocate at Lightrun, and I can very much empathize with those sentiments.

What Do You Do?

A former boss of mine is running an open source company without a DevRel person. He asked for my help, so I popped into a Zoom meeting with them. It was clear they felt uncomfortable asking this, but it’s the obvious question: “What do you do?”

What Does a Developer Advocate Do?

I can answer this about my job, but I can’t provide an answer for other developer advocates or developer relations. The reason is that our jobs vary too much and include a lot of flexibility.

An open source company that targets big data will have completely different needs from a close source enterprise debugging tool. The job of a developer relations advocate in both companies can be completely different. As a result, a perfect candidate for the job at Company A might be a terrible candidate for the job at Company B.

How Do You Begin?

With Lightrun, our founders interviewed a lot of developer relations people. This didn’t take off. Part of this is the huge demand we have in the market right now. We’re getting a lot of solicitation over LinkedIn by just having that job title.

But another part is the vagueness of our job descriptions. If I’m considering a job, I’d like to know that I’ll be able to do it. I’d like to know what it would require. Unfortunately, that’s something the employer needs to define for the employee… Not the other way around.

Lightrun solved this problem by hiring me. Since I was already a part of the team, I understood the product. I’m a company founder and effectively did developer relations for 20+ years in one way or another (we just didn’t call it that). Since I know what’s needed and understand the company/culture, I could draw up a plan and decide what needs to be done. When we grow this activity, additional DevRel staff can fit into the framework I’m constructing here and improve it with their experience.

Right now with the proverbial “blank slate,” I very much feel the words Wesley wrote about and can understand why people don’t want to be the first developer relations person in a company.

Founder in DevRel?

Most companies don’t have an experienced person on staff already. But most have a technical founder. When reaching out to developers, a lot of the founders do this in an ad hoc way. You post to Reddit or set up a blog and try to get some developers to use the product.

That’s all great and could be the starting point for a developer relations role within the company. But the trick is to turn this into something that’s more strategic and actionable. Are you hiring a developer relations person just to write blog posts?

Where can that person contribute?

What are reasonable KPIs?

What would the day of a developer relations person at your company look like?

What’s the chain of command? Is marketing in charge or is it the CTO?

If you can’t answer these basic questions, you don’t have the infrastructure in place to hire a developer relations person. You can hire the “best” person out there and be disappointed because they won’t know what to do.

I know, a lot is thrown on the shoulders of founders, but if you’re a B2D (business to developer) company, then you pretty much need to understand the role in depth. Otherwise, you’ll have a hard time managing and evaluating the work of the developer relations person.

Some Other Thoughts

Wesley’s thread struck a serious nerve in the community with 63 responses. Here are some highlights, which I think are the perfect TLDR for this post:

“The inevitable reaction in these situations, 3 – 6 months in, is either ‘You’ve gotten great results from your efforts, but we’re not seeing the vision or the strategy part done. Maybe you’re not the one to do that part.’ Or, you focused on the strategy portion, so you get ‘Nice execution on the strategy, but we’re just not seeing the results on the ground. Maybe DevRel doesn’t actually work.’ It is an absolute strategy for failure.” — David G. Simmons

“I’ve seen a number of these first hires fail this summer and now the engineers, first advocates themselves, feel imposter syndrome and otherwise about DevRel. And it was the stakeholders’ fault for not having their strategy known to their hire.” — Tessa Kriesel

“This is a well-articulated response with understandable examples. VP of Eng/Mkt should do a lot of legwork in these small companies on that strategy piece BEFORE hiring the first DevRel.” — Dewan Ahmed

“It’s been a different experience for me. As a first devrel at $CURJOB, I had a lot of existing trust with the founder/exec team and executing on a couple of tactical things (docs, tutorials, forum) helped build some credibility. The main strategic goal when I was hired was ‘get more pageviews,’ though since then it has been refined since. We’ve been working toward a strategy, but one hard thing about a strategy at a small company is that it is difficult to formulate. It’s hard to do internally (to make the time) and hard to know who to trust to come in and consult. It’s hard to find the right fit (esp when you are still trying to do the tactical stuff at the same time). I doubt I would have had the same success without the deep trust I had with the founder.” — Dan Moore

Originally published at The New Stack.