The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success

by Mary Thengvall

Awareness: General knowledge of the product and what it does Acquisition: Users coming to the site from various channels, resulting in a sign-up Activation: Product implementation (for example, makes first API call) Retention: Continual use of the product Revenue: Pay for usage (for example, subscribe or buy product) Referral: Refer others (become brand ambassadors) Product: Provide feedback or contribute to the product

input metric you’ll run into—what could you implement that might influence your outcome?

What’s going well? What could we be doing better? What should we do differently going forward?

The first three titles I list (DevRel Manager, Developer Advocate, and Technical Community Builder) are ones that I feel strongly should be a part of every Developer Relations team.

(Developer Experience Manager, Technical Ambassador, Technical Engagement Manager, DevRel Project Manager, and Full-time Engineer) are relevant for some teams but not others.

You’re looking for someone who may or may not have a technical background but who can speak the lingo and keep up with the conversation. They know the right questions to ask and have experience with technical products. They don’t necessarily have day-in-and-day-out coding experience, but they know the basics and can follow along with simple instructions enough to know whether your Getting Started guide is clear and easy to follow. They’re also able to take a “forest” view of the situation rather than getting stuck in the weeds of sample apps, bug fixes, and community forum wrangling.

having regular check-ins with Marketing, Product, Support, Sales, and Engineering.

The title Developer Advocate covers two of the biggest questions in the community space : What are your qualifications? What do you do?

One note of caution when hiring for this role: although it’s tempting to require that this individual produce several pieces of technical content per month, as well as speak at conferences regularly, as well as keep up with all the latest and greatest code developments, as well as take a deep dive into the product code base and create sample applications and SDKs , you need to be conscious of the fact that there are easily three full-time jobs within that job description.

I very specifically call these folks ambassadors, not evangelists. The word evangelist implies a religious affiliation, which has a negative connotation in many countries and can make it difficult to even get in the door at some businesses, let alone build credibility.

The term Technical Ambassador , on the other hand, distinguishes this role from Developer Advocate and establishes this individual as an ambassador of goodwill on behalf of the company.

Though this might at first glance seem very similar to the Developer Advocate role, this role has more of a sales focus than a community focus. These are the folks who excel at speaking on large stages and selling not just the product, but the importance of the product to the larger technical community.

Your Developer Advocates are the folks who will connect easily with the developer community, selling them on the what and why and life-changing ease of your product, but the Evangelists will sell the leadership (VPs and C-suites) on the ...

This could be the person who handles all your events logistics, making sure everyone submits CFPs in time, that all the boxes are checked for various sponsorships, and that the swag inventory is kept up-to-date.

They could also handle all the overarching project details for a larger DevRel team. Considering how much DevRel tends to cross over into other departments (Marketing, Engineering, Product, and so on), having one point person who knows where all the moving pieces are is invaluable. This person can then be the point person at the regular status meetings for other departments, freeing up the rest of the team to get other work done instead.

Are you building tools for your customers? Product might be a good fit. Are you assisting with brand awareness through conferences and sponsorships? Marketing. Are you helping to triage issues that your customers are running into and solve the overarching problems that are causing the support queues to fill up? That usually falls under Customer Success. Are you working on a content strategy that highlights the work that your Engineering team is doing in a way that will both attract developers to your product and build up the personal brands of your engineers? This could fall under either Engineering or Marketing, depending on whose time you’re most dependent on. Are you trying to integrate with as many APIs as possible to get your product up on various websites throughout the industry? Partner or Business Development may be your best bet here.

it’s up to the Developer Relations team to not only have the community as their foremost focus at all times, but to infuse other departments with that mindset as well.

The head of the department understands the value of Developer Relations and is willing to fight for them. The team is made up of an awesome group of people who work well together and is able to seamlessly move between teams and roles.

Who are their favorite people to hang out with (virtually as well as in-person)? What books, articles, magazines, and Twitter feeds are they reading? Whom do they look up to? What are their favorite topics? What do they love and hate about their job? What’s the one thing that would make their professional life easier? What are their priorities?

This next audience could either be a slightly different market segment or it could focus on the buyer persona.

Figure out where your customers already hang out and meet them at their level rather than force them to find you in an obscure Google search or your latest press release.

Build relationships with developers across the industry and show them that your company is not only willing but excited to meet their needs, and they’ll take you (and your product) to the next five companies they start working at.

Don’t make the open source products subpar to your paid products. Offer support to them just like you would to your paying customers. And treat your open source community just like you would your paying customers—with respect and appreciation.

Sponsoring podcasts and events geared toward new developers can be beneficial as well. If nothing else, the relationships you’ll build with the organizers can pay off tenfold in additional connections.

You’ll want to be sure that both your company’s name and your personal brand are associated with concepts like inclusivity and diversity, as well as being welcoming and receptive to feedback.

you want to be empathetic to developers’ needs while also curating a community that is kind, helpful, and includes individuals who are committed to maintaining a welcoming and helpful environment.

This vision should be forward-thinking and progressive, pointing to where you want the community to be in five or ten years.

Your mission statement, on the other hand, should be a clear and straightforward statement that reflects your purpose as a team.

This is where a Code of Conduct comes in handy. This document clearly states what the company expects of these community members and what the consequences are for breaking this contract.

It’s now your responsibility to make sure everyone on the DevRel team (as well as others throughout the company who are interacting with the community on a regular basis) knows how to respond to Code of Conduct violations.

Keep this in mind both while writing your Code of Conduct—is the wording clear and straightforward? can you get it translated into other languages for non-English speakers?—as well as when enforcing it, because cultural misunderstandings can be common, particularly in online communities.

establishing a particular day and time where that is appropriate keeps the group from being overrun with information that may or may not be relevant to a majority of the group.

Rituals, or traditions, provide a good source of the community “stickyness” I’ve referred to previously.

Are you looking for a place for people to share what tools or projects they’re building using your service? Having a place on your website where you can highlight these projects is key.

Are you hoping to take a load off of your Customer Support team by providing a forum for your community to ask questions?

Are you wanting to build a place for community members to share ideas, ask for resources, and collaborate?

Are you needing a place to keep track of ongoing work and community feedback?

Are you trying to create a platform for asynchronous conversation that can be archived for the sake of future community members, where you can float decisions and garner feedback from the community?

as long as they’re within the guidelines of the Code of Conduct, don’t fight them. How they’re using it is obviously what’s most useful, helpful, and beneficial to them. Instead of struggling to make it be exactly what you want, why not work with them?

find your community where they are is key.

Nurturing this group of people organically is the best way to create what is popularly known in marketing terms as an influencer or ambassador program.

Community isn’t automatic. It takes work.

Once their questions are answered, why do they stick around to answer others? Make sure you’re syndicating content down to keep them involved.

What keeps them excited about your product and interested in what’s next on the product road map? Keep them engaged and moving up the pyramid as they become more and more interested in the next phases of your development.

What problems have you solved for them that inspire advoc...

Maintain: Make sure you’re encouraging your top community members.

Engage: Be sure to actively engage anyone and everyone in your pyramid.