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.


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 (twice per week). 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才做反应,而是主动组织office hours或其他“对外”工作,在问题变大之前就发现它。

该什么时候雇DevRel?

现在我们了解了DevRel的重要性,那来谈谈时机问题。对于大多数公司来说,我建议在雇产品经理(PM)之前先雇DevRel。如果是一家开源公司,雇DevRel的优先级就应该更高。

首先,DevRel与产品经理带给团队的价值有很大的重叠。除此之外,DevRel还能带来些额外的技能,对早期创业公司尤其有帮助。他能为团队的营销、工程、文档和产品部门带来的反馈是很有价值的。DevRel是最接近于终端用户的。以DevRel的方式与社区和终端用户互动和合作,可以创造许多好处,比如:

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

还有很多其他好处,可以写一整页。当然,一个PM也会挖客户需求,帮助定义产品的未来。但是,一般的PM尤其是有经验的PM一贯习惯在很抽象的层面做事情。抽象的工作很难帮助你的用户解决具体使用的问题。

先雇DevRel还有一个额外好处就是,你的DevRel团队很有可能是你未来产品团队的pipeline。做了几年DevRel后的一个非常自然的职业轨道就是进入技术PM的角色。为什么不培养一些内部人才为未来做准备呢?当公司扩大时,再雇一些营销和销售人员来补充和协助曾经是DevRel的PM,就会拥有足够的力量达到A轮或B轮的里程碑。

作为一个创始人,如果你正在考虑雇一个PM,但你还没有一个DevRel,那请再好好想想吧。

怎么找到合适的DevRel?

好的DevRel最重要的特质就是“同理心”(empathy)。为了帮助任何用户不被“浪”冲倒,DevRel必须深刻的理解开发者的经历和痛处,无论是开发者对你的文档的疑惑,遇到与API结合的问题,还是关于产品本身的基础问题。但文档或工程团队怎么能知道这些缺点呢?把广大开发者和内部团队连起来,就是DevRel需要搭的桥梁。而这座桥梁的基石是建立在DevRel团队的同理心之上。

同理心,从DevRel的视角来看,就意味着走进开发者的鞋子,理解他们可能会面对的挑战。当你不了解所有状况时,就要花时间去倾听。DevRel需要创造一个空间或渠道,让开发者愿意分享他们的感受和挫折,而且不在意被评论或批评。最后一点就是要永远学习,而不做太多评判。通过倾听开发者的反馈,在每一步都挑战自己公司以及个人的假设。这将帮助你与你的核心受众建立健康长久的关系,并发掘共识。

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

具体的“考题“可以是请候选人围绕公司的产品创造出个故事来讲。Pseudocode一般就够了,因为重点是围绕产品的故事。这种面试可以个候选人自由发挥创意的机会,既能证明他们对技术的理解,也能突出他们讲故事的能力。Leetcode式的面试对DevRel候选人能不能服务最终用户没什么用。

最有还有一点值得一提,如果你是负责招聘的人,要准备好补偿这些候选人“做作业”的时间;顶级的DevRel候选人是非常抢手的。

该把DevRel放在公司的哪里?

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

来源:State of Developer Relations 2020报告

Part II:“剧透”

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

DevRel团队已经是许多著名的或有前途的初创公司的核心,尤其是有全球扩张野心的公司。因此,本系列的第二篇将深入探讨DevRel如何成为初创公司准备国际扩张的关键要素。

如果您喜欢所读的内容,请用email订阅加入“互联”。要想读以前的文章,请查阅《互联档案》。每周两次,新的文章将会直接送达您的邮箱。请在TwitterLinkedIn、Clubhouse(@kevinsxu)上给个follow,和我交流互动!