The 3 C’s of Developer Relations

A lot of people ask what a Developer Evangelist does, and the answers can vary a bit depending on which company they work for, and how the team is placed within the organization. Regardless of the tactics in place, all of them are based on a few core principles of Developer Relations, which I call the 3 C’s: Community, Code, and Content.

Community

If you don’t have a way to reach developers, your Developer Relations program isn’t worth much. At SendGrid, our main strategy is “give first”–the more successful start-ups there are, the better off everyone is.

As Tim has said before, a personal connection is worth more than a click. We don’t think in terms of leads. We’re thinking about how our interactions with developers and entrepreneurs can inform what we do, and how we can help those developers and entrepreneurs be their best possible selves. To build personal connections, you have to contribute to communities.

For us, this entails sponsoring and mentoring at hackathons, supporting cool projects that need help (like mailhops.com), visiting and mentoring at accelerators, code schools, and community outreach programs, and offering discounts to startups and non-profits. We also offer up our office space to host meetups and events.

You also need to think about your online communities, like people asking about your product on Stack Overflow and Twitter. It’s impossible to be everywhere where developers are in person, although we try our best. Fortunately, pretty much every developer is on the internet, so we try to be everywhere we can online as well.

Code

If you’re trying to reach developers, you’re gonna need code.

At SendGrid, evangelists manage all of the official SendGrid API wrapper libraries. We provide support to developers and often help them debug code. Sometimes things we write end up in production, like the SendGrid Subscription Widget. We answer code questions on Stack Overflow. The Dev Rel team is also the custodian of the SendGrid Documentation, which is open source.

Content

It’s not enough to solve a developer’s problem in an abstract way. You have to proactively publish very clear, concrete implementations, and you have to do it in a way that is relatively easy to find and consume. We publish most of this content in the technical category of the SendGrid Blog. Our evangelists also give demos at events that demonstrate not only concrete solutions, but how easy they are to write and implement.

Developer evangelists also demonstrate value. Sometimes, this is accomplished by showing people answers to problems they don’t even realize they’re having. For example, Kunal’s hack at TC Disrupt, using the inbound parse webhook to maximize your value at Taco Bell, which got a ton of press coverage and showed people that we can help solve their programmatic inbound email problems as well.

The Takeaway

If you’re thinking about a Developer Relations program for your startup or scaling business, focus on the Code and Content sections first. Have your engineers write technical blog posts and sample code, and make sure your documentation is a priority. Try to establish these things as part of the engineering culture as early as you can. They will help you scale to the point where you can hire dedicated Dev Rel engineers to focus on community by driving a lot of self-serve revenue.