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?!

Welllllll...

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!

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:

👀 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

Marketing Madison

Product Pat

Support Shannon

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.

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?