Surfing the Wave of Developer Relations: Part 2

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?

Three-C Approach

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.

Collaborate Excessively

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.

Commission Globally

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