This is "DX Mailbox", a new "agony aunt" format where we offer quick (not definitive) responses to your questions. Email new questions in to [email protected] or DM @DXTipsHQ and subscribe to our email newsletter for answers!
btw after you hire - check out the first 90 days in DevRel
Question from a Series A founder (read to the end to see who 👀): We're opening our first dev advocate role, and it's not something we've hired for before. Are there any good resources on setting up a process, attributes to look for, interview panels, etc?
The most important thing to note about a "first hire" for anything is that you're in a mutual discovery phase where you're learning what you want and they're learning what you need. So hiring and structuring for flexibility is more important than having absolute clarity upfront.
Deciding Who You Need
In other words, if you're hiring a first dev advocate on a 10-15 person team, you should figure out whether you need "an early engineer that does devrel" or "a devrel that joined us early". What you decide here determines whether you put them in for a generic technical early employee hiring loop or something more specialized.
Mainly early engineer: Prior experience as user/customer, heavy technical chops, open to learning devrel
Mainly experienced devrel: Prior experience in dev content creation, has existing reputation/network, open to learning your tool
Of course the best case scenario is you could get a unicorn that has all these qualities, but often they are already spoken for.
Another ideal is "hire the customer you'd most like to clone", because dev advocates have a tendency to clone themselves by all their subtle tribal traits from their word choice to media/network preference. So you might as well hire someone who has successfully argued to adopt you at their company (a lot of devrel have never paid for their company's product and have no idea what it's like to advocate internally amid other alternatives and priorities - then again, you may not have even started charging yet).
- You don't want to outright poach from your biggest customer, but you would be surprised how often the big champion of a tool implements the tool and then leaves their company to join the tool (Oct 2022 edit: 20%!). This is because they tend to see more potential in the tool than everyone they work with (this was also more appealing back when devtools valuations 3x-ed every 6 months).
All things equal, I'd actually go for the early employee that does devrel, A) because you have an "out" to transition them back to eng/product if they end up enjoying that more, and B) it can be easier to train engineers to speak and write than it is to train writers and speakers to have an authentic connection to your technical problem. This is not a strongly held opinion, just a "hunch".
The worst case scenario here is paying up for an experienced devrel, expecting them to brew install audience, and then finding out it doesn't transfer.
Pairing engineers-who-write with experienced DevRel managers and advisors might be a good approach
However there are also plenty of folks who change domains successfully, especially if they know how to stay outside their comfort zone.
All of these transitions deserve more room than I have in this answer, ping me with scenarios to help motivate a future writeup!
The last dimension to think about is whether you want to hire a team lead or IC:
Hiring Team Lead: less pressure on you to define strategy and hire in future, but cost of mishire higher
Hiring IC Devrel: lets you take more time to figure out what works/what you want, leaves room for IC to grow into Lead role if they wish
Understanding what mix of Product-focused, Content-focused, or Community-focused DevRel you want can also help, although at the early stage the usual answer is wanting one person to cover everything everywhere all at once. Mostly they will report either into Product, Marketing, or founders.
Candidate Pool
Most recruiters will just live in LinkedIn all day sending you people with some version of "Developer Advocate" in their title. -All- of them are doing this, because they don't understand where devrel hangs out and it may not be LinkedIn.
If you aren't having any luck with the LinkedIn pool you will need to be a bit more proactive:
Your current users & customers, as mentioned above - including those of competitors
Existing speakers and organizers from conferences you'd like to appear at - go thru prior year speaker lists
Top HN bloggers, Youtubers, Streamers relevant to your field
Twitter network density can be a really good prospecting tool
Shortlisting candidates isn't the hard part - by definition they will probably have some kind of public footprint (but it should not be a hard requirement). It's just more that they are likely already spoken for, and you need to get both their interest and timing right.
Job Description
Many first devrel's get hired without a JD and figure it out as they go along. I did not look at the JD for my last 3 jobs even though I've also written them. But it can still be a useful exercise for you to understand/communicate your expectations before you start.
There are some standard components of any good JD you should consider - I've added some devrel-relevant commentary here:
The opportunity
What appeals to devrel is a beautiful (well designed) product with a quick aha moment and yet long tail of features to get deep into, with an obvious large audience that just doesn't know about it yet.
Tell a story that you are Post-PMF, pre-"future is evenly distributed"
Solving a problem/mission with as wide an audience as possible
The work
Give an expectation of amount of travel (if possible - again you may not have figured this out and that's ok - and yes both 0% and 75% travel happen)
Give specifics on content types you expect them to work on most
To some extent you can't really get creative here, everyone just has variations of the same few things, so don't stress out too much making this stand out. Just make clear that creativity is encouraged. Show, don't tell, what kind of work you want out of devrel and you'll attract people who "get it".
Experience (just a menu of options, don't require all, split between must have and nice to have)
X years in industry, or with certain tech stack
Regular organizer at a meetup
Have organized a technical conference
Published X articles in well known industry publications like A, B, C
Regular speaker/keynote speaker in well known technical conferences
Notable blog/podcast/newsletter/social media/video following on related technical topics
Standard disclosures on tech stack, team, interview process, comp range, benefits
Some JD's to crib off of:
🔥🔥 https://fly.io/blog/we-are-hiring-elixir-developer-advocates/
🔥 https://fusionauth.io/jobs/senior-developer-advocate
🔥 https://startup.jobs/developer-advocate-cloudflare-315330
https://remoteok.com/remote-jobs/72590-remote-developer-advocate-stripe
(i'm biased) https://jobs.lever.co/temporal/c227b836-443b-4844-b6fb-9ea11cf65cfe
(i'm hiring) https://boards.greenhouse.io/airbyte/jobs/4304422004
Please let me know if you've seen other 🔥 JD's for dev advocate! I will develop this to be a bigger resource in future.
For leadership roles - rarely see a JD as most people are promoted into these:
https://leerob.io/blog/head-of-devrel
https://www.netlify.com/blog/2021/01/06/developer-experience-at-netlify/
https://trag.dev/
https://alexlakatos.com/avocados/2020/11/24/building-first-year-devrel-program/
Please let me know if you've seen other devrel leader self-descriptions! I will develop this to be a bigger resource in future.
Qualitative Qualities
There's an open question of "what qualities to look for", which is a deeper question about understanding what qualities matter and something I don't yet have a good framework around.
Five things I do care a lot about:
Insight: Can explain complex things in as simple a manner as possible and not simpler
Tactics: Knows how to get mass attention when a big launch is at stake
Grit: Doesn't give up when faced with the "content grind" - not just talking a big game but knowing how to ship content consistently over time through thick and thin.
Empathy: Understanding what the user/developer needs and wants
(nice to have) Knowledge of surrounding ecosystem
Whatever the list of qualities are, pick them with a view to the questions you will ask and the interview process you will construct.
Hiring Loop
As mentioned this will branch based on who you have decided to focus on, but here's what I've done given the qualities above:
- Initial Screen with Hiring Manager or Recruiter. Go over Background and Grit.
- If I'm doing the screen, I like to speedrun the whole thing by asking about what tech they know well, picking something I also know, and then asking them to "Explain how X works" (see below)
- Junior/Senior level Technical challenge with Eng team
- The reason we had tech screens so early is we found a lot of devrel candidates that were extremely rusty in code, and we really needed people who were still actively able to demo and run workshops, hence preferred to find this out earlier rather than later. YMMV.
- Full panel (usually all behavioral):
1:1 with Docs. Focused on Information Architecture & Product Understanding.
1:1 with Marketing/Product. Focused on Tactics.
1:1 with Community/Support. Focused on Developer Empathy.
1:1 with other Devrel (or Devrel advisor). Focused on surrounding ecosystem.
- Presentation to Panel. Focused on Delivering Insights. (more on this later)
- Followup feedback/deep dive session with Hiring Manager
- (If leadership) Planning session with CXO on strategy/hiring process (can be take-home)
The Presentation is the DevRel equivalent of FizzBuzz. It is a practice I stole from the AWS DA hiring loop, where you are simply asked to do a 20-25 minute presentation on something you know well (sometimes simply recycling an old talk), and to have a panel of 4-5 engineers lob all sorts of questions at you for 15 mins, from off-topic to in-depth. The test is not only about roleplay and handling questions under pressure, but also one of making boring technical content both clear and engaging. If you're struggling to stay awake or follow along, that's a problem.
Experienced DAs will have a wide body of work from which you can actually observe this under more realistic scenarios, so it is possible to exempt this step based on obvious past work and/or modify it to test for other activities like content brainstorming, event planning or building a demo (something I've actually done and had a lot of fun with, but definitely was a much bigger time commitment).
The hidden 6th step, as with every key hire, is reference checks.
Followup question: How important it is to have knowledge of specific tactics, understanding of which companies today have good dev rel / should be emulated, etc? Especially if we're focused more on the early employee profile, they might not be knowledgeable of devrel at all - in that case, do we just assess communication ability?
I do think it helps if the candidate can name role models (whether company or individual), but only if they can specifically break down what tactics they use to succeed (better if they have direct evidence). Everyone wants to be "like Stripe", but fewer have spent time studying the Collison Installation or reading up on their API versioning strategy. But it is no dealbreaker - knowing how people retroactively explain success is still quite a distance from being able to replicate/execute it.
Some (very rough) ideas for tactical open ended interview questions:
Explain how X works? look for clarity of communication, analogies, attention to protocols/technical tradeoffs, ability to go deep, comfort with/resourcefulness in ignorance.
- Then follow up with Why was X successful?. Ask them to counter argue with themselves.
What makes a good talk? look for opinions on slides, sequencing, speed, emotions, prep
- If they are an experienced speaker, ask for the best/most impactful talk they've done and as much detail on the creation process as possible
What makes a good blogpost? look for tone, information architecture, humor, facility with the various types of content
- Bonus: "Which companies write great blogposts and why?"
What makes a good demo/workshop? look for opinions on documentation, simplicity traded off with utility
- Bonus if they've actually done one, and done paid workshops
How do you ensure a great product launch? look for timing, pitching, mastery of toolkit, understanding of other launches
How do you think we should pitch ourselves? First authentic answer, then ask for a second answer from a different POV/audience. Looking for empathy, ability to hook interest.
Interdepartmental questions - How do you like to work with Docs/Marketing/Product/Founders? Nice if they volunteer an opinion on how they work with Engineering.
I tend to agree with Shishir Mehrotra on question setting - Try for a mix of "home" (what would you do if you worked here), "neutral" (a hypothetical scenario that you roleplay) and "away" (what do you know extremely well), "lower bound" (risk mitigation) vs "upper bound" (take me through your highlight reel, what must we know about you) questions - don't bias too much toward one or the other.
Who's Asking?
If you're keen on being a first DevRel hire at an early stage company, our first mailbox writein also agreed to doxx themselves - It's Josh Ma of Airplane.dev! Hearing a lot of good things, check them out.
Further Reading
Thanks to Dan Moore for sharing Wesley Faulkner's writeup on The New Stack linking to Taylor Barnett's Recruiting your first Developer Advocate!
Help us share this post!
