What Developer Relations Is and How to Do It
I've worked with Developer Relations for many years now, and I think it's a fascinating topic with many takes on what it is and how to do it! I wanted to sha...
Join the DZone community and get the full member experience.Join For Free
I've worked with Developer Relations for many years now, and I think it's a fascinating topic with many takes on what it is and how to do it! I wanted to share my view on it here, and what I think it encompasses.
Last year I gave a presentation called "Have you tried listening?" at the DevRel Summit which I think outlines a number of the main DevRel concepts and areas, and examples from my personal experiences with them.
The idea is to go through them here, and hopefully, they will inspire, help, and make you think more about ways of doing it.
- Developer Relations personas
- Dev Rel activities
- Measuring your work
- Feedback and interacting with people
And in essence, if there's one thing I wish you will take away from this, it's this:
DevRel is people business!
Developer Relations Personas
There are a number of personas I've seen working with Developer Relations throughout the years:
- Super technical
- Hacker developer
- People relations expert
The super technical ones love the technology part of it: they're really passionate about it and it's their main drive. They want to solve problems in a good structured qualitative manner, suggest the best ways of doing it — sometimes opinionated, sometimes more broad — and constantly push the platform they work on to the limits of what it can do.
The hacker developer type is similar to the super technical one, but in my experience, more solution-driven — whatever it takes — than necessarily the format of the solution.
The teachers find their motivation in being able to inspire and help people work with the platform, help them over hurdles and jumping through hoops, to succeed in what they are trying to do. Their main drive is more about the messaging and making sure people understand it and will grow from it.
The final one is focused on people relations: this persona is usually closer to the teacher one than the others, in that they love to connect people, enable them through networking and connecting them with the right people and being responsive and making sure people are happy about what they do and don't get stuck.
Of course, most people working with Developer Relations don't just match one of these personas, and they aren't mutually exclusive, but I would say that most people I've met in DevRel are strongest in one of these four areas.
In terms of titles, the most common ones seem to be Technical Evangelist and Developer Advocate. I guess the intention of Evangelist would be that you bring out the word of the company, whereas Advocate is that you are supposed to be advocating the needs from external developers to help make your product(s) better for them to build on top of. As for the Evangelist title, I see it less now, probably partly due to the religious connotation (no matter if you are religious or not, best not to confuse them) and that it implies more of a one-way communication than the desired bidirectional one.
No matter the title, though, in my experience people's behavior doing DevRel has been leaning more towards one or the other of the approaches, mostly independent of the title itself, which has been just fine.
Who Are You?
My advice with personas and the way you want to do DevRel is to figure out who you are. Figure out who you really are.
Find what you are good at and what you like. Hopefully, they match. Find out how to be this person with everyone around you.
I still struggle with this, almost every day. I constantly keep thinking about how I can do better, be better.
2. Developer Relations Activities
There are a number of different activities you can do Developer Relations through, and generalizing, these are the more common ones:
- Speaking at events
- Blogging and documentation
- Writing and sharing code
- Social media
(Note that these are all outward facing; there's another layer to this around internal work in your company, working with Engineering and Product teams around the platform, sharing developer feedback and more, which I won't really cover here.)
Speaking at events: What does speaking at events really mean to you? Are they great fun? Getting personal attention? Sharing knowledge? Or, are they a necessary evil? Do you cringe every time you do it, but feel that you have to?
To me, it means trying to inspire people, and being there for them. Taking the time to present, introduce or engage people in a certain topic, and then being around — in-person — for discussions, feedback and thoughts.
Blogging and documentation: I believe sharing knowledge and thoughts through blog posts and articles are key, and collectively we're not doing enough of that. The written word is so, so important to make sure you can reach as many people as possible, because they can read it in their own pace and often their own language, they don't have to scrub through a video to find a certain section, and much more.
Documentation, in general, I would say lives on respective companys' developer sites, or, in the case of the web, also in public collaborative places like MDN Web Docs. Where to blog, on the other hand, can be a bit more complicated. Most people seem to feel that if they blog on the company blog, they're limited in what they can say, sometimes it becomes blogging-by-committee for legal/stakeholder reasons and the output is quite bland. And if you blog in your own website or Medium channel, it's great in the sense of freedom and building up your personal brand (which is usually harder in a company blog). But, there's also the risk that that blogging and important content is tied to that specific person and when they leave the company, all that content is gone. And additionally, people's personal blogs might feature company content and focus mixed with personal opinion posts that doesn't always represent the company's values.
When I worked at Mozilla, an interesting phenomenon — in the spirit of being totally open and transparent — was that people wrote public blog posts complaining or dissing the work of their colleagues and/ or another part or product at Mozilla. My take here is that openness is great, but also needs to be paired with personal respect and reaching out to people directly with your criticism, not just making it public directly. Also at Mozilla, I was the Editor for Mozilla Hacks for ~2 years. During that time we had lots of guest posts from external developers in the developer community, and I was really happy we could use that platform to share their knowledge and expertise to a broader audience. And this is something I think more companies could do.
Writing and sharing code: For a long time now, I would say that sharing code on GitHub is by far the most common, and also creating or contributing to frameworks for specific technologies. And I think that's still a great platform for people to do that! Stack Overflow has been quite popular over the years as well, and a lot of people get concrete help there, but the signal-to-noise ratio has overall been a bit challenging.
When you create and share code, I would say that the most important things are:
- Make sure to be open to feedback. You will get a lot of feedback and suggestions, and at the very least listen to it.
- Be constructive and respectful. Not everyone is that online, and sometimes the gut instinct is to just be defensive or attack back. I'd urge you, if possible, to at least give disrespectful people an initial chance. I've experienced many situations, comments etc that, once I've responded respectfully and constructively, actually has led to quite good and rewarding discussions.
- There are always 100 ways to solve something. If you write code, how you structure your solution, there are many ways you can build things. So when you get feedback on your things, or you give feedback on others' work, remember that there is never just one way of doing it.
Social media: When you have good code, content, and documentation, naturally you want as many people as possible to see that. How might you approach outreach and communication? Going out on Twitter is like crossing a floor filled with Lego...
You will be working hard to get attention for what you've done.
And what it even harder is that snark, quick burns, and petty attacks often get much more attention than quality content and a respectful tone. But still, don't despair, keep on sharing good content. Don't be tempted to lower your bar of behavior just for some quick likes. Personally — while you want to stand up for your work — I don't think it helps anyone getting into fights in a public channel where no one will back down just for the very reason it's public, and a level of territorial pride. Rather continue in-person or a video call, if possible, or over e-mail, but take disagreements out of the public space — unless you can keep it civil.
3. Measuring Your Work
Measuring Developer Relations is really hard. You can measure the easy things like X people at an event, Y people reading an article, Z people watching a video, etc. But how do you measure the actual outcome?
This depends a lot on your product. Would or should you measure the number of downloads for your product? The number of uses of your API? End users getting a better experience through big companies shipping your code or product? First of all, I'd strongly encourage you to have as much analytics of usage numbers as possible. Can you find a clear correlation between a blog post you did, documentation shared, an event done, etc., with an uptake following that? And how do you know that the developers using, for instance, your API, are using it because something you or your team did, compared to possible influence from other parts of your company?
One important thing to point out here as well is that it's not mainly about who should get credit for developers using something, but rather having enough data points to know which activities are most successful in helping developers adopting the best solutions.
Firefox DevTools and Feedback
One more measurable outcome that I worked on at Mozilla was around Firefox Developer Tools and UserVoice, which I started exploring because of a tip from a friend. Microsoft had used it for other areas before, and they started using it for their Edge browser later after this.
The core approach was:
- Let people give feedback and ideas
- Analyze and triage that feedback
- Compare it to other features on the roadmap, and prioritize it
- When developer community-suggested features were shipped, reconnect with them and the developer community to achieve a positive feedback loop
With UserVoice, people could suggest ideas, vote on them, and comment. And the main criteria were that it was simple to use, no sign-up or log-in needed, just an e-mail address. It also had a built-in search so for people creating new suggestions, it was matching ideas to see if there already existed a similar suggestion. It also had a general search, paired with official replies from Mozilla, with a direct contact and where we could indicate if an idea was Under Consideration, Shipped, Being Worked on or Declined. And even if we declined something, developers were happy because they got a reply! Better to know than to constantly wonder.
And my favorite part was that, 6 weeks later and in line with the Firefox release cycle, the first features shipped! And we could publish blog posts, showing the community that 3 out of 5 of the new features were suggested and prioritized by them!
And developers loved this, and in the big Vision Mobile survey that year, the number of web developers who said they used Firefox Developer Tools as
their primary toolset had increased 6%!
I also gave a keynote at Nordic.js in 2014 about this experience.
4. Feedback and Interacting with People
People are great! No, really, I'm not kidding! People are great! It just takes time to sometimes understand the many facets of interacting with people, from different approaches to their online persona and tone. People aren't always logical, and many factors affect their behavior. A vast majority of people, though — once you actually take the time to listen to them — aren't as bad as you think. It does take time and patience, however, staying calm and working hard to understand different perspectives. And it doesn't mean that you can't ever lose your temper, although I'm hoping most of you can stay calm. But just don't explode directly, and not in public. Try and take it easy, take a few breaths, get a second opinion from someone else to try and help you see things from another angle.
But I would recommend giving people the benefit of a doubt as much as possible, to try and assume they are meaning well and that — in particular in DevRel business — they are not upset with you, as a person, but more likely about a technical issue they can't solve, and sometimes misguidedly they express it towards you personally.
And then, of course, everyone is your friend on LinkedIn. Like, everyone. And that's ok.
And at Google, as you can imagine, there are a lot of opinions about Chrome to other areas of Google working with completely different things (and idiots writing manifestos doesn't help...).
Another key learning here is that people want, deserve and need to be seen and heard. In many cases, people just want to share their experiences or challenges, explain their problem and that you take the time to listen. If you can help, great; but if not, that's just as fine. Because at least you listened, at least you tried.
DevRel Is People Business
And for me, interacting with people, meeting them in real life: this is what I get energy from. It's so easy to get lost in e-mails, angry tweets, spreadsheets and more. But once I get to help and inspire people, I'm so happy and I see meaning in what I do.
I would also strongly encourage you to find your real passion.
DevRel is hard work, it can be very frustrating and it is a very unique mix of being technical and dealing with people. It can definitely take its toll on you, so make sure to find your passion
But if we can make people feel like this:
Then we're on to something. Then we're doing something right.
Published at DZone with permission of Robert Nyman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Authorization: Get It Done Right, Get It Done Early
Scaling Site Reliability Engineering (SRE) Teams the Right Way
Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
Never Use Credentials in a CI/CD Pipeline Again