No one gives a &*^@# about your DevRel/Community Programs (and what to do about it) #2: Collaboration

Photo by Mayur Gala on Unsplash

No one gives a &*^@# about your DevRel/Community Programs (and what to do about it) #2: Collaboration

Putting the "Relations" in Developer Relations


8 min read

Ok, so we've now established a sadly common "organizational apathy" situation found in DevRel/Community work, and we've also talked about how to lay solid foundations through organizational alignment as a first step. What's next?

Whew! I now have org-aligned goals that my manager agrees with! Yay! So NOW other people will listen to me when I ask for help, right?!


Here's the thing.

Those co-workers you're trying to engage with? They have ALSO done that same organizational alignment exercise.

But... instead of aligning with your boss and your chunk of org chart, they're aligned with their boss and their chunk of org chart!

Surprised pikachu : r/MemeRestoration

Argh, WTF! Well, this is completely hopeless, then! What a waste of time. :-(

Objection! Not so fast!

At its core, cracking this problem is "just" a matter of Community Building. And you're already freaking awesome at Community Building! :D

Allow me to explain.

A Tale Of Two Open Source Projects

Let's imagine there are two open source projects: Project AllAboutMe and Project AllAboutUs. While they may be similar in functionality, how they treat their (largely volunteer) contributors could not be further apart:

Project AllAboutMeProject AllAboutUs
ContentFocuses mainly on their own features and benefits, what makes them so great, and why their competition sucks.Focuses on really understanding their audience and their needs, talks about benefits through their perspective, orients content around how to solve their pain points.
Community EngagementTransactional. Only interacts with them when they want something from them.Authentic. Takes the time to build lasting relationships where both parties gain something.
Contributor OnboardingSparse docs, plentiful use of jargon, assumptions of knowledge, "RTFM n00b"Excellent docs, friendly mentors, "buddy" system to get started, ways to influence direction

๐Ÿ‘€ Pop quiz time: Which of these projects are you more likely to spend your limited, valuable time on? ๐Ÿ‘€

Most would answer "AllAboutUs" without hesitation. And yet. Many enter into conversations with prospective collaborators with an extremely "AllAboutMe" approach. :-\

Building Cross-Functional Empathy: Taking an "AllAboutUs" Approach

So, if you re-frame what you're doing in your role as building a community of contributors, and those you need help from outside of your immediate team as volunteers (it doesn't matter that they're actually employed, and at your same organization), then you'll start to make some very different choices about how you approach collaboration:

  • Engage with your contributors before asking them to do something for you (and on an ongoing basis). Rather than firing off a Slack message asking for something, see if you can set up a quick introductory call with prospective contributors where you can both put faces to names and learn more about one another. Apply the alignment principles from last time: look for the Venn diagram between what you need and what problems are stressing them out.

  • Make it as dead-ass simple as possible for others to help you. Make sure your "Getting Started" documentation is excellent. Operationalize everything: Templates. Playbooks. Automations. Put a recurring onboarding session on the calendar, hold office hours on a cadence so they have a way to talk to you. Your contributors have their own problems; if you're asking them to spend time on yours instead, do everything you can to make it as quick and easy on them as possible.

  • ๐Ÿ’ก
    Tip: You can save yourself a bunch of headaches by making your programs scalable from the start vs. trying to retro-fit scalability onto them later. Much in the same way as programming, actually: if you find yourself writing the same bit of code multiple times, you encapsulate it into a function/method. Similarly, if you find yourself repeating the same process or sending the same type of email or things of that nature more than about twice, figure out a way to make it easily repeatable.
  • Figure out some initial "quick win" collaborations to build momentum. To pick just one of many possible examples: They're trying to generate leads for a big event in $City? Host a user group meetup in $City a few weeks before, and end it with a slide that lets people know about the event. (And include a fancy-dancy QR code that attributes any registrations to your team, which we'll talk about in the later "data" episode. ;-))

  • Make it fun! :D Help your volunteers feel awesome by promoting the work they're doing in a highly visible way. Give 'em a shout-out in whatever place is most appropriate: company Slack channel, HR "kudos" system, a public post on your community forum, etc.

Cheat-Sheet: Your Cross-Functional "Buddy System"

While there's no substitute for actually doing the work of seeking out individuals in your org to partner with and building those relationships, here are a few "short-hand" personas to help get you started.

๐Ÿ‘€ It's recommended that your "cross-functional buddy system" have at least these personas, but don't shy away from expanding out further: Engineering, UX/UI Design, Legal/Compliance, Infosec, People, you name it! ๐Ÿ‘€

Sales Sam

What's their goal?What are their pain points?What are some "snack sized" collaborations?
To "secure the bag" by closing deals and generating revenue (ultimately paying yours and everyone else's salary :))Addressing technical queries and objections from prospects; having a way in to reach out to prospects that are stalled.Join sales calls to address technical questions, turn technical FAQs into content, do enablement sessions to train sales teams on product technicalities.

Marketing Madison

What's their goal?What are their pain points?What are some "snack sized" collaborations?
To increase product awareness, and generate leads for Sales Sam.Creating technically accurate and appealing content.Assist in creating (or reviewing) technical marketing content, participate in social media Q&A sessions or webinars, co-create developer-focused marketing campaigns using your knowledge from speaking with developers in your community.

Product Pat

What's their goal?What are their pain points?What are some "snack sized" collaborations?
To develop products that meet market needs and exceed customer expectations.Gathering actionable feedback from users and translating technical capabilities into marketable features.Facilitate user feedback sessions, provide insights from developer communities, co-host webinars on product features.

Support Shannon

What's their goal?What are their pain points?What are some "snack sized" collaborations?
To resolve customer issues quickly and efficiently.Burning time answering the same question over and over; Dealing with complex technical issues that require deep product knowledge.Develop technical content to address common customer issues before they happen, participate in support escalation path for complex issues.

Advantages of "Cross-Functional Empathy"

If you start building these cross-functional relationships and collaborations, this will have many upsides all-around, including:

  • Increased profile and visibility on your work: You'll stand out among your peersโ€”some of whom seem to think Sales and Marketing have cooties ๐Ÿ™„โ€”and grow the impact of the work you're doing, with more people pushing for your success.

  • Improved credibility in your organization's developer-oriented content: No one likes working for a company that sends out cringe-worthy messaging to developers. So help them write it right, the first time.

  • People from outside of DevRel can speak to what the *&@# your DevRel team does: This is important given if you asked 12 different DevRel/Community professionals what their job is, you'd get 15 different answers. ;)

  • The content you create will be more powerful, as it's based in "real world" problems developers actually have. That leads to driving more page visits and signups for your written content, and it also leads to more CFP acceptances for your talks.

A non-intuitive advantage of having a cross-functional buddy system? Making more money. No seriously, "real talk" for a quick sec. If you're in an organization of a certain size, there's probably going to be some sort of "calibration" process when it comes to levels and salary increases. The exact process varies from place to place (sometimes more like "polite, measured discussion," sometimes more like "thunderdome bloodbath" ๐Ÿคฃ), but essentially it involves all of the managers coming together armed with performance data, advocating for the best members of their team, and the org leaders ensuring things are kept equitable. You want the general reaction when your name comes up in this meeting to be "No shit, Sherlock!" and not "Who is that again?" and especially not "Ugh, THAT guy..."

But... but... I'm shy! How do I get started?

This all sounds well and good, but how to find these prospective partners?

  • Ask your boss for recommendations

  • Check the departmental Slack channels to see who's most active

  • Check your company's website to see who's writing content around that area of the business

  • Participate in Employee Resource Groups (ERGs) to find folks from other departments who share something about your identity

  • Look in "social" channels to find folks from across the company who share a common interest

Reach out politely, tell them a little about your background (don't assume they'll necessarily have knowledge of what you or your team does), ask if they'd be open to a quick ~15-30 min chat.

Before you talk, spend a few minutes reading their departmental wiki pages, goals, QBRs if they have them available... so that you're somewhat knowledgeable going in. Through the conversation, give them a chance to talk about their day-to-day. Find out about their goals, motivations, and pain points before you jump in with your own. Figure out possible collaborations they're open to. "Align" it with your own list of needs and... profit! ;)

In our next episode, we'll talk about using best practices from product management to help with prioritization, to help ensure you're not just keeping super busy collaborating all over the place, but are instead focusing on the highest-impact things. Read more in No one gives a &*^@# about your DevRel/Community Programs (and what to do about it) #3: Prioritization.

In the meantime, I'd love to know: what are your tips for building relationships and collaborating cross-functionally?