Lessons Learned From Building Developer Communities

Key Takeaways in DevRel

This issue is delivered by Bianca Buzea

Over the past four years, I've immersed myself in the world of developer communities. From 1:1 sessions where I delved into architectural best practices, to orchestrating immersive Game Days and hands-on workshops during my tenure as a Solutions Architect at FAANG, my journey has been fueled by a passion for empowering builders.

In the ever-evolving Web3 landscape, I've eagerly embraced the challenge, diving deep into different protocols, organizing and attending developer events, and diligently gathering feedback. This journey culminated in the creation of DevRel Uni, a testament to my commitment to nurturing the next generation of DevRel practitioners.

Through this journey, I've learned invaluable lessons from both successes and setbacks, refining my approach and deepening my understanding of what it takes to cultivate and nurture developer ecosystems. Here I want to share the top lessons I have collected.

Finding the Right Fit: Placing DevRel Teams in the Organizational Framework

When establishing a DevRel function within an organization, one of the biggest considerations is its placement. According to "The State of Developer Relations 2023 Report", the positioning of DevRel teams varies, with 35% aligned under Marketing, 23.3% under Product, 19.4% reporting directly to the CEO, 15.5% under Engineering, and the remainder under the purview of the CTO. 

Each of these arrangements carries its own set of advantages and tradeoffs. Ultimately, the optimal decision hinges on various factors including company culture, team size, product characteristics, and overarching organizational strategies.

For example, while aligning with Engineering or Product may limit DevRel's impact on marketing endeavors, tethering the function to Marketing might strain its credibility among technical teams. In contrast, for sufficiently large teams, establishing DevRel as an independent entity can often prove to be the go-to move.

Nevertheless, irrespective of its formal placement, DevRel inherently operates as a cross-functional role, exerting influence across Engineering, Product, and Marketing spheres. Thus, it is important to empower DevRel teams to devise metrics that accurately capture their influence across different departments. This ensures that their contributions are duly recognized and leveraged within the broader scope of the organization.

Strategic Team Building: Embracing Diversity

Devrel proficiency spans a multitude of skills such as coding, communication, public speaking, social media engagement, and more. While the ideal candidate possessing mastery in all these areas might seem elusive, it's essential to recognize that individuals naturally excel in certain domains based on their interests and strengths.

Rather than embarking on a quest for the “elusive perfect unicorn”, a pragmatic approach involves assembling DevRel encompasses various roles including technical writers, developer advocates, developer relations engineers, managers, and others. It is a misconception that a single individual should embody all these roles.

Contracting allows organizations the ability to fill gaps in expertise in Devrel teams or strategically invest in particular areas of focus while being able to closely control costs. This approach enables teams to maintain quality output without necessitating rapid expansion.

Keep the Personal Touch

It may seem counterintuitive, but some of the most impactful outcomes arise from actions that cannot be easily done at scale. While Developer Relations typically prioritizes scale and broad reach, there are instances where personalized, one-on-one interactions yield better results. 

For example, the 1:1 interaction you have with a passionate team building on your protocol might propel them to the next stage of development and make them a valuable player in your ecosystem over time. 

Similarly, investing time at a hackathon to offer direct support to a developer can foster trust and loyalty. This personal touch may lead to them transitioning into a full-time contributor to your ecosystem.

Time spent deeply connecting and helping your developers is how you build a great reputation as an organization, and often, word of mouth is just as, if not more effective, than larger-scale campaigns. 

Hackathons: In-person vs. Online

In-person hackathons present an opportunity for deeper connections among participants and between your team and builders. However, their shorter durations (compared to online hackathons) may limit builders' exploration of your technology. Furthermore, these events often coincide with large gatherings, creating even more competition among various protocols for builders' attention. 

For protocols with growing ecosystems, online hackathons generally yield better results as builders can focus solely on your protocol and have ample time to explore its potential.

Alternatively, if engaging with hackers in person is a priority, consider organizing a hacker house. This approach allows your team to cultivate strong relationships with hackers, nurturing a vibrant community of builders who actively engage with your protocol and leverage your technology over time.

Create Feedback Loops

Feedback stands as one of the pivotal elements in DevRel. However, it often gets overlooked or inadequately implemented. Feedback is the most effective method for understanding how builders utilize your technology, discerning how best to support them in the future, and identifying areas of success. It's crucial to establish robust feedback systems. 

Starting with the basics; it's important to regularly schedule one-on-one sessions with a diverse range of builders from your ecosystem. These sessions provide invaluable insights into their building experiences and project requirements. This practice should be ongoing rather than a one-time effort to ensure continual alignment with evolving needs.

In addition, conducting surveys at regular intervals, such as every 3-6 months, allows for gauging and comparing the progression of ongoing initiatives. These surveys encompass documentation quality, tooling effectiveness, and satisfaction with support services.

These two feedback loops are vital and together give the ability to gauge the impact of long-term projects and the information needed to make crucial pivots along the way if necessary.

Conclusion 

Developer relations is multifaceted and it is hard, and although I think these lessons will help you on your journey, there will always be more to learn. Remember, the pursuit of excellence in this field requires an unwavering commitment to growth and continuous learning. Embrace each challenge as it comes and as an opportunity for growth knowing that your dedication and perseverance are what will lead to the success of your developer community.