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.

Source: the State of Developer Relations 2020 report

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).

怎么冲“开发者关系”这股浪:Part I

今天的文章是Kevin Chen贡献的“嘉宾专栏”。他是开源创业公司独角兽Kong的第一任 Developer Advocate,目前在另一家早期开源初创公司smallstep从事开发者关系工作。


  1. 所有事情都是股"浪"。我们目前正处在数字化转型的第三波浪潮中,眼睁睁看着办公技术的第二波浪潮流过(主要是因为疫情的影响),并准备迎接云计算转型的新浪潮(就更不要说还有加密货币的浪潮了)。
  2. 两波连续的浪之间的那段时间一般称为swell period。当你被一股浪冲倒,而与下一股浪之间的swell period很短的时候,从水里一出来的你很可能就被下一股浪头再次击倒。在这个瞬息万变的快节奏环境中被浪花连续打倒,得到的“喝咸水”的教训就是:你已经过时了。

那么,我们如何能在变化和创新的无情浪潮中不被击倒呢?如果要将"冲浪"的比喻进行到底,那不得不提的另一部分就是冲浪板。冲浪板使我们在浪上“冲”起来,即使我们落入水中,也能帮我们浮起来。在科技行业里,开发者关系(Developer Relations)就是你的冲浪板。

但是,做Developer Relations的人到底是做什么的?一个公司什么时候该雇佣他们,又该找什么样的人呢?在本系列文章的第一部分里,我们将简要地回答关于Developer Relations的一些基础问题,为第二篇关于开发者如何推动公司的国际扩张战略的主题做铺垫。

什么是Developer Relations?

先给一个广泛的总体定义:Developer Relations(业内人士通常简称DevRel)是使开发者成为某项技术的成功使用者的实践。从事这项工作的人一般坐在公司里其他部门的交叉点 -- 主要是工程、营销和产品开发。众所周知的、曝光率较高的DevRel活动包括:

  • 在行业大会或meetup上发言
  • 写各种关于技术集成的博文
  • 构建演示(demo)以展示具体的使用案例
  • 在论坛上回答问题


  • 领头带动产品或文档反馈的会议和过程
  • 面对开发者做用户访谈和研究

工程和产品团队很容易被他们认为是重要的功能所吸引,难以自拔。DevRel团队最重要的任务之一,就是把开发者用户的意见、挑战和建议反馈给这些团队,而且要积极主动地去做这件事,不要等到用户都开了条GitHub issue才做反应。DevRel需要主动组织office hours或其他“对外”工作,在问题变大之前就发现它。




  • 促进社区发展和对项目或产品的狂热(真的是需要狂热,真爱!)
  • 增加早期的采用(adoption)
  • 改进产品路线图
  • 增加测试用户量
  • 打造营销需要的内容







创造力(creativity)也是DevRel必备的另一项关键技能。测试这项技能比较困难,因为它在面试过程中需要花很多时间才能评估 (《2020年开发者关系状况》报告在这个问题上分享了很有价值的研究)。




正如下面的调查结果所示,对于DevRel团队来说,目前并没有默认或标准的上下级结构。就我个人而言,我的直接上级曾是CTO或产品总监。这在很大程度上取决于DevRel团队的目标。我的建议是,让DevRel直接向工程领导团队(engineering leadership team)中的某个人报告,这样团队才能得到他们需要的资源去把战略变成现实。

来源:State of Developer Relations 2020报告

Part II:“剧透”

促使我给《互联》贡献文章的最大原因是我对国际社区的兴趣和热情。我在本科时主修国际关系,并已经在三大洲生活过了,我和《互联》创始人Kevin Xu一样,对未来科技驱动的全球化充满好奇。