What is Developer Relations? A Look into DevRel at Vercel

I've been leading the DevRel team at Vercel for over a year now, growing from just myself to a team of six. I'm often asked questions like:

• What is DevRel?
• What is DevRel like at Vercel?
• Is DevRel a good fit for me?
• Will I stop developing if I move to DevRel?

This post aims to answer these questions, while elaborating on my philosophy behind DevRel and how I've scaled our team.

What is Developer Relations?

You might hear Developer Relations, Developer Advocates, and Developer Experience used interchangeably. They do have differences depending on the company, so I'll start with how I personally view DevRel.

To me, DevRel is helping educate developers and grow our community. There are pillars of DevRel that everyone on the team shares ownership for, like developer experience, quality control, and excellence in communication.

Part of the reason DevRel teams are ran so differently depends on the type of company and industry. So, let's narrow down this post even further: Developer Relations at DevTools or developer-led companies.

What is DevRel like at Vercel?

DevRel is an integral part of everything we do at Vercel. We care deeply about developers and their experience using our platform and tooling.

It starts from Guillermo (our CEO) and works it's way down. Great DevRel teams stem from founders who empathize with developer pain. You'll often see @rauchg replying to folks on Twitter, asking for feedback on the product or helping customers succeed. He leads by example for the entire DevRel team to follow.

Since DevRel is such a public facing role, the DevRel team represents the ethos of the company. When we host an event, create a video, meet with a customer, or any other interaction – it should scream Vercel. I believe this comes from being a company that leads with design.

Design is user experience and developer experience. It's the DNA of what makes Vercel successful. Everyone at Vercel sweats the details to provide an exceptional experience for customers. We're very blessed with some incredible designers who I've been able to shadow and learn from, helping me (and the rest of the DevRel team) lead with design in everything we do.

One of my goals is to create a positive, uplifting, and vibrant community of developers who are excited about making the web faster. This means you'll find me or others on the team in GitHub, Twitter, Discord, Reddit, Facebook, Hacker News, and everywhere else online learning about how developers use our products and where we can improve.

In the process of educating developers about the tools and products we provide, we learn what is working well and what's not. Our team then is able to work with product to relay valuable customer insights so we can iterate towards the best customer experience.

Is DevRel right for me?

I truly believe the demand for DevRel (and content creation in general) is only going to continue increasing at a rapid pace. But I think it's also important to stress you don't need to quit your job to validate if DevRel is right for you.

You can start creating content today – it's permissionless. No one is stopping you from writing that blog post, creating that video, or teaching others about tech you find interesting. While it's definitely easier to transition from an existing developer/programmer/engineer into DevRel, it's possible to start with DevRel as your first role.

Let's assume you're looking to move into DevRel from engineering, which is the most common path. Here are some questions to ask yourself, along with my own responses that led me to switch to DevRel.

Are you finding your engineering work fulfilling?

I felt limited, wanting to do more than just code. I knew my experience and skills in writing, design, and video creation could be better utilized. I'd actually had design teams shut down my suggestions to help improve the user experience of the product before.

If you need to write a one or two-page document outlining an architecture design for a feature you're working on, does that sound fun or dreadful?

Yes. I love writing. Especially clearly articulating tradeoffs for architecture decisions. If we do this, what are the pros? Cons? How does it impact our product in 6 months? 1 year?

Do you enjoy staying up to date with the latest tools and libraries in your space?

Yes. I love to learn and experiment with new tech. It helps programming feel fresh to me. To be a developer is to be a lifelong learner.

Do you like to work across teams? Do you enjoy communicating with marketing and product?

Yes. I have an entrepreneurial heart and love seeing and being involved with all parts of how the business runs.

Are you the type of person who enjoys debates? Can you articulate your points clearly?

It's a skill I've developed over time. Having empathy for other developers and being able to understand their situation and constraints is key.

Will I stop developing if I move to DevRel?

No, you should continue coding. You can't lose sight of the “developer” part of Developer Relations. To understand and empathize with developers, you need to put yourself in their shoes. Especially if you're advocating for a product developers use.

For example, let's assume you're advocating for a database. You might start to get questions like:

• How does this database compare against [competitor]?
• When would I use [feature] over [feature]?
• What's the best way to build an [industry-specific] app using this database?
• How should I model my data to stay within the free tier?

It's going to be hard to accurately answer these questions if you don't have hands-on experience developing using the product. You should be the first user of beta features and the first to provide feedback to the product team on what's going well (and maybe not so well).

Growing DevRel Teams

High trust teams are high growth teams. I want to create a team that trusts each other, has autonomy to get their work done, and is given ownership over some part of the experience.

For example, on my team each member has a specific area of focus and ownership. This helps them have a north star for the type of content they're creating, and also allows them to get invested in that segment of the community.

I have a few non-negotiables in terms of how DevRel teams should be ran:

1. It doesn't matter if DevRel reports to marketing, product, engineering, or directly to the CEO. What matter is how the team is given ownership, autonomy, and what metrics quantify their success.
2. DevRel teams represent the company, but they are also individuals, often with their own following or areas of interest. It's the wrong approach to try and box creatives into company/team structures of the past. The new age of developer creatives are more like professional knowledge athletes, where they represent companies or teams but also have their own independent initiatives.
3. The company does not control your social media accounts. You should never be forced to tweet/share something on behalf of the company from your personal account. Many advocates have worked hard to create an audience that finds their work valuable, and shouldn't be pressured to dilute that. I've heard some horror stories about this and feel pretty strongly about it. You should be creating content or products so good that advocates want to talk about them.
4. You can always, always learn something from your customers. Even when they're complaining on Twitter or upset in GitHub issues. Leading with empathy and a genuine curiosity in how the product could be better will lead to insights others might have ignored. Engaging with upset developers can be tricky, but ultimately rewarding if done well.

If this sounds like a team you'd want to work on, I'm hiring. While I'm open to folks looking for more general DevRel roles, I'm very interested if you match these descriptions:

• You're passionate about build systems, monorepos, CLIs, and making ship happen. This person would work closely with the Turborepo team, as well as every part of building and deploying code on the Vercel platform. You can discuss tradeoffs of how web apps are architected and love to help developers improve performance in every possible way.
• You're passionate about the web, and the growing ecosystem of tools and companies often working together to craft incredible user experiences. You may find yourself trying out the latest database, or the new component library posted on Hacker News. You like to stitch together tools and build examples showcasing interesting open-source libraries. You can craft an impressive Notion doc. This person would work closely with all of our technology partners, like databases, content platforms, ecommerce tools, and more.

That's all for now. Drop me an email at lee@vercel.com with three paragraphs on why you'd be a good fit if you're interested in joining.