top of page

Sales & Developer Relations sitting in a tree, k-i-s-s-i-n-g

Updated: May 28, 2023

Photo by Spring Fed Images on Unsplash
Photo by Spring Fed Images on Unsplash

If you have read our book or follow our blog, you know that our main motivation is to help increase the recognition of Developer Relations as a distinct practice alongside more traditional business units like marketing, sales, product, and engineering. Ultimately, we advocate for a Developer focused role at the C level of a company - a Chief Developer Officer or CDO.

There are a few hurdles to clear along that journey, including the standardization and development of common terminology, frameworks, and processes, as well as addressing attitudinal blockers that could inhibit Developer Relations from taking that collective step forward.




There are thousands of people working in Developer Relations across the globe, so it is expected that many have differing views on the role and scope of Developer Relations. It is also important that new ideas are voiced to advance our collective thinking and Developer Relations’ impact. Agreeing on a collective set of definitions and best practices, however, is necessary to create the foundations of the profession. Having agreed on the basics, we can then redirect the energy that gets expended debating and reinventing rudimentary Developer Relations topics into the advancement of the profession.

We mentioned “attitudinal blockers.” A number of Developer Relations tropes persist: “Developers hate marketing”, “They don’t get developers” (the “they” normally refers to senior management), or “It’s impossible to measure what I do”. Perhaps we will write about all of these individually at some point, but the subject of this post is a personal favorite of ours: “Developer Relations is not about sales.”

Aside from open source projects, we can’t think of a Developer Relations role that doesn’t contribute to the company making money. Developer Advocates are actively out there convincing developers to adopt their company’s technology. DevEd are creating content and documentation to help developers adopt that technology faster. Support are removing roadblocks to the adoption of the technology. Customer/Developer Success are finding ways to scale usage of the technology inside their customers. The list goes on.

Despite this, it is not uncommon to hear people in Developer Relations circles say they have nothing to do with sales, that salespeople don’t get developers, and that they don’t talk pricing with developers because it somehow '“dirties” the conversation. Seriously, developers are well aware your technology is not free. To deny this does a disservice to the impact your work has in creating value for your company.

In addition to the Developer Relations team’s role in selling, at some point in your company’s growth, you will start to build a dedicated sales team. In many companies, especially Developer Plus companies, it is likely the Sales team was in place long before the arrival of Developer Relations in the organization.

In a Developer First startup, the trigger for a Sales investment is normally:

  1. Internal pressure to increase revenue by targeting large corporates who typically don’t buy via self-service.

  2. As your reputation grows, new buying personas appear. You are no longer exclusively talking to Developers. You now encounter “business” job titles who are less technical, who assess using different criteria, and require different tactics of engagement.

Social Media Sharable

Your activities as a DevRel team are predominantly focused on Developers and related technical job titles inside the target organization. Sales will operate in parallel to your DevRel activities to find, reach, and influence the “business job titles” inside the same organization.

It all comes together in the “sweet spot.” Here, all the relevant decision makers and decision influencers in the company are aligned and advocating for your product.

Top Down and Bottom Up Sales Approach

Ameer Badri has led Sales Engineering teams at several high-growth companies, including Netlify, Twilio, and Salesforce:

At Twilio we went into a number of customers where the DevRel team had warmed up the opportunity. We frequently heard, Oh I saw someone from Twilio speak at this conference or meetup. It created a familiarity. Of course we still had a lot of work to do, but it gave us a foot in the door.
Over the past 5 years I have seen significant changes, and the days of DevRel and Sales mixing like oil and water are gone. At Netlify the DevRel team attend customer meetings alongside Sales and help with sales related content production. Both teams are focused on solving customer problems and driving revenue.

The bottom up/top down sales motion is just one part. To be successful you must also align your activities so you can accurately track your sales funnel and measure the return on investment of all your activities, including Marketing, DevRel, and Sales.

In the diagram below, we have mapped the:

  • Developer context via the stages of our Developer Journey Map

  • DevRel Team perspective via the typical objectives of a DevRel team

  • Business perspective via a typical Sales funnel.

When aligned, you get a holistic view of performance.

How DevRel is mapped to the Sales Funnel and the Developer Journey

You will see that the DevRel objectives do align with the sales funnel - we did our homework!

Because most Developer Programs have some kind of zero-risk trial, a developer can become an active user (i.e., they complete registration) without spending money. This is why activation comes before engagement in our DevRel objectives. If you don’t have a “try before you buy” offer, it may be more appropriate to place engagement ahead of activation.

While the developer is at the experimentation stage (Learn), they are considered an “opportunity” in sales parlance because there is still a chance they never implement anything in production or buy your product.

The Developer only becomes a “won customer” when they start spending money. This is why the sequencing of the Build stage aligns with Customer won/lost. This is where the rubber hits the road, and it becomes clear if the developer has serious intent to adopt your technology.

Once the developer has successfully implemented something in production, the focus switches to nurturing and retention to ensure they remain customers over the long term, and additional revenue generation opportunities are explored. This is why Scale aligns with Retention, Account Management, and Customer Success.

How do you do it in your company? We’d love to hear your story of how DevRel and Sales are working together.


Don't miss new posts. Get email notifications by subscribing to our blog.


Commenting has been turned off.
bottom of page