Dev Relevancy & Building Bridges

Dev Relevancy & Building Bridges

As a leader, it’s *your* job to keep Dev Relations relevant at your company.

Featured on Hashnode

Prompt: Effective DevRel teams are able to facilitate cross-company collaboration. What are the models and lessons learned for building cross team success?

Monthly Developer Digest

When "keeping the lights on" is in fact earning your keep

For developer relations teams, there’s often a reluctance to take on recurring tasks, especially ones that start to fall into the realm of content / marketing. From my experience, Monthly newsletters aka “Developer Digests” are the exception - when done well it becomes the drum beat for developer monthly updates. The tone of the digest should be that of developers talking to fellow developers, where any scent of marketing/gloss/“fluff” should be turned down significantly and the updates should be both actionable and useful.

Over time, the product teams building for developers will learn that the dev digest is the source of truth for monthly developer-facing updates — just make sure all the stakeholders know how to add content easily to the queue for review. In addition, make sure the digest sign up form is across the docs and other public facing surfaces (dashboard / api settings /etc).

Voluntary demos & previews

Brown bag lunches, all hands, and show & tell opportunities


When these moments arise, have your team take advantage of internal demo calendar events. It’s a great way to flex in the spirit of “show, don’t tell” and reminds adjacent teams what Advocates do best. It also helps senior leaders get a sense of how DevRel fits within the context of the organization.

Internal roadshows

AKA those “What do we actual do here” presentations


Just accept the fact that that most adjacent teams won’t understand what Dev Relations is or why it matters. There’s freedom and benefit in reminding your team that Developer Relations is only effective when it’s a tool to accelerate a companies top-line goals. Stay focused on what matters.

Practically, this means having a presentation deck always ready to explain the program, who the team members are, how you measure success, and what’s upcoming for projects. Accept any offers to present at other all hands teams and 1:1 with peers that should / could be working with Dev Relations more. Also make sure to write up a “How to work with Dev Relations” guide, so that the product, sales, and eng stakeholders understand when/how/where to engage with the team and what the timetables are.

Shared projects with Product teams


Dev Relations teams should be scouring the launch calendar for ways to add value and support the broader mission.

For example, if a product / marketing team is working on an upcoming launch, offer up yourself and an Advocate to help form the “developer GTM”, where we figure out what developer-facing content and call to actions should be available on Day 1. With enough time and planning, it makes launches so much more effective than just announcing something for developers without tangible features/samples/videos to explore.

Wrap up

Stay in the mix with the mission, goals, wants, and needs of the overall platform. Dev Relations teams are an accelerant and you need to be “in the trenches” to support your peer organizations for shared goals. Keep this as a North Star and get comfortable with changing priorities and responsibilities.