skip to content W3C SVG

What is Developer Relations, Developer Relations Primer Part 1

Publish date: 2016-11-08

I’ve been doing developer relations long enough that I get asked a lot of questions. Particularly by people at companies that don’t have a developer relations program. So I thought I would put down a few thoughts in this series. This is Part One, What is Developer Relations. I’m not going to pretend this is an exhaustive examination of all possibilities, rather more putting down some thoughts.

A note on terminology

I work for Docker, a company that produces tools used by both developers and operations pros. Often find people using a relatively new term “DevOps”. I use the term “developer” here because the term “developer relations” is in general use, and there’s no respective “operations relations.” I know it’s not ideal to say “when I say developer, I mean IT too…” but it’s the current term of art.

What is Developer Relations

Developer relations is a relatively new field. Here’s my view of what developer relations team tries to accomplish:

  • Create champions for your tools. Champions are important for three reasons:

    1. Champions in the community generate interest in your tools by promoting it at meetups, blogs, StackOverflow, etc. It’s very rare that companies will adopt tools others haven’t vetted first, and developers are suspicious of marketing approaches.
    2. Champions give important feedback on how your tools can be used. You don’t know all the ways your tool will be used, and you don’t know all the bugs that exist in it. Accept that now. By creating a relationship with people in the community, whether it’s a personal one or through online participation, you are going to get this feedback that is crucial. Responding to feedback, and rewarding it is even more important. Probably more on that later.
    3. Champions in companies or consulting firms, where a lot of development is done, are vital. You can have all the sales or business development meetings you want, but if the people implementing the tools don’t understand the tool it won’t get adopted. Which is why it is important to get developers and operations people, whoever the right people are to adopt the product, to understand how to use something and why it is good. It’s even better if the champions promote the tools so that they come to your sales people.

  • Make it easier to use your tool once adopted. Your champions can’t do everything, you need to generate content that helps developers use the tool. This can be technical references, people who help developers on a one-to-one or one-to-(small number) basis, articles, reference architectures, etc.

There are many activities that fall into these categories, but it’s important to remember that this is why we do what we do.

What Developer Relations Isn’t

There are many people who have written about developer relations, and I’ll certainly reference a lot of them in the future. But they all seem to agree on one thing: Developer relations isn’t marketing. By that, they mean that developers are very suspicious about things they regard as marketing. That doesn’t mean you’re not engaged with the marketing team when you are doing developer relations. In fact, many DevRel teams are part of marketing. It means you speak plainly and technically, helping people and establishing these kinds of relationships. In the end, everyone at the company wants to make money and increase users, but DevRel teams do this in a very different way. More on that later.

Check out [Part 2: DevRel Personnel]({{ site.baseurl }}{% post_url /devrel/2016-11-14-devrel-primer-2 %} )