The three pillars of Developer Relations

This post is a fancified excerpt from Lee Robinson’s guest appearance on The Changelog podcast. Lee is the VP of Developer Experience at Vercel, so he really knows his stuff on this topic! To get the full experience you should listen while you read 💯

🎧  Click here to listen along while you read. It's better!   🎧

---

The way that I run my Developer Relations team focuses on three different things:

1. Education 🧑‍🏫
2. Community 🤝
3. Product 🎁

But first, a caveat

The way DevRel teams or organizations are structured at companies kind of depends on where it falls in that company’s priorities. So for a developer tooling company where their bread and butter is talking to developers, it’s probably gonna have an elevated position in the company. It’s incredibly important to their business and to their community.

Maybe if the company is just… they have an API as part of their products, but that’s not the main thing they do… they might have a Developer Relations team who’s helping with the adoption of that API, and ensuring that people are successful with it… But it’s not the main thing.

I like to give that caveat, because it’s hard to give a singular definition of what DevRel is, but there’s multiple flavors we can be inspired from for teams who are trying to figure out.

Okay, how do I wanna get into this space? Or how do I wanna structure my organization to support developer communities?

I talk to a lot of startup founders/early-stage companies who are talking to me about:

When should I hire a DevRel?

When should I hire these people to build our communities or to help educate developers?

It gets tricky, because not all companies are the same. It requires a little bit of nuance to dive into there. So, back to the three pillars I talked about, of education, community and product - I can dive into each one of those independently.

1. Education 🧑‍🏫

Vercel is a frontend platform you can build and deploy code and host it around the world. And because of that, we also have frameworks like Next.js, that allow you to write your code. The nature of the products requires education.

We have to teach developers how to use these tools. It’s not always immediately obvious how you would build a global application. Maybe you need some guidance along the way. And I think that education for developers is deeply rooted in basically everything we do.

As we got started learning how to code, education was important, and being a lifelong learner or a continual learner is so rooted in the development journey, especially for web developers, where the types of technology go through cycles, and you’re learning new things over the years, and kind of iterating on your knowledge and learning new techniques…

So, it’s important that you’re helping guide developers along the journey, and teaching them the tools and the tricks that they need to be successful with the product.

2. Community 🤝

The second pillar I think a lot about is community, because it’s harder to replicate a community. You can purchase a product, you can acquire an audience, but that doesn’t automatically mean you have a community.

Community-building requires dedicated effort and attention, and I think it’s one of the highest-leveraged things a developer-focused company can have.

If you have a community of developers who love your product, they kind of do the job for you. They advocate for your product for you. They’re your outsourced DevRel team at that point; they’re talking to the community about:

Wow, this product is amazing. You should be using it!

And they love it so much that maybe they go talk to other developers about it. And being very intentional about growing that community is a very important part of what a lot of DevRel teams focus on.

3. Product 🎁

The third one is really how it all relates back to the product. And I think it’s important that developer relations roles, or developer experience, or developer advocate (there’s multiple titles; we can get into that nuance…)

All of these roles play some part in giving feedback on what works well, and maybe what’s not very good on the product. And I think it’s important to get that feedback internally before you hear it from your customers.

For example, if we’re releasing a new product or a new feature, I would rather have some engineers internally who have this critical eye for what a good developer experience looks like walk through the product, try to figure out how things could be broken, where beginners might struggle, where advanced people might struggle, and get that feedback before we release it to everybody.

And there’s this continuous feedback loop of:

Community pain point: how do we solve it in the product? Community struggle: how do we better create educational material to help prevent that from happening in the future?

---

Lee has written extensively on this subject. See also What is Developer Relations? A Look into DevRel at Vercel and Developer Experience at Vercel. Oh, and listen to our entire conversation which is filled with wisdom on the topic.