If you've been paying attention to conversations around DevRel on Twitter this week, you'll know that there have been a lot of negative tweet threads and hard-to-swallow "hot takes." I've been reminded multiple times of what it was like over a decade ago when I was at O'Reilly Media, still trying to figure out what this whole "Community Manager" title meant for me. I switched from handling book publicity to building communities right around the time that social media networks were exploding (Facebook tabs, anyone?) and pretty shortly thereafter, I was getting the classic "oh, you're a Community Manager? Can I talk to someone who actually knows what they're talking about? You simply handle the social media accounts." at technical conferences.
To say it stung is an understatement. I knew that more often than not, I could answer their technical questions. I also knew that on the off chance I couldn't, I knew exactly who to ask within the community. I started testing out different titles at conferences, rarely putting my actual title on my badge, and saving my business cards until after a mutual respect had been established in the conversation.
It's hard to realize that despite being one of the most visible roles in the tech industry these days, people largely have no idea what we do or the value that we provide. That struggle isn't helped by the fact that companies around the world are co-opting the term "Developer Relations" for their own purposes, including Sales Engineering and Demand Gen Marketing teams.
But I'm also realizing that we can't get our backs up. It doesn't do anyone any good if we're approaching this from a defensive standpoint, coming across as judgemental of other departments ("We're better than
x " or "At least we don't do
y ") or silo'ing ourselves as "special" or "different." Are we different? Sure! But if we're saying that the top priority for DevRel is to provide value for our various technical communities, are we doing that when we attack our colleagues?
Why not live out that goal instead, helping to shape people's understanding of DevRel so that they too can distinguish between pure Developer Relations and that which might have been co-opted as the latest buzzword by an overly ambitious company that doesn't quite understand the true purpose?
Let's take the high road. Ask for clarification. Explain our intent. Assume the best of others. And continue to spread the good word about (dare I say, evangelize? 😜) Developer Relations.
The Essence of DevRel
Out of all of the negativity and controversy on Twitter in the last week came a few brilliant tweets about the essence of DevRel that I thought I'd share with you.
p.s. I'm always looking for good explanations of DevRel to include in the resources on my website as well as over at devrelcollective.fun -- if you know of some, send them my way!
I'm not a dev rel, never have been, but all the good dev rel's I know spend lots of time with customers, seeing where their pain is, and then preach to have that solved within the company.
Their talent is in communication - not just communicating to customers/users how to use a companies products, that's only half their job, they also communicate to the companies engineers on what needs to be prioritised. Their talents would be wasted working on the products.
Some people are good at building products, some are good at building community. There should be crossover, sure, but I've met amazing engineers who would be terrible at devrel and vice versa. Developer relations is a specialisation in its own right.
🤔 Developer Relations involves a lot more than writing code.
DevRel is: - building relationships and fostering trust
- collecting and relaying feedback to other teams
- helping people work through challenges
- inspiring people to build
- building tools to empower