A short informal introduction to Developer Relations

A short informal introduction to Developer Relations


8 min read

When you think of companies that build products that can be built on or used by developers (see Flutterwave ) or communities that work directly with developers (see Open Source Community Africa ) or even organisations that build APIs for public consumption (Think about it and share example in the comments. I promise it's not homework lol ๐Ÿ˜‰), one thing they have in common is that a direct connection with developers exist.

This connection, whether taken as a priority or not is Developer Relations.

In simpler terms, Developer Relations is everything that's done to make it easier for developers to use a product, acquire new skills or be a part of a community - relationship with developers.

Pick your favourite developer facing companies and think of how they have tried to make it easier for you to use their product and you'd realise that it all falls into developer relations.

A practical example

For us as part of the Developer Relations team at Flutterwave, we are often focused on creating and improving resources. This could include libraries, SDKS, articles and documentation etc for developers to easily use our APIs.

We maintain a line of communication with members of the general community that use us through providing support and also taking feedback to the actual team that builds the products and can make the changes needed.

What does the role look like?

The role is different in many companies and can be pretty broad. Some companies consider Developer Relations as developer marketing so that would also influence how the role is perceived.

In most cases, there is usually a team called the Developer Relations team and in there, you could have:

  • Developer Advocates: People focused mostly on public speaking, technical writing, documentation and other advocacy tasks. Can also include engineering and more.

  • Developer Experience Engineers: They can also be advocates but they work more on building tools like the SDKS and libraries and may not be as visible as the advocates.

  • Integration Engineers: This could be called anything but it's mostly people that are simply focused on direct support of engineers that want to integrate a platform or use a product.

This is not an exhaustive list (See title) but it's a nice place to start from. The Developer relations team serve as a bridge that connects the product to the rest of the developer community.

Getting into the role

I usually recommend that anyone looking to get into this role should have a few years of experience working as a developer. It's the easiest way to be able to understand how to communicate with and understand issues other developers are having. If you have this experience, you are more comfortable diving into unknown territory and also growing into the role.

I also recommend starting advocacy on your own. If you want to get into this role, a great way to start is to start working on it in your own capacity. Are there products you use regularly or are interested in? Talk about them, write about them, help other developers out with them, share your experience and if possible build tools leveraging on the platform that can help other developers.

With this step, you are able to identify which aspect of Developer Relations actually stands out with you and you can double down on honing that skill.

PS: I'm looking to generally assist or provide a platform for people to be able to get into this role. I sent out a tweet to this effect and I'm looking forward to connecting with people that are looking to get into the role. It's also great that other people experienced in the role are also offering assistance so check out the thread.

Hard things about the role.

In complete honesty, one thing I particularly struggle with in this role is metrics. And it doesn't help that this role varies from one company to another so in most cases, you have to be creative and intentional about the metrics that determine success for your own company.

You could also have to constantly prove to management and the rest of the company the effect of the work you do on the constant growth of the product and why your team is important.

One way I've tried to address this myself is to read about other people's experiences, speak with other advocates and take ideas from what has worked in other places. A few people I spoke to or looked at for help at various times include:

To succeed here, you also have to be willing to network and learn.

My personal experience.

I started my journey by helping developers out in communities like DevCenter Square. I realised it was something I enjoyed and it did help me learn more about tools I used. With time, a lot of people would see my work or reach out to me for help.

A few years later, I got recommended to Ingressive as someone that could work with Developers to help grow adoption and use of GitHub in Nigeria at the time. And that was my first formal entry into Developer Relations and Advocacy.

From there, I'm currently at Flutterwave where I started as a Developer Advocate but currently working as a Frontend Engineer and Developer Experience Engineer - you learn more about yourself as you continue in the role. ๐Ÿ˜ฌ


As mentioned, this role varies across companies, so I implore you to keep an open mind. And if you're already in Developer Relations, I'd love if you could also help share your experience and support other people trying to get into the role.

Here's a platform showcasing Developer Advocates you should check out as well. avocados.dev