Karan breaks down what it really takes to grow developer programs internationally, based on his experience leading GitHub’s global DevRel efforts. He shares why simple translation isn’t enough and how GitHub adapted its India launch with local initiatives instead of copying global programs.
The key insight: success comes from understanding each ecosystem’s unique challenges, not just applying the same playbook everywhere.
Karan: Just a quick introduction. I'm Karan and I lead international developer relations at GitHub, and what it is, is essentially we have multiple teams supporting developer ecosystems around the world, and my team helps with the India ecosystem, Latin and a few other regions, et cetera. I've been a part of the DevRel role for I think more than a decade or so, and started off as engineer, writing a whole lot of application, then got interested into writing SDKs and things like that, and then moved into this specific role. Yep. Okay. So I've been across multiple different roles within DevRel as well, like many of on the advocacy side, on the programmes side where you're kind of running developer programmes and various other initiatives as well.
Quite recently, at least this year, I've also had a really, really nice privilege to do a whole lot of executive keynotes as well. So I think it's been, yeah, just this year it's been very, very honour and privilege to present as a part of Satya Nadala's keynotes across Southeast Asia and Bangalore and other regions speaking about GitHub, and also as a part of GitHub, CEO, Thomas Keynotes, showcasing all the things which are new, et cetera, and telling the story of what GitHub is up to. So in this specific talk, what I really wanted to do is, while having some of the conversations, I realised not just in this decon, but also previously, that there were many questions coming up saying that, okay, we are having these initiatives and programmes here or there in India or in the US or Europe or somewhere else. How do we take it elsewhere? How do we grow this or what do we have to do, et cetera. Right now I want to share a few key things related to that in my experience of really working with developer ecosystems around the world, and for all of you as DevRel professionals, what it is that could be very, very helpful. Alright, let's test this. I'm fine, I'll run it.
Okay. Oh, there's a bit of delay or is it?
Okay, so I'll just be covering really three key things. Apologies for my poor choice of using dark mode for my slides. Might be a little hard to read, but I'll be talking about why international, what the ecosystem is like, and also how to really execute. Alright, just three key things that I'll be going over and giving you some more insights on. I know you might have some questions either related to GitHub or related to just how do you do DevRel internationally, et cetera. So I'll definitely keep a few minutes towards the end for the q and a, et cetera, so we can go over that. Alright, so let's go into the why piece. Alright?
Now, how many of you really are thinking about, okay, I want my DevRel programmes in other countries or regions as well? Okay, many of you. Alright. Now there are a few key things really to keep in mind and these might seem like, alright, fine, this is like, yeah, we know this also. Alright, but practising it is very, very important. I am sure that many of you in the ecosystem, you would've seen all various different kinds of, how do you say, initiatives, programmes, which are very similar, but when you start practising some of those things, it becomes very, very different in your own context, et cetera.
I think I need to angle it or something. Do you mind moving the connector just on this side so it's in line of sight? Okay, let's try that. No. Okay, thanks. I'm just going to yank this whole thing out and then try, all right, while we're just again getting that sorted, right? So one of the first things that's really important is to think about why you are looking into an international market, alright? This is very, very, very important.
That is defining why your international market matters. Now, this could be multiple things. At first you might be thinking that, okay, this is something which is like, alright, fine, we want to have presence elsewhere, or we want to have users from here or here or here, et cetera. Most often the challenge is that this is probably not clear, okay? I don't know what happened over here.
Yes, yes, please. I need help with that. Oh, there it is. Alright. Oh, someone did that or was it me? Fine. Alright. Okay.
So the first thing really is whether is your product ready? Now, when I say is your product ready, you might be thinking that, okay, fine, well of course we are a developer product and then anyone can start using it, et cetera. Most often, the very tricky answer that I get from people is that, of course it's for all developers, anyone can use it, et cetera. But have you thought about the nuances of what it means for developers across the world to use it? Have you thought about things like language challenges? Have you thought about things like local restrictions? Have you thought about things like regulations which make use? Have you thought about things like sometimes network blockages and things like that?
Have you thought about things? What does the workflow look like for developers when they're using their product? So there are multiple things which come into play, which defines is your product really ready to go into different regions? And when I say different regions, I don't mean to say that, okay, India to X country or X country to India or US to X country, wherever, be it wherever you are thinking about it. So really look very closely into what does your product look like, alright? And of course there are multiple ways how you can do that. You can do that through some of your user research or study or talking to people, et cetera. Alright, next slide please.
I can. Alright, let's try what I was talking about. Define why your market matters and it's not just about going international and saying that, okay, I'm going to look at this market or that market or this market.
Think about strategically, why is that important? Say you pick something like Latin America or you say that no, I want Singapore, or you say that no, I want the UK or something like that. Why is it that it matters? Understand that sometimes it probably comes from your leadership or sometimes it comes from elsewhere from insights that you get, but really define it that this is important because we have say most of our customers from here who are interested, so we want to grow that market. Or you could also say that, okay, this market is important because most of the end users who are using our developed products are based here because of which we might get some more feedback or growth, et cetera. So defining that why your market matters becomes very, very important. Otherwise you'll just be shooting in the dark thinking about that, okay, this is important, but you might be working things in a very, very similar way. So think through why does this matter and not just across anywhere or so, but pinpoint.
So those were kind of the couple of very y pieces which are very, very important when I said whether your product is ready or not, and also whether the market matters or not. Now, the major part that you would also have to do a lot more thinking into is what does that ecosystem look like? Alright? Most often I noticed that in the developer product ecosystem, everyone tries to reach developers across the world through social channels, alright? Probably they're doing a different tactic like, okay, let's do some boasting in this specific region, or let's do some more events or conferences in this region or something of that sort without really understanding the ecosystem itself. Alright? That's very, very, very important to know what does that ecosystem look like? And when I say what, there are a few things now different developer ecosystems have very, very different strengths and maybe even weaknesses.
Alright, what does this mean? So for example, if you look at a certain, say even take a certain city within India, you'll find a whole lot of developers focused around certain technologies or certain skill sets. Or if you take a look at certain other regions, even in Southeast Asia you might be seeing that certain ecosystems have really good developers around this or that, et cetera. So really understand as to what are these different strengths. And what I mean by that is that you might be thinking that, alright, fine, a project like Kubernetes is really, really awesome. It's helping everyone, but imagine taking that as a project to an ecosystem which is very heavy on PHP or which is purely heavy on frontend developers and the JavaScript ecosystem. So your approach and messaging could be very, very different to that ecosystem. So think through as to what is the strength of this developer ecosystem developers are the same.
What they work, how they work, how they approach to things, but the ecosystem on what and what kind of support they're getting. And that is all a function of many different things. It's a function of what kind of demand there is for developers, what kind of products and services they're working on and multiple other things. Alright? So keep this in mind that the ecosystems are different. It may not always be the same.
Okay, did I skip a slide? No. Okay, can you go back? Alright, yeah. Now I'm going to skip, are you doing this as a signal manually when I click your tapping? Yeah, that will be helpful. Alright, so one of the, again, important things where most often folks miss out on is there are many multiple industry reports which talk about the developer ecosystems. Alright?
Now, sometimes it might so happen that your leadership or people way above are probably thinking about this, looking at the industry reports, et cetera, and define the why market matters part, but they might probably skip off on what the ecosystem is like or so that is where it might probably help you sometimes for you to read these own industry reports yourself to see if there are more insights that you will get about what the ecosystem is like. Now, when I say that, it could mean that in certain regions you might have say academia provide a whole lot of support to developers.
In some regions there is probably very, very strong government policies which encourages developers. In some countries there are really, really big service development centres which help developers grow. So there are multiple stakeholders like these who are probably changing and supporting how the ecosystem really grows. So many of that is usually captured in the industry reports. If you already have some of your users of your product from various different countries or so, look at your own data that will be even more insightful, even if it's a small sample set, even if it's just 10% or 20% of your users or developers are from regions that you are interested in. Understand what are their characteristics and how they're using your product, how they're behaving, and even talk to them to understand a little bit more. Alright? It's important to kind of understand what is the lay of the land and what the ecosystem actually looks like.
And I'm calling this out a bit separately. What happens, what I've seen a very, very common pitfall that many of them do while looking at, okay, I want to focus on this country or this region, et cetera. They look only at specifically developers, they don't look at what else is happening around them. And most often there are a whole lot of different complex interplays which are there, which influence us. Now, for example, what I mean by that is startups. Now you might think that okay, you are focusing on developers and what they're using, et cetera, but probably the startup culture is playing a very big role in the skillset of what developers are using, the tools they're using and what they're actually producing, what they're doing in open source, et cetera. Alright? Similarly, there is probably a really, really big product focus which a specific region has.
Even if it's a very, very large company which has offices in multiple places, that specific company in that specific region might be focused more on a single vertical or so because of which your developers in that region might have a very different strength and might have a very different ecosystem. So essentially if you go with the mindset that it's working here, so it's going to work there because my audience is the same, it's going to work over there. It'll be very, very similar to thinking, saying that, okay, I can take an auto over here so I can take an auto there as well. Alright, because it's available also, not really the case, as we all know and talk to people, talk a lot, talk a bit, but listen a lot. Alright? I see this happen very, very often because we all as very, very passionate devil professionals, we tend to talk a lot.
But what is also important, especially when you are thinking about some other regions where you want to enter into et cetera, is listen, what are they telling you and what are they not telling you about what's happening? And not just the developers who are using your product, but also talk to the people who could be potential users and also people who are around this ecosystem as well. People who are in the academia, people who are in startups, people who are in enterprises, and all of these people just to get an understanding, alright? Because this is something which will really, really help you to get a whole lot of qualitative feedback. In the previous slide I mentioned saying that look at the data where you get some quantitative idea, but also speaking to people will give you a whole lot of qualitative insights as to what's really happening and what is not really flying well or what could be a whole lot more better. Is there an opportunity in the way that your product works here also, et cetera, right?
Did I cover that? No. Oh, you are going way forward. Yeah. Okay, next. Alright, so let's go back to the how piece. I spoke a little bit around why some of defining your product, whether it really makes sense for the market or not matters, and whether how you define whether the market matters or not and what you really need to think about. How do you go about it?
Alright, I can already see a whole lot of people interested in this part, but probably not the previous two. But I'll tell you the success of how you do something is really defined on why you do this. I'm sure you might have heard of all of the term called a pray and pray, alright? You spray things everywhere and hope something sticks and then see that, okay, I'm going to try this thing everywhere across all regions and just see what happens. The problem, what happens is that you might be successful or you might fail or you might have some learnings, but either way you won't know why. Alright? Which is why I spoke about the why and the what now coming to the how piece is where I need help from my manual slide clicker.
Thanks. Alright, I mentioned about this, it could be different. So what I intend to say is that please don't try the what works here could work over there as well, alright? Because your product messaging would be very, very different and the way it is being used could be different. And also what is the key problem that someone is trying to solve along with your product also could be different. So just give a little bit more thought about when you're thinking about tactics and techniques, how this could be different. A very, very simple example for all of you is that you go into some of the other regions outside of India and think about having a meetup on Saturday not going to work because that ecosystem is different where Friday evenings or Thursday evenings might work better or late afternoons could work better rather than Saturday mornings. A very simple example.
Similarly, there are a whole lot of nuances where people probably, if you are in events or so they might want to start off with lunch and then continue in the evening rather than end with a lunch or end with whatever is evening snacks, et cetera. There's very, very different nuances, which you might easily probably get wrong when you are thinking about how to execute some of your tactics in other places, et cetera.
Now, I mentioned these two things separately, whenever you are hearing about where things happen in various different markets, you'll just hear about localization, localization, localization. I mentioned this a bit differently, I mentioned this localise and customise. And the way that I would differentiate this is that you are localising something, means that you are making it easy for someone to use either your product or being a part of your initiative or being a part of your programme. What that means is that having this developer product in a local language or with certain other aspects, which are very, very unique to that developer community, but you also need to customise need not your product, but it could be your initiative or it could be your programme. And what I mean by customise is that say your thinking about say student programmes for that matter. Alright? You might be thinking that, okay, in India I'm thinking about student programmes for people going to college and things like that, et cetera.
And you might be surprised that if you go into certain other regions and markets, you'll see that it's not just your undergrads, but post-grads and even doctoral fellows are very, very interested in part of being initiatives and programmes. If you don't customise, you are probably letting out a very big audience out. Or similarly, you might be surprised to know that a lot of high school students are interested in a whole lot of development or usage of developer tools and products, which again might be very, very surprising. That's not localization, that's customization either of your initiative or your programme. Making sure it's customised and very, very appealing to that specific audience as well. Buck, I think you skipped a slide. Yeah, okay. Is also to work with a whole lot of experts and partners.
Now you might be thinking that, okay, I'm going to get started and I'll do this in this specific region.
I'll go travel, I'll get a whole bunch of my community members to do this, or I'm going to do some stuff on social, I'm going to get a few people who are very, very well known and all of those things, all of that is fine as tactics. But what's really, really useful for you is kind of going back a little bit into our discussion yesterday when we were talking about metrics is what are you trying to achieve in this market? Alright, while you might get a whole lot of qualitative inputs when you are travelling yourself, getting your community members, et cetera, but if you are really looking at good adoption or feedback or whatever else it is, it's very important to work with some of the local partners and experts because they might have much deeper insights into how the community and the ecosystem works and what really ticks them, which would be very, very surprising. And this is a strategy that so many organisations use as well and partner with very, very specific partners and experts. When I say experts, again, it doesn't have to be only content creators or influencers. It could even be advisors, it could even be startup, CXOs and other kind of people who know the community very, very well as well.
And one thing that I have seen despite of all of the things that we do right, foot on the ground, ears to the ground is what works and helps a lot. Alright? Now I know it's not really easy initially to think about, okay, or can we be there in this specific region every time we are thinking about and initiative or a programme? It's not easy, but I think the success is really when you're able to drive enough amount of adoption and enough amount of feedback or whatever else you're looking at such that you have a team member in that specific region and also keep listening. What I've also seen is that many people say that, oh, okay, we have this initiative happening, this programme happening in this region, and then they forget about it. So iteration is very, very important and listening to what developers are telling you, you might get a whole lot of different insights from various different kinds of developers or stakeholders within that ecosystem as well. So I mean this is the gold standard that ideally you might want to achieve of having very local presence in order to reach developers, be it through initiatives or programmes or through multiple other ways. I think that's all that I had, but I want to save a big amount of time for any of the q and a.
I'm sure you might have a whole lot of questions as well.
Audience member: Hi Karen. Very good doc, thank you for that. I would like to know your experience when GitHub came to India. You basically stretched your point in the talk of localization. What challenges GitHub faced when he came to India and how did it's one of the biggest community India have on the GitHub right now? Didi has any challenges with the localization and what part of that problem has been solved?
Karan: Yeah, good question. So I think even before we had the launch of GitHub in India in Feb 2020, not just us, but because of a whole lot of industry reports as well, everyone knew that India is a really, really growing community of developers and it was something almost like a no-brainer that hey, we have to help support the community in India. One of the things that was interesting is that a whole lot of, from either a product perspective or even from an initiative or a programme perspective works really well in India as much as it would work in any other region. Mainly because most of the developers have very good fluency with English. Thinking about localization, if you go into some of the other countries where English is not even a second language and the fluency and proficiency is very, very less localization becomes very, very important.
Say for example, if you go to any of the Spanish speaking countries or you go into Brazil or you go into greater China region or you go into Japan, all of these places, localization becomes very, very important. So in India, most of the developers of course, and we of course as even a population are one of the largest English speaking populations. So localization wasn't really a challenge, but of course we brought in a whole lot of customization for many of your initiatives and programmes. So to give you a few example, when GitHub launched in India in Feb 2020, GitHub sponsors wasn't available in India and we brought GitHub sponsors to India customising it for the needs over here. And also we had various different programmes as well come in. And similarly we had GitHub's task programme, which is like our MVP programme where we again brought that to India, we brought some new programmes as well meant for the community over here.
For example, initially we launched something as a GitHub open source grants, which was like a one core grant for open source projects and maintainers. And this was only in India, this wasn't there anywhere else. It was a thought process which came in over here as well. So there was, in terms of challenges, the only thing which I can think of is that it's such a large developer community, I'm so much of an opportunity. So how do we support this large community with whatever is the limited resources that every organisation has? So ensuring that everyone is supported was the challenge. Yeah.
Audience member: Hi, my name is Tanay. Thanks for the talk. I basically want to ask you about, see there are multiple programmes that you run. So you mentioned that basically when you launch a programme, so multiple people join the programme. So apart from the signups, right? When you launch a programme, there is definitely some excitement. People join signup, you make sure that they participate, contribute, stately end of the programme. But what happens is that after the programme is done, how do you engage with that audience?
How do you make sure that they stick around for a long time? You make sure that when you run the second programme, a new programme, the same community participates again and stay for a longer period and do not go out as soon as the moment you finish the programme. So how do you make sure that people stick around within the community?
Karan: Got it. That's a good question. So see there could be multiple objectives for any developer programme. Alright? I think what you're referring to is a programme where you want to drive continuous engagement. Alright? So most often, if you have seen a lot of the programmes that we run, we want to empower developers as much as possible through the construct of the programme itself. What I mean by that is, say the example of the opensource grants, which I mentioned about, which was a one crow grant and we had a programme around it where we invited applications, there was a jury who was looking at the applications, we provided some funding and everything else as well.
Alright. Now there were many, many individuals maintainers projects who got funded. Now our objective was to really empower them with whatever funding is needed so they can kind of go ahead and then create that impact and back to the open source ecosystem.
Alright? And that was accomplished within the programme itself. So we weren't really looking to say that, okay, how do we get again, all of these grant people into a next funding round? Because they, within that programme structure itself had already reached a level where they started getting funding from other sources as well where we've acted as a catalyst for them for both their own product as well as for GitHub as a platform so that the objectives of what we wanted to do was accomplished within that one programme itself without bringing and re-engaging all of those people into the next programme. That's first thing. The second thing is also that we make sure that we have continuous open channels for communication and engagement. And of course we don't break or burn the bridges anytime. An example here is that the GitHub task programme that we run, it is one of the most exclusive MVP developer programmes in the world.
And there are less than a hundred GitHub stars across the world. I think it's like 70 or 80 or so, very, very exclusive compared to so many other such kind of ambassador programmes. And it's by design because we want to make sure that we are really recognising and also seeking insights and also providing the support from the people who are providing the most impact to the community as well as to the GitHub. And there are new stars who are coming in, stars who are graduating, et cetera, and we make sure that there are always open communication channels for a certain programme or so where people who have graduated from the programme or people who are alumni or people who have kind of completed the programme, et cetera, we continue to engage them wherever there are opportunities. So I think it's, to answer your question in a very nutshell, it's all in how you design that programme structure such that it's not like, okay, you do this, it's finished and then it's done. We have achieved that objectives, et cetera. Our objective whenever we are designing the programme is to make sure that that impact is delivered, even if probably some of these numbers are not reachable or so, et cetera. If that impact is delivered within that one programme itself, we have done all everything that we had to do.
Yes.
Audience member: Give me one moment, I'll just finish this question and pass it over the mic. Yeah, so I'm just curious on a different line of thinking. That is, when developers use GitHub nowadays, I mean developers is just beyond a set of repositories. We have GitHub, CLI, we have GitHub actions, a lot of things coming in. And when we run programmes usually as products which are startup or bit more mature state, we also collect feedback and share it with product teams. Now I was just wondering and super curious for products which are as mature as GitHub and when we collect feedback from a lot of different engagement programmes that you run at GitHub, how does this feedback loop or feedback cycle start and close? Right,
Karan: That's a good question. So one of the things that we do is we have a very open community discussion group. So if you go to GitHub community, you'll find discussions around each product area and things like that where people are continuously sharing feedback around multiple different areas of the product, like how you mentioned price, probably an actions or a pull request or something that's happening and the product managers spend quite a significant time going through all of these feedback items. It's maybe not something which is as much as they would like to because of the volume, et cetera. And that's where our function and our role as DevRel folks also come into play. Because we are foot on the ground, we have ears to the ground a lot more than the product managers. We are able to do a first level of triaging per se, and say that okay, we are seeing a whole lot of this feedback which is coming in and in some instances probably we are also seeing this for ourselves and pass it on to the product manager because there is a whole lot of trust from the product team, from the engineering team, and from all, even from the design team, et cetera, in the role that we are performing.
Some of that feedback gets addressed very, very quickly. There was a very similar feedback that we got where someone shared about a very, very minute thing around the pull request experience and we saw that, we noticed that so that, oh, this is interesting, it's valid, passed it on to the product and engineering team and within one day it was fixed and that developer was super happy. Oh, I just mentioned about this yesterday and it's already fixed today kind of a thing. So we try to again iterate really, really fast and we do tens to hundreds of ships every day to the platform, be it these minor fixes or something that we got as a feedback, which is probably a very small thing or so, et cetera. So we kind of try to keep that agile and for us as several people, we help the product engineering teams with that first level of tragedy saying that this is real big feedback. And then they go back and then look at as to, yes, we are aware of it, however it was not addressed because of X, or it's like, oh, this is really new, we are going to consider this, et cetera. So we have that open forum where we are very, very open for feedback and at the same time many of us are also open and help make that happen. Think Ram
Audience member: The question. I think that's the end of the session. Oh cool. Because we are late by a little bit, so that's why we just wanted to join this. No worries. Thank you. So if you want to connect with current, please do connect with him later after this talk as well. Yeah,
Karan: Yeah. So in case I'm not around, feel free to reach out to me on email or any of the social networks. You're connected and happy to reconnect anytime. Thank you. Thank you so much.
MC: Thank you so much Karen.