The Supabase Influence on my DevRel Mental Model

The first in-depth chat I had about developer relations was with Jon Meyers, DevRel at Supabase. We talked about definitions, tackling the representative of the organization dilemma, the challenges of context switching, and the upsides of always learning something new and usually cutting-edge.

These conversations happened in my first official year in tech and formed the basis of my understanding of developer relations. Soon after, I joined Supasquad, an unofficial group of Supabase advocates, and have continued contributing to the community.

My contributions range from helping with the code, building a community package, creating technical tutorials, and organizing meetups to just shouting about Supabase on socials 🤭. All while staying in touch with the team and seeing their DevRel, community, and open-source approach play out in real-time.

It is no surprise, then, that the Supabase philosophy influences my mental model of developer relations as a whole. And given how wildly popular Supabase has become with near $0 in ad spend, I think it’s a positive influence.

What is DevRel?

Developer relations is often defined as the link between the developers who use a product and the developers who build the product. DevRel is, therefore, more relevant and common among organizations whose product is meant for developers. For example, devTools and organizations that provide API access to their product.

DevRel professionals take feedback from the developer users and send it to the product team. They advocate that this feedback be incorporated and considered when creating product roadmaps.

They also take new product features and communicate their value and use to the developers, the intended users. They do this by ensuring that documentation is accessible and concise, providing technical examples and sample code, and being available to answer questions.

By this, DevRel cultivates a culture and community around the product and is responsible for nurturing and keeping it healthy.

The “Is DevRel dead?” Discourse

It is quite clear that DevRel plays an important role and is invaluable for developer-focussed products. But there has been discourse that periodically bubbles up about whether the function is stagnating or just straight up dying.

As long as developer-focused products exist, DevRel will always be needed. It’s more a matter of evolving expectations and environment.

Why is DevRel Important?

DevRel is important to developers because it makes the product approachable. DevRel professionals ensure seamless onboarding, and that product documents make sense.

They act as a point of contact if you have trouble with the product and humanize the experience of interacting with and building with it.

For the organization, DevRel professionals keep users happy and engaged while increasing product awareness among developers outside the product’s circles. A well-functioning DevRel team increases product trust, loyalty, and sustained growth.

The Different Faces of DevRel

DevRel is wide and is generally built upon these pillars:

• Developer Advocacy - This focuses on creating technical content, building relationships with the community, and taking feedback from the community to the product team.

• Developer Experience - This aims to enhance developer productivity with your tools. It generally involves aspects such as clear documentation, creating SDKs for the community, and offering dependable example code snippets.

• Community Management—This part focuses on community building and nurturing. It rewards active community members, creates ways for the community to participate, and creates a healthy community space.

Different organizations might have different titles and responsibilities for DevRel, but it will usually build upon the above pillars.

DevRel as Support

There is a lot of tech talk about whether or not DevRel is marketing or sales, but my personal take is that DevRel should be closer to technical support.

Considering that companies that need DevRel are targeting developers, their technical support is in service of their users, and their users are developers, it makes most sense that DevRel should do support.

Yes, marketing and sales are important, but I think DevRel working closely with the technical support team is the killer combo that serves all the purposes. Working with technical support will mean:

• They understand their paying users and pain points.

• They understand the reasoning behind why some of the users are paid, and some aren’t.

• Based on this knowledge, they can better move the community down the funnel.

• They can help correlate support data with their own observations from the community to inform a better product.

• They can optimize onboarding materials and education materials to be more effective with the insights gained from technical support.

Ultimately, both functions serve the same-ish user profile (tech support probably serves more of larger enterprise customers). They would still be more effective if they internally collaborated more often.

Final Thoughts

Over the past year, I’ve had the privilege of collaborating with DevRel teams across different organizations. The diversity of skills required to be badass at this amazes me.

DevRel professionals can remain technically skilled while developing deep expertise in skills like effective communication and collaboration. This is what draws me in. I love that I can continue to develop my core technical skills while helping educate the community and influencing the developer experience.

While I haven’t officially worked in a DevRel role, my experience contributing to communities, creating technical content, and collaborating with DevRel teams has made me appreciate the place of good DX.