Surfing the Wave of Developer Relations: Part I

Today’s post is a guest contribution from Kevin Chen. He was the first Developer Advocate at the now-unicorn open source company Kong and currently works at smallstep, an early stage open source startup.

(The audio version of a similar discussion between me and Kevin Chen on Developer Relations can be found on the Interconnected YouTube channel):

If I had to compare working in the tech industry to a sport, surfing would be the first thing that comes to mind. And this is because of two key reasons:

1. Everything is a “wave”. We are currently riding the third wave of digital transformation, watching the second wave of workplace technology pass by (thanks to COVID), and bracing for the new wave of cloud transformation. Oh, and don’t get me started on the crypto wave.
2. The time between two successive wave crests is called a swell period. When you get wiped out by a wave and the swell period is short, odds are you’ll be greeted by a lovely wave to the face as you emerge from the water. Wipe out on a wave in this ever-changing fast-paced environment, be ready to eat the salty sea-water truth that you’re outdated.

So how do we stay afloat amongst the relenting waves of change and innovation? To finish out the surfing analogy, we look for the surfboard. Surfboards keep us on top of the wave, and afloat if we are to fall into the water. In the tech industry, Developer Relations is your surfboard.

But what does a Developer Relations practitioner do? When do we hire one, and who do we look for? In Part I of this series, we’ll briefly answer the basic questions on Developer Relations to lay the foundation for the Part II post on how developer engagement drives international expansion.

What is Developer Relations?

First, a broad overarching definition: Developer Relations (people in the industry often just say DevRel) is the practice of enabling developers to be successful users of technology. People working in this practice sit at the intersection of many functions -- primarily engineering, marketing, and product development. The well known and high visibility DevRel activities are:

• Speaking at a conference or meetup
• Writing blog post about new integrations
• Building demo application to showcase realistic use-cases
• Answering support questions on community forums

I categorized these activities as outbound advocacy. But relationships are a two way street (or at least a healthy one). So to build a healthy relationship with developers, the inbound advocacy is equally important. Inbound advocacy are activities such as:

• Owning product or documentation feedback meetings
• Running developer interviews and studies

Engineering and product can easily get caught up in features they think are necessary. The DevRel team owns the sacred task of echoing developers’ opinions, frustrations, and recommendations back to these teams. And being proactive about it. So instead of waiting until a user opens up a GitHub issue, the team needs to set up office hours, or do outreach to help identify it before it bubbles up.

When to hire a DevRel?

Now we know why DevRel is important, let’s talk about timing. For most organizations, I’d advocate for a DevRel hire before a Product Manager. And if it is an open source company, the priority for hiring a DevRel should be even higher!

First, DevRel overlaps heavily with what a PM can bring to the team. On top of that, they bring additional skills that help an early-stage startup. The marketing, engineering, documentation, and product feedback experience one can bring to a team is valuable. Developer Advocates are also closer to the end user. Working with the community/end-users closely in the “DevRel way” creates a multitude of benefits like:

• Foster community growth and love (seriously, love!) around the project
• Increase early-stage adoption
• Improve product roadmap
• Additional users for testing
• Create marketing plans for content

The list could go on for another page. Yes, a PM identifies customer needs too and defines the product vision. But experienced PMs work at the conceptual level. And working on a conceptual level will not help your users solve practical problems to reach their end goal.

An added benefit is that the DevRel team you build out may very well be the foundation of your future product team. A very natural career trajectory for DevRel folks is to go into a technical PM role after. Why not create some homegrown talent that really understands the product? When the company expands, hire some marketing and sales folks to complement your PM that used to be your DevRel, and you’ll have all the pieces to stride your Series A or B milestones.

As a founder, if you're thinking about hiring a PM and you don’t have a DevRel yet, think again.

Who to look for?

The most important trait to look for is empathy. To keep anyone afloat, DevRel practitioners must understand developers’ pain points and experiences. Developers will face frustration with the documentation, integration issues with the API, or just basic questions regarding the products. But how will the documentation or engineering team know about these shortcomings? The bridge that connects these external developers back to the internal team is propped up by the DevRel team. And the cornerstones of this bridge is built on the team's ability to empathize.

Empathy, in the DevRel context, means to step into the shoes and understand the challenges developers may go through. But when you don’t understand everything, take the time to listen. DevRel needs to create a space or channel for developers to share their feelings and frustrations without the fear of judgement or criticism. Lastly, to always learn and not judge. Challenge both your own organization and your personal assumptions at every step by listening to what developers are saying. This will help you create a healthy relationship with your core audience and discover common ground.

Creativity is another critical skill to have in a DevRel practitioner. It is harder to test this skill since it requires the interview process to be time intensive. (The State of Developer Relations 2020 report shares some great research on this topic.)

Ask the candidate to create a story surrounding the products you have to offer. Pseudocode will suffice, because the focus is on the story built around the products. This sort of interview gives the candidate the freedom to be creative, illustrate their technical understanding, and highlight their storytelling ability. Leetcode-esque interviews provide little insight to a candidate’s ability to serve your end user.

Lastly, if you are the one doing the hiring, be ready to compensate these candidates for their time in doing these take-home assignments; top DevRel candidates are a hot commodity in the job market right now.

Where to place DevRel within your company?

As shown in the survey results below, there is no default or standard reporting structure for DevRel teams. Personally, I’ve reported directly to CTOs and VPs of Product. It would heavily depend on the goals of the DevRel team. My suggestion is to have DevRel report directly to someone within the engineering leadership team (ELT) so they can get buy-in and budget to run their strategies.

Part II Preview

The biggest reason that motivated me to write on the Interconnected newsletter is my passion for international communities. Having majored in International Relations as an undergrad and lived on three continents, I share the founder, Kevin Xu’s curiosity of a future of technology-driven globalization.

The function of Developer Relations sits in the center of many prominent or promising startups looking to expand across the world. So Part II of this series will cover how DevRel is a key ingredient to a startup’s international expansion playbook.

If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox every Sunday. Follow and interact with me on: Twitter, LinkedIn, Clubhouse (@kevinsxu).