When I transitioned into working with technical communities, I was pretty sure I was a weird outlier who was suddenly getting to explore my passion for developer culture. Then I noticed something funny; some of my peers followed the same track shortly after I did. Investment in developer tools has also been on the rise, so demand for this work looks like it’ll keep on flowing.
If it’s going to be a trend, I’d like to help newcomers serve the developer community better and be more successful in their own right. Here are a few things I wish someone had told me.
Developer community management isn’t new
What is somewhat new is early-stage venture backed companies concerning themselves with it. For a long time, this was the domain of enterprise software giants. Community management has been core to successfully run open source projects since open source emerged, and in OS, community decisions and engineering decisions are often been inextricably linked. Your developer-focused company might not be driven by open source specifically, but if you’re trying to facilitate any kind of collaboration, you’ll need to understand how open source works.
If you want to study some of the roots (and you do), go read about the Java Community Process, find out what Ubuntu’s community efforts entail, and get to know the backstory between Sun and Oracle. This may sound outlandishly academic and arcane, but I promise you this is imprinted on the developer community’s collective subconscious, and is affecting how technology gets made today. If you show up and behave as though there’s no history or cultural precedents, your efforts wont go as far.
The incentives are different
If you’ve been working with a non-technical community, you’ve likely been investing time and effort into helping your community members feel close to your brand. Developers don’t care about brands as abstract entities. It will matter whether you connect with your community in the mediums they’re most comfortable in. It will matter whether or not you try and hard sell them. If you’re a developer, everybody wants a piece of you, both from a positive standpoint of being able to set your price in the market, and from a negative standpoint in the commoditized and transactional ways people will approach you as a resource. The things that made your old community feel appreciated might not transfer. Developers want to build good systems and be recognized for their contributions. Prepare to understand and respect that.
It’s not a spectator sport
The only way to be a facilitator is to be a member. I don’t believe you can successfully work with the developer community if you’re not actually part of it. Building with code is the act of assembling individual actions into a process that can be repeated whenever desired. You should have at least some understanding of those components, of the technical facets of your specific ecosystem, and a few opinions on them. It’s far better to fail at hacking tiny things together than it is to not try at all. Prepare to show up to events, just be there, and get your hands dirty. It may be tempting to think that as a community manager you can just deal with the big broad picture. I believe that you need to understand the granular components in order to make your vision real.
Creating a space where people know and care about one another, and interaction is high is still the name of the game, whether or not you work with the developer community. Just get ready for the social mores to look and feel different.