Strategies: Developer Relations as a Growth Engine

Developers have become a buying audience of consequence. Just as tech-savvy employees kicked off the “BYOT” trend introducing Slack, Dropbox, and Notion-type platforms into the workplace, developers are increasingly the key influence when a company adopts new tools and services. Paralleling the rise of the developer buyer is the growing discipline of Developer Relations (DevRel), a discipline that bridges the gap between the company and the developer community. 

To answer questions about when early-stage companies should make their first DevRel hire and how to measure success for the role, we turned to some seasoned DevRel professionals: Adi Polak (VP of developer experience at LakeFS and previously a DevRel executive at Microsoft), Luke Tucker (VP of marketing at Lightspin and previously the VP of community at HackerOne), and Caroline and James Parton (co-authors of Developer Relations: How to Build and Grow a Successful Developer Program).

To start, what is Developer Relations?
Developer Relations is at its fundamental level a “conduit for feedback between developers who use your software and the engineers who build it,” says Adi Polak. Beyond that, she adds, “DevRel enables multiple engines of growth for a company and because it can both generate and capture value, it can be its own engine of growth. A strong developer experience is a real competitive advantage.” 

Many of the early-stage companies we invest in at DTC are “Developer First,” building tools, services and platforms foremost for the developer, earning the developer’s influence in the buying decision to drive revenue and growth. As these types of companies scale, DevRel plays an increasingly important, cross-functional role in driving adoption, growth and revenue. 

When should you make the first DevRel hire?
Companies should consider developer engagement from day one, argue Caroline Lewko and James Parton. Initially, this role may unofficially fall to a founder/CEO or an engineer who already happens to be engaging the community, but if developers are buying or influencing the buying of your tech, an FTE hire for managing DevRel should happen early on. “Even when the company and marketing motion is just starting, there needs to be someone focused on advocating for the developer persona,” Caroline says. She and James add, if you’ve got a product, some documentation and maybe a beta, you’re ready to go. 

REFERENCE: Team size, budget, and program development by stage. From Caroline and James’ book “How to Build and Grow a Successful Developer Program.”

Even when the company and marketing motion is just starting, there needs to be someone focused on advocating for the developer persona.

What makes an ideal candidate for a developer relations role?
Across the board, Luke Tucker, Adi, Caroline and James agree: the hire should be a strategic, seasoned individual, preferably operating at an executive level. The candidate needs to be a clear communicator—a good writer and storyteller who isn’t afraid to speak in front of a discerning crowd. Developers can be a tough bunch; their liaison needs to communicate complicated points in trustworthy, real ways. 

In addition, these are strategic, decisive people that not only wield a large amount of knowledge about the product, speak to fine technical points and can read a room. They also have to have a business mindset, and are able to effectively manage relationships across myriad internal stakeholders and articulate the value of what they do back to the organization. 

“You need somebody who can think strategically, that understands what the company’s goals are and what they’re driving towards – and how the developer fits in with that,” says Caroline. She adds that developer relations managers don’t need to be software developers but, they must understand the language and frameworks of their ecosystem in order to appreciate the problem their product solves and the overarching developer lifecycle. 

Adi throws an “it depends” into the mix, saying if your product is super technical and it’ll take a non-engineer months to get up to speed in the DevRel capacity, prioritize hiring someone with a deep technical background. If your target audience is citizen engineers working in a lower code environment, hiring a skilled storyteller could be the right way to go. 

James provided perhaps a sharper point: “Developer relations hires must always be technical leaders!” he says. “They must be able to stand up on stage at hackathons and live code. If companies don’t bring on technical gurus as heads of developer relations, they’ll set a bad tone with prospective users, discourage engagement, and lose credibility.”  

Look for someone already driving value within the developer ecosystem—check their Stack Overflow or Hacker News profile—someone who’s contributing already and shows an innate ability to “walk the walk.”

To that end, Luke says to look for someone already driving value within the developer ecosystem—check their Stack Overflow or Hacker News profile—someone who’s contributing already and shows an innate ability to “walk the walk” with developers. Academics and research can also be a fertile ground. Adi shared that her move into DevRel was a natural extension of her work as a researcher, where she was constantly presenting new technologies, writing documentation blogs, building courses, and disseminating information to the broader community.   

Who does developer relations report to?
Caroline and James say in their experience, DevRel most often rolls up to marketing but it can also be a part of the engineering or product teams. There are tradeoffs and the right decision may come down to company culture and product attributes.

Reporting into engineering or product can move the role further away from sales objectives and/or weaken DevRel’s influence on marketing strategies. Conversely, reporting into marketing can undermine the DevRel team’s credibility with internal technical teams and sometimes the external developer community itself. 

Regardless of where DevRel officially sits, it is a cross-functional role involving almost every area of a young company: engineering, product, marketing, and sales. Yet another reason why James and Caroline advocate creating a CX level role early on is to maximize the potential positive business impact of the role. 

Developer relations should have its own budget and its own success metrics.

Whatever reporting structure you pursue, developer relations should have its own budget and its own success metrics. Otherwise, Adi advises, the budget can be seen as a carve out from another function and priorities can become muddled. That can lead to financial starvation and a lower chance at success. 

How does DevRel start engaging the community?
Adi makes clear: Developer relations should always prioritize generating value for developers before capturing it: first content, then community. 

Caroline and James agree. DevRel should make its corner of the website a “soft landing spot” with high-quality, technical content such as documentation, tutorials, getting started guides, and detailed use cases. This content should never market or sell but should instead explain what the technology does and how it’s implemented in a straightforward and honest way. 

Because DevRel is a feedback loop, what resonates with the community should inform the content strategy and the team should be open to trying multiple mediums including podcasts, interviews, and meet-ups. Luke says keep the conversations going wherever your community naturally lives, be it Slack, Reddit or on social media. But also, formalize some of your interactions via advisory boards and regular NPS surveys.  

One of the more challenging aspects of DevRel is managing expectations. Luke says that while the community must always feel heard, not every policy and decision can be an open book. Be clear about how often you’ll share product roadmaps and the level of influence the community will have on it. It’s also good to be clear about codes of conduct, especially on owned channels, and work to promote diversity and inclusion of underrepresented voices in conversations.

Be clear about how often you’ll share product roadmaps and the level of influence the community will have on it. It’s also good to be clear about codes of conduct, especially on owned channels, and work to promote diversity and inclusion of underrepresented voices in conversations.

How do you measure success for a developer relations program?
“There’s no use in developer relations building a community if it can’t communicate its value back to its company,” said Adi.

Metrics like engagement numbers and follower growth are important to understand at the team level but broadly reported metrics should be commercially driven. James says one of the things he and Caroline try to hammer home in their book is that for DevRel to gain the recognition of other disciplines, they should adopt standard OKRs and KPIs that roll up to broader organizational objectives that usually tie into driving revenue. 

REFERENCE: Mapping to a traditional sales funnel.From “How to Build and Grow a Successful Developer Program”

Adi agrees, saying “There’s no use in developer relations building a community if it can’t communicate its value back to its company.” She recommends employing common language and data-driven objectives that the whole business can understand. “To measure community engagement in a mature and high-functioning manner, developer relations needs a funnel just like sales and marketing with comparable benchmarks.”