How to scale a developer relations team

In this talk from DevRelCon London 2019, Google’s Uttam Tripathi shares practical advice on how to scale a developer relations team to meet your programme’s growing needs.

Transcript

Uttam: My name is Uttam Tripathi. We’re gonna talk about scaling your Dev Rel. This is my second DevRelCon. I was in San Francisco in June. It’s really heartening to see how the practitioners of dev rel as a new craft, fairly new craft, right? Like in the morning we talked about not more than 15 or 20 years old as a practice is growing. It’s really heartening to see the work that DevRelCon, Hoopy, many of the other partners are doing to enable this. So I would actually like to start by giving a round of applause to all the organizers of DevRelCon London – Carla but – everyone is just – reviewing 250 talks, selecting the best content, it’s not easy. So it really is a remarkable feat.

Scaling your Dev Rel. As I was preparing for coming to DevRelCon London, one of the topics that came up as a suggestion is, many of us are really starting to build our own dev rel teams and practices. And there are tips of tricks that some of us have learned over the years. And as we grow this community, it’s important that we actively share. I also want to start with a disclaimer. All the tips, tricks, tactics, and strategy I’m gonna talk about is my own personal impression and opinion. It’s not related to, it’s not a Google’s point of view on how you should be building your dev rel. It’s literally my own view. And it might also be contrary to what some of you think is the right thing to do when it comes to dev rel. So with that disclaimer, let’s get started.

And I’ll start talking a little bit about my own story, the serendipity with which I ended up in dev rel. I never, if you would have asked me 10 years ago, dev rel, I actually didn’t even know that something like this exists. But here I am now talking about dev rel and working in this profession. I was born and brought up in a Northern Indian city of Kanpur, a city that grew in British India in the 1800s and 1900s really as a garrison, as a cantonment for military in The British India and also as an industrial city. At at one point in time, the city had a huge textile industry with scores of textile mills across the city. It was really a magnet for people to come in and get employment.

This also continued post-independence. India got independence in 1947. So through the ’50s and ’60s, the trend continued. At that point Kanpur was the second-most important city in Northern India, right after Delhi. For cricket fans in the room, it’s also an important city from a cricket map, at least from an Indian point of view. One of the first cricket stadiums in the country was set up in this city. And India registered their first Test victory against Australia in Kanpur in 1960s.

But then something changed when it came to 1970s and ’80s. The textile industry, which was providing a lot of jobs and employment suddenly started to struggle. A lot of those mills were shut down. That led to massive unemployment. The city that was a magnet for people, not just in the town and the City of Kanpur to get employment, but also from the neighboring towns and cities to come, it was all of a sudden struggling with unemployment. People who were skilled, who were skilled workers, trained workers couldn’t find job. And then that trend continued in ’80s and ’90s. That was the phase when I was growing up in the city. And while I had the privilege of quality education, I was growing up in this environment where I would see youth struggling with finding a quality jobs after they’ve finished their education.

So in that mode when as a growing kid, you play cricket, of course everyone in India plays street cricket in 45ºC in the summer, you come back in the evening and you are contemplating what your career move would be. In high school, I saw Maths and Science as kind of a sure-shot guaranteed way for a more secure career option. That gravitated me towards pursuing Science and Maths as a stream. I was lucky enough to eventually go to IIT where I studied Computer Science, Bachelors and Masters. But a lot of those formative years kept that memory with me in terms of why it’s important to not just have talent but match it with opportunities where the talent is to really grow a much more thriving ecosystem.

After I graduated from IIT, one of the firsts job I got into was Amazon. I was the software developer at Amazon working on both back-end and front-end technologies, building display-ads solutions for Amazon’s publishers, affiliates. The idea being you display ads on your website, you drive traffic back to Amazon’s retail website. This really taught me a lot from a technical point of view. What does it really takes to build scalable infrastructure supporting literally millions of visitors coming to your retail website? And during holiday season, it really goes through the roof.

But one of the things I was starting to already miss, for me, I wanted to be in an area which is an intersection of technology and business. And while I enjoyed being behind the monitor and deploying code, I really wanted to be also involved in the business side of things. That led me to pursue MBA fairly early in my career. And then the switch happened on the other way. I went into management consulting right after B-School, something I did for one year. But the swing was too much on the other extreme. And I have a huge respect for management consultants. You learn so much in the profession.

But I started to feel I was not being technical enough. I was focusing a lot more on business side of problems but not really focusing on how you solve for technology. Luckily for me, and this is where I talk about serendipity, Google reached out. They were hiring for the first Dev Rel Program Manager in India. And literally I think the second Dev Rel Program Manager in all of India and Southeast Asia. And they’re like, we have looked at your profile, because I think I applied for Google for another role, that role is not available anymore, but would you be interested in considering this new Dev Rel Program Manager? And this is 2011 or 12. When I consulted my mentors, they said it looks like a marketing role. You should maybe contemplate it because one of the reasons you were looking for a change is you feel you are away from technology for quite a bit. I talked to the hiring manager, he’s like, it’s not marketing, we are part of Product & Eng. You should give it a shot.

So with serendipity, if I was not enjoying what I was doing at management consulting, I took the chance, worked for Google in India for four years and then for last five years I’ve been working with Google in Mountain View. This has also given me the opportunity to work on the ground with developers in India, and Southeast Asia because for the brief period of time I was leading the team for all of Southeast Asia and more recently working with developers in Americas. A lot of my experiences when it comes to scaling comes from those experiences when you are the only person in the region trying to work with developers across a vast market. What are some of the challenges you face?

This brings me to my current role at Google. I currently lead the team that works on global programs for developer ecosystem. Because of the way our team is structured, we have regional teams in key markets. So all of Americas also is part of my responsibility. The constant struggle I had was scaling. I never had enough people on the team, I never had enough budget that I needed. And I think that’s a good problem to have because once you add those constraints, that really forces you to think about how can you scale your work a lot more. If you get unlimited resources and budget, A) that is probably a bad news for your company because they’re not being thoughtful how they are investing and the floodgates are literally open. And the second thing, I feel that doesn’t really focuses one to innovate as they should be. If you think of scaling, what is really scaling? It’s really preparing the ground for the next wave of growth. Are you setting the foundation up so that in next two years from now you’re able to do your job a lot more successfully?

A lot of tips and tricks that I plan to talk about are generally not meant for large-size dev rel teams. If your dev rel team is 100 people, 200 people, 1,000 people, maybe these things are too obvious for you. But not everyone is in that boat. How many of you here in the room, quick show of hands, represent a dev rel team of size one? How many of you represent a dev rel team? Please keep your hands up. How many of you represent a dev rel team which is of the size between one to 10? Dev rel team between size one to 40. Yeah, so this talk is primarily for folks in the size one to 40. It will probably be relevant for others as well but this is the key audience because I know that’s where you’re really struggling with it, some of the challenges around scaling. What is also important when you are thinking of your dev rel is really thinking about these three key principles. These are the principles that my team uses when we are building developer programs and strategy.

The first one is feedback. Dev rel traditionally has been an outward-focus function. Like the megaphone for you to talk about, here are the best things we have developers for you to start building on. And that’s a sure-shot problem. There needs to be two-way advocacy. You need to be able to take the developer feedback and bring it back to the Product & Eng Team. Luckily in the morning talks that I listened, everyone was talking about feedback. So if you’re already thinking about it, that’s great.

The second is community first. There are numerous examples in industry when organizations looked at their developer community as an extension of their own organization and pushed their internal goals into the developer community. That’s a sure-shot way for you to lose the trust of your community in short-term and then you have to spend a lot of money to gain that trust back. It’s also not the right thing to do. What do I mean by community first? And we all say let’s do it all the time. If you’re able to do it majority of the time, that itself is good news. Did you have influence in your Product & Eng Teams to block a product launch if you think that launch is not going to be beneficial for your developers? If you have strong signals and feedback that the product is not ready, are you able to make that call? When you are sharing content for meet-ups or events among your developer community, is that the content that you and your Product & Eng Team wants to push out? Or is that a content that your developers really need? Focusing on the needs of developer community really helps you win their trust in the long-run and that really pays back also in business value.

And finally, diversity and inclusion. A lot of us are building products for global audiences worldwide, not for a fraction of the audience, across gender, ethnicity and background. And as you build, as we’re thinking about that, it’s also important that the developer community that we’ve worked with and engage is also representative of these developers that we want to eventually engage with. So if your dev rel team size is one to 40, looking at these three pillars, probably some of these recommendations resonate with you a lot more. And the way I’ve structured some of these tips are across four pillars, team, outreach, operations and feedback.

Let’s start with teams. One of the first question that comes up, what kind of personas exist in dev rel world? What kind of roles exist? The first one is Developer Advocate. It’s fairly mainstream, fairly common, in some organizations it’s called Developer Evangelists. But Developer Advocate is much more common word being used now. These are the folks who go on stage, the ones that go at events, at meet-ups and talk, go behind the camera and record talks that you’re able to share more scalably. Literally the public face for your developer programs and your platform. These are also some of the first people that are likely to be hired in a dev rel organization. In some organizations, Developer Advocates also work with partners, helping on integration and launching features. And again, those in those engagements are pretty time-bound. So you don’t have a dedicated Partner Manager but instead Developer Advocate steps in, gets something launched and then comes back into their regular job.

The second role, which I think is super important is Community Manager. Very quickly, if your product is starting to get traction, there will be a community that will build around it. And now it’s a responsibility for you as an organization to navigate that community in a proper direction. And the Community Manager’s role is vital and critical in achieving that. These are the folks who are helping swags for meet-ups, helping buy pizza for the hackathon. These are also the folks who are helping run events if your company has to run those first party events themselves. Couple of other roles, Developer Program Engineers. As your Developer Advocates are going and talking about the vision of the platform, getting people excited, the next step would be, folks would like to see the code samples that they can take and use it in the application that they are building. In certain organizations, specialized roles like Developer Program Engineers exist, whose primary responsibility is this. In many companies, especially if the dev rel team is fairly small, Developer Advocates will be doing the same responsibility.

And finally, Tech Writers. A lot of our work from developer advocacy to community to online reach will literally be focusing on a call-to-action, inspiring someone with a key message and saying, if you wanna know more, go to developer.xyz.com. Now, the experience that that developer website has is key. If the documentation and content you have there is vague, that is a leaky bucket. That’s where you’re going to lose all your developers in the pipeline. And therefore having a really solid technical writer team is important. Again, if your dev rel team is fairly small, probably this will be a job that will be done by your Product & Eng Team that you’re working with. All the DA’s are gonna be sharing that responsibility. So the roles to start with are typically developer advocates and community managers. Once you grow beyond a certain size, then you start to look for other roles to hire.

The second challenge that typically comes early on is expanding globally and scaling. Dev rel teams typically get started wherever the host organization is based but then very quickly realize, Oh, you also have developers in San Francisco that are building on our platform. And we also have a community in Japan, Tokyo. And by the way, the community in India is going crazy, we need to do something to engage with them. The challenge in these cases is hiring leaders in these key hubs who can really grow your dev rel presence over there. My recommendation is also not to go to, not to spread to 10 in terms of hiring across all the key markets, but really focusing on hubs. So if you can have a hub in North America that is able to work with developers across US and Canada, that’s more scalable than trying to put one person in New York, one person in San Francisco. The challenge of putting individuals in different offices is they’re remote and the overhead for you to coordinate with them, it just is much higher. At the same time, I do recommend exploring global expansion early on if your product is starting to get traction because the insights someone on the ground will be able to bring and the constant engagement that they will have with the developer community on an ongoing basis, you can’t replace that by flying someone in constantly into those markets or trying to only focus on online and scalable engagement.

That brings us to the third question. Where do we hire for Dev rel? This is again like a fairly new practice and using traditional interview formats of either hiring for a software engineer role doesn’t really helps. The good news is the number of practitioners in this industry is growing. You can see in this room here, you go on LinkedIn, you look at people with dev rel titles, that pool is growing. The other places you can look at is, especially for roles like Developer Advocate and Developer Program Engineers, if there are software engineers in your company who are keen on not just being behind the monitor but occasionally going on the stage and talking with the platform, maybe offer them a rotation opportunity or a short-term project for them to explore dev rel as a practice. Community managers, we have been quite successful in hiring some of the community managers from the broader developer community that we work with. Through programs like Google Developer Groups, there’s an active pipeline through which one can hire.

The other thing which is important here is, if you want to build a diverse and inclusive developer community, it’s important that your team represents the same. You can’t say, Hey, we wanna be serving everyone and diversity and inclusion is important. You throw up an event and the lineup is all men. That’s not really walking the talk. It does takes a little bit longer to hire the right candidate but it’s important to invest in it. Again, the business value is super high.

And finally, it doesn’t matter which organization your dev rel team is part of. The obvious ones are marketing. We see a lot of dev rel teams based out of marketing. We also see some of the dev rel teams that are based out of Product & Eng. I’ve seen a couple of examples where dev rel teams are also based out of customer success but the first two are very common. My experience also is, if your team is part of marketing or Product & Eng, irrespective of that, you can build a successful dev rel practice and you can build a successful dev rel team. The pros and cons are in marketing, one is likely going to get a lot more budget, maybe less headcounts but more OpEx to play with. With Product & Eng, the huge value is the feedback cycle that you can have with the Product & Eng teams that are working on those solutions for your developers is much stronger. Also, my own experience is, sometimes if you’re a part of Product & Eng, the short-term focus in terms of goals are less than you’re part of marketing.

At the same time, we do use things like Funnel even if we are part of Product & Eng because that really helps you put things into perspective. So the key being, irrespective of where you are, you can be successful if your dev rel organization is an early phase right now. And each one of us have a different preference. Use your influence to land your dev rel team where you as a leader for the dev rel team would be most comfortable with. If you strongly think that your dev rel team should be part of marketing, make that pitch early on. Then once your team is size of 30 or 40, at that point in time sometimes executives are reluctant to move a large-size team. But if you are a couple of people, they probably will be okay. So use your influence early on to land where you want your dream team to be. The next important thing that we as dev rel practitioners do is a lot of outreach. This is also around the time when we’re starting to get a little bit bored, so let’s have a quiz! How many developers are there worldwide? Let’s hear some.

Audience Member 1: 40 million.

Uttam: 40 million?

Audience Member 2: Not enough.

Uttam: That is the right answer. We don’t have enough developers. 40 million, we got one answer, any other?

Audience Member 3: 22.

Audience Member 4: 25 million.

Uttam: 22, 25, so that’s the ballpark I hear, 20, 22, 25, 40, I have a slight problem with that number. That number around 20 million has not shifted in last five years. And we do talk about, Hey there’s a huge presence, there’s a lot of developers out there but we’re not seeing that number move. It’s also important for you to know what are the developers that are most relevant for you. 20 million, it doesn’t matters a lot. What’s important is, are you really engaging with developers that are relevant for your platform? And that they might be just few thousand. There is a lot of research available now to which you can capture that information. When I started doing my job at Google, the very first thing I did, and my responsibility was to build community across India, I went to the developer website and looked at which are the cities from where developers are accessing our content. And these were the first few cities were where I set up the developer community. Really identifying which are the developers important for you is the thing to start with.

The second, online channels. We all love events, we all love DevRelCon. We all love our flagship developer conferences. But it has a set of problems. Events are very expensive, expensive on time, expensive on resources. And also they don’t give you a channel to constantly engage with your developers. You will probably talk to them once or twice at an event. Do explore online channels. We have had a lot of success by creating high quality technical videos, publish it on our YouTube channel, use social media. That really helps you get a lot more traction.

The other thing that it’s helped us be successful is really scaling with influencers and community managers. Even if you are a single dev rel person in the market but you’re able to identify key influencers and community leaders in those markets and build relationship with them, through that relationship, you are able to reach a lot more developers than a traditional channel will probably offer you.

Third, operations. Dev rel is a job that requires a lot of travel for example. Are you booking all your travel yourself or is there someone, a vendor or an agency who can help you? I would strongly recommend investing some money in getting that help because that is going to save your life quite a bit. And it’s totally worth every single penny that you spend on that. Running events, you don’t have to do everything yourself. Look at vendors, look at partners who can help you in that journey. If your responsibility is to create educational content, training content, as a two-person team, you can’t do that. But there are organizations that can help you and even we at Google work with many of those organizations whose responsibility and their primary job is to create that high quality content that you can use for sharing with your community.

Swag, keep out shipping t-shirts. Phil talked about his experience when he’s trying to get a t-shirt delivered when his wife entered labor a few years ago. It is intense, right? And it’s also a problem when we have swags being produced centrally, not headquarters. And we’re trying to ship it worldwide. The problems are, it’s way too expensive if your developers are in emerging markets and you would rather get those t-shirts made there, is four to five times cheaper. The second is the shipping cost. It really quickly adds up. And customs, I’ve had occasions where my packets were stuck in customs for months and months. The events were over and then the packets arrived. It’s of no use, right? So the keyword there is producing locally. And this also has positive impact on the environmental footprint that we are able to create.

Finally, feedback. A key part of developer ecosystem, the work that we do is gathering developer feedback. This is an area where I sometimes feel it’s okay to not focus on scale. We have done projects where we tried to create a dashboard and an online portal, submit all your feedback. Someone on my team created a 20 page report, we send it to the product managers. They acknowledge they got the report but nothing happened after that because they have other stuff to do. Then we did another format where we got some of our key developers, we’ve brought them in, had a product manager’s fee of half a day or a day of their time and had face-to-face conversations where the developers were sharing their pain points. A lot moved in those experiences. Quickly, the notes were taken, the followups happen, things shifted in product roadmap. So as we are trying to scale everything, I don’t think it’s needed. In areas like feedback, it’s okay to not scale every single thing that we do.

As I said, I’ve spent eight years in dev rel. If you were to ask me when I started, I don’t think I would have lasted in dev rel for so long. It was a new profession and I was just taking a bet. And if I reflect what led me to spend so many years, I think those formative years in my impressions when I was seeing a lot of distress and unemployment around me growing up. And dev rel for me has been a profession where we are actually able to create positive impact in individual’s life.

There’s a Japanese phrase Ikigai, which is a reason of being. As you are making career choices and options, something for us to consider as a framework, literally an intersection of full circles. Things that you love to do, things that you are good at, things that you can get paid for and thing that will create a positive utility in the world, thing that the world needs. Because if we were just to focus on the first three, something that you love, something that you are good at and you can be paid for, it can lead to a lot of questionable career choices. And therefore the fourth one focusing on also something that the world actually needs helps you really ground. And everyone’s Ikigai is very personal.

For me, dev rel helps me create positive impact in people’s lives. A lot of our mission is around making developers successful. And when you see someone who’s starting as a student, came to one of your programs, learn to program, went on to be a software engineer, an expert and then eventually she launches a start-up and raises huge round of funding, that is pretty fulfilling. And as some of you who are entering this profession, this is something, my own experience that has helped me stay in this for so long. That brings me to the end of the talk. As you heard, the work that each one of you are doing is really creating impact on individuals lives across the world. So when those weeks are becoming longer, the travel fatigue is setting in, think of the person whose life your work is impacting and it will make it a lot more bearable. So with that, thank you so much.