7 things I learned from DevRel Engineers 🥑 at DevCon

Web3 business model requires adoption which means it needs a constant flow of builders, new features, users and feedback.

Builders is the key word and the best way to get builders aware of a project is through well designed resources such as exciting hackathons, tools, practical education materials, live events and community support. Here is where Developer Relationships comes into play.

One of the most insightful moments for me during Dev Con VI at Bogotá was the full-of-alphas DevRel Workshop hosted by Sunny Jaycer (DevRel at SuperFluid) and a panel formed by:

Sam Flamini @ Superfluid
Albert Hu @ Alchemy
Emily Lin @ Truffle
Yaz Khouri @ Celestia
Steph Orpilla @ Polygon
Francesco Andreoli @ Metamask

Here is what I learned.

1. What DevRel is not

• DevRel is not sales.
• DevRel is not marketing.
• DevRel is not Engineering.

Where you put a DevRel will determine their success so it’s important to understand the role.

2. DevRel main goal

Your main goal as DevRel is the product success and you will achieve it having a lot of empathy with other developers and creating resources that are very accesible.

The developer is the main character of the story and there are plenty of ways to support their journey.

3. DevRel is actually an umbrella term

There are different focus areas for DevRel Engineers including but not limited to:

• Evangelism
  • Talk in public about the project, company or protocol.
  • Create educational resources for users and builders.
  • Engage the communities on-line and off-line.
• Advocacy
  • Support the community and get feedback from it.
  • Serve as a bridge between the outside community and the internal team of the project.
  • Encourage contributors and build tools and processes to effectively support them.
• Documentation
  • Create written documentation for the project.
  • Maintain current documentation.
  • Keep tack of new features or updates delivered by the internal team.
• Community
  • Moderate online community channels.
  • Provide support at events such as hackathons.
  • Keep track of high value members of the community and help the to succeed.

Content will play a key part of the role indistinctly of your focus area so you will need to develop a strategy effectively impact your community.

4. The DevRel Playbook

Creating content for developers is tricky. Here are some useful ideas to figure out how to do it right.

• Create great content for your community and your product will thrive.
• Your personal brand is important but you are advocating for your platform and the brand. Your goal is help everyone to succeed.
• Think about developer first, product second. Make others feel they are not alone when using your product.
• Educate people about how to look for relevant material.
• Some content is more volatile than other. Things change fast in Web3.
• Written content is updatable but video is not. You’ll probably want to create videos about more ever-green general ideas and text for updates or release notes.
• Be creative! you can mix art with technical content. You could do a web3 rap for example.
• Make useful stuff. Think about something you would love to have in the past but you didn’t.
• When creating content think about use cases. Don’t repeat the documentation but add value to it by exploring new use cases.
• Show how to integrate your product with other products. Web3 is about composability. Most of the time developers will need to use several tools or platforms. “Wagmi-fy” your content.
• Be transparent about your own developer journey. Build in public (your community will love it).
• Consistency is the key.

5. Developer Personas and The Orbit Model

As DevRel you should be clear about who you are talking to and when. The Orbit model (presented by Yaz Khoury) is an awesome tool for defining Developer Personas.

According to Khoury there are 4 community orbits around a project. Each of these orbits will require a different strategy. The closer the orbit is, the more mature the person is in their journey with your product.

1. The Casually Interested: haven’t explored the project in depth but is curious about it. Requires help and motivation getting onboard and understanding the project better.
2. The Builder: knows the documentation and can build or integrate with your product with other products. Needs technical help around specific use cases when building. Hackathons are a common place for builders with this profile.
3. The Community Member: is involved in the community. Participates in communication channels even volunteers for activities. Needs support to get more visibility and remove blockers from their journey.
4. The Biggest Fan: is invested long term. Participates in grants. Bring value to the project and other members trough contributions, support and feedback. This is the most valuable member of the community and will need the best incentives from the internal team such as direct technical guidance, priority and why not? limited edition swags.

Depending on the project there will be more or less specific activities across the orbits. One particular case is being a DevRel for a Layer 1 project.

6. DevRel for Layer 1

Being a DevRel for a Layer 1 instead of a project higher in the stack has its own particular activities and responsibilities like:

• Improve developer experience.
• Hardfork coordination
• Validator relations
• Governance relations
• Improve the proposals
• Host Core Dev calls
• Advocate smart contracts languages
• Technical writing
• Community calls and coordination
• Engineering activities

This skills will help a lot in your journey as a Level 1 DevRel

• Basic practical knowledge about cloud computing
• Building Dapps for workshops or demos
• Being confortable with the command line (don’t be afraid of it, it’s really useful)
• Being confortable with Linux

Making sure you understand your responsibilities and execute accordingly is important however you will also need to quantify your progress in order to communicate your achievements to the core team.

7. How to measure DevRel success

Measuring success in DevRel is quite challenging because not everything is quantifiable. However there are some strategies you can use to get a better understanding of the impact.

Here are some tips to define success metrics:

• Create interactive tutorials and measure the progress of your users
• Quantify how many hackathon projects get funded
• Track engagement on Discord and Github
• Look for repeated pieces of feedback
• Track attendance at workshops
• Use social media analytics

You can get better metrics doing these:

• Ask what is interesting for people and document it
• Go to every hackathon and get feedback
• Look for trends and move fast
  • Develop integrations with new products
  • Provide feedback and ideas to the core team
  • Develop documentation and examples for new use cases
• Hack with your community!

Conclusion

DevRel is a complex role extremely important for web3 projects and difficult to find by recruiters. In my opinion it will become hotter and hotter in the next few years.

If you want to become a DevRel start by paying attention to what other DevRels do and learn from them. Finally here is a hack from the legendary Nader Dabit: target smaller projects instead of big famous protocols. There is more room for you to shine and a bigger probability of getting noticed.

Enjoy the ride!