We’re all on a boat. The same boat. Together.

Take a long hard look.

Tl;dr. Developer relations is not a cost center, but a revenue center, whose goals are closely tied to sales’s goals. And this is good news, because now we have something interesting to measure. And we’re just going to have to get over it.

Why our organization even does DevRel anyway

We do developer relations, as an advocate or an evangelist or whatever title we’ve given ourselves. We find ourselves faced with the question:

“So, what would you say you do here?”

For my money, I don’t know if it gets any better than when he sings “Jack Sparrow”.

We’re people-persons, dammit! We get developers fired up about our platform or tool. “We get developers to try our platform!”

Great — we probably even know how to measure that goal, and understand if we’re making progress towards it. We’ve got our strategy in place, we know our key activities, and we’re going to town filling that developer funnel.

Then comes the response we dread to hear. “I see. So, why do we need developers using our platform, exactly? They’re not paying for it, so the free hacker plan is a huge cost center for us. I’m thinking about shifting your budget to the sales team.”

Shit. Time to start the hand-wringing. I mean, come on, we’re a developer tool, right? Developers are obviously important to us, and we’re bringing them in. What more do you want?

The problem is that sales, or even marketing, is always going to look like a more attractive place for those-who-decide to invest their budget in, at least in the short term, because these activities fill the sales funnel, and have directly measurable effects on revenue. So why bother?

One way to answer this question: Because DevRel is a sales support team.

Yeah, that’s right, I said it. We do sales.

Kinda.

OK, so that’s taking things just a little far. There are lots of other teams that work even more closely with sales to the same effect, like sales engineers and buisness development. But I do want to take some time to critically assess the relationship between developer relations and sales. The surprising conclusion (wait for it…) is that DevRel is a revenue center, not a cost center.

(Clearly, there are plenty of other good ways to think about the role of developer relations. But I think we unfairly make discussion of the relationship with sales taboo. Let’s break that taboo.)

So, I’m going to argue for this: Regardless of how our organization is structured, DevRel’s role is to shape the sales funnel, to increase the conversion rate by making leads happy. DevRel is a good investment when every additional dollar/euro/yen spent makes sales deals more likely to close, faster to close, or results in larger contracts—and you can measure that impact.

Developer Business Models

To make this point, the first step is to think carefully about the relationship between developer platforms and sales. I think, broadly speaking, there are roughly two distinct business models for which developer relations is often called to play a role:

Platforms that sell directly to developers or developer-adjacent roles (such as operations or security). Examples include:

• developer-focused APIs, e.g. Stripe

• developer productivity software, e.g. JetBrains

• cloud code and infra monitoring, e.g. New Relic

• PaaS, e.g. Heroku

• developer tools, e.g. NPM

Platforms that drive sales of a consumer product (such as ecosystems). Examples include:

• consumer platforms, e.g. iPhone / Android

• business software, e.g. Slack

• anything where the platform is not being directly monetized as a revenue source

This list isn’t exhaustive. I would love to hear about other business models. But it’s designed to at least sound exhaustive and mutually exclusive. So:

assumption: Either we’re selling to developers, or we selling to non-developers.

In either case, the role that developer relations plays is going to be quite different.

Selling to developers

This is the obvious case, and probably the one we’re probably most familiar with. We have a product geared specifically to developers, and here developer relations is super close to being straight-up marketing: Our goal is to get the product in front of developers, and convince them to just give it a try.

To the extent that developer relations is marketing in this scenario, we see ourselves as widening and loading up the sales funnel. All of our activities are designed around this goal: Building awareness through sponsorships, swag, and generally getting in front of people; Increasing signups by offering free plans, referral programs, or giving away premium swag.

But, we work so very hard at distancing ourselves from sales. We are not, are not in the business of generating leads for the sales team. Our community would revolt the moment they even thought that might be what’s going on!

Aside from underestimating the inferential power of our community (they know what we’re up to, believe you me), this reaction reflects a peculiar tension in our thinking: We can’t both be front-loading the sales funnel, and also not engaged in sales activity.

But is that really the right way to think about what we’re doing? I think there’s a better way to think about our purpose in doing DevRel that avoids this tension.

Consider: Developers almost never directly convert to paid customers. There are exceptions, of course, but in general I’ve heard this time and again. It’s the engineering managers, or VP of engineering, or CTO who makes the purchasing decisions for developer tools. And herein lies the key.

The purchasing decision may be made from on high, but it’s not made in a vacuum. That decision requires the support of the line engineers. If the product sucks, or the engineers don’t like it, or don’t even know about it, it’s not going to get used — and comments will be made. Indeed, the sale probably won’t even close in the first place. On the other hand, if it’s something the engineers are enthusiastic about, already love, already know, then closing the sale is going to be a lot easier, and we’ll see less churn.

Our role is to ensure that the latter case is what happens, to ensure that developers are aware of, know and understand, and love our tool/platform/whatever. We do that by building awareness, getting free samples into their hands, and listening to their feedback.

We don’t expect them to convert. But we do expect their company to be more likely to convert.

I call this shaping the sales funnel. We don’t fill it, we don’t herd people through it, we sure as hell don’t close sales. But we increase the percentage of qualified leads who convert.

theorem 1: With a developer tool or platform, developer relations exists to increase sales directly, by affecting the purchasing decision.

Is this measurable? I think that it is. Let’s come back to this question in a moment, and first look at the other kind of developer relations gig.

Selling to consumers

OK, so maybe the previous case was not so much of a surprise. Let’s consider the case where developer relations is totally divorced from sales — the case where the product we’re selling is a completely distinct entity from the developer platform.

Let’s just take Slack for an example of a product in this space, since it’s at least one that I’m familiar with. Slack is a communications suite for businesses. The value in Slack is in how it transforms office communications.

Slack built a developer platform on top of the consumer product, with the idea that Slack becomes more valuable when there are apps that can increase productivity or improve channels of communication. And, at a given price, the greater the value of the product, the more likely someone is to buy it. Easy-peasy.

Generalizing a bit, the role of developers in this kind of ecosystem is to build awesome apps that make the consumer product more valuable to our customers (present and potential). In return, developers get a slice of the ecosystem for themselves.

Our role is to ensure that the developers are excited about seeding our platform with cool apps that actually do increase the value of the consumer product. We work at building awareness not just of the platform, but of the opportunities there, and acting as a supportive partner to nurture them all the way to delivering their own product. This means we have our own developer funnel, entirely separate from the sales funnel, with conversions measured in terms of apps in the marketplace, or third-party product adoption.

What’s the point all this? What happens when developers deliver apps into the marketplace? It makes potential customers more likely to convert (and existing customers more likely to upgrade, or at least not churn). That’s the idea anyway. That’s why we even have a developer platform in this scenario.

So, the extent to which we do interact with the sales funnel is quite indirect. But we are still very much shaping it: The fruit of our labors is ultimately that we increase the percentage of qualified leads who convert, because the appeal of our product is increased by the marketplace.

theorem 2: With a consumer app with a dev platform, developer relations exists to increase sales indirectly, by making the product more appealing. intermediate conclusion: Developer relations exists to shape the sales funnel, from assumption 1 + theorems 1 & 2.

So: Developer relations shapes the sales funnel

Although the DevRel processes and activities are very different for each of the business models discussed, the end result is the same: The more developers actively using our platform, the easier the sales process is.

But developers are allergic to salespeople, right? Yeah, maybe they are. But there are advantages of being open about our relationship with sales. For one, forging a closer relationship with the sales team can only build a better culture in our company by creating opportunities for collaboration. For another, being honest with ourselves helps us build the image of authenticity that we need to do our jobs effectively. But most importantly: It gives us something to measure.

I think we can measure this effect on the sales funnel. Which means we might very well have a measure of how developer relations has a direct impact on the company’s bottom line (that isn’t just outrageous expense reports). And that’s quite a step up from the tired “DevRel’s impact isn’t really measurable” line. Indeed, is our ammunition for the claim that developer relations is not a cost center, but a revenue center. Just like sales.

Measuring this effect is more tedious than opening our books and looking at the sales numbers for the month, unfortunately. We have to look at each sale closed and ask ourselves: How easy was this sale? To what extent did DevRel contribute to make the sale easier, faster, or larger than it would otherwise have been? The first question requires us to quantify a quality. The second requires us to evaluate counter-factual claims that are very tricky.

How we go about answering these questions depends on the business model.

Measuring consumer platforms

Measuring consumer platforms is less direct, but at least we can look at numbers. We want to know: Did the availability of apps increase the likelihood of closing a sale? Put plainly, we want to know whether this is true:

P(S|A) > P(S|A)

Where S is a closed sale, and A is the availability of apps.

Properly measuring this requires us to perform some rather invasive interventions, such as stopping offering apps on our platform for a little bit, and measuring the drop in sales conversion — not something we are likely to get approval for.

But we can estimate these probabilities, through a number of proxy measures. We could, for a start, compare the rate of growth to the rate of availability of apps. Hopefully you have these numbers at your disposal. We can also ask: How many apps do paying customers use, compared to customers on a free plan? How much do our customers spend on apps? Do sales slow down in the same months that marketplace launches slow down?

Of course, measuring the impact of apps on conversion should be the concern of everyone on the platform team, not jut DevRel. What we really want to know is whether the availability of apps is something that we’re driving. And that’s where the usual developer relations funnel comes in. To the extent that we are driving the creation of those apps that are driving sales, we are successfully shaping the sales funnel.

One thing I am leaving out of this discussion, because I don’t want to go too far out in the weeds just yet is the impact on app quality on all this. If all that’s available in our marketplace is a bunch of flashlight apps, we’re not likely to see a great deal of impact on the sales funnel. This is another area where DevRel can have an impact, especially if we are willing to provide not just technical assistance, but product design assistance as well. But that’s an article for another day.

Measuring developer tools

Here, we won’t have numbers to help us, because there isn’t a clear relationship between the developers developing, and the developers’ managers purchasing. Often, we won’t know when the developers in our developer funnel are working for teams that are in the sales funnel, because they developers are using the products in side projects, or in other contexts. But generally, the impact that our developers have on purchasing decision is just plain foggy: It might manifest as an attitude of support or an atmosphere of grumbling in the workplace.

But that’s not to say we need to fly blind. I propose this, in fact. We ask the people who decided, at long last, to hand us their money. What we ask will depend on which business model we fall under.

To what extent did developer opinions influence the decision to purchase? To what extent did developers support the decision? Harder: How did developers first hear about our product? Do developers use the product on the side?

DevRel success, in these cases, is evident when there is an abundance of anecdotal evidence that developers are supportive of purchasing decisions. Understanding how we should adjust our strategy in the face of such evidence will be more like reading tea leaves. But we can at least use this data to experiment — does developer support for a purchase increase after an experiment? Or decrease? We can at least use this kind of data to hone our strategy over time.

OK, fine. What did we learn?

∴ Developer relations is a revenue center. It’s goals are closely tied to revenue, and hence sales, regardless of who is paying for our product. And we can measure this impact of our activities on the sales team, although it’s maybe not easy. It is at least theoretically possible.

And all of this serves to justify our existence, in very strong terms, to our questioning bosses.

∎