Building a Developer Relations Function

Building a Developer Relations Function
Mary Thengvall leads developer relations at Camunda, and has long been a thought leader in the space, authoring the book, "The Business Value of Developer Relations" and publishing DevRel Weekly. In this guide, she describes what DevRel is, and how to stand up a function to drive developer awareness, enablement, and engagement.

This is a preview of a single guide - to access the full library or request a call

Questions covered in this guide

What are the responsibilities of Developer Relations (DevRel)?

Awareness – increasing developer community awareness of the product and the company.

Empowerment/enablement – making sure that the developer end users have the tools that they need to be successful with the product, enabling them to really have a good experience.

Engagement – building community and connections (e.g. connecting members of the community with different functions at the company, feeding useful tools and information back into the community).

When does it make sense to build out a DevRel function?

As soon as you find yourself needing to convince developers to use your product – if the company’s primary target is developers, I’ve seen companies that hire a developer relations professional as employee number six, because even before they have a full product in go-to-market ready status, having that community feedback and relationships is key. If developers are your end users and your main buying audience is the business side of the business or management or something like that, then slightly later on makes sense. Early on, it is possible to hire someone part time to ghost write some content or evangelize at conferences, but that person won’t be able to build the same type of relationships.

Where does DevRel sit in the organization?

For a company that sells a developer product, DevRel truly works across the company – it’s the hub of the wheel. For instance, developer relations could be helping sales navigate technical conversations, connecting marketing with developer-focused podcasts or newsletters to sponsor, and channeling community feedback back to product.

As far as reporting goes, the ideal setup would be to have a dedicated team reporting up to the C-suite, but developer relations can sit within whichever team makes the most sense for the organization. Product is often the best match because DevRel works so closely with the product managers and with engineering to implement feedback and care for the community. 

When you hire for DevRel, what should you look for (and where)?

For your first hire, try to find someone with developer relations experience – by background a DevRel professional might have been a developer who also enjoys writing and speaking or someone coming from product management or solutions engineering. When you’re looking to hire, seek out someone who knows your community. For your first hire, try to prioritize someone who has some experience, or it will be hard for them to stand up the function by themselves.

When looking for candidates, the DevRel community is pretty tight knit. Searching on LinkedIn is great, and you can even post to Twitter with #DevRel and attract the right kind of notice. I also run a weekly newsletter, DevRel Weekly, which offers job sponsorships and a DevRel community, DevRel Collective.

What are the first steps in establishing a DevRel function?

Define Personas – what type of technical person, exactly, do you want to reach?  Are you talking DevOps professionals? Are you talking software architects? Are you talking app developers and front-end developers? Really dig into who is your primary core audience.

Figure out where your target audience is – you’re never starting from scratch, that community already exists, you just might not know where they’re hanging out. Are they asking questions on Stack Overflow? Are they on Twitter? Are they attending conferences? Are they in Slack teams?  Figure out where they are, and then start listening.

Find the patterns and the influencers – don’t necessarily contribute right away, but listen and start to pick up on patterns. Start to figure out what are the problems that the community is facing. What are the solutions that they’re looking for? And then start to figure out who some of the top leaders are in those spaces.

Solicit feedback and set a cadence for getting it – reach out to influential community members and have one-on-one conversations with them. Just say, “Hey, we’re working on this new thing”, or “we have this product and we’re trying to improve it, where can we improve what do we do? Can you give me some advice on what would you like to see in this type of product going forward?” Setting up in regular cadence to receive that feedback from customers or key community members can be huge, so you’re not just depending on drive-by feedback.

What tools do DevRel teams use?

Forum tools – tools like Discourse or community experience platforms like Orbit allow companies to host and monitor user conversations.

Tools for monitoring open source usage – projects like GrimoireLab and software analytics consulting solutions like Bitergia can help with open-source reporting.

Tools tracking broader conversations – a solution like Krunch can track social media mentions and can catch spikes in activity on platforms like Stacker or Reddit. 

In-person conferences – nothing fully replaces attending events and having conversations in the hallways or by your booth.

What materials does this role create?

Blogs and talks – to drive awareness and customer acquisition, DevRel can put together tutorials, thought leadership, meetups, talks for conferences etc.

Documentation and support tools – to ensure customer activation and retention, DevRel can create product guides, references, quick starts, tutorials, libraries, and sample apps.

What does success look like, what can you measure?

Decreased churn – using feedback from the audience, DevRel can prioritize and advocate for impactful changes or enhancements to the product management team to the engineers. They also ensure that community members know where to turn, to catch problems early and make the community stickier.

Decreased support costs – good DevRel helps contain costs in other departments – good documentation and a strong community can help decrease support ticket volume.

“DevRel Qualified leads” – the DevRel team can source people in the community who provide value to the company. That could mean introducing new customers at sales, but could also include things like finding someone who authors a case study for marketing, signing up a beta tester for product, helping engineering with a hard-to-solve bug, or recruiting as awesome new hire.

How long does it take to start to see results?

DevRel is a long term investment, be patient – a lot of people hope that develop relationships is going to be the magic, but oftentimes it’s the longer tail that helps and really build a solid product and solid community down the road. You’re not going to see the full results in three months, six months, or even nine months.

What are the most important pieces to get right?

The biggest thing is to make sure that DevRel goals can be traced back to overarching company goals – it’s easy for people to not understand the value of what DevRel is, because it’s not  instant. It’s important to make sure that the goals set for the team ladder-up to company-level objectives.

What are the common pitfalls?

Not setting expectations for how DevRel works – especially if DevRel is reporting into marketing or sales, there’s a tendency to try to tie everything back to leads as the sole measurement of value. In reality, it’s much harder (and slower) to measure the value of the relationships that DevRel builds.

Promoting the product too soon – DevRel can fall down when a company hires a developer advocate to drive awareness, but they don’t actually have a product that can back that up.

How do you scale the DevRel function?

Your second hire depends upon whether the top priority is awareness, engagement or enablement – as you build the team, you can afford to add people with deep community or product experience, but less formal developer relations experience. The skillset you need depends upon which part of the developer relations function is most important. If the company is focused more on awareness, hire a second developer advocate. If you’re focused more on enablement, hire a technical writer or a head of developer experience. If you’re focused more on engagement, bring on a technical community manager who can really work on building relationships and connecting people focus.

To browse the full library of guides

Already a member? Sign in to view the full library.


Scroll to Top

Request Access


Want free guides?

We feature guides every week in our newsletter