Also in Developer Stories
Me, my computer, and the will to act
Maximizing developer community participation is a journey, not a destination. It requires continuously engaging with your community and making innovative changes along the way.
The term DevRel, or Developer Relations, refers to the activities that resolve developer needs, drive awareness and adoption of software, and provide a feedback channel between a developer community and product maintainers. The strategic objectives of DevRel can vary significantly between developer communities. And while there’s no one key to optimizing developer relations in a community, it’s important to start by understanding the developer journey. My own journey from contributor to developer advocate in the decentralized web technology (Web3) space illustrates a theory of maximizing developer onboarding as well as a hierarchy of developer needs.
Leading with discoverable educational resources
As developers, we are some of the biggest consumers and producers of technical content. When I was first introduced to Web3, I had no shortage of questions and curiosity about the many relevant technologies on the market.
Learning to deploy solutions on various decentralized web networks was an education-intensive process for me. For instance, when learning about Libp2p (an overlay protocol integrated in various p2p networks like IPFS, Eth 2.0, and Filecoin), I had to source educational resources in formats like tutorials, code samples, and set-up guides.
I attended conferences, seminars, and community activities like meetups and hackathons, and I subscribed to newsletters as avenues to understand these solutions and their base of builders, supporters, and developers. I learned about the fundamentals of the technologies—like their architectural features, performance optimization strategies, and cryptographic primitives—through use-case reviews and other technical papers.
At one conference, I learned about the InterPlanetary File System (IPFS), a peer-to-peer communication protocol on a mission to replace its commonly known counterpart HTTP. Enthusiastic about technology, I continued to interact with the network through resource materials including introductory documentation and videos, FAQ sections, and how-to guides.
Across Web3, I found the availability of developer resources engineered in collaboration with product maintainers, like tools, documentation, and other training materials, are widely appreciated in communities as they enable developers in the ecosystem to rapidly build and deploy innovative solutions.
The discoverability of this content was the first step to bring awareness of this solution to its intended audience and build a community by continuously reaching developers and sharing solutions.
Providing resources that illustrate how a solution is customizable, extensible, and scalable to meet developer needs is a guaranteed way to generate developer interest. In my case, I identified problems, and was able to get a sense of all the solutions decentralized technology provided.
Scaling community through advocacy
Armed with essential guides to solution deployment, I was able to fast track my adoption of Web3 technology. At this stage in my journey, I focused more on community activities that reduced my time-to-competency, such as in-depth workshops and masterclasses that involved deep coding and engineering support in discussion forums.
In such collaborative building environments, the complexity and sophistication of the technologies was complemented by low-code tools to streamline adoption for on-the-fence developers. For example, the IPFS Brave Browser integration and the IPFS Desktop application are both great low-code ways to get started with IPFS.
Satisfied with the reliability, usability, and overall value of Web3 technology, and tapping into the advocacy capacity within the IPFS community, I worked with other community members to organize developer-centric workshops and local community events where we introduced a new network of developers to the technology. Although we started small—only five of us at the first IPFS Nairobi meetup—we have since grown to a community of members from across the continent, and aptly renamed IPFS Africa.
Through other advocacy pipelines, like speaking at conferences and producing technical content, we are able to increase the visibility for the community. I have found that enabling authentic ambassadors in a community to contribute to the onboarding funnel is the key to exponential growth in developer onboarding.
Photo: Moses Acquah, CEO at Afrolynk at IPFS Nairobi meetup
Hierarchy of developer onboarding needs
Pulling these functions together as a steward of a community requires the tremendous effort that goes into building each level. While it might not seem obvious where to start, the hierarchy of developer needs that developed on my journey to advocacy highlights the base layers and builds upward in relevance and functionality.
While not all developer journeys are similar, developers have vast and varying needs during the onboarding process, and it is imperative to provide the resources to fulfill these needs as they move up the hierarchy toward a level of self-actualization within the community.
The hierarchy of developer onboarding needs is a reflection of Maslow’s motivational theory that depicts the developer needs I identified in my journey. These hierarchical levels are meant to be fulfilled one step at a time towards self-actualization.
Onboarding documentation
While the promise of value in any technology lies in its connection to developers, the lack of meaningful information required to effectively utilize the solution drastically reduces the probability of any long-term interaction with it. On the flip side, I’m an avid user of solutions that engineer developer-specific documentation that mirrors the technology state. This may include guides to set up a local development environment, to outline workflow procedures, and to highlight common bugs and resolutions.
One way to fulfill documentation needs for developers at different levels is to empower DocsAdvocates within the community. This can be an individual or group of people who will champion and execute documentation engineering. As a technical writer, I’ve contributed to ecosystem DocAdvocacy by producing technical content that synthesizes the complexity of decentralized technology into digestible concepts.
Education for growth
Beyond great documentation, my experience adopting Web3 technologies was rooted in a two-tier learning strategy focused on both qualitative and quantitative content. The qualitative content strategy zeros in on the depth of knowledge in specialist areas. Content produced here was highly-specialized and incorporated extensive research with papers, whitepapers, and specifications charts.
The qualitative method spotlights the completeness of the topics covered for any wide range of network components. This included getting community updates through a regular technical newsletter, updating developers on upgrades, performance analysis tools, and blogs.
Ultimately, most developer communities benefit from a combined quantitative and qualitative strategy. For community stewards, it’s important to understand how learning happens in your community and invest time and resources to meet that need.
Community support
The third level of the hierarchy of needs is a place for developers to give and receive community support. As previously mentioned, to fast track my adoption of decentralized technology, I relied on discussion forums to network with other developers, ask questions, answer other members’ inquiries, and have wider conversations. Communities that can identify the platforms that work best for their members and continuously engage with developers through social media, chat, and forums, foster collaboration that meets the need for continuous support.
Developer enablement
Within the Web3 ecosystem, we enable members to contribute to the development of the community by giving feedback, testing and building applications, and participating in community events. To achieve this engagement level, communities implement technical training and workshops with a hands-on enablement plan. This can be instructor-led or self-paced workshops, or webinars that provide the tools and information that meet adoption needs.
In-person evangelism
Now that you have cultivated a community rich with developers who authentically love your product and advocate for your vision, it’s time to develop programs that will bring all this energy into one room (well, a digital room for now) by organizing conferences, expos, and networking events. This enthusiasm will rub off on new users who may have connected with your community at these events, evidenced perhaps by the ever lively series of blockchain conferences we’ve had over the years.
Conclusion
It's important to note there is no one-size-fits-all approach to onboarding developers. Developer journeys are as different as they come and DevRel advocates need to continuously track the measures that are working within their community, and identify the multiple programs that can be run simultaneously. Having a fundamental understanding of human interactions and using this knowledge to anticipate developer needs before they get started is a great way to stay ahead of the curve.
The DevRel theory of developer onboarding will help you understand what to do, who to engage, and how to measure your efforts.
Further Resources
