As CEO of Orbit, I get to speak with tons of DevRel and community members about the industry. I learn their challenges and—in particular—their opportunities. Over the past few months, I’ve noticed a set of questions emerge across my conversations...
The questions can be summarized like this: how can DevRel and community teams ensure their work is driving impact and collaboration across the whole company?
This bucket of questions includes:
If you’re dealing with these questions, you’re not alone. According to the 2022 State of Developer Relations report, “Aligning with company stakeholders” is a top-5 priority of DevRel teams.
We spoke with more than a dozen leaders of DevRel and community to understand their processes and tactics for ensuring effective information flows from their teams to the rest of the company, and vice versa.
In my discussions, I discovered several tactics that help the voice of the community remain top-of-mind for other teams. Some are passive while others are active. Some rely on organizational structure, while others work within existing frameworks.
And hopefully, some will be useful for you and your team.
Below we’ll look at 10 different tactics, grouped into two categories. First we’ll look at structural tactics that deal with organizational design and planning. Then we’ll dig into the cadence of communication within that structure.
The tactics in this section focus on organizational design choices that help ensure the community team can have the kind of impact it wants.
It turns out the best leaders start working on collaboration well before new team members join, primarily as part of the interview process. Peggy Rayzis, Sr. Director, Developer Experience at Apollo GraphQL:
We include key stakeholders on our interview panels + explicitly mention collaboration as one of the competencies we care about for all our roles. Dev Advocate candidates who speak negatively about Marketing or talk down to our Marketing partners during their interviews are automatically rejected.
Of course, mutual respect is essential for building trust and teamwork across teams, so configuring the interview process in this way filters out the folks who are obviously going to make collaboration harder later.
Once hired, Peggy takes the extra step of ensuring new hires have full context of how to work with the community:
I have onboarding meetings with every new AE + pre-sales engineer to teach them about our community values + how to use Orbit.
We have a developer advocate sit on every engineering "pod" that has a content launch — they join meetings, particularly when projects are initially being scoped; this guarantees that we have a DRI focused on storytelling. When a feature is launched, we also reach out directly to our community (whomever upvoted or emailed regarding a GitHub issue) so we can scope a follow-up release i.e. v2, v3.
Chris Traganos suggests a similar approach focused on upcoming product releases:
If a product/marketing team is preparing for a launch, offer up an Advocate to help form the “developer GTM”, where you figure out what developer-facing content and calls-to-action will 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, or videos to explore.
On the other hand, the team at Apollo is trying something more long-term, with developer advocates embedded more permanently, namely, “embedding developer advocates in the engineering team that aligns with their focus area.”
Samson Goddy, currently OSS Advocate at Chainguard and previously Director of Community Relations (DevRel) at Sourcegraph, mentioned the importance of having the community or DevRel embedded in the leadership team.
Driving collaboration is a lot easier when the community team is present when key initiatives and projects are being discussed. It means I can bring the community POV to the conversation, determine if and how my team should be involved, and immediately direct the people and resources toward the project if needed.
Peggy at Apollo shared that there’s perhaps no better way to ensure alignment and collaboration than to actually share goals with other teams.
The Developer Experience team shares SEO goals with Marketing Ops, Summit goals with Events, OSS downloads with Engineering, and activation goals with Product. In fact, we’re just about to wrap up a 3-month cross-team project with Product and Engineering that we're unveiling at Summit in a few weeks!
This level of collaboration certainly requires a lot of conversations and full trust, but also means DevRel and community impact is clearly visible among other leaders around the organization.
With the right structural elements in place, we learned that the best teams have designed processes that enable consistent information sharing in both directions between the community and the company.
While many of the tactics shared here are asynchronous or structural, sometimes collaboration just comes down to getting people into the same room. Here are the more common meeting genres folks told me about:
Apollo hosts biweekly meetings between DevRel and Product. Their education team also meets with Solutions and Support once per month, and the video team meets with Marketing/Design biweekly.
CircleCI conducts weekly DevRel + Marketing standups, as well as quarterly reviews that get shared with the Marketing team.
In addition to operational alignment meetings, some teams set aside time specifically for executive discussion and buy-in. To wit, Emily at Cypress holds monthly check-ins with their CEO to get input on ideas and feedback on community programs.
“We often say the community can drive a huge feedback loop back to the product team, but in reality, it can be really hard to pull this off,” says Jeremy Meiss, Director, DevRel & Community at CircleCI. The trouble comes when folks in community or DevRel tell PMs something like, “The community thinks X,” or “We’ve been hearing Y from developers.” This kind of input might be informed by reality, but it’s often too general to change minds. And in the worst cases, it can get written off as not data-driven and potentially biased.
Instead, Jeremy recommends working with PMs and product marketing to define specific areas of feedback they’re interested in:
For example, we’re going to KubeCon soon, so we’ll go to the teams and say, “What are the 3 products or areas you want feedback on, and what kind of feedback are you interested in?” Then, when working the booths and having conversations, these items will be top-of-mind for my team and we can collect actionable feedback from the attendees.
Then, his team shares that feedback with the relevant internal folks, and includes their name, title, company, and when possible, a picture. Jeremy says, “Product should hear from specific humans, and we’re the ones who can provide those stories.”
In other words, specificity breeds credibility.
If you use Orbit, you might consider adding product feedback as a note on a member profile and adding a tag to the member, like “provided feedback,” which will make all that great input easy to find later.
This was another major theme from my conversations. Basically, elite DevRel and community members invest in internal storytelling to get ideas and information to the right people.
Chris Traganos suggests internal events and roadshows to share the knowledge:
Internal demos, brown bag lunches, and show & tell are a great way to flex, and in the spirit of “show, don’t tell”, it reminds adjacent teams what Advocates do best. You should also have a deck always ready to explain the program, who the folks on your team are, how you measure success, and what’s upcoming.
Also make sure to write up a “How to work with Dev Relations”, so that product/sales/eng stakeholders can look up when/how/where to engage with the team and what the timetables are.
Jeremy from CircleCI will often get time during standing meetings held by other teams to share what his team’s been up to, and to make sure those teams are aware of what his team can offer. He’ll often ask, “What is an objective you have that supports your department and company goals” and then explores ways he and his team can help drive impact. It could be sourcing demos, finding partners, helping with content and events, and more.
These initial conversations lead to collaborations, which form the foundation for working together down the road and provide a meaningful reason to keep working with those teams.
The specific items are quite different from meetings that are “just to check in,” which are meetings that should be avoided.
In addition to sharing details on what the team does and how it works, it’s great to share wins as well, as they can help build momentum and excitement around DevRel and community efforts.
Apollo shares wins in check-in and #praise slack channels, and Cypress has the team create video updates from teams attending conferences and other events.
A ton of great new SaaS apps launch every year, and DevRel and community folks tend to be among the early adopters. That’s great, until community information ends up siloed away from other key business data, and as a result, invisible to other stakeholders.
Sidenote: this is why we built the Orbit Slack app to pull Orbit data into internal Slack workspaces, as well as connectors for common CRMs like Hubspot and Salesforce, along with an API and a Zapier app.
We track campaigns and tasks using Linear.app, which the whole company uses, so everyone is in the loop with what is going on at any given point. I make it a point to just reach out to any concerned team when I need something, so I’m not leaving the ball in their court. They have a lot to do as it is, if I need something, I’ll ask for it.
In this approach, Tim puts data about his team’s efforts right inside Linear, where the whole company has visibility, then couples this with a proactive approach to keep things moving. Emily at Cypress follows a similar process by creating Confluence pages for key community information.
For most B2B companies, the community can represent a powerful source of product awareness, adoption, and sales. And it’s increasingly common for sales teams to collaborate with their peers on the community team to produce better outcomes and to offer a better experience to the prospects in the community.
Samson Goddy shared that at Sourcegraph:
I worked with AEs to provide context on the people they’re reaching out to or considering reaching out to. Sharing who each person is to the company and in our community, and helping identify when a person was ready to hear from us. Orbit was a big help there.
Using this kind of contextual data, reps can ensure that their outreach takes into account the full picture of a person’s relationship with the company and community, leading to better response rates and, we hope, fewer spammy emails.
But the feedback can flow the other direction as well — from sales back to community. Samson again:
I would go to the sales team and have discussions like, “What are new and interesting use cases you’re seeing in the field? or “What is the biggest blocker to adopting our tools?” For example, they might hear a lot of potential customers are having trouble understanding why code search matters to their company. So in that case, my team would create content to help educate potential users on all the benefits. Sometimes, we might spin-up a whole program based on this input.
Much of what we’ve discussed here so far involves team-to-team communication, as well as the advocates pushing information back to other teams internally. But we also learned that a regular cadence of external communication can help orchestrate and prioritize work across teams internally, while keeping the community at the center of key external communications flows.
For example, Chris Traganos suggests a regular developer digest that goes out to developer customers with key updates on features, docs, and anything else the audience will find useful:
It’s easy to overlook this, but it becomes the drumbeat of monthly updates. Over time, the product team building for developers will learn that the dev digest is the source of truth for sharing monthly developer-facing updates. If you’re going to do this, just make sure all the stakeholders know how to add content easily to the queue for review, and make sure the signup form is easy to find across the docs and other public-facing surfaces (dashboard / API settings / etc).
Not only does this digest become an important source of information for the community, it also positions the community as the central hub in ongoing public-facing communication. That’s a great way to build credibility and demonstrate impact.
The Cypress team uses initiative-centric channels in their community Slack to gather ambassador and general community feedback on new releases. This couples with monthly or quarterly blog posts about community initiatives, goals, and actions, which naturally include ways to partner with the community to deepen the partnership.
Most community and DevRel teams I know are fully focused on building and growing their community, but communicating the impact of our efforts and collaborating with other teams is essential to the success of the community as well as the company.