Broaden your Community and Developer Relations reach through collaboration

Cover image by civilservicelocal from Pixabay

Community is hard. It just is. There. I said it. That's the blog post.

Seriously though, building developer communities is hard work. It's long hours of looking at stats, metrics, and worrying about if what you're building is sustainable or, heck, interesting enough. It's putting yourself out there in every interaction, from social media to blog posts to community threads and answers to meetup and conference talks. It's playing the long game of community growth and member lifecycle, which can take years off of your mental stability. (You should have known me before I started doing developer community work!)

And I love it. All of it. Well, maybe not all of it. But it's what I love doing for my job.

With all of the hard work that building communities is, why would you ever make it that much harder on yourself by building your community in a bubble? Why position yourself on an island, staring at Wilson?

Building developer communities requires you to function much like the very developers you're building your community for. Developers exist in interconnected communities due to the particular software or technology they might develop with/for, their hobbies, etc. These might be everything from TypeScript to Open Source to Salesforce Trailblazers. Because of that, it makes sense to grow a community, especially when starting from scratch, by collaborating with others.

This collaboration starts by first taking stock of the developers in your community and the tech they're using, along with the core tech your company might be using to deliver your product or service, etc. Take the following as an example.

You have a product which developers use to make their job easier. Let's say that the developers using your product have to install it somewhere, whether it's in the cloud, on-premise, etc. One such product happens to have a very active community of open source contributors who the company behind the product gets together yearly for a community conference. At this conference are developers who work at the same companies that you are targeting for adoption of your product. This is a prime opportunity to make the worlds collide, for lack of a better term.

There are a number of ways that you can get involved in these other communities:

• Meetups where you both sponsor and speak on something where both tech is used together
• Speaking at their community conferences, and vice versa
• Write shared content (blog posts, samples, tutorials, etc.)
• Much, much more.

Doing these things obviously raises awareness of your brand, but it also:

• Shows those in both communities how your tech is not on an island, and works with many different things they might already have in play in their specific environment(s)
• Can open doors that previously were not available, thus boosting your community value
• Sharpens your skills in building collaborative materials

If these aren't happening, by omission or lack of support from upper management, you're severely limiting the reach of your community, and you run the very real risk of your community becoming one-dimensional. Once that happens, it will eventually become stale & ROI will be questioned often. And I will say this: if your attempts to raise collaboration in your approach and fulfill your mandate through multiple means, are met with resistance or outright blockage, it's probably time to find a new job. It's my experience that those situations rarely correct themselves, and you will not reach your true potential in Community or Developer Relations.