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

by Mary Thengvall

Grow: Continue to grow the community. Engage with new potential community members whenever you can.

Even if you have a few folks who gravitate toward that position naturally, it takes encouragement and nurturing to keep them there—and wisdom to make sure that the group represents a good cross-section of your customer-base.

make sure that both paid and free or open source customers are represented.

Beyond diversifying the types of customers, you’ll also want to do what you can to diversify your community as a whole.

Developers are more likely to trust people to whom they can relate, so to expand your reach you need a team that includes people with diverse backgrounds: languages, backgrounds, countries of origin, ethnicities, genders; as well as different programming languages, preferred IDEs, and industry experience. Presenting a diverse team as the public face of your engineering efforts may even help inspire a greater diversity in the industry — a win for everyone — so it’s worth trying to create a team with even greater diversity than the company (and industry) that they represent.

The better relationships you can build with them—actual relationships—the more likely they’ll be to offer feedback, advocate for your product, and help out when the need arises.

Mozilla Tech Speakers was born as a result of that goal. “We established 3 principles that define the program:

Open participation: Working collaboratively and communicating openly in a decentralized environment, across time zones and cultures. There are definitely downsides to this model, but as long as they are managed properly, the upsides are huge: we extend our workforce, and volunteers extend their skills, access, and experience. Everyone benefits!

Psychological safety: People thrive on teams where they are treated well. We’ve built a cohort of individuals that help each other. The Tech Speakers have created their own network effect: helping each other find job opportunities, connect...

Minimum viable program design: Flexibility, feedback, and constant tuning. We set up the first cohort with the intention of being flexible, responding to feedback, and iterating with each cohort. This allows us to meet the needs of the specific in...

start by introducing yourself,

Amplify the work they’re doing that relates back to your overall community.

help out when they get stuck on a particular bit of code or need some wordsmithing help on an upcoming blog post.

they are your p...

how do you handle a Code of Conduct violation when the Community Manager or Head of Community is off the grid? Is anyone else on your team prepared to handle an antagonistic community member who may or may not have a valid complaint or issue?

Keep in mind that these amplifications shouldn’t be external only—you should be highlighting these accomplishments internally as well. Stakeholders throughout the company will see that the relationships you are building are valuable, and that money is being spent wisely.

This is also why you need to have an understanding throughout the company that the DevRel team, and only the DevRel team, makes these requests of the community advocates.

As the community expert, you know the best person to write that article, work on that project, or help out at that event.

Your community advocates have gotten accustomed to a particular system of work and compensation. If another department steps in and offers something different, the community advocate now knows there are other options available that can undermine the relationship you’ve been building with them.

Like most things, figuring out the right approach for events goes back to your key goals: Are you trying to increase your general brand awareness? Do you need feedback on the usability of your product? Is the company looking to expand into another geographical region or new audience segment?

Brand awareness is the most straightforward outcome from speaking at or sponsoring an event.

metrics around brand awareness are incredibly hard to track.

Brand awareness can come in a variety of events. Speaking, sponsoring, helping to organize, or hosting an event at your headquarters are all ways of getting your company name out there, and not all of them cost a lot of money or time.

figure out the best time-to-value proposition, or observe how developers are using your product, events are great places to get hands-on feedback from your potential customers.

If you’re an API platform, the best place to get this hands-on feedback is at hackathons.

hackathons aren’t right for everyone.

There are three keys to engagement at a student hackathon:

Have an interesting or engaging challenge for the attendees to complete. Most hackathons have sponsored prizes in addition to the grand prize categories. This could be a monetary prize, gift cards, some sort of fun technology (such as drones, robots, or LEGO sets) or something else entirely.

Don’t spend all of your time at the booth. Walk around the event and observe attendees . Ask about the project they’re working on (even if they’re not using your API). Chances are, there’s a mentoring opportunity or a hack you can show them to make a particular process easier.

Have great swag that will get picked up and used. Think practical—branded pads of graph paper and pens for brainstorming sessions—as well as your standard swag such as stickers, pins, t-shirts, and so on. The more you can tailor your swag to hackathons, the more popular it will be.

Bring one of your coworkers from the product team along—having them onsite to hear what people think about your messaging and the use cases that they can think of off-the-cuff can inform the next iteration of your product road map.

listening to the community, engaging in conversation, and making introductions—can be an incredibly valuable use of your time.

spend time at the booth meeting community members but also float between sessions and the hallway track.

use your platform to amplify the company’s announcements.

It is always okay to back out of a speaking engagement or sponsorship. Conference organizers not only understand, but also often have a waiting list of speakers lined up precisely for this reason.

I firmly believe that anything more than 50% travel is too much. As community advocates and DevRel professionals, we’re expected to be connecting with our community on a regular basis, but we’re also expected to communicate that information back to our colleagues and contribute helpful content.

Again, although starting a meetup for your product can seem like a great way to build a presence in the greater developer community, I’d caution against it for a few reasons:6 A meetup hosted by a company about its (usually proprietary) product is easily called out by developers as a sales tactic. Finding speakers for a monthly meetup whose theme is your proprietary product (unless you’re a fully open source company) can be difficult. It can also drain not only company resources but any goodwill you’ve built up with the community. Even if you do have an open source product, limiting your meetup to customers and prospects limits your audience and keeps people from learning from others outside their immediate purview, which is often what people come to meetups to do. If there are already-established meetups talking about similar topics and bringing in a similar group of people to the one you’re trying to start, you’re actively detracting from the organic community efforts already happening in your audience segment.

Creating a backlog of speakers can be the most stressful part of organizing a meetup. Keep in mind that having one quality speaker per meetup is a perfectly acceptable standard to have.

Be sure that you encourage diversity in your speakers as well as in their topics. Meetups will often skew toward more intermediate to advanced topics, which is a logical progression,

“Lastly, diversity matters—not just in gender and background , but also in level of programming. You don’t want to only have experts talking about advanced topics.

trainings and blog posts on writing a good CFP9

Even if you’ve spoken at dozens or perhaps hundreds of conferences, some of the attendees may have come to this conference to hear you specifically, which means your offhand comment about how you just finished your slides five minutes ago can be seen as inconsiderate.

true burnout2 is a state of chronic stress and frustration at work that leads to physical and emotional exhaustion, feelings of cynicism and detachment, and a sense of ineffectiveness and lack of accomplishment. The problem with constant stress is that it impacts your perception of yourself as well as others. Burnout can also often increase the risk of depression or exacerbate depressive tendencies.

Most of us start out excited, passionate, and invested in this new career, but the limited resources available combined with the hardships I’ve covered elsewhere in the book can start to rob us of that excitement and energy.

“What burns people out is not doing hard work, but rather feeling like their work doesn’t matter.”5

The number one way to prevent burnout is having clear and open communication from both management and team members.

If you’re a manager, you have the additional responsibility of not only taking care of yourself, but your team as well.

Is there too much on their plate? Are they in over their heads with their current tasks? Are there things they’d like to be working on to further their careers? What projects would they like to be involved in going forward? How do they feel about the current team structure? How do they feel about the company culture?

Even when you aren’t in crisis mode, retrospectives can encourage a culture of open communication and alignment.

By advocating that your team take time off as necessary and actively encouraging them to do so when they haven’t recently, it becomes clear to them that you prioritize their health over the day-to-day work.