DevRel: What to avoid, when to hire, and how to succeed

An interview with the amazing Bear Douglas

If you have a developer product or API, you’ve likely spoken about hiring developer relations. You may have already done so. Many companies hire DevRel knowing that they need an evangelist, technical writer, or were just told they need this function but don't have any true sense of what they want developer relations to DO for their business.

A number of companies we have worked with had hired and fired DevRel by the time we started working together. That doesn't have to be you! 

We’re starting a content series where we look at various disciplines through the lens of developer marketing. Our inaugural piece looks at DevRel with Bear Douglas, one of our favorite DevRel leaders in the industry. She’s worked at Facebook, Twitter, Slack and now leads DevRel at Pinecone. Paige and I have had the pleasure of working with Bear at Slack and got to see first-hand how she directed her team to drive impact.

We cover a ton of critical topics including when to hire DevRel, common pitfalls, where DevRel can/should report in an organization, and even how to think about working with developer influencers. Bear is the best of the best and I hope this piece helps you chart a strong path forward in your developer relations journey! 

Key takeaways:

1. DevRel’s business impact can be measured, but instrumenting measurement can sometimes be costly to set up

2. Hire DevRel when the work you’re already doing (tech writing, evangelizing etc) is breaking because of your company’s scale

3. DevRel should report to a leader that understands it’s purpose within their org. When a a business’s core product is a developer tool, DevRel often reports into marketing as they are an essential part of the go to market function. When DevRel is working on ecosystem APIs or a non-core-business product, they often report into product or eng.

Let’s dive in!

---

Thank you for joining me Bear! To start off - what does DevRel do?… Because let’s be real, there are a ton of titles and varied jobs that fit within the DevRel bucket. How do you break down the core roles?

Carolyn Lewko pointed out a trend  in the state of Developer Relations survey a couple of years ago. At companies where the entire product is a developer product, DevRel sits in marketing and takes on marketing work. When the platform is a feature it tends to roll up to either product or engineering. The short answer is that DevRel is what the company needs it to be for the company’s business goals. 

How do you know when you’re ready to hire DevRel?

When the people already doing the components of DevRel that would be owned by a DevRel person can no longer sustain it! For example:

1. If an engineer is writing docs end to end and are reaching a breaking point, then hire a technical writer. 

2. If your founder is going to hackathons and meetups, and this worked well early on but is getting unsustainable, hire an evangelist.

By the time you hire your first DevRel, someone was already doing the work, just ad-hoc and reactively, and now you want to put some more structure and strategy around it so get ahead of the ball.

What are mistakes companies often make when hiring their first DevRels?

Thinking that DevRel is one job, and not acknowledging that DevRel can shift to address what the company needs.

Over-rotating and thinking a person or a team was a mis-hire when what needs to change is strategy, rather than humans.

DevRel practitioners are by nature adaptable– the role of DevRel at a company can change over time, as the company’s needs change. I have been re-orged in DevRel more and across more disparate orgs than I think nearly any other org or team type except for maybe program management? Who else can say they’ve been in Engineering AND Sales AND BD AND Marketing AND Product with the same job title? 

What qualities are you looking for when you’re building a team?

I care a lot about hiring complementary skillsets; having a match between people’s career goals, aspirations and understanding what the role is and what the org needs from them.

At Slack, my team was in Product, and the bulk of the work we did was product-related — beta program management, API feedback and governance, docs writing, building the SDK suite as a product — so I ended up hiring a lot of people who wanted to do product work rather than evangelism. Even when we were on the road more often (hey there 2019), not everyone on the team  wanted to travel and go to conferences. And that was OK! 

At Pinecone, we’re in Marketing, and we have a lot of work to do to help people understand what vector databases are and can do, best practices for building AI apps, and so on.

So there’s a lot more evangelism work to do and it makes more sense to hire people who want to spend a lot of their time creating educational material and reaching outbound. 

How do you vet technical writers? We get a lot of clients with technical writing needs but concerned about how to hire well. 

I read what they've written! Ideally things that are not too-too dry, to get a good sense of how people write.

I always ask for a writing sample, and it’s interesting what people pick to be representative of their best work.

I also ask them questions about their process– like, how do you write about a product when you're out of your technical depth? How do you approach learning for the medium and long term so you can write more and more independently? 

How do you know you have enough work for a technical writer to do?

The question is: what are you ready for a technical writer to do beyond launch content? There are lots of projects like creating good information architecture, building your documentation stack for long-term success,  taking on UX polish to improve the experience of reading, and building a style guide in collaboration with marketing.

Most teams could hire a tech writer today and have good results — you’d just have to be clear about what they would be doing above and beyond writing if you think there isn’t enough new content to create on a daily or weekly basis. 

Where do you prefer DevRel to report into?

When there is broad agreement that DevRel belongs in an organization, then I belong in their org! When a leader doesn’t know what to do with DevRel, your trajectory hits a ceiling.

It is more important to be in the org that champions DevRel than it is to be in the one it “should” always be in. They all have their benefits and drawbacks.

• Being in marketing, money flows more freely because budgets are large. This is often NOT the case in product or engineering, and can be a barrier to getting things done. 

• Reporting to BD, like I did at Twitter, we had a strong focus on partnerships and execution of integrations. The KPIs were clear and within our power to achieve..

• Reporting to engineering helps with two major things: (1) because you hire into the engineering org, internal perception of the hiring bar is higher, regardless of whether your hiring criteria are any different. Fighting for credibility for the team is less of a fight, because you aren’t combating the assumption that, e.g., marketing’s bar for hiring must be lower. (2) salary bands are higher in engineering. 

At the end of the day, it’s where you have exec support and people who understand what you’re doing that matters most.

And what I’ve found is that ultimately for hiring, candidates care most about the product, and a great product can trump a less-than-ideal org setup. 

How do you think about influencer work that is sort of Developer Relations? A lot of successful DevRels become semi-influencers, but constantly shilling the product you’re working on doesn’t sustain and a lot of people don’t like to blend their personal and work brands. So how do you think about this? 

If you think about the people who have gained influence, they get it one of two ways.

1. Talking a lot about a space, educating people, putting out 101 content, bringing more people into the fold on that topic, and producing a lot of information in an unbiased, semi-neutral way.

2. Doing cool shit and talking a lot about the stuff that they do, regardless of whether they are good ecosystem players.

I think people wrongly assume that you have to hire someone who already has a following, rather helping build their influence by demonstrating the coolest stuff you can do with a product.

Also, it’s not a given that a person you  hire is willing to make their online identity about your product. They might be, but it should not be assumed. Also, it is not a bad thing to hear from companies directly- it’s OK to rely on making the coolest stuff come from your brand account! 

Let’s wrap with something controversial: measurements! I know this is historically a challenge area for DevRel but how do you think about them? What should DevRel be accountable for at a company? 

Here’s the thing: you absolutely CAN measure the impact of DevRel activities. But the cost of instrumentation is sometimes not worth your time.

It’s worthwhile to think differently about “north star” metrics and project-level success metrics, which can be easier to track. 

For example, at Facebook — and this was a decade ago, too — to sign up for an event, you had to be logged into your Facebook account, which was also your developer identity.

And since we hand-rolled all our tools, there was unified developer identity across EVERYTHING from documentation page reads to API usage metrics. This is really hard to do on other stacks, by the way. People often use different software for forums and meetup registration and core product, and you just have to cross your fingers your devs used the same email address for every platform.

With a consistent developer ID, we were able to do things like cohort people who attended our events and create a control cohort with similar characteristics (again, volume was so high this was possible) and found that attending events with us was correlated strongly with you staying updated on our latest and greatest products.

We could then attempt to try and show the causal link at an individual project level — like, you could throw a workshop where we would try and get people on new SDKs and learn whether they would have made an upgrade without the help and the nudge from us, and what it would have looked if we just did nothing and let the ecosystem adopt new products entirely organically. 

At Slack I cared a lot about retention through the funnel, since our team was largely responsible for the DevX of everything above the API that might influence someone’s interest in successfully making an integration — good docs, tooling, educational programs, and so on. We meaningfully improved retention through the funnel over the years and I was super proud of that- we figured out the things that made people drop out (lack of tooling, needing use case examples, etc)  and systematically knocked them out which drove results. 

When it comes to north star measurements I like to think about ones you and your team feel like you have reasonable control over:

1. Developer NPS - all of the programs Developer Relations owns are the candy coating on a good API, and I feel confident DevRel can impact NPS. 

2. Retention through the funnel - same reason 

Depending on where you’re orged, you can argue that top of funnel growth makes sense, too, as long as you have activities planned and some way to drive it.

And at a project level, you can always measure whether a project was worth doing with success metrics for outcomes.

Ultimately, the hullaballoo over metrics is really about an underlying existential threat that a lot of people in DevRel feel and are subject to. You have to prove success, and pick a compelling metric to do it, or maybe your whole org is at risk.

I like to mitigate that risk by having  every individual person on my team have some work that is inarguably critical for the success of the company. There’s no question that any new release needs to be documented. It needs to have code samples. You need someone managing the change process for customers and partners. There’s no measurement of success here- it simply has to be done. And the more that your work simply has to be done, the less likely anyone is to look at your team and wonder if they really need you. 

Huge thanks to Bear for providing this interview! You can follow her on Twitter/X and Linkedin.

We’ll have more content covering brand, growth, community, developer sales, and more in the weeks and months to come! And please know that we plan to keep this newsletter free.