DevRel: Developer Relations and Technical Evangelism

The motivation for writing this article is actually quite simple. Recently, I had the privilege of communicating with several DevRel professionals in the Chinese community, such as Steven, Teacher Dai, uvd, and George. At the same time, I also occasionally communicate with my former boss and found that there are not many DevRel personnel in the Chinese community. Based on some of my own accumulated experience and insights in DevRel work, I want to take this opportunity to share my thoughts. DevRel is a complex and young profession, and sometimes I am not sure if I am on the right path. But one thing I believe is: DevRel is a lifestyle.

Special thanks: Jenks @ filecoin and Rod @ Ledger, my two mentors, and thanks to my former boss.

PS: There is too much to say, I can't finish writing ah ah ah ah

Some Introduction#

My first exposure to evangelism was at seedao, where I participated as a main speaker in a course. Later, I also shared Web3 knowledge in the Rebels and Little Ghost community, at that time I might not have been in DevRel more as a lecturer. My professional background leans towards technology (specializing in supercomputing, with research topics related to blockchain), and this background helps me output better. At the same time, according to the Feynman learning method, explaining a concept clearly to others in simple language can test whether you truly understand that concept. During my sharing in Rebels, I found that I could explain technical concepts clearly using simple language. Gradually, I began to study web3 and blockchain more deeply in preparation for my graduation project.

During the learning process, I came across LearnWeb3 and Alchemy Learn. Vitto (now working at Cyfrin) had a significant impact on me because through him, I learned about the DevRel position. It was also through the developer community that I learned about open source and technical evangelism. Later, I joined BNB Chain as a DevRel, thanks to my former bosses Zoe and Yian. During my time at BNB Chain, I mainly researched the Greenfield storage chain. After that, I joined FLock, choosing this place because it logically fits and matches my background.

Although I personally feel that my coding ability is not strong, definitely not as good as many others, I can only write MVPs at most, and I am indeed not very good at deeper logical frameworks. However, I have one ability, which is to simplify complex logic. This ability is not possessed by many people, and I will simplify based on the background of the audience or conversation partner, changing my narrative style. For example, for non-technical people, I will pursue a higher-level overview. For those interested in web3 technology, I will mention more about blockchain knowledge. For those interested in AI, I will focus on explaining federated learning.

I believe that as a DevRel, in addition to a technical background, communication and explanation skills are also very important. This is why I strive to learn how to convey complex concepts to others in simple and clear language. I will adjust my narrative style based on the background and needs of the other party to ensure they can understand and accept my explanations.

In summary

Technical background
Willingness to output externally
Compatible communication and explanation skills
Research ability
A passion

What is DevRel#

The History and Evolution of DevRel#

Before we get into the main topic, I think we should first understand what DevRel is and its specific responsibilities. The term DevRel originated in the 1980s from Apple, when the situation was the origin of computers and software. At that time, Apple found that their ideas were too novel, and many people could not understand what they were or the benefits of macOS. Therefore, they needed someone who understood technology and marketing to do some guiding and instructive work. Teaching and guiding everyone on what macOS and Apple products are and how to use them. With the emergence of more technology companies, people found that products were no longer the main focus, but how to integrate became the main issue. Thus, DevRel became popular, and more and more people became DevRel. Many companies built their own ecosystems through DevRel and gradually became stronger through ecosystem partners. For example, Twilio and Spotify, which we will discuss further in the next chapter.

In the definition of DevRel, it not only includes teaching and guiding but also interacting with the developer community, building relationships, and providing support. By establishing close ties with the developer community, DevRel can better understand developers' needs and problems and provide corresponding solutions. This interaction can also promote collaboration and knowledge sharing among developers. Therefore, DevRel is not just a marketing tool but a process of growing together with developers.

Moreover, as the number of technology companies increases, DevRel is becoming increasingly important. The competition for technology products is becoming more intense, and having a good product is no longer enough; it is also necessary to convey the product's value and advantages through DevRel. By collaborating with the developer community, technology companies can better promote their products and attract more developers to use and support them.

Currently, DevRel plays a very important role in the technology industry. It is not just a marketing tool but a way to work closely with the developer community. By establishing good relationships with the developer community, DevRel can help technology companies promote products, solve problems, and facilitate collaboration and sharing among developers. In the next chapter, we will delve into the specific practices and cases of DevRel.

I think this quote is quite classic, it indeed illustrates what a DevRel's daily norm is, (a polymath (not, specifically feels like a fusion of dev + mkt + prod.

Generating leads, taking over the documentation, being a partner to product management, on-site consulting, organizing conference booths, budgeting, creating marketing materials, participating in product development, creating and running weekly workshops, maintaining integrations into other products, traveling your geo region up to 80% of the working time.
—— Alexander Reelsen

Dev Evangelist, Dev Advocate, Dev Relations#

Here’s an explanation of these three roles, which are quite similar in my view. However, their functionalities may vary by company.

Typically, companies that can make such distinctions are usually large companies, and such divisions are rarely achieved in small companies. From what I understand, Polygon, Circle, and BNBChain have clear divisions. Circle divides DevRel into three departments under MKT (we will talk about this later), and the founding members of the DevRel team are members of Twilio's DevRel team (Twilio's DevRel is recognized as one of the best in the industry). The introduction of Circle's Dev community will be handled by the Dev advocate. The Evangelist will be responsible for workshops and presentations. Finally, Dev Relations will be responsible for documentation and demo code. This is the practice of large companies. Other small and medium-sized companies do not divide it too finely.

When I was at BNB Chain, we also had solution architects and DevRel, and often different personnel were dispatched based on the event location. For example, my superior was in Dubai, and he would attend events in Dubai, India, and the Middle East. The solution architect was in Europe, and he attended EthCC. I happened to be in Europe, so I also made a guest appearance at the Eth Lisbon presentation.

Code, Community, Content: The Three Pillars of DevRel#

In the following paragraphs, I will explain the main responsibilities of DevRel using a more scientific approach. We can break it down into three Cs and a five-layer pyramid. The three Cs mainly refer to "code," "community," and "content." Let's first talk about these three Cs.

Code#

Code represents demo repos, live coding, and everything related to code. Currently, I have seen several good examples, such as lensV2 and Jarrads's boiler template and videos. Code examples and live coding can quickly help developers integrate various services. This is very important because good code examples can make developers in the ecosystem more efficient. Code examples are usually associated with documentation, while live coding is part of the community and events. Therefore, many times in industry discussions, it is said that DevRel (developer relations) does not need to emphasize code too much. However, I believe this view is incorrect. Only when we understand the developer's development path can we better write documentation and assist developers in joining the ecosystem through the use of demos/SDKs.

Community#

In the field of DevRel, the concept of "community" encompasses two main parts: the developer ecosystem and events (both online and offline).

Developer Ecosystem#

First, let's look at the developer ecosystem. Traditionally, managing the developer ecosystem is usually the task of developer operations, which is different from DevOps work like Docker and CI/CD. For example, BNB has a dedicated developer operations team on BNB Discord, responsible for handling various issues faced by developers, such as node setup and Greenfield development. Our main responsibility in DevRel is usually technical explanations to the outside. However, in smaller companies, the responsibilities of DevRel and developer operations often overlap, and any technical issues encountered in the community are usually resolved by DevRel. For example, in the Lens developer community, Nadar personally intervenes to answer questions, which increases the warmth of community interaction.

Events#

Another important part is events, including online and offline activities. Online events include Community Calls, AMAs, and Workshops, and DevRel personnel are generally capable of handling these activities. From previous data and experiences, technical community calls are an effective way to promote discussions and demonstrate project activity. AMAs can be externally or internally led, depending on the needs. For example, I participated in AMAs for ZetaChain and Greenfield and hosted a weekly AI x Web3 AMA, inviting various project parties to participate in discussions. The main difference between online and offline workshops is the perception of audience enthusiasm. Online events often involve multi-screen operations and may not receive feedback in real-time, while offline events allow for direct interaction on-site, making it easier to sense and respond to audience emotions. The advantage of online workshops is that they help those with social anxiety participate more easily (such as online workshops hosted by starkastroCN, LW3, and Developer Dao).

As for offline events, such as hackathons, developer conferences (devcon), and ETHCC, the situation is even more diverse. At these conferences, DevRel usually handles booths, helping attendees better understand the technology and products. DevRel's role is particularly important at hackathons because we know best how to present to the outside world and can help participants solve problems. At these conferences, you can almost always meet some resident DevRel, such as Nadar (Avara, Lens/AAVE), Simon (Edge&Node, The Graph), Kevin (Polygon), and Mirko/Francescco (Consensys&MetaMask). DevRel forms a close-knit circle. Additionally, offline talks and workshops, such as HackerHouse sharing sessions and speeches at various events, are usually also handled by DevRel. The external dissemination of technology is one of our key tasks.

Content#

In DevRel, content creation is an indispensable part, mainly including two categories: text and video.

Text Content#

Text content involves various forms, including technical analysis, documentation, tutorials, courses, and threads. Based on my personal experience, I particularly enjoy writing documentation, tutorials, and threads. Usually, the writing of threads for our official Twitter is handled by our technical writer, while I mainly write about my own research and DML-related content. Here I also share some of my experiences in maintaining documentation: many times developers do not like to write documentation, but good documentation is the key to getting developers started. How to write in a more understandable and timely manner is key. At the same time, writing documentation is not just about recording steps and explanations; it is also about organizing the narrative in an engaging way, allowing each information point to connect coherently. To this end, I spend 3-4 days each month thinking about how to improve our documentation to make it more effective and appealing. As for tutorials, please think of yourself as a newcomer and follow the logic of understanding; if beginners can understand, then everyone else can too. When I write documentation, I first think about the topic and what the tutorial aims to achieve, then break down the code and decide on the length. Finally, I start writing. After finishing, I must position myself as a beginner and run through it several times, creating a good test set, continuously optimizing and improving the content.

Video Content#

Video content production is another key area. I have learned a lot from the video production methods of industry leaders like Patrick Collins, Nadar, and Jarrods. The production of YouTube shorts usually emphasizes telling a concept or story completely within 60 seconds. Regular video content is broader, usually revolving around demos and integration usage methods. For example, recorded videos of workshops and panels are valuable learning resources. Although I personally prefer to read code directly, considering different learning styles, combining video with Git Repo is a good choice, especially when the audience is not clearly defined. For "How to" type content, video is a more suitable introduction method because it can visually demonstrate how to use our products and what to pay attention to.

Pyramid#

The above is my understanding of the three Cs. When writing this article, I also did some research and found a more detailed explanation. This explanation clearly outlines the general work tasks of a DevRel, while other miscellaneous tasks can be categorized as misc. As I mentioned earlier, DevRel is usually very close to technical BD/product marketing, but there are many differences. The primary principle of being a DevRel is to have a comprehensive understanding of our own products, knowing the technical principles, user logic, and execution logic. Then, through different means, convert this information and advantages into a language that everyone can understand. The means can be events, workshops, or content output. But the key is to let everyone understand what we are doing, why to use it, and how to use it.

events
workshop & webinar
education content
Community support
Documentation & onboarding

Developer First & Developer Plus#

In the world of DevRel, we classify companies into two types: Developer First and Developer Plus.

Dev First refers to products primarily aimed at developers, usually focusing on developer tools, development tools, and development aids. Notable examples include Vercel, MongoDB, and Twilio. The goal of these products is to enable more developers to use SDKs or services for development. They are committed to providing developers with an excellent development experience, helping them develop and deploy applications more efficiently. These products typically offer rich documentation, example code, and support, as well as integration with other development tools and services. By meeting developers' needs and helping them succeed, Dev First companies can build strong developer communities and loyal user bases.
Dev Plus refers to products where developers are a secondary target or an added bonus, rather than the main focus. The core business of these companies is usually aimed at enterprises or consumers. Although they also provide developer tools and support, developers are not their primary user group. Instead, their products focus more on meeting the needs of enterprises or consumers, providing solutions and services. Notable Dev Plus companies include Apple, Google, and Microsoft, which have strong market positions in various fields and attract a large user base through innovative products and technologies.

In DevRel, both Developer First and Developer Plus play important roles. They jointly drive the development and innovation of the developer ecosystem. Developer First companies attract a large number of developers by providing excellent developer experiences and tools, promoting the prosperity of the developer community. Developer Plus companies, on the other hand, drive the application and promotion of technology through products aimed at enterprises and consumers, providing developers with broader markets and opportunities.

Whether Developer First or Developer Plus, the goal of DevRel is to establish good relationships with developers, understand their needs, and provide support. By participating in events, hosting workshops, and sharing knowledge, DevRel can engage in in-depth communication and collaboration with developers, helping them solve problems, improve their technical skills, and promote product innovation and development. Overall, both Developer First and Developer Plus play important roles in DevRel, each with different positioning and goals. Whether focusing on developer products or treating developers as auxiliary targets, they provide developers with rich resources and support, driving the prosperity and innovation of the developer ecosystem.

Mkt or Ops or Dev? Where Should I Be!#

After communicating with numerous DevRel professionals and interviewing several companies, I found that different companies have vastly different understandings and positioning of DevRel. There is no right or wrong in this; it is only a matter of practical effectiveness. Some companies view DevRel as part of the marketing department, while others believe it should belong to the technical department, and still others think DevRel leans more towards an operational role. These different perspectives largely determine the overall strategy and responsibility positioning of DevRel.

Clearly, taking a moderate stance here is not feasible. On the contrary, the multifaceted nature of DevRel corresponds to the "three Cs" principle we mentioned earlier. Among them, "Content" corresponds to Marketing, "Community" corresponds to Operations, and "Code" is linked to Development. Each company has different understandings and expectations for the DevRel role based on its business needs and strategic goals.

Traditional and Web3#

Since I have not worked in traditional web2 DevRel, this section mainly relies on interviews with web2 to web3 DevRel professionals and the materials I have collected.

There is not much difference in the core between traditional DevRel and web3 DevRel; the main tasks are also similar. However, web2 DevRel is more commercialized, while web3 DevRel focuses more on community development.

"web2 companies are actually profitable lol so it's much easier to see exactly how devs translate into profit, which in turn makes it easier to measure and plan devrel" - cat

This quote comes from a friend of mine in the DevRel field, Cat from Aztec. Her words reveal the differences in the emphasis on DevRel between Web2 and Web3 companies. In Web2 companies, due to subscription and product payment models, they can more directly observe the impact of various developer relations activities on revenue. In contrast, tracking KPIs and formulating metrics in Web3 DevRel work is more challenging. For example, we may rely on intuitive data indicators such as on-chain transaction volumes and app download counts, but these do not directly reflect revenue, especially when the product is in the testnet phase.

In Istanbul, I had the opportunity to discuss the situation in the Web3 field with several DevRel professionals. One viewpoint particularly impressed me: "In the Web2 era, the number of developers I was responsible for might range from 10,000 to 100,000, making it difficult to understand each person's situation deeply. But in the Web3 era, the developer community is smaller, and members often interact in various activities, forming a close-knit group." In fact, according to the Developer Report data from October 2023, the number of monthly active developers in the Web3 field is 19,279, with an estimated 6,279 full-time developers. This indicates that the Web3 developer community is relatively small compared to Web2, but this is precisely why it can form a unique relational network.

Another friend of mine, Rod, once said: "Web3 developers are like a small family, often meeting at various hackathon events. This environment fosters special interpersonal relationships and provides opportunities for communication." Compared to Web2, communication in Web3 is more intimate and personalized due to the smaller number of participants. This sense of intimacy is one of the reasons I particularly like Web3; it gives a feeling of a big family.

Insights and Feelings#

Since starting as a DevRel at BNB Chain in March, it feels like I have experienced 2-3 years in just half a year. The saying "one day in Web3 is like a year in the human world" is truly applicable. This year, I have traveled to many places; to be honest, in my ten years in the UK, I hardly went out except for returning to my home country. This year, I spent 25% of my time attending conferences, which meets the DevRel standard of 25% travel. In April, I attended ETH Lisbon, in July EthCC, in August GHH, in September Token2049, and in November Devcon. In these ten months, I have really tried many different things, constantly experimenting, summarizing, improving, and progressing myself. Here are some things I have done this year.

This year, I participated in the preparation of two offline events, What the flock at Token2049 and DML night at ETH London.
I judged three hackathons: BNB Chain's Zero2Hero (assisting), HomeDao Hack, and ETH London.
I participated in four hackathons: ETH Lisbon, ETH Paris, ETH Singapore (thanks to the Card3 team), and ETH Istanbul.
I attended over 50 events, conducted more than 5 offline workshops, and over 10 online sharing sessions.
I have written a lot of content that is currently under review and will be updated gradually!

Overall, my experience shows that DevRel is a very complex job, and I prefer to call it a lifestyle. In addition to the three Cs, the main theme of DevRel is business trips, especially large hackathons and developer-focused conferences (devcon, edcon). Through constant traveling, DevRel gradually becomes a lifestyle. Going to various places to connect with local developers, understand pain points, and solve them. For me, this year I have been to many places and seen many interesting things.

Research and Narrative#

In addition to the basic responsibilities of DevRel, I also do some research work myself. I believe that for DevRel, exploring new trends and technologies is crucial. This involves not only understanding new narratives but also combining these narratives with existing technological frameworks to make innovative attempts to attract new developer groups.

After listening to Bob, the solver in Paris, I immediately thought about how to combine our product technology with his views, how to rely less on classifiers and more on AI agents.
The combination of DAO and AI agents is currently being explored by William (42 Agents) and Safe. I personally have high hopes for this. Moving towards automated voting custody to improve voting efficiency.
Researching internally initiated academic studies, the combination of ZK or decentralized computing power.

Many times, because DevRel is very close to technical BD, I also follow up and review documents for many projects discussed at conferences. In daily life, what BD says at DevRel conferences is essentially me. Reviewing documents is a challenging task. I need to thoroughly understand the project's content, operation methods, SDKs used, and even whether there is a dedicated language, and then based on this information, conceive potential collaboration plans. This requires me to be very familiar with our own technology, as well as to have insights into market trends and understand the project vision and technical implementation of partners. For example, I am currently looking at how we can collaborate with decentralized computing power, allowing users to rent computing power by only contributing data. A good DevRel must have used their own products and be very familiar with them.

Hackathons#

Now comes my favorite part: hackathons. Hackathons are a wonderful scene that brings together many hackers, providing excellent opportunities for communication and learning. As a DevRel, I believe participating in hackathons is the best learning and interaction scenario. Here, you will see many DevRel assisting hackers in building products, and this process is filled with creativity and collaboration.

The reason I participate in hackathons or serve as a judge is simple: only by deeply understanding the entire process can I guide and support other participants more effectively. The main KPI for DevRel in hackathons is the number of projects—we hope as many projects as possible use our technology, which can provide ample samples for subsequent data analysis. For example, at ETH London, I mainly did two things: first, I simplified the tutorial; our bounty mainly focused on application innovation, so I hoped participants would not spend too much time integrating our code. I directly demonstrated the interface code and returned data, making the integration process more intuitive and simpler. Second, I would patrol the venue between 1 AM and 2 AM to understand the developers' progress while promoting our bounty tasks. I found that the period from 1 AM to 3 AM is relatively free for participants because everyone has a break after intense work, making it the best time to communicate with them.

Based on my experience and practice, the final feedback was very positive. A total of 12 projects integrated our model API, which far exceeded our expectations. At hackathons, attracting participants is somewhat similar to grassroots marketing activities, especially in such high-density developer gathering situations, using the identity of a judge to engage in in-depth communication with developers, promote our bounty tasks and products, and assist them in solving problems helps to further build deep relationships. One compliment I received was: "Thanks Tim, definitely the only one who stayed up with us during the battle, thanks for the support." This made me feel that my efforts were worthwhile.

Events, Workshops, and AMAs#

Let's talk about attending conferences. This year, in various events and conferences I participated in, I often felt like I was the BD. My experiences this year have taught me that there are not many events that can truly attract developers to participate; developers still need to seek out hackathons before and after. Therefore, targeted promotion or joining specific small groups has become key. In this regard, ElectricCapital's Developer Report has been immensely helpful to me; it serves as a bible in the DevRel field, providing us with an in-depth analysis of the developer ecosystem. Through this report, we can clearly understand the current state of the developer community. Of course, from an open-source perspective, if the project itself is not open-source, these analyses lose their significance.

Overall, organizing and participating in events, workshops, and AMAs is a challenging job. I need to constantly think about how to communicate effectively, ensuring that participants can quickly understand our work. In AMAs, quickly recording the guest's remarks is essential; after each round of answers, I echo to enhance the audience's memory of the guest's responses. Preparing for workshops is similar to a teacher's lesson preparation; I need to carefully consider how to teach and explain. Developers' needs vary, so there are no one-size-fits-all answers when building an excellent developer community. Only through continuous attempts, engagement, and stimulating discussions can we gradually establish a community. There is no shortcut to quickly building a community; everything requires time and sustained effort. But it is certain that continuously holding events and workshops can definitely showcase our efforts and effectively attract developers' participation.

Conclusion#

Finally, I want to say that DevRel is too complex; it is truly a mix of pain and joy. I hope more developers can join, and I also hope we can attract more developers into the circle. This is mainly from the perspective of the project party, combined with what I have seen and done. There are actually pure developer community practices, but I am not very familiar with that.

timtimtim