Don Goodman-Wilson

Engineer, teacher, philosopher. Time travel paradox resolution consultant. Developer advocacy evangelist. he/him

DevRel is about scaling trust

Come with me if you want to build cool thingsCome with me if you want to build cool things

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.)


Start With People

Networking often works about like this.Networking often works about like this.

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

Let’s 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.


Building Trust With Lots of People at the Same Time

Parallel parking, get it? Get it?Parallel parking, get it? Get it?

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.

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.


Building Trust Through Delegation to Other People and Food

Hire this guy, like right now.Hire this guy, like right now.

So, you can use 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.

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.


Surrogates: Because this shit is too hard

You can give this feeling to others.You can give this feeling to others.

We can use 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.

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. But I have mixed feelings about this.)


Community

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

Go go go!Go go go!

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?


Conclusion

Wherein I dispel my apparent cynicism. A little bit.

Such enthusiasmSuch enthusiasm

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.

Thanks for reading along.