I organize Developer Relations around four specific areas. That’s not to say that any individual does or does not do all four. It’s more that our roles can be boiled down to these core areas.

1. Capture and represent product feedback
2. Build credible and authentic content that offers value to technical audiences
3. Connect and build relationships with community leaders
4. Attend and speak at events

Number 1: Capture and represent product feedback.

The core definition of Developer Relations mandates that we spend time with prospective communities or customers to get them excited to try (and adopt) a product, and really good Developer Relations people have a strong idea of how well those prospective customers receive the product. Great Developer Relations teams are expert observers and connectors: they earn the trust of engineering teams by crisply summarizing customer feedback (explicit and implicit) — and then use their solid reputation and credible technical arguments to drive action within their organization.

Number 2: Build credible and authentic content that offers value to technical audiences.

Some Developer Relations teams are also responsible for product documentation, which is a very smart and advisable thing, IMO. Your docs should represent the spine of your growth strategy. You may have the most beautiful website, but developers will quickly scan the homepage and search for “Docs” or “Developers” in the top-nav.

To the chagrin of many traditional marketers, they’ll bypass whitepapers and opportunities to sign up for a webinar and head straight to your docs. Your docs MUST be informative, entertaining, and comprehensive. If they’re great, your docs can cover up paper cuts in your product. If they’re excellent, your docs can turn a skeptical developer into a fan. You want your docs to spark the imagination of your developers and keep them coming back for more. It’s not just API references and introductions to core concepts. It’s also fun tutorials that fire up the creative impulses of your customers. Simply put, get your docs right.

Beyond docs, Developer Relations teams should build fun and engaging content that reaches new customers, gets them excited to use a platform, and guides them through specific scenarios. Note the word “guide”: the prospective customer should feel not only a sense of accomplishment with the product, but the content shows them how the product will be applicable to their projects or use case. Often, this content reflects deep knowledge of the community or types of developers that the product aims to recruit. Kathy Sierra does a great job discussing this concept – and many others – in her book Badass: Making Users Awesome.

Typically, you want a good mix of first-party hosted content (product docs, company blogs, etc.) and third-party content (Twitch live-coding streams, videos on YouTube, non-sponsored articles DZone, Smashing, and so on). Third-party content always includes liberal links back to first-party content (your docs and tutorials). You want to entice and motivate people to learn more, and give them the ability to do so, by clicking through to detailed technical guidance. This is a big reason why it’s so important that your docs are stellar: you drive developers to them through everything you do.

• For example, when posting on social media, use animated GIFs of your product in action with links to tech docs for developers to explore themselves (this is different from social media advertising, which is pure marketing and where you’d use campaign landing pages).

My strong advice is to not jump ahead of yourself and pay for placements before you get your docs and content right. As most traditional marketers learn, developers are inherently skeptical of advertising. Even if you’re a startup, it is a much better use of time and money for your top engineers to author quality content, alongside your Developer Relations team, and earn your way into top publications. Stephanie Morillo has written a fabulous book on content marketing for developers, with advice on how to identify relevant publications and approach the submissions process.

At the end of the day, good content is important. Your content must be technical, helpful, and everything we’ve discussed to this point. But breaking through the din of content requires more.

Great content is a reflection of your personal brand. You can do all the SEO and organic discovery tricks in the handbook. But the difference between consistently good and consistently effective content is how often people seek out your opinions and authority.

Number 3: Connect and build relationships with community leaders.

Your goal is to focus on long-term, collaborative, and technically credible activities. In other words, things that will develop over time, involve a good deal of mutually beneficial technical discussion, and be rooted in code. (Read my post on better community engagement.)

A lot of what we used to think of as “community engagement” revolved around meetups. Of course, community development is a lot more than buying pizza and giving talks. Spending time with like-minded enthusiasts helped us stay abreast of the latest thinking from community and product leaders, and the latest use cases from developers.

Today, communities exist everywhere. From private Slacks and Discords, to hashtags on Twitter, to email lists (what’s old is new again!) Identifying the communities most critical to your product is the first step.

You have to earn your way into a community. The way I’ve always done this is to first join a community, then lurk for a while. Learn the culture and common questions within the community. I’ll then author content to answer those most common questions. In those content pieces, I take the time to research the background behind the question. Why has a particular issue persisted version over version for a product? Often, there’s a good reason, with reasonable tradeoffs. Providing that background is important. Later, when an opportunity organically arises, I’ll jump in and answer questions, providing links to resources that provide more background on the answer.

Here are a few additional ideas:

• Partner with your internal engineering team and contribute to open source projects of the community leaders you admire and would like to build relationships with.
• Support or start meetups of your own.
• Create working specs for future products or services and share them publicly for collaborative feedback. “Developing and designing in the open” has tremendous benefits for both product design and community development.

Be genuine, authentic friends to your community. Adam Grant wrote wonderfully about this in Give and Take.

As we’ve discussed, the fundamental frame of the Developer Relations role is to engage with communities and get people excited about using your product, service, or project. You should never, ever do “fly-by-night” activities or marketing tactics with these folks: don’t ask them to Tweet something for you, don’t ask them for a quote in your press release, don’t ask them to endorse your product in exchange for a fee. These shortsighted approaches are inauthentic and will do far more damage than good. Mary Thengvall an excellent blog post on this topic.

Number 4: Attend and speak at events.

This tends to be the most glamorous part of the job, and I always intentionally put it last.

I’ve worked at companies big and small, and there’s always a reckoning with management over the cost of events. Whether your management is free-spending “lead acquisition at all costs” or errs on the side of frugality, it doesn’t matter. At the end of the day, justifying the expense of sponsorship, travel and entertainment, and time out of the office is always hard.

The first thing I would say is to take stock of all the events you believe are worth speaking at. If you’re a remote-first team with employees around the globe, you’ll likely be able to take on more events since the cost will probably less. Depending on your circumstances, some combination of time, resources, and cost will factor into which events actually make the cut for you.

From there, ask yourself whether you want to be in the sponsorship game. If your marketing team elects to sponsor booths and maintain a physical presence at events, more power to them.

More important than booths for Developer Advocacy is the opportunity to speak. Crafting CFPs is an art form, and Asim’s blog post on the topic is fabulous. Submit CFPs liberally. There’s nothing like working on a talk to really make sure you know your stuff!

But here’s the important part. Write the talk no matter what! That’s right, whether you win the CFP or not, write the talk!

And don’t just write the talk!

Write the blog post or white paper to go with the talk.

And record a video of you giving the talk! (don’t post it yet, though…some conferences only want original material. You can post it after your talk is done.)

Now, when you speak at the conference, you have two assets, a blog post/whitepaper and a video, to point your audience to. That’s a very powerful call to action for someone who was intrigued by your abstract and sat through your talk in its entirety.

Read more in my post about developer events.

Summary

In my 25 years of hiring and coaching Developer Advocates, I’ve only rarely found an individual who excels at all four categories of activities. It’s okay to specialize. Some people are exceptional community connectors who love to speak at events. While others are content factories who love to churn out blog posts and videos. Hopefully, you’ll be able to identify which category fits your personality best.