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.
In Part I of this two-part series, I discussed the fundamental purpose of Developer Relations (DevRel), and outlined basic structure and strategy for hiring and reporting.
Most of what I touched upon in Part I echoes existing DevRel literature and blog posts. What few people in the industry have talked about, and coincidentally also what attracts me to DevRel, is the pivotal role the function can play in a startup’s international expansion playbook.
So in this Part II, let's talk about why DevRel benefits international expansion and my three-prong approach to delivering said benefits.
Meet Me Where I Live
Before we dive into the international expansion playbook, let's take a look at why we want to expand across the world. DevRel practitioners are focused primarily on the success of developers.
Where are these developers located?
Ben Frederickson created an awesome blog post that helped visualize where in the world developers live. He used the GitHub Archive to get a list of all the GitHub users that have had any public activity in the last 7 years. This gave him roughly 15 million GitHub accounts, 2.3 million of which had locations listed on their profile. With that data, he created some insightful visualizations:
Displaying top developers on a map pushes a simple narrative: developers are nearly everywhere, but predominantly in North America, Europe, and Asia. But if we filter and sort them into accounts per 1 million population or accounts per $1 billion in GDP, the results may surprise you:
So if we want to engage and sell to these developers, we have to meet them where they live. To do so, we'll need to update our international expansion playbook.
Have We Met Before? - A Short Story
Quality DevRel is best illustrated with people-to-people stories, so I’ll share one of my own in Shanghai, attending KubeCon China while I was working at Kong. It has been seven years since I last set foot on that self-devouring metropolis.
Seven years and DiDi has devoured taxis.
Seven years and WeChat Pay has devoured cash.
And seven years since I devoured a lamb skewer there.
So familiar, yet so new and strange. "Have we met before?" I thought to myself.
KubeCon China, a technical conference on cloud technology that draws in thousands of attendees around the world, was flooded with innovation, free swag, and surprisingly relationships. Conferences play a big role in most DevRel strategies, so I was no stranger to the scene. But seldom do you meet the same people. One hour into the mania (which is the only way you can describe KubeCon), a man walks up to me.
So familiar, yet...
"Have we met before?," He blurted.
It's Good To See You Again
I share this anecdote to highlight my favorite outcome of a successful DevRel program: community. During that trip to China, we found ourselves overwhelmed with local name recognition. Kong had not invested much in the region, and attending conferences and hosting local events was a means to gauge local interest. So it surprised me when 60% of the folks I talked to already knew about our products -- more than the 45% recognition rate at the European and American KubeCon.
So why were the regional numbers so high in China despite the absence of investment? Many people cited events or content that traced back to the DevRel team. Our strategy was simple: create a community of successful users.
I found some insightful statistics on emotional reactions from Phillip Adcock’s work, a consumer behavior and purchasing decisions expert:
- Emotional reactions are 3,000 times quicker than rational thought.
- Emotional parts of the brain process sensory input 5 times faster than rational thought.
- The persuasiveness ratio of emotion to reason is 24:1
A pillar of any given community is emotion. So by structuring your DevRel strategies around building an international community right from the get-go, the company will see the following benefits:
- Reduced product churn rate
- Decreased barrier of entry for international markets
- Increased sales efficiency
So how do you build an international community to kickstart, or fuel existing, international expansion efforts?
My Three-C approach -- Code Clarity, Collaborate Excessively, Commission Globally -- tackles three separate pillars of a company: Engineering, Marketing, and Human Resources. Did I mention that DevRel is a cross functional role (See Part I)? Each approach is designed to help DevRel build a stronger community, which in turn will benefit the organization when expanding abroad.
Code (or Product) Clarity
The first approach is clarity, which is a joint effort between DevRel and Engineering. I will predominantly focus on code clarity because I specialize in growing open-core companies. Note that this approach will still work for Developer Relation teams built on closed-source software, but the focus shifts from code clarity to documentation and product UI clarity.
Programming languages come in many shapes and sizes. Different communities/countries adopt and prefer different languages. But fundamentally, the logical statements that exist in every programming language are the same, and clean code gives developers an idea of what you're trying to achieve. So having a crystal clear codebase allows developers from any corner of the globe to understand and contribute. A codebase people understand and can contribute to will help bring them into the community.
But how can a Developer Relation practitioner enforce code clarity?
The DevRel team needs to work with the engineering team. The key responsibility that falls under DevRel is surveying contributors and users for code feedback and enforcing those feedback.
Getting actionable feedback is important but then working the feedback into the engineering team is another challenge. This is why I said in Part I that having the executive leadership team (ELT) buy-in is so important. So hypothetically if your engineering team is unwilling or just incapable of helping, what should you do?
First, send them Part I and II of this blog post series, so they understand the value of DevRel. Second, police the open pull requests and issues on GitHub to ensure that newcomers are aware of the expectation for code clarity. This involves asking for changes if any code is unclear or deviates from the style guide. Lastly, work with engineering to see where code documentation or tests are lacking. Both documentation and tests are a great way for people to understand what the code is doing. And if need be, roll up your sleeves and write some integration or unit tests. It’s never a bad thing to have more test coverage.
If you alienate users, your community will be divided. By taking advantage of the universal nature of programming languages, Developer Relation teams can overcome the biggest barrier to building international communities: human language. Take advantage of it and really hammer home code clarity.
Working alongside the marketing function, DevRel needs to be the ones extending the olive branch. My golden rule is if it is something that your communications team is looking at, you missed an opportunity along the way. Because communications (or PR, public relations) is, more often than not, reactive in nature. Something bad happens, put the PR team on cleanup duty. Something good happens, get PR to make a big push about the event. However, being reactive is not the right approach for DevRel when trying to build an international community. The community will not cross the Pacific and Atlantic Ocean to work with you. So you have to go to them and ask to collaborate. This starts at the lowest, most grassroots level.
First, collaboration with code contributors. My favorite way of doing so is setting up pair programming opportunities or open pull request reviews. This gives the code contributors a way to feel invested in the work they put in and that their work is seen by maintainers.
Second, focus on collaboration with users. Collaboration with users can take shape in a lot of ways. The key is to make users feel heard. Taking in feedback is the bare minimum. Implementing the feedback is what will really earn the trust of a user. Advocating for the user’s feedback in internal product discussions is a key DevRel responsibility. Lastly, go the extra mile and get the marketing team to highlight said users. Whether it is on your website or a newsletter, give recognition when recognition is due.
Lastly, focusing on collaboration with content creators. Content creators could mean two things: 1) community users, and 2) company users. Community users who want to create content are a great story to tell because it’s the most authentic to other readers. So Developer Relation needs to actively seek out these users. The best place to start is to target outspoken members of the community and offer them a platform to voice their thoughts. Be sure to offer help with editing and/or co-creating content. Then they're not burdened with too much work and more willing to collaborate again in the future. Content collaboration with other companies is usually a win/win since both companies get more visibility. However, it may be hard to get other companies to invest the time or resources to co-create content. The easiest way is to see if the company has a DevRel team. Trust me, they'll be excited to hear from you. (Shameless plug: if you have any content ideas related to PKI (public key infrastructure) or certificates, I'd love to collaborate with you!)
Needless to say, all of this should be a global strategy because developers are global to begin with. By collaborating on a global scale, the DevRel team builds social capital around the world, which translates to a larger community that is key to your international expansion playbook.
The last one is pretty simple: hire from around the world.
The diversity of the organization will impact the diversity of the community it is trying to build. So by working closely with the HR team, DevRel can ensure that both the internal and external folks are a true representation of developer diversity. While companies understand that you need to have a more diverse workforce, many are not thinking broadly enough. Diversity locked within a single country’s border is really not sufficient in a global technology market.
According to a 2018 McKinsey report, companies in the top-quartile for workforce diversity are 33% more likely to outperform their less diverse peers. But the main focus for DevRel is not to focus on profits, but to build communities. Thus, focus on hiring a DevRel team that is global and diverse. A diverse team will help foster a diverse international community. A diverse international community will bring revenue from customers around the world to keep the company growing.
Community Driven Strategy
Given how diverse and global developers are, startups looking to scale cannot place international expansion as an afterthought.
DevRel should be prioritized in the seed or series A round of funding. Most companies this size will not be selling on a global level yet. But foundations are important, and we can build that foundation by getting our DevRel team to create code clarity, collaborate excessively, and commission globally. And when the time comes for the company to expand and start capturing global market share, your sales team will be greeted with a familiar voice.
"Have we met before?"
Yes, we have.
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).
我分享这段小故事是为了强调成功的DevRel最有价值的产出结果：社群。在那次中国之行中，最大的发现就是产品在当地的知名度出奇的高。虽然Kong在当地的投资不多，参加这种大会和举办活动也是衡量当地开发者感兴趣程度的一种手段。在大会与参会者交流时，有60%的人已经听说过我们的产品，这让我很吃惊 -- 比欧美KubeCon大会45%的知名度还要高。
获得有用的反馈是很重要的，但说服工程团队吸收这些反馈又是另一个挑战。这就是为什么我在第一篇中提到，得到公司领导班子（executive leadership team，ELT）的认可是极为重要的。那假设工程团队的同事不愿意或没有能力提供帮助吸收反馈，那该怎么办呢？
首先，把本系列博文的第一和第二篇发给他们，让他们了解DevRel的价值。第二，监督GitHub上所有开着的pull requests和issues，以确保新的开发者了解对产品代码清晰度的期望值，这包括在任何代码不清楚或偏离style guide的情况下直接进行修改。最后，与工程部门合作，看看文档或测试在哪里有漏洞。文档和测试都是让开发者理解代码该做什么的好方法。如果需要的话，卷起自己的袖子，亲自写一些集成或单元测试，毕竟扩大测试覆盖率永远都不是件坏事。