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

by Mary Thengvall

Part of what sets Developer Relations apart is the fact that they can overlap with so many departments, and that teamwork is part of what makes your team so valuable.

Tim Urban’s Yearning Hierarchy9 prioritization model comes in handy here. He uses a bookshelf as an analogy for prioritizing projects: The Nonnegotiable Bowl: This bowl sits on top of the bookshelf, protected and guarded, but also front-of-mind and visually prominent. Top Shelf: Which ones are the top priorities that I’m choosing to pursue at 110%? Middle Shelf: What projects are important to avoid completely failing at? Bottom Shelf: These are the projects that it’d be nice to work on, but only if there’s time. Trash Can: What is easy to fall into but should be resisted at all costs?

The typical Developer Relations professional is expected to be “on”—interacting with attendees at conferences or community members online—fairly often, and sometimes at back-to-back events. Putting our own oxygen mask on first is essential, whether that means setting aside time just for yourself, saying no to personal or professional obligations, or ordering room service in your pajamas after a long conference day. Otherwise, you’re going to be short-selling your community and, more importantly, lining yourself up for burnout. Learn to Take a Step Back

As community professionals, we get used to being online at all times, solving problems for our community, or up late at conferences, networking and connecting people at events. But it’s not healthy to do this on a regular basis.

The Developer Relations team often has a unique skill set that can benefit many different departments, as covered in Chapter 5, but we’re not responsible for fixing issues for all the other departments, no matter how helpful we’d like to be.

“four-hour decompress” a few years ago, borne out of a personal business retreat that he took. He made a commitment to fight off burnout by engaging in this four-hour decompress every week, using it as a time to reflect, evaluate, and recenter his goals and ideas before tackling another work week.

one of the most valuable aspects of Developer Relations is the ability to listen, observe, and identify trends within the community. It’s not our job to know all the answers, but to amplify the questions and get the conversation started—then sit back and take note of what happens next.

There’s an important balance here, because DevRel requires you to know a fair amount of information about a lot of different topics. In the realm of T-shaped skills17 DevRel teams are often far stronger on the horizontal bar (collaboration with other areas) than they are on the vertical (depth in any one skill). In other words, you have a broad frame of reference that expands into many different topics and departments, but you don’t spend enough time in any one topic area to grow into a specific vertical.

Some DevRel professionals get hired because of their “rock star” status in a particular developer community. Though that position is a valuable one to hold, you need to be careful to protect your network from coworkers who see you as an easy way to get access to that group of people, while simultaneously making sure you’re still fulfilling your role at the company to be the cruise director and connect members of the community with your colleagues.

The exact information you should include will depend on the goals of your company, but here are a few items that should translate well across all industries: Types of people in attendance Geographic demographics Types of developers (front end/back end, specific language preferences, and so on) Job titles (managers, individual contributors, C-suite or VPs) Sponsor interactions (did people spend a good amount of time in the expo hall?) Caliber of talks (sessions as well as keynotes) Overarching themes from the sessions or hallway track General impression of the conference