You and me, we do DevRel. Let’s take a moment and be blunt.

DevRel is, for me, about building trust, at scale. Except you can’t really build trust at scale. That’s kinda the nature of trust — it doesn’t scale. So we have all these cool tools in our toolbelt to get around this fact.

But once we start talking about “tools to scale trust”, well I dunno about you, but I start feeling awfully cynical. Maybe you noticed.

I begin to feel that developer relations is all about marketing to people who really don’t want to be marketed to. (Although, really, who does want to be marketed to? Maybe developers are just more explicit about their desires.) And then I begin to feel dirty. I begin to feel like my job is really all about manipulating people.

Is DevRel really this Machiavellian?

Obviously, it can be if you let it. But the Machiavellian developer evangelist will soon or later be found out, and their entire trust network undermined. Trust is fragile like that.

Although charisma can be faked, DevRel also requires genuine enthusiasm for your platform or product. I emphasize “genuine”, because it’s really hard to have fake enthusiasm. If your product or platform is no good, it doesn’t matter how much you flail your arms and smile and talk, no one will take you seriously. But if your product or platform really is very good, it’s actually difficult not to be actually enthusiastic about it.

The infectiousness of enthusiasm is our ally, not just in growing trust in us and our products, but for own psychological well-being. When we can see our enthusiasm start to spread, this is when I begin to feel re-assured that I’m not some detestable manipulator, that I’m not just engaged in psy-ops marketing designed to undermine the will of others, but that I am actually engaged in an activity that offers something of value to others.

Look for those moments of spreading enthusiasm. Create them wherever you can. If only for yourself. And if you can’t create them, if that enthusiasm is missing, take that as a signal that you’re at the wrong place, and use that knowledge to get yourself somewhere better.

As for me: I hope you can see and share in my enthusiasm for DevRel. And if you give me a chance, I hope I can get you as fired up about security as I am 😆

Thanks for reading along.

If you’re just joining us, however, you’ll want to head back to the intro and find your way from there 🤗

• Introduction: DevRel is about scaling trust
• Part 1: Convincing people to trust you
• Part 2: Lots of people, all at once
• Part 3: Selling pizza for favors
• Part 4: Surrogates, because this shit is too hard
• Part 5: Ambassadors and community
• Conclusion: Wherein I dispel my apparent cynicism (you are here)

Who am I? Hi! I’m @DEGoodmanWilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

Conclusion was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

The only way to really scale trust, however, is to scale the number of people involved in your trust network.

The final tool in the DevRel tool belt for building trust at scale is the hardest yet most rewarding: Ambassadors. Put simply, an ambassador is someone with whom you’ve created an especially deep and meaningful relationship, that you have deputized to go out and act on your behalf. They are your lieutenants, the future leaders of a community. Their networks become (by proxy) your networks, their reach your reach.

Earning the loyalty of anyone, let alone developers, is enormously hard work and requires not just dedication, but genuine affection and authenticity on your part. (Also, it requires a kickass product, and other things besides, but that is a topic for another time.) If you can’t form bonds with other humans, you have no hope of building a community.

And better yet if your ambassadors are not actually employees — when their love for your product springs from something other than a paycheck (or at least is not encumbered by the complications of a paycheck), that love is (rightly) perceived as having greater authenticity. You will even find that your ambassadors end up being a lot more effective at building meaningful relationships than you are. That’s great!

The point is that when you have help, you can escape the psychological bounds of social network size, and begin to really scale the relationships of trust you can build. This is the point where you have a community — and is the first real step towards making your product the obvious choice of developers everywhere.

Welcome to DevRel Level 1.

That’s a wrap. But, well, that was maybe a little cynical. Let’s talk about that in the conclusion, shall we?

If you’re just joining us, however, you’ll want to head back to the intro and find your way from there 🤗

• Introduction: DevRel is about scaling trust
• Part 1: Convincing people to trust you
• Part 2: Lots of people, all at once
• Part 3: Selling pizza for favors
• Part 4: Surrogates, because this shit is too hard
• Part 5: Ambassadors and Community (you are here)
• Conclusion: Wherein I dispel my apparent cynicism

Who am I? Hi! I’m @DEGoodmanWilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

Community was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last time I talked about using meetups to increase your reach and your individual effectiveness. But even meetups still require your physical presence, which in the context of current physics, is enormously limiting. Let’s transcend the laws of physics…with content.

This is part 4 of a series.

Let’s start with trust surrogates — artifacts, things, that stand in for you. In case you haven’t guessed it, I mean…yeah, content. By itself, content is dead trees & electrons held in ineffable quantum states. To be effective, raw content requires two things. First, just like the content you provide in person, it must dispense helpful and actionable advice. It’s also your chance to go really deep into a subject, and so to transform the reader into a hero by equipping them with large amounts of knowledge and even experience (through tutorials). However, as an instrument of trust it needs one more thing.

The reader needs a human connection to form the bond of trust with. Recall the hypothesis that trust is a feature of human relationships, and not of things. That hypothesis is particularly important here. The reader might believe the article, might find it useful, but we require some way to use the article to generate trust, in a person.

One obvious first step is to prominently introduce yourself (or the author, if you didn’t write it), rather than on anonymously attributing it to your organization. Great, now we have a human face! That’s a great start — now the reader knows that there is a person to trust, and who that person is.

Second, and far less obvious, is to pay close attention to the tone. The article must feel like a conversation with the author — as though thy were right in front of you. (Hello! 👋) Address the reader, engage them directly, use active voice, and make it feel like a shared journey. Just like I’m trying to do now. Make the article, in short, feel human. This is how a trust surrogate works (and why I call it that): It should be a stand in for you. It should be initiating conversations (and hence relationships) on your behalf while you’re busy doing something else, like sleeping.

Third, make it shareable. Your article will have far more impact if the reader discovered it from a friend, rather than a search engine. Because the reader will transfer some of the trust they place in their friend on you, the author. Search engines, being machines, things, not people, have no well of trust that can be transferred onto you. So while SEO is great, and so is maximizing overall views, the most important views are the ones who come to your article from a friend or colleague, because these are the readers that you can most readily build a relationship with. (And so sharing is what you should be measuring as your primary KPI!)

(This suggests that Medium is probably where you want to be sharing your content, as an inherently social platform where referrals from trusted sources are an easy and common route of discovery.)

In the next and final episode (Part 5), we’re going to finally find ourself face to face with trust at scale.

If you’re just joining us, however, you’ll want to head back to the intro and find your way from there 🤗

• Introduction: DevRel is about scaling trust
• Part 1: Convincing people to trust you
• Part 2: Lots of people, all at once
• Part 3: Selling pizza for favors
• Part 4: Surrogates, because this shit is too hard (you are here)
• Part 5: Ambassadors and community
• Conclusion: Wherein I dispel my apparent cynicism

Who am I? Hi! I’m @DEGoodmanWilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

Surrogates: Because this shit is too hard was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last time I talked about using talks to parallelize yourself. But talking, while both awesome and necessary, has two drawbacks: First, it’s really hard work to find a speaking gig on a regular schedule. Second, you are in the loop: your physical presence and energy is required for talks to work.

This is part 3 of a series.

Let’s get you out of the loop, and let’s set up something on a regular schedule. Yeah, that’s right: Let’s set up a meetup.

Creating and maintaining a meetup is perhaps a monumental undertaking for smaller organizations (and very difficult for larger ones), and the chance of failure is very high — but when it works, it works very well.

Why does it work? You get the chance every month to engage with a crowd of new people, and more importantly, to re-engage with returning regulars. Just like the relationship your bartender has with you, the repeated encounters allow you to deepen many relationships in one go.

The other compelling aspect of meetups is that the value you offer attendees is not wisdom from your own rapidly dwindling font, but a never-ending stream of helpful and actionable advice from a changing, ever-fresh variety of sources, as well as the chance for the speakers and the attendees to forge new, profitable relationships with each other. You get to play matchmaker, and people like that. When it works. And is opt-in. Which meetups are. So there.

Why is it hard work? Why do meetups so often fail? If you’re asking, it’s because you’ve never tried. A week of coasting on the previous meeting’s success, two weeks of frantic searching for speakers, sponsors, a venue, catering. One week of pleading with your friends to maybe come fill a slot with a last minute talk, oh thank god you have a place, crap you forgot the food you’ll just order some pizza and call it a night. Oh crap, it’s this week, we need to promote it on Twitter, why isn’t anyone RSVPing, we need to get more people to attend. And you have a day job too…yeah, it’s easy for this kind of enterprise to fall flat on its face.

But these techniques — talking and workshopping and meeting — still have their limits. You can only meaningfully connect with an audience of a certain size at a time, and, more to the point, human psychology puts an upper limit on the number of social relationships you can reliably maintain. This is where trust surrogates and ambassadors allow you to scale to the next level.

In the next episode, we’re going to transcend the need for actual face-to-face conversations using dead trees and spinning magnetic fields.

If you’re just joining us, however, you’ll want to head back to the intro and find your way from there 🤗

• Introduction: DevRel is about scaling trust
• Part 1: Convincing people to trust you
• Part 2: Parallelizing yourself
• Part 3: Selling pizza for favors (you are here)
• Part 4: Surrogates, because this shit is too hard
• Part 5: Ambassadors and community
• Conclusion: Wherein I dispel my apparent cynicism

Who am I? Hi! I’m @DEGoodmanWilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

Selling Pizza for Favors: Building Trust Through Delegation to Other People and Food was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

OK, so we’re starting to form personal relationships, a couple anyway. How do we scale our DevRel efforts from here? The next step is to increase the opportunities to meet new people.

This is part 2 of a series.

The best way to meet more people, as any backend dev worth their salt will tell you, is to parallelize. This means getting in front of as many people as you can, and addressing them at the same time. But all those people have different needs, and different values, and maybe even they have better things to be doing with their time. We can’t possible give them all personalized advice or whatever, not without boring everyone else to tears and driving them out of the room.

This is why we do “talks”.

A talk, when we approach this technique from the point of view of building trust, is generalized, yet in-depth, advice with wide appeal. The desired outcome of a talk is to make as many people in the room trust you as much as can be managed, in virtue of having been help to them. It’s like having a one-on-one discussion with everyone except that you have those conversations all at the same time. Obviously, this parallelism will dilute the effectiveness of the relationship-building aspect, but this is just a first step.

Because, secondarily, the content of the talk will hopefully encourage a manageable number of the listeners to approach you to deepen that nascent relationship. You will be tempted to brush them off, as giving a talk is extremely exhausting. But in fact finding people that want to approach you is really fucking hard. There is a good chance that these people are future ambassadors (see later in the series). Take advantage of the moment.

Workshops are similar to talks, in that you are addressing a room, but typically you will be going for longer, in more depth, and interactive with many if not all of the participants directly over the course of the event to help them succeed. Also what you are offering is a little different, a little more personal — you aren’t just arming them with sage advice, you are giving them the giddy sense of accomplishment. Ideally.

Workshops are therefore even more exhausting, but also proportionally more rewarding in that the relationships built are that much stronger. I personally find workshops the most effective tool in the DevRel tool belt, and I aim to say a great deal more about them in a future post. Watch this space.

You’ve been reading Part 2 in an ever-increasingly mis-conceived trilogy of posts on scaling trust with Developer Relations.

Next, in Part 3, we’re going to talk about scaling trust with pizza.

If you’re just joining us, however, you’ll want to head back to the intro and find your way from there 🤗

• Introduction: DevRel is about scaling trust
• Part 1: Convincing people to trust you
• Part 2: Parallelize yourself (you are here)
• Part 3: Selling pizza for favors
• Part 4: Surrogates, because this shit is too hard
• Part 5: Ambassadors and community
• Conclusion: Wherein I dispel my apparent cynicism

Who am I? Hi! I’m D.E. Goodman-Wilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

Parallelizing Yourself: Building Trust With Lots of People at the Same Time was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developer Relations begins with trust, and trust begins with people.

This is part 1 of a series.

In case you missed it, we’ve been talking about how Developer Relations is fundamentally about building and scaling trust. In this article, I want to talk about the ontological underpinnings of that endeavor, meeting people, and building relationships with them.

Yeah, that’s right: I want to talk about networking (ugh). Nothing else that we do will work without building a strong foundation of real, personal relationships with developers.

This shit is hard. Developers are often suspicious and introverted by their nature. (But not always! Hello Duretti if you’re even reading this!) They aren’t always easy to find (the ones you are looking for, anyway), and they don’t always want to make friends (and hell, maybe you don’t either). So, even though this is a fundamental activity of DevRel, it usually piggybacks on other activities. Attending meetups can be effective, but requires time and energy — and anyway such ephemeral meetings rarely involve an exchange of value.

Did I say “exchange of value”? Yeah I did. I said we were going to be frank. Relationships, at least in our field, begin with you giving a developer something of value, something helpful. Not “maybe helpful”, but “actually, obviously helpful”. This might be a timely piece of advice, actionable long-form content, or an item or experience that raises their status among their peers (like cool fucking socks).

Such opportunities for exchange are uncommon, and each is different and must be carefully read. The idea, then, is to put yourself in places that maximize the possibility for such an exchange (like at your company’s booth at a conference, or as the speaker at a meetup), and to arm yourself with as much useful knowledge as possible. And swag, definitely swag.

Now after all this preparation you’ve met someone, and buffed them with some timely advice and some sweet stickers — now what? Keep the conversation going after you part ways. Find as many opportunities to be valuable to them. Not because you are a Machiavellian jackass, but because you actually give a shit. This may be the hardest part of DevRel, the giving a shit. It’s draining. And absolutely necessary.

People have a great sense, I’m sure you’ve observed, for when someone is not being genuine, for bullshit. And unless you are a master manipulator, they will see right through you, and all that trust you’ve built up is gone in a blink.

This is just one reason why trust is so hard to scale.

Side note: This is also why DevRel cannot in any way be connected to sales, not ever. If someone discovers that your “helpful advice” is being driven by sales KPIs (and OMG they have their ways of discovering the truth), it doesn’t matter how pure your intentions. Basically everyone, but developers especially, hates the feeling that they are being sold something. This is among the worst kinds of manipulation that people are forced to endure. So keep DevRel out of sales. Seriously.

You’ve been reading Part 1 in an ever-increasingly mis-conceived trilogy of posts on scaling trust with Developer Relations.

Next time? Let’s move beyond the one-on-one, and think about parallelizing the task of communicating with people.

If you’re just joining us, however, you’ll want to head back to the intro and find your way from there 🤗

• Intro: DevRel is about scaling trust
• Part 1: Convincing people to trust you (You are here)
• Part 2: Parallelize yourself
• Part 3: Selling pizza for favors
• Part 4: Surrogates, because this shit is too hard
• Part 5: Ambassadors and community
• Conclusion: Wherein I dispel my apparent cynicism

Who am I? Hi! I’m D.E. Goodman-Wilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

Scaling Trust: Start With People was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

A series

You and me, we do DevRel. Let’s take a moment and be blunt.

DevRel is, for me, about building—and scaling—trust. Trust and awareness. Trust and awareness and a business case for international travel. But I get ahead of myself. Let’s talk about trust.

Look — if we want our products to be no-brainers for people to choose (and who doesn’t?), we have an enormous task ahead of us, one of building trust. Without trust, not using our product is the easy decision. To make using it an automatic choice requires intense, widespread trust.

We want developers to automatically turn to our product or tool. We need them — perhaps all of them — to believe in the value of our tool implicitly, which means trusting us, the people behind the tool, implicitly.

That’s tough.

I’m going to talk about tools for building trust, and (more importantly) for scaling trust. There’s little here that might surprise you, when I start talking about, I dunno, giving talks, and talking to people. What I aim to do here is to put everything we do in DevRel into a coherent and interesting framework, something that makes sense of our jobs, and that maybe can help us understand ways to advance our craft. A framework that emphasizes trust, and giving our product a human face.

Working definition: Trust is a human thing, a feature of human relationships. One cannot trust things, only people, (although one can believe claims about things of course).

Hypothesis: Trust is built through developing close personal relationships.

Immediate conclusion: Holy shit, this is gonna be a lot of hard work.

Let’s take a simple example. Imagine: You stumble across an article randomly. Said article makes a bold, perhaps controversial, even outrageous claim. Chances are you’ll dismiss it out of hand. Now imagine: A close friend shares the same article with you. Some of the trust you place in your friend makes you more likely to believe the article. You transfer a small amount of the trust you place in your friend into the article’s author.

This is precisely what we do with DevRel: We set out to form bonds of trust with developers, and we do it not to drive leads through the sales funnel, but to create warm fuzzy feelings in developers so that ultimately they can’t not imagine using our tool — and recommending it to those decision makers who are in the sales funnel. We create the conditions for strangers to build trust in our product team, and belief in our product.

So, we in DevRel are chasing trust, real genuine trust built on meaningful personal relationships…at scale.

By their very nature, personal relationships cannot scale. So how do we make this work, and how do we measure it? DevRel has a lot of arrows in its quiver. Over the following series of articles, let’s examine how they work together to bring about trust at scale, and maybe we can figure out how to do our jobs just a little bit more effectively.

Up next, we’ll take a look at that most basic of DevRel activities…yes, networking. (Ugh.)

• Introduction: DevRel is about scale trust (you are here!)
• Part 1: Convincing people to trust you
• Part 2: Parallelize yourself
• Part 3: Selling pizza for favors
• Part 4: Surrogates, because this shit is too hard
• Part 5: Ambassadors and community
• Conclusion: Wherein I dispel my apparent cynicism

Who am I? Hi! I’m D.E. Goodman-Wilson, and I’m the head of developer relations at Sqreen. We give your web application the ability to defend itself against attacks. You should try it out.

[Note: this was originally a much longer article — too long, in fact! — that I have broken down into a series of shorter articles, because who knew? people can’t digest that much all at once. 😵]

DevRel is about scaling trust. was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

All of that seems odd considering that one doesn’t ask what an engineer does. Or what a sales person does. Those things are fairly well defined and easy to measure; either you shipped a product or you sold said product. It’s because of this modern lean manufacturing need to categorize things in ways that can be measured that I’ve often heard Developer Relations likened to Marketing or Technical Marketing. Sometimes you will find the words “Developer Relations” or “Developer Evangelism” in the job description for a Marketing Manager.

To be perfectly clear, Developer Relations is not Marketing.

Attractional Vs Relational

When we think about Marketing, we can think about it as an attractional model of connection with customers. Marketing by it’s function says “Look at me! Look at me!”. You can hardly get away from it. It’s on your favorite web pages. It’s before the YouTube video you want to watch. It’s plastered all over highways and in between every 3 songs on Pandora.

Marketing is often done in a way that is intrusive and overpowering. There is a good reason for that. Many brilliant marketing minds have provided good evidence to show that you can imprint and idea into someone’s mind and get them to take action simply by saying it to them over and over again. Kind of like Inception, but with 100% less Leonardo.

In 1885, Thomas Smith wrote the following about advertising.

The first time people look at any given ad, they don’t even see it.

The second time, they don’t notice it.

The third time, they are aware that it is there.

The fourth time, they have a fleeting sense that they’ve seen it somewhere before. The fifth time, they actually read the ad.

The sixth time they thumb their nose at it.

The seventh time, they start to get a little irritated with it.

The eighth time, they start to think, “Here’s that confounded ad again.”

The ninth time, they start to wonder if they’re missing out on something.

The tenth time, they ask their friends and neighbors if they’ve tried it.

The eleventh time, they wonder how the company is paying for all these ads.

The twelfth time, they start to think that it must be a good product.

The thirteenth time, they start to feel the product has value.

The fourteenth time, they start to remember wanting a product exactly like this for a long time. The fifteenth time, they start to yearn for it because they can’t afford to buy it.

The sixteenth time, they accept the fact that they will buy it sometime in the future.

The seventeenth time, they make a note to buy the product.

The eighteenth time, they curse their poverty for not allowing them to buy this terrific product.

The nineteenth time, they count their money very carefully.

The twentieth time prospects see the ad, they buy what is offering.

This is called Effective Frequency. This is the cornerstone of modern Marketing. That means that everyone selling a product knows they have to get their message in front of you 20 times before you will buy. This is why the average consumer sees between 4,000 and 10,000 ads every day. That’s Marketing saying, “Look at me! Look at me!” That’s a DDoS attack on your head!

Developer Relations flips this model on it’s head and says “Let’s talk about you”. Developer Relations acknowledges that there is a human being on the other end of any commercial exchange, and that human being has feelings and struggles. They get sad. They have good days and bad days. Everyone is fighting a battle that we cannot possibly comprehend. It’s to that end that Developer Relations seeks to help the company sell it’s products by going into the community where the customers are and sharing their burdens.

Here is another way to think about it. Imagine that someone is building a house. As they build the house, multiple people are walking by on the sidewalk and yelling things to them. “Buy a nail gun! You’ll go so much faster!” “Get a new hammer!” “Look at this gorgeous tape measure!” This is Marketing.

Developer Relations is the person on the lot next to you that’s also building a house. Both of you are doing the same work, but the Developer Relations person is using a certain set of tools because she works for the company making those tools. After a while the two of you become friends. A little while on you realize that there are some things that this person is doing that seem to work really well because of the tool that they are using. It’s at this point that you tune out all of the marketing noise and begin to make your purchasing decisions based on your friendship with the individual next to you and your respect for the work that they do.

This is the essence of Developer Relations.

Personal vs Impersonal

Marketing is, by definition, impersonal. Organizations and Corporations don’t have souls. They are entities that do not feel despite their best efforts to do so and the feel good commercials that make them seem like they might. That’s not to say that the individuals that work there don’t feel, but rather that the collective hive, that thing which sells and needs to grow to stay alive — that thing does not feel. It cannot feel because you are too far removed from the individuals behind it.

We do not form relationships with groups of thousands. We form relationships with one person at a time.

This was echoed just recently in some investigative journalism that was done on Facebook. They reported that people on Facebook are more likely to be left depressed by the interactions that they have. Why is that? Aren’t all those people their “Friends”? Of course not. These are simply people that you know of. Meaningful response only occurs when there is deep 1:1 interaction. We can have this deep interaction with multiple people, but it has to occur or we are left feeling alone. Shallow relationships drain us. Deep ones are the fuel by which we keep moving day after day.

Marketing on it’s own will leave consumers without any meaningful interactions with a company, which means it will ultimate drain consumers. Without a connection, there is no “stickiness”. In other words, in order to keep this consumer loyal to your brand, you must constantly churn out a string of products and chant about those items day in and day out.

This model of interaction is classic and proven, but also quite expensive.

The market — any market — is saturated with competitors doing the exact same thing you are with a highly comparable product and a team of Marketers who are just as aware of effective frequency as you are. This is where Developer Relations becomes the competitive differentiator.

Developer Relations forms meaningful relationships with consumers built on mutual respect and trust. This is possible because Developer Relations is in the field, meeting customers and experiencing their exact same pains, frustrations and needs day in and day out. This has the added benefit of providing you with first-hand knowledge of what it’s like to actually use the tool or product that you have created.

In Defense Of Marketing

Now my good Marketers out there will take serious issue with the above point and point out that theories like effective frequency (The above is considered one theory of Effective Frequency) have many different interpertations. They will also say that it is quite possible to have meaningful interactions with individuals via standard marketing mediums if it is done well.

On this notion, I entirely agree.

I am not suggesting that Marketing as a function is all bad, but rather the model that we’ve come accustomed to is.

At Progress, we attach Marketing and Developer Relations at the hip. For any product we have both a Marketing Manager and at least one Developer Advocate. It is through this relationship that we help create meaningful messaging with marketing while building meaningful relationships in the community. When you are able to get these two groups to work together successfully, the ultimate goal is to get your Effective Frequency numbers down as low as possible through the use of Developer Relations. Not only does this save a lot of money spent on Marketing; usually the largest cost center in any organization, but it should also drastically increase customer loyalty. Anyone who has run a business knows that loyal customers are how a business is built.

Merging Developer Relations With Marketing

This might lead one too ask, “Couldn’t we just combine Developer Relations and Marketing into the same role and eliminate redundancy?”

This is another urge perpetrated by those lean manufacturing principals on which modern industry is propped up, but which will ultimately leave you with only Marketing and no Developer Relations.

Marketing has discreet goals. Sometimes these are MQLs (Marketing Qualified Leads) and sometimes they are actual sales quotas. As soon as you assign a product metric to an organization, you remove their ability to form relationships with the consumer. Imagine if that Developer Advocate building the house next to you was told they had to sell 10 hammers every month. It’s going to be very hard for them to form any sort of meaningful relationships because they will always have the agenda of selling you a hammer, which completely flattens their integrity.

People are very cautious of these sorts of interactions in their lives and they avoid them. There is nothing more insulting than someone who shows interest in you so that they can sell you something. If you’ve ever been propositioned for a Multi-Level Marketing Scheme, you know exactly what I’m talking about.

Developer Relations is wholly different because it’s output is hard to discreetly measure. Modern lean manufacturing principles eschew what cannot be measured. As if a lack of measurement is an indication that the need doesn’t exist. Ignoring what can’t be measured is a fools errand with honorable intentions.

All of that said, Developer Relations most certainly should be measured, and there are different theories about how to properly do this, but that is another post for another time.

Developer Relations Vs Marketing was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.

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?”

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.

∎

DevRel × Sales was originally published in The DevRel Salon on Medium, where people are continuing the conversation by highlighting and responding to this story.