Starting Strong in Developer Relations

Good DevRel starts with understanding your company, your product, and your community. All of your initiatives are built upon this foundation of knowledge.

Don’t just generate ideas: make informed decisions for what will make the most impact. First you must ask questions, listen, and understand.

If you do, you’ll:

• Have a greater impact sooner
• Be genuinely helpful to your community
• Progress in your career quicker
• Create high-quality content
• Enjoy your job more

What we’ll cover

You need to build knowledge in three main areas:

• Company - The people who pay you and create the product
• Product - What the company builds and the community uses
• Community - The folks who use your product

Who should read this?

• Newly Hired DevRels just starting at a company. This will give you a robust understanding to help you start strong.
• Working DevRels already in a role. This will fill potential gaps in your understanding. You can share your findings with your team and onboard new hires faster.
• Aspiring DevRels interviewing at companies. Many of these questions would be good to ask your interviewers to learn more about the role.

Think of this guide like a travel packing checklist. You can efficiently prepare for your journey without worrying that you’re forgetting something.

This is the guide I wish I had when I started. I learned the hard way and made more mistakes than I’d like to admit. Let’s help you avoid those.

Understand your company

First we’ll learn everything we need to know about the company. Your initiatives should tie into your company’s goals, values, positioning, and beliefs. Understanding your company provides important context for the product and community.

What is the company’s mission and vision?

The mission is your company’s why. What is their reason for shipping code? How are they looking to impact the world? What do they want to provide for the community?

Some examples:

• Patagonia: We’re in business to save our home planet.
• Honest Tea: To create and promote great-tasting, healthy, organic beverages.
• Prezi: To reinvent how people share knowledge, tell stories, and inspire their audiences to act.
• Microsoft: We strive to create local opportunity, growth, and impact in every country around the world.

If your company doesn’t have one, ask people at your company what they feel the vision is.

In Developer Relations, you act as the face of the company and product, so it helps to know what mission you’re representing.

What are the company’s goals?

Goals are your company’s what. What are the specific benchmarks they’re trying to achieve this year?

• Which goals are the DevRel team expected to impact?
• What is the timeline on those goals?
• How are they measured?

With this understanding you can craft initiatives that factor back into these goals. While no decision in DevRel is a sure thing, this will get you moving in the right direction.

Who are your company’s competitors?

Learn about your company’s main competitors and what differentiates you from them.

• What features do you have in common?
• What features differ?
• When would you objectively recommend one product over another?
• How is your company positioning itself compared to competitors?
• How do your communities differ?

Remember, the companies are competing; not you personally. Stay friendly with the Developer Advocates at these companies. They’re not your rivals, just friendly devs like you working at a different place.

How is DevRel success measured?

Companies measure the long-term impact of developer relations differently.

Some focus on the number of developers signed up. Others may focus on developers attending events or open source contributions.

The two questions you need to ask are:

• What metric(s) are tracked to determine success?
• What tool(s) are used to track those metrics?

Like with company goals, you’ll want your initiatives to move the needle here.

Stealth jets undetectable by radar = awesome. Stealth initiatives undetectable by your metrics = not awesome.

Get to know your team

These are your main collaborators and partners. They might have different roles within the team, but they all work to improve the Developer Experience.

Here are some key things to learn about the team.

• Why were you brought on?
• What are they looking for you to do specifically?
• How big is the team? (Smaller teams often require members to wear several hats.)
• What are your team’s goals?
• Who sets the goals, and how often are they measured and adjusted?
• What kinds of initiatives are they working on this quarter?
• How do the team and overall company engage the community?
• What regular events do they put on?
• What are the goals for your community?

What is your role?

What does your manager and team see you doing in this role? The umbrella of DevRel or Developer Experience is a large one and can contain people who:

• Write documentation
• Go on podcasts and livestreams
• Write tutorials
• Manage and grow the community
• Build integrations
• Organize events
• Create demos/starters
• Talk at conferences
• Advocate on social media

You’ll probably focus on a handful of related tasks.

• Developer Experience Engineers might find themselves split between engineering and advocacy tasks.
• Technical Writers would work primarily on documentation
• Community Managers could spend most of their time organizing events and engaging the community.
• Developer Advocates typically spend their time creating content for and speaking to the community.

None of these roles and duties are standard across the industry, so don’t assume anything. Clear communication with your team and manager will prevent frustration down the line.

How is your company organized?

Where is your team in the company org chart?

Typically, DevRel is:

• Under Product
• Under Engineering
• Under Marketing
• Its own thing

The goals of your parent team will likely influence your team’s goals. Certain decisions might be confusing without this important context.

Get to know other teams

The DevRel team can’t succeed on its own. Many people at your company contribute in some way to the Developer Experience. That’s why building relationships across the org chart is a great idea.

Schedule chats with some of the different people or teams across your company. I think small groups are best; meeting ~3 folks from a team at a time.

As always, ask questions and listen.

• What do they think is relevant for you to know?
• How do they want to work with you?
• Which users do they talk to and what for?
• What issues are they facing?
• What do they want to know about you or your role?

Building relationships now makes it easier to work on projects with people in the future. Plus, you’ll want to reach out to some of these people as you begin to dig into the product.

Learn your product

Over time you should become deeply familiar with the product you’re representing. This will help you to:

• Create resources to teach others how to use it
• Communicate with the community about it
• Identify new issues and solutions
• Influence your product team with feedback

This journey will be different for every company and even different products within the same company.

If you have a complex enterprise software product like Shopify, there are dozens of complex features with hundreds of developers building features. Even learning the core product might take a couple weeks.

We want to learn the product quickly, but not so quick that we miss out on invaluable beginner moments.

Be the Newbie

If you’re brand new to the product, that’s a wonderful thing. You have a priceless opportunity.

I call it the Gift of Ignorance.

Right now is the only time you can genuinely empathize with a brand new user.

Once you learn your product, you’re susceptible The Curse of Knowledge. It’s a cognitive bias where an expert forgets what it’s like to be a beginner when teaching. It’s someone telling you, “just rebase and force push,” when you’re just starting to learn git.

Embrace your Gift of Ignorance while you still have it.

If you’ve already used the product before, try to come at the product with fresh eyes. This is an important skill for improving Developer Experience. I’m always asking:

• What does this look like to someone new to our product?
• What background knowledge are we assuming they have?
• Where might they struggle or get stuck?

Take notes on your own user journey.

• What concepts do you struggle with?
• Where do you get lost in the documentation?
• How do you assume the product should work before you know how it does work?

If you get stuck or confused, don’t blame yourself. Instead, take note of it so that later, you can help users who hit your same issue.

Build with it

Whatever you’re advocating for, make sure you know how to create things with it.

During onboarding, build several projects with the product. Build a project for each of the three most common use cases. For a CMS maybe that’s a blog, an app, and a marketing site.

Then, you need to leave the happy path and experience what it’s like to really build with it.

Create a personal project using the product. Something you’ll come back to over and over again, at least a couple times a week. This could be your personal site, or a custom app to track your workouts. This really depends on what your product is.

This level of knowledge is so beneficial to your company and community. You’ll be able to provide insights to your product team, and be able to help users with more advanced use cases.

Strengths and weaknesses

Once you’ve built a couple of things, get your coworker’s opinions on the product.

• What are its strengths?
• What are its weaknesses?
• What’s their favorite thing about it?
• What are the killer features?
• If they could add one feature, what would it be?
• What use cases does it solve perfectly?
• What use cases are not a good fit?

We ask these questions after we’ve tried the product so we can create our own opinions first. If any of their answers surprise you, go to the product and see for yourself.

Read the docs

Read the documentation for the product you’re focused on. All of it, front to back.

You’ll gain a thorough understanding of the tool and discover features you would have missed. You’ll find yourself in the docs often, so it’s good to know where everything is.

Docs are crucial to user success and a core part of the product. For that reason, you should be familiar with everything a user might encounter there.

Take notes

Take notes about everything, especially during these first few months.

Your notes can include:

• What you found confusing
• Moments of delight or joy when using the product
• Questions you have and the answers you get later
• Things that surprised you
• Places you get stuck
• Ideas for future projects
• Important product concepts in your own words

Later, these notes can help you:

• Improve onboarding for future hires
• Remember where you struggled so you can empathize with users
• Easily create content like blog posts
• Check for misconceptions or misunderstandings when shared with a coworker

No product is perfect

As you learn everything you can about the product, you’ll start to find a lot of bugs, unsolved issues, and things you think could be improved. This is not unique to your product. Even places like Apple, Google, and Microsoft have tons of unresolved issues and unhappy customers.

Be proud to represent your imperfect product. Be kind to the imperfect humans who have put their best efforts into making it.

Meet your people

The community is the most important aspect to Developer Relations. They put the Dev in DevRel.

If you’re plugged into your community, you’ll consistently:

• Organize well-attended events
• Write helpful, timely blog posts
• Create useful, relevant starters

If you don’t know your community, you’re rolling the dice every time you produce something. You won’t know what your people want or need.

Who are your users?

You can’t reasonably target all Software Developers, so find out who your target demographic is.

• What programming language(s) do they use?
• Are they junior to mid-level devs, or big stakeholders like CTOs?
• Where do they work?
• How do they like to consume information and learn?
• How do they use your product?
• What problems do they have that your product solves?
• What features or resources would make their jobs easier?
• How enthusiastic are they about your company or product?

Where are your users?

Where do your users spend their time online? This could be:

• Twitter
• GitHub
• Reddit
• Stack Overflow
• Hacker News
• Discord
• Slack
• Forums

If your product has a dedicated space for the community on Slack, Discord, or a forum, that’s a good place to start.

To discover Tweets, blog posts, and other places online that discuss your company, you can use a tool like Mention.

Identify your Champions

Who are the most active members of your community?

The Orbit Model explains why these folks are so important.

They play a central role in attracting other members and directing the community toward accomplishing its goals. Without these members, the community would struggle to stay focused.

Ask your team who they see as the champions. What users are out there advocating for you?

Reach out and schedule a call with them if you can. Make it a relaxed, social call that lets you get to know each other. Remember, we’re here to listen and understand.

They’ll surely have keen insights into your company, product, and community. This outside perspective is priceless, so take note of everything they tell you.

Connect with content creators

Who has made content about your product in the past year? Find the tutorials, videos, and courses that feature you and reach out to the creators. Get to know them and tell them what you liked about their work. Understand their goals as creators, where they struggle, and how you can help in the future.

Content creators can form a symbiotic relationship with your DevRel team. They help you by teaching others about the product. You help them by promoting their content with your company’s social accounts.

In the future you can offer to review their content before they publish it. They get invaluable feedback from an expert, and you can make sure they teach the best way to build with your product.

Don’t fake it

You don’t need to be an expert to help your community. Your community includes beginners and experts, and you’re always going to be somewhere in the middle.

There are always going to be folks who know the product better than you for their specific use cases.

You might feel the need to be the top expert, but that’s not what the community is looking for. They’re looking for someone to point them in the right direction, create helpful content, listen to their issues and questions, and make them feel heard.

Be honest about how much you know. Appreciate when they teach you something new.

Supporting users

Ask your manager when and how to pass struggling users to your Support Team. While you have the desire to help, you’ll eventually find yourself doing the work of your company’s support team.

The organization at every company is different, so make sure you understand where the line is for you.

Sometimes users will reach out to you specifically, or you’ll see someone sharing concerns on Twitter. When that happens, see if you know the answer or can find it with a search. Otherwise help them find the proper support channel.

You can still be that first contact for the community, but don’t go outside your scope when your support team can do it better and faster.

Final thoughts

While you’re learning about the three big areas, here are some things to remember during your first few months.

Take what works

Just like your company, product, and community, your approach to DevRel is going to be unique. There is no single right way to do DevRel.

This guide is meant to give you a broad overview with actionable steps. Take what resonates or makes sense for you, and leave what doesn’t.

Give yourself time

DevRel is inherently creative, so give yourself time to find your voice. Experiment with different types of content to find what works for you.

You might end up working on things you or your manager didn’t expect, and that’s okay. Be patient with yourself and know that community building takes time.

Shadow a senior DevRel

If you can follow and observe the workday of a senior DevRel, do it. It’s a great way to learn the job and get insights into their thought process.

You can observe as they create content, engage with the community, and use the product. This will help you develop your personal style and approach to the role.

You’re there to learn, so observe and ask lots of questions. Hold back any suggestions, critique, or corrections unless they ask.

Reach out

I might not know you yet, but I genuinely want to help you succeed in this field. Reach out and I’ll do my best to give good advice or point you in the right direction.

If you’ve got anything to suggest about this blog post, please send it my way. I want this guide to be as helpful as possible.

I want to thank Lucie Haberer, Grace Miller, Prince Wilson, and Vadim Smirnov for their feedback and help shaping this guide.