How to activate the developer relations flywheel with the why, try, buy, fly method

Even your best cold pitch or campaign has a low chance of convincing developers to consider your product — let alone buy it. Just look at the data: in Stack Overflow’s survey of 83,184 developers, less than six percent said they research companies that email them and less than 15% said they research companies that advertise on the websites they visit.

Of course, that doesn’t mean you can’t build a great business creating tools for developers. Atlassian, GitHub, and AWS have been able to attract and retain millions of technical users and generate billions of dollars in revenue. But gaining traction with developers requires a unique mental model that isn’t always accounted for in traditional go-to-market playbooks.

“The customer journey of developers looks different from the journeys of other types of users,” says Adam FitzGerald, VP of Developer Relations at HashiCorp. “For one, developers almost always encounter new products when they have a question and are out searching the internet for answers. To be successful with developers, your company needs to provide those answers.”

To be successful with developers, your company needs to be a source of truth.

The data bears this out. Sixty-three percent of developers report spending more than 30 minutes a day searching for answers or solutions and another 27% report spending between 15 and 30 minutes a day. For companies that sell to developers or rely on developers using their products, each minute represents an opportunity.

But how do you make sure that your product solves a problem developers actually have? How do you get your content in front of the developers searching for a solution? And how do you make sure your solution is compelling enough for developers to try it, buy it, and eventually share it with others? This is the work of developer relations, a.k.a. “DevRel.”

Compared to other functions in tech, developer relations is relatively nascent, but Adam is a veteran, having accrued more than 20 years of experience in the field. After working at BEA Systems and VMWare in the 2000s, Adam became the Head of Worldwide Developer and Startup Marketing at AWS, one of the most popular platforms among developers in the world.

In his career, Adam observed a paradox: developers often dislike traditional marketing, and yet, producing strong technical content and leveraging SEO was at the core of effective marketing for developer-centric businesses.

“Developers searching for solutions usually land on company documentation via search engines like Google,” he says. “Effective documentation must be user-centric, problem-focused, and SEO-optimized to rank highly. At companies where founders prioritized top-notch, user-centric documentation, we saw high engagement as developers went straight to the docs, bypassing other site parts, demonstrating the power of strong content in driving engagement.”

Today, Adam runs developer relations at HashiCorp, which helps some of the largest organizations in the world manage their cloud and security infrastructure. Adam joined HashiCorp shortly after the company raised its Series D, and has remained there for the past five years, including through HashiCorp’s recent acquisition by IBM.

In his capacity as an operating advisor at Bessemer, Adam meets with founders to share best practices and ideas they can use to establish or improve their developer relations strategy and team. In this 101 guide, Adam shares some of that same wisdom, including his advice on how to get developers to discover, test, adopt, and advocate for your product; how to allocate resources on developer relations teams of all sizes; unique ways to track success (that aren’t revenue metrics), and other lessons from his long and storied career in the field.

What is developer relations?

“I describe developer relations as the process of building trust with technical users who are loath to give you trust,” says Adam. But what the process looks like, who’s responsible for designing and executing it, and where those individuals sit within an organization can vary significantly and change over time.

"DevRel is the process of building trust with technical users who are loath to give you trust."

While by no means a comprehensive list, here are a few of the core activities that are typically either owned or supported by developer relations teams, or people in developer relations roles (in cases where there is no dedicated team):

• Creating content such as case studies, blog posts, docs, demos, and technical guides to attract developers to your platform and make them successful
• Engaging with developers on the platforms where they’re already active (i.e. GitHub, YouTube, LinkedIn, Discord, Stack OverFlow, and Reddit)
• Gathering and organizing technical user feedback to share with the product and engineering teams and inform the product roadmap
• Speaking at or hosting events to spread awareness of your product, connect with existing users, and identify potential advocates of your product
• Building advocacy programs such as core contributor groups, community champions, and opportunities for skill development and credentialing

Keep in mind, developer relations is uniquely interdisciplinary, so many of these responsibilities may be concurrently owned by engineering, product, and marketing (either temporarily or permanently) depending on whether developers are a key buyer of your product, the available budget and resources on other teams, the preferences of leadership, and other factors.

To Adam, the most important thing is that the developer relations function sits within the part of the organization that is partly or wholly responsible for deepening engagement with developers.

"The DevRel org should report to the leader who believes that developer relations is a critical component of what they are responsible for,” imparts Adam, “If it's product, great. If it's engineering, great. If it's marketing, great. They will all have to work together anyway to successfully engage with developers anyways."

At HashiCorp, this means Adam’s team sits within the marketing organization, but the best setup will vary from company to company.

Who needs developer relations?

SaaS, developer tools, and cloud infrastructure companies are the most likely to have a developer relations team. But not every company that falls into those categories will actually need to have a dedicated team — or even developer-focused content, events, or programs.

When Adam speaks to founders, he usually starts by helping them determine whether or not the company even needs to invest in developer relations (now or later).

He leads these conversations with two questions:

1. Is the developer on the critical path to success for your company?

“I’m very deliberate about saying company here, and not technology. The question is whether your company really needs developers using its products in order to be successful vs. whether your product could be improved if developers were using it.

You might answer ‘yes’ to this question for different reasons. The most obvious one is because the developer is the buyer, but it could also be a ‘yes’ because your technology is so complicated that a developer needs to implement it. Or, it could be a ‘yes’ because the developer enables an essential ecosystem that your company is part of,” says Adam.

2. Does my company need a developer relations function?

“If you answered ‘yes’ to the first question, then you’re going to need to be doing at least some developer relations activities. And in most cases, even the earliest stage startups already are, even if they’re not calling it that.

This can look like the founder or CTO speaking publicly about the technology at events or posting about it on their LinkedIn; the product team running regular customer feedback sessions; engineers or technical writers writing docs, etc.

So the question then becomes whether to build a dedicated team, create dedicated developer relations roles within other teams, or continue to keep the work distributed among the types of roles you already have (like content strategists, engineers, and user researchers, for example).”

There’s also another, less common, case where developers are so critical to the success of a company that the company doesn’t actually need developer relations. “If developers are the true north star for your business, you can sometimes get away with not having DevRel at all. GitHub is a great example. For the first six years that the company existed, there was no designated DevRel function. But the product, the content, the marketing campaigns — everything — was built with their technical end user in mind,” says Adam.

“AWS is a more extreme example. When I joined in 2013, AWS had only recently gotten a marketing department. Before that, they just had engineers producing great tools for developers. So it’s entirely possible to be successful without DevRel, but only if the entire company is intensely focused on developers as the key buyer or end user of the product.”

On the other side of the coin, Adam has encountered developer relations teams and activities that he wouldn’t call developer relations. “Sometimes, I’ll see DevRel roles at a large company that’s building hardware, for example, and when you scratch beneath the surface, you can see that their concept of developer relations is just a veneer and the actual role is running a partnership program. It’s an adornment to their business process — not core to it — and that’s the key difference.”

How to build your initial developer relations team

If you answered ‘yes’ to both of Adam’s questions, the next step is to decide when to make your first developer relations hire, and how to structure the team in the long run.

“When your startup has fewer than 50 people, you can make a judgment call about whether to hire someone. This will usually be a decision made based on the personalities and skillsets of your company’s leadership,” explains Adam. “Once your company gets a bit bigger, then DevRel should make up roughly one to three percent of your total organization’s headcount. I’ve found this ratio becomes more important as your company scales. So once you reach 100 employees, you should make that first hire (if you haven’t yet).”

(As an example, HashiCorp, with about 2,000-2,500 employees, has around 50 people in their DevRel team, which is about two percent of the total headcount.)

DevRel should make up roughly one to three percent of your total organization’s headcount.

Because developer relations is so interdisciplinary, people with different experiences and expertise can all be potential good candidates for your open developer relations roles. While more than half of people working in the function are former engineers or developers, there are many who come from roles in sales, marketing, and customer success.

While the majority of developer relations teams report into marketing, there are also many that report to product or engineering, or even directly to the office of the CEO. “A lot of the work of developer relations is a supplement and accelerant to what marketing is doing, so the team often ends up rolling into marketing. But DevRel can be successful within engineering and product too. It ultimately doesn’t matter what reporting structure you choose because the developer relations leader will need to have good working relationships and support from stakeholders across all those teams, as well as sales.”

As you’ll read later in this guide, team composition is made up of roles dedicated to content creation, advocacy, programs, events, or a mix of multiple domains. Adam recommends starting with roughly two people focusing on content and advocacy. As the company grows and the DevRel becomes more important, expand the team according to the breakdown mentioned below as a guide to ensure that all critical functions (content, advocacy, programs, and events) are adequately covered.

Here’s an example breakdown for different company sizes

• Small Company (50 employees)
  • One to two DevRel professionals focusing on content and advocacy
• Mid-Sized Company (200 employees)
  • Around four to six DevRel professionals, with a split among content, advocacy, and a bit of program management
• Large Company (2,000 employees)
  • About 40-60 DevRel professionals, split into content creators, advocates, program managers, and event organizers as per the recommended percentages in this section

How to optimize the developer journey

The foundation of developer relations is a good understanding of the developer journey — the process or funnel that technical users go through from discovering your product to reaching a purchasing decision, and beyond.

Adam describes the phases as “Why, try, buy, and fly” and uses the chart below to synthesize the typical developer journey. “When I speak to startups, I try to use this slide to describe the common behavior of a developer engaging with a new piece of technology that they don’t already know. This last part is important. If they already know how to, say, program in Ruby, they're not following these steps because they’re probably asking a narrow question that they can quickly find the answer to,” explains Adam.

Let’s break it down:

The ‘Why’ Phase

1. Search

The most likely place that a developer will encounter your product is on a search engine. “The impetus is not curiosity or a desire for skill development — that’s something people tend to misunderstand. A developer is rarely thinking, ‘Hmm, I have two spare hours and I’d like to go learn about the abstract theory of binary tree traversals.’ They’re thinking, ‘I have a problem traversing my binary tree, and I need a solution,’” explains Adam.

The goal is for your content to appear at the top of the results and show you can solve the problem. “You need to organize your content so that it provides the solutions to problems that developers are actually searching for.” (We include Adam’s detailed advice on how to create great developer content in the next section).

2. Understand

After developers discover your solution, they’ll try to fit it within an existing mental model. “The way developers understand a new technology is by comparing it to something they already know. ‘Oh, it’s like this thing, but for another use case. Or, it’s a better version of this other thing.’”

3. Validate

Once developers have a basic understanding of a technology, they’ll try to determine whether it’s trustworthy and worth trying.

“We think of developers as always being on the cutting edge, but they can be conservative when it comes to unknown technologies. They’re not going to just download a random library from GitHub. It has to be validated first,” says Adam.

“The most effective form of validation is seeing that other developers are already using and liking the technology. That’s why it is so important to find developers who are advocates for your technology — their evangelism creates a “virtuous cycle.”

The ‘Try’ Phase

4. Experiment

Experimentation might look like a developer downloading bits from your website, getting source code from GitHub and compiling it into a project, or signing up for a free tier of your platform in the cloud.

“The more barriers you put in front of developers to run their experiment, the less likely they are to use your product.” Adam recommends making that on-ramp as light-touch as possible by doing any of the following:

• Giving developers a virtual sandbox in their browsers
• Offering a free download that doesn’t require registration or a credit card
• Creating a free tier that developers don’t have to pay for during the first year

If the barrier to experimentation is low, developers will typically follow your instructions. (This is PLG principle #1: the product has to be its own self-service distribution vehicle.)

But make sure that experiment works. “If your basic ‘hello world’ example doesn’t work, the developer is gone,” says Adam. “They will not try to debug your solution. They’ll just go to the next item in the search results and try that one instead.”

5. Evaluate

If the developer runs an initial test and it works, they still have to determine whether your solution will solve their specific problem. Getting this part right has as much to do with the scope and efficacy of your product as it does with the quality of your content.

“You have to write an explanation of the product that aligns with the problem they have, not an abstract definition that relies on technical terms. Going back to my previous example, you don’t want to say you have a great tutorial on binary trees. You want to say you have a great tutorial on how to build index search across large corpuses of words.”

If the content is clear and compelling, developers will likely test the solution against their own requirements. “You really want to make a big investment in succeeding at this stage because if they are successful in building their own proof of concept — and they have that ‘aha’ moment — you’ll be very close to locking them in as a user or buyer.”

For advice on delivering instantaneous ‘eureka’ moments and an end-user experience that sells itself, check out Bessemer’s ten principles for product-led growth.

The ‘Buy’ Phase

6. Research

“Once you have intellectual buy-in, developers need to see that the solution is easy to use and that they will be able to convince other people within their organization to start using it, too,” explains Adam.

“Developers are going to try to answer questions like: ‘What are the best practices for the architecture or platform I’m using? What will I need to observe and maintain in order to get this to work well for my company? How frequent are the releases?”

If you can provide resources that answer those questions clearly, and give them tools to facilitate adoption among their wider team, you’ll expedite the research phase and increase the chances that the developer makes it to implementation.

7. Implement

If a developer determines that the product passes their requirements and won’t cost too much (in either time or budget), it’s time to implement. This may also involve displacing an existing technology or process.

“Once your technology is being used for a product deployment or product deliverable, you can consider it locked in,” says Adam.

The ‘Fly’ Phase

8. Advocate

If your technology is embraced by the broader team, the developer(s) who found and implemented it will want to share their success with others.

“Sometimes, developers will just share within their own company — over lunch or during a stand-up,” says Adam. “But if you’re lucky, they’ll write a blog, post on social media, or even make a presentation at a conference.”

It’s important to understand the motivations developers have for sharing these stories so that you can tailor your activities to create more advocates. In Adam’s experience, developers are almost never talking about your technology to do you a favor. Common motivations include:

• Recruiting like-minded developers
• Demonstrating that their company is on the cutting-edge
• Supporting their own career growth and job opportunities

Remember: the content created by existing users provides the validation that potential users need during the ‘Why’ phase. So make sure to invest adequate resources into your advocacy programs (more on this in the next section).

9. Certify

If your product is very successful and has widespread adoption, you may need to create a mechanism that allows developers to certify their competency in your technology (i.e. HashiCorp Cloud Engineer Certification, Salesforce Architect Certification, AWS Certified Developer Program, or Atlassian Certified Professional).

“Developers want to demonstrate that they know standard technologies inside and out in order to differentiate themselves in the job market, and employers will want to validate candidate expertise in a given area — whether it’s a security clearance, programming language, cloud domain knowledge, or something else.”

The 50/30/10/10 rule: How to allocate resources to get results

It can be hard to know where to focus your developer relations efforts, especially for a younger company. Adam provides a formula to help effectively allocate your resources that works regardless of the size of the team, type of product, or target customer. We’re calling it the 50/30/10/10 rule.

“Let’s say you have one person doing DevRel at your company. In that scenario, I’d have them spend 50% of their time writing content, 30% outside engaging with users and speaking at events, 10% organizing events, and 10% designing and running programs that engage power users. If you have a 10-person team, the same rule applies. Five people focus on content, three on advocacy, one on programs, and one on events,” says Adam.

“Keep in mind, the distribution is of energy, not dollars. Eventually, events are going to eclipse everything else in terms of cost, especially if you start going to pricey conferences or if your company starts hosting its own conferences.”

The right breakdown for your company may be different if other team members or functions have taken on work that falls into these categories. If your CTO is already speaking at events, your first developer relations hire may not need to spend time on advocacy, or, if you have a content marketer creating great blog posts for developers, you might be able to reduce the time you spend on content. In these scenarios, use your best judgment and make changes as needed.

50% Content

Most of the questions that Adam gets from founders about developer relations are about content —- and that’s a good thing. “You need great content to get developers from the ‘Why’ phase to the ‘Buy’ phase, so it should be a major focus not just for developer relations but for the whole company,” says Adam. 

Great developer content is: 

1. 1. Authentic and user-centric
   2. Clear about what the product is and does
   3. Focused on solutions to real developer problems
   4. High in SEO value 

• Poor SEO: Docs are hosted on platforms that give no flexibility for adding important SEO metadata, limiting the chance of discovery by potential users. 
• Wrong focus: Docs are centered on features shipped rather than the needs and problems of technical users. 
• Not prioritized: The engineering leader sees great docs as a nice-to-have, so it falls to the bottom of the to-do list.
• Low interest or skill: Engineers see doc writing as a chore and prefer to code, or they struggle to write docs well.
• Outsourced: A leader hires a lone technical writer to the engineering team who doesn’t have the right context, authority, or resources to succeed.

Calculating impact hours

Formula: (Audience size) x (Time) x (Level of focus) = # of Impact Hours

Adam’s formula rewards developer relations advocates for capturing the attention of as many developers as possible, for as long as possible, but provides the flexibility to choose the types of activities and channels where they have the most skill and interest. “I find that flexibility really helps DevRel employees stay engaged and motivated,” says Adam.

KPIs

The metrics that will be relevant to your team are going to vary depending on your end customer, business model, and the responsibilities and structure of your developer relations team, but you can use these as a jumping off point.

Funnel metrics

If developers are a key buyer of your software, then the KPIs you track for developer relations will be very similar to how you measure brand and performance marketing.

Extended ‘pirate’ metrics

The AAARRRP framework allows teams to tie activities to key goals including awareness, acquisition, activation, retention, referral, revenue, and user input in product development.

Web traffic

To measure top-of-funnel traction and content performance, Adam uses classic web traffic metrics such as page views, average time on site, top pages, and conversion and exit rate.

SEO rank

While not a primary measure for developer relations teams, SEO rank is critical for awareness and acquisition and can help teams understand and improve the performance of their content.

Developer relations needs sufficient scope

Developer relations is both a function and a strategic agenda for the business. The timing, size, and structure of developer relations teams can vary from company to company and still be effective, but it’s critical to build out your developer relations function with a clear understanding of its goals, and then give the responsible team enough scope and influence to reach them.

“I’ve run developer relations inside companies where I did not own docs or events. As a result, they were not always created with technical end users in mind, and that ultimately led to a fragmented user experience and missed opportunities. At HashiCorp, we’re really involved in the full user funnel, and that’s made a world of difference in terms of what we’re able to achieve.”

Influencing the entire developer journey, and helping drive real revenue for the business, is a tough task, no matter the software. Being successful within a DevRel organization always requires deep empathy and technical understanding, but at the core of this team is authenticity. The success of your agenda can come down to whether you meet one clear expectation of developers: “Say what you do and do what you say."