Summary: In my keynote talk at DevRelCon London 2019, I shared a framework on how to start a developer relations program that was well-received. You can watch it here. This article, building off that talk, shares some best practices on scaling developer programs overseas.

Say you have built up a great developer relations program in your local market and are ready to expand your program to engage with developers overseas who may not speak your language. How and where do you start?

That was me 4 years ago. When I started doing DevRel at Facebook - I was not well-travelled, am only fluent in English, and only have experiences with developer communities in Singapore.

It was a challenge to scale a global developer relations program in Asia, a region that speaks over 2000 languages with multitudes of cultures.

Common ways to scale developer relations programs and why they both aren’t quite right

I studied how other organizations tackle this problem and discovered that the methods categorized into 2 schools of thoughts:

• Copy-pasting the program to a new market
• Find a local partner to design and execute on the developer programs

Both of which are not ideal because:

Copy-pasting a DevRel program ignores local context & affects engagement

For example, it is very common to find overnight hackathons in the USA where alcohol and communal resting areas are provided. While these may be perks in that country, it would be tone-deaf to audiences in other markets, such as Indonesia and Pakistan.

It may also discourage women from participating as it’s not safe for them to be out late, more so if they’re expected to rest in a gender-neutral communal space.

Outsourcing entirely to a local partner affects your effectiveness as a DevRel professional

You know your company’s culture, internal dynamics, resources, and goals far better than any partners. You are the best person to get things done while maintaining brand consistencies globally.

I believe that a company should own their relationships with developers, not a third party. I’ve seen amazing community leaders move away from specific companies because they didn’t like the partner’s management style.

Same same but different is my recommendation

My best practice is to adopt an approach that’s somewhere in-between these two - design a global DevRel program that allows for some local adaptions and create these adaptions with a local execution partner. Then, consistently check-in with the partner to adjust the program accordingly.

To explain it with an analogy, take McDonald’s for example. You know you’re in a McDonald’s restaurant when you walk into one and Big Mac tastes the same everywhere. However, your nearest McDonald’s may also offer rice (in Indonesia), shrimp burger (in Japan), or rubbish (in USA (sorry I couldn’t resist this joke)) to suit local preferences, depending on where you are.

Each McDonald’s restaurant is owned by a franchisee, someone experienced in running local businesses, trained, and supported by McDonald’s headquarters.

Taking that as a reference, a developer relations program should be same same but different globally. It should have the same ethos and value proposition, localized to meet people’s needs, and executed by a local partner who speaks the language and understands the local culture.

The challenge here is getting to the right balance between consistency across markets and localization. While this balance varies for different companies, here are my best practices to overcome culture and language barriers to build developer communities and design effective developer relations programs.

1. Do your online research

This may sound very basic, but it will surprise you how many people don’t do it before visiting a new market. Yes, the purpose of a research trip is to learn about the market. Yes, it may be difficult to find information on the developer landscape in certain markets. However, having a high level understanding of a country before a trip is table-stakes to showing respect and interest in the market.

It’s just like how you read up on a company before a job interview in preparation to build a working relationship.

Pro-tip: Read up about the developer and cultural landscape before you visit a new market. High-level information like major cultural practices, mobile usage, connectivity challenges, and payment modes are easily found on most of the markets with a sizeable amount of developers.

2. Learn from the locals

With the information you’ve gathered from Step 1 and your company’s goals, you can easily come up with a list of you want to learn from the locals.

In my travels, I have not found it difficult to find people who speak enough English to chat with. Sometimes, I’ll invite someone who’s bilingual in English and the local language to join my meetings (in exchange for pleasant conversations and/or a meal). I’m often amazed and grateful for how many helpful folks I’ve met!

Pro-tips:

• Ask for recommendations for people to meet via your social media platforms.
• Find key ecosystem influencers and reach out to them. Sending cold emails is fine!
• Be open-minded, curious, and non-judgemental of others’ cultures. Ask questions, not make comments.
• Ask the same set of questions to different people so you have a clearer and more holistic view of the answer.
• Cross-check people and companies by asking others how they feel about an entity or person. Most people won’t spill the tea, but any tea spilled is good context.
• Be respectful of people’s time. I usually bring some swags to share, hold meetings over coffee and meals, or share community best practices from my personal experiences.

I’ll be honest - sometimes I find it difficult to hold my tongue from commenting on certain cultures that clash with my own beliefs around women’s rights to work and safety. I remind myself I’m here to design developer programs, not to fix a society.

3. Appreciate and observe the local culture

While I can’t speak for other regions, people in Asia generally appreciate people taking part in their cultures through language, clothing, and food.

I would dress like a local, learn how to say simple phrases like hello and thank you, and practice cultural business practices like bowing to acknowledge people in Korea and Japan and not offer a handshake to men in Pakistan and Indonesia. These are how I show respect and interest in engaging with people as a guest in their countries.

One thing that I didn’t expect was how many people appreciated my effort! I’ve literally received applauses after greeting the audience in their language. Obviously, I don’t get everything right. Most people don’t mind if I’ve accidentally committed social faux pas as a foreigner.

Pro-tip: Learn to say simple phrases like hello and thank you to better connect with the audience. Observe local cultural business practices.

4. Find local partner/s

Once you understand a market, its key influencers and potential collaborators, you have enough context to know what qualities make an excellent partner. That’s when you look for local companies or community leaders to work with. Finding a local partner is important as they speak the language, understand the culture, and are more efficient in getting things done than doing it myself.

However, having a superb partner doesn’t mean to outsource the entire program design to the partner. Again, you know your company’s culture, internal dynamics & resources, and goals far better than any partners. Co-creating a program or community is the best approach to balancing between brand consistency and local customisation.

Pro-tips:

• Make a list of qualities you want your local partner to have, including ethos, reputation in market, and track record/experiences.
• Cross-check your prospective partners with the folks you’ve met in Step 2. Find out about their reputation and track record.
• Co-create developer programs with your local partner - you provide the direction and resources, they provide the local strategy and execution.

5. Check in with your local partner/s and developers

Neither a community nor a program is a success at launch.
In fact, I usually prefer a low-key launch event because the grander a launch is, the higher the expectations and attention a DevRel program receives.

As inspired by Mike Tyson, everyone has a DevRel plan until the market punches them in the mouth. Building a successful DevRel program requires consistent iteration and making smart iterations requires collecting consistent feedback.

Pro-tips:

• Design a feedback loop for developers to surface their thoughts. I usually recommend starting with a bi-weekly check in with developers and change the cadence accordingly as you go along.
• Decide on what qualitative and quantitative feedback you want to collect from the audience. Qualitative feedback is great in exploring blind-spots whereas quantitative feedback allows you to track & compare across time periods.
• Provide feedback and updates from your company to the local partner too. Changes within your company could affect how the partner executes.

What are your best practices to scale developer relations programs overseas?

I hope these best practices are helpful! These are the lessons I’ve learned on my DevRel journey and are not an exhaustive list nor a definitive how-to guide. I would also love to hear from your experiences, do share your best practices in the comments section below.

If you’ve found this article useful, subscribe to my newsletter where you will receive monthly emails on my lessons learned as a DevRel professional, building communities, and designing developer relations programs.

✨ Subscribe here: https://bit.ly/updatesfromsha * ✨

* Yes, I’m aware of how much I sound like a YouTuber in the last couple paragraphs. lol.

Image credits:

• McDonald's
• Indonesia Fintech Map
• Mike Tyson's quote