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

Ok, so we've now established a [sadly common "organizational apathy" situation](https://webchick.tech/no-one-gives-a-bleep-about-your-devrelcommunity-programs-and-what-to-do-about-it) found in DevRel/Community work, and we've also talked about how to [lay solid foundations through organizational alignment](https://webchick.tech/no-one-gives-a-bleep-about-your-devrel-community-programs-and-what-to-do-about-it-1-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!

![Surprised pikachu : r/MemeRestoration](https://external-preview.redd.it/9AWn6JJOzBSl3XLfNHCtEtfjaw3iUPriDltGV10P5A4.jpg?auto=webp&s=19b8fe70cd041d6fc3e49fbee361c9b0c46c049f align="left")

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

***Objection!*** Not so fast!

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1708059541432/c55d8f9a-bd10-40e3-8bc9-5e5422e14979.webp align="center")

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 AllAboutMe | Project AllAboutUs |
| --- | --- | --- |
| **Content** | Focuses 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 Engagement** | *Transactional.* Only interacts with them when they want something from them. | *Authentic.* Takes the time to build lasting relationships where both parties gain something. |
|  |  |  |
| **Contributor Onboarding** | Sparse 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](https://webchick.tech/no-one-gives-a-bleep-about-your-devrel-community-programs-and-what-to-do-about-it-1-organizational-alignment) 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.
    
* <div data-node-type="callout">
    <div data-node-type="callout-emoji">💡</div>
    <div data-node-type="callout-text"><strong>Tip:</strong> You can save yourself a <em>bunch</em> of headaches by making your programs <strong>scalable from the start</strong> 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 <strong><em>easily repeatable</em>.</strong></div>
    </div>
    
* **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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1709525612132/cb950c24-e9cd-4678-abd7-54fa486873ea.png align="center")

| 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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1709526153154/9ba91f1a-0d5c-4ac1-af15-31056a27c2df.png align="center")

| 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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1709529979297/d53e4125-31d4-4713-a595-ba7059709a7f.png align="center")

| 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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1709526237090/80d4d0e8-5ac3-4d03-8091-9348ba218b0c.png align="center")

| 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.
    

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text">A non-intuitive advantage of having a cross-functional buddy system? <strong>Making more money. </strong>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 <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.cultureamp.com/blog/performance-review-calibrations" style="pointer-events: none">"calibration" process</a> 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. <strong>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 <em>especially</em> not "Ugh, THAT guy..."</strong></div>
</div>

# 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](https://webchick.tech/no-one-gives-a-bleep-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?
