Today marks my one-year anniversary in the Developer Relations (DevRel) industry. As an “old hand” in the industry, I was asked by netizens to write this article to introduce newcomers to the workplace about what needs to be done in the Developer Relations profession and the work it involves.
The content of this article is purely my personal thoughts and experience, and does not represent any of my professional achievements.
In my home country of India, the term “newcomer” refers to someone who has just graduated and has no work experience. Today, I am no longer a newcomer. But it still feels fresh and memorable, and also a bit sad. Like many things, you realize you’ve gotten older.
My first job was as a Technical Evangelist in a country thousands of miles away from home (UK). Although I had six other job offers that would have let me stay in my home country, I chose the former because it was the only opportunity related to Developer Relations. This article is about what I’ve learned about Developer Relations over the past year, and why I accepted this job opportunity across continents.
Developer Relations (DevRel is short for Developer Relations) is currently considered one of the most sought-after roles. To someone not in Developer Relations, looking at tweets about Developer Relations on Twitter (which is basically our heaven!), this profession seems super dreamy. Over the past year, at least a thousand people have asked me what this role actually involves and how to become one of them.
Many people are explaining Developer Relations and why it’s important for a developer-facing company, but I’ve never met anyone whose first job was or is in Developer Relations (but that’s exactly what I experienced!). So, I want to share my perspective on Developer Relations.
This article is written for people working in companies without a Developer Relations department who don’t quite understand the role, and also don’t understand that its function may be different for different types of companies. At the same time, it will be very interesting for those aspiring to join a Developer Relations team.
A Developer Relations department is more often composed of roles such as community managers, technical writers, technical evangelists, technical advocates, etc., but sometimes even includes growth hackers and marketing personnel. The goal of the Developer Relations department is to build positive relationships with developers, who are the primary customers of developer-facing companies, such as my current role as Technical Evangelist at Ably.
These relationships only become positive when those developer customers are satisfied. For developers, happiness comes from perfect product documentation, simple website navigation, responsive customer support, constructive onboarding tutorials, attractive events/competitions, and everything in between. This is exactly where the Developer Relations team focuses.
Depending on the size, product, or type of the tech company, the goals of technical evangelists/advocates also vary.
-
In a global multinational corporation, a technical evangelist’s work focuses on attending as many events around the world as possible. While sharing technical knowledge, they also need to mention that they represent XYZ company. Sometimes, technical evangelists are also responsible for newly recruited developers, helping them get on the same starting line as others.
-
In a tech startup, a technical evangelist’s work focuses on getting as many developer users as possible to know about the product, and ensuring existing users understand everything about the product so they can fully utilize it.
-
In a medium-sized tech company, a technical evangelist’s work focus may not only be participating in technical events but also building various internal strategies to attract and retain developer customers.
Although this means different things for different companies, importantly, the larger goal of the Developer Relations team is to share knowledge, whether about a programming language, a software engineering discipline, or even technical details of their own product.
Therefore, in my opinion, a technical evangelist should be someone who can transform advanced conference presentations into something junior audiences can accept while retaining the technical details of the original content. Because of this, all resources shared by technical evangelists must include introductory material about the topic, or at least link to other simple materials, so that even junior developers can follow advanced materials.
| ** | Development Experience Required for Developer Relations** |
It’s a well-known fact that some of the greatest minds, when building solutions to the most complex problems, sometimes feel that what they’re doing isn’t handy enough to communicate. Sometimes, they don’t want to waste time on the latter because they prefer the former.
Therefore, there’s a huge gap between the creators of technology and the consumers of technology, and this is where the Developer Relations team is needed to fill it.
As I mentioned before, my first job was in Developer Relations. Although I did many side projects during college and interned at startups, hoping to launch my own tech products, I didn’t have any full-time developer experience at any company.
Of course, sometimes I feel (and still feel) overwhelmed by the amazing things people share on Twitter. I keep thinking, “There’s still so much in this world I don’t know.” But the fact is, believe me (I heard this from others too), actually most people are in the same boat as me (or you).
Incredible technology is emerging every day in this world, developing so fast it’s beyond human limits. Therefore, an expert in one field often only knows some details of another field. But as an audience, you put all these different experts together, making you feel like you’re the only one who doesn’t know many things.
If anything, every post I see on Twitter encourages me to learn something new. If I encounter something I like, I’ll spend more effort to understand it. I’ll also share it with others in the simplest way, so they don’t have to spend as much time as I did, or look at as many materials as I did, just needing to connect the dots at the end. I enjoy this process myself.
My day is spent helping others understand things they didn’t understand before, while I myself need a long time to understand. It’s very interesting.
| ** | Sometimes Developer Relations May Mean Wearing Multiple “Hats”** |
A large Developer Relations team means each technical advocate can spend time trying to figure out how to better serve the company’s developer customers. For example, writing interesting tutorials, talking about the hottest tech trends, hosting webinars, writing thought-provoking technical articles, recording teaching videos, hand-drawing sketches to explain complex data structures/algorithms, proposing more effective technical support strategies, building onboarding guides for products, or just attending as many developer events as possible, trying to have face-to-face interactions with people in the technical field.
But a smaller Developer Relations team means doing more than one of these things at the same time. This is a perfect balancing act, inherently experimental in nature. Too much or too little of anything can be dangerous. Therefore, you need to constantly evolve strategies, regularly check metrics, analyze what works and what doesn’t based on multiple variables, etc.
| ** | What Value Do Newcomers Produce?** |
Of course, it’s certain that newcomers can’t have first-hand experience with technical problems like experienced veterans and propose corresponding solutions based on the problems.
I very much agree that an experienced person can easily talk about a tech topic. Correspondingly, a newcomer needs to spend ten times the time to understand the topic themselves before having enough confidence to share with others. Even if the content is different from experienced technical advocates, it will definitely be understood from a completely different angle.
| ** | Everyone is Developer Relations** |
As I mentioned before, current graduates are full of curiosity about Developer Relations and hope to join it. There may be a huge misunderstanding here, thinking that technical evangelists are trendy people roaming around the world sharing some basic development tips. But even such a super cool role requires serious work.
Believe me, behind every published article, every written tutorial, and every speech, there’s a lot of work to do. Content is the biggest challenge, and many things play a role in it, such as visual presentation, technical breakdown, relevance, technical level, and length of materials, etc. Standing on a stage with thousands of people below isn’t easy. Having meaningful conversations with strangers and becoming good friends isn’t easy either. Being able to openly accept criticism, constantly learn and improve is even harder. None of this is easy.
Developer Relations isn’t easy. But for those passionate about building amazing things and constantly talking about it, it’s indeed very interesting.
Of course, joining a Developer Relations team also means you don’t have as much time to write actual code. This is frustrating for many people, affecting their entire decision to join a Developer Relations team. I’ve also seen many people return to developer positions after staying in developer teams for a short time. Therefore, it’s very important to understand what it is before you decide to join a Developer Relations team.
People who know me know I’m a super talkative person. I think my mom is a college CS professor, and she also instilled in me the joy of teaching complex things to others.
Therefore, I think Developer Relations is natural for me. I’m not saying I’m good at it, but I like participating in it and constantly learning in the process. The same enthusiasm drove me to connect with the Mozilla Foundation starting from college, first becoming a Firefox Student Ambassador, then a representative, and now a technical speaker. Through this, I met a group of like-minded friends, which drove me to co-author a book about virtual reality with them, “Learning Web-based Virtual Reality”.
I like talking and writing about what I know, and I’m very interested in learning what I don’t know, so I can share it with others myself.
If you can relate to this article and this is what you often want to do, then Developer Relations is for you. Start looking for opportunities! But if you can’t understand, then my friend, until now you still have some misunderstanding about Developer Relations.
| ** | Experienced Developers != Senior Technical Advocate/Developer Relations Lead** |
By now, you should have understood that a Developer Relations team has completely different goals, responsibilities, and skill requirements compared to a technical team composed of developers or a marketing team.
Therefore, even if you’ve been a developer for many years, you still need to spend some time on Developer Relations itself to accurately understand it. Therefore, transitioning from an experienced developer to a senior developer advocate is unlikely to be very productive for you and the company.
| ** | Developer Relations in India** |
Unfortunately, the Developer Relations scene in India is quite bleak. Compared to Europe and the United States, the number of conferences held here is very small. Although many people (like Siddharth and Dhananjay) have realized this and are working hard to change the situation by organizing meaningful events in India, connecting with the global Developer Relations community, participating and contributing.
However, the current technical community still doesn’t view “technical evangelist” as a natural job role. Quite a few companies do have a Developer Relations department, but the goals vary greatly.
I myself have served as a technical evangelist role in Indian companies, but the focus there was simple marketing, not developer/community building. This is a completely wrong idea. If you’re one of them, please understand it before you hire. You may be changing many people’s understanding of this role. At this time, Christian Heilmann’s blog would be a good starting point.
If you’re a developer-facing tech company, it’s time to seriously consider building a Developer Relations team. If you’re someone who wants to join a Developer Relations team, please make sure you’ve figured out the situation and clearly know what you need to do, then make the right judgment.
I’m very excited to have completed my first year of career! Here, I want to thank everyone who helped me understand various things over the past year and helped me grow into a professional. Also, if you want to follow my work content, I often tweet @Srushtika.
Author: Srushtika
Compiled by: Zhuang Qi
Original: A fresher’s guide to DevRel
Reprinted with permission: Developer Relations »
