Karthik Gaekwad

Hi folks, my name is Karthik Gaekwad, and I'm here to talk to you today about internal developer relations. Let's get started.

I will share my screen.

Alrighty. Good.

So like I said before, my name is Karthik, and I'm the internal DevRel lead at Google for the experiments team. I live in Austin, so I participate in a lot of Austin community things such as DevOpsDays Austin, Cloud Austin, etc., and I'm also a LinkedIn Learning author. You can follow me on Twitter at iteration1 as well.

So before we dive into internal DevRel, let's look at the high-level context over here.

Google as a company has over 60,000 developers in the entirety of Google, and a lot of developers, whether you're on a team or products you use, for example, everyone's globally distributed. So you might have users or you might have developers on your team that are in Europe, for example, or in the US, and also from a user perspective, a lot of folks using your tools will be in different geographical locations as well.

Our ecosystem internally is super rich. So there's a lot of different tools, platforms, and products. One thing that's a little bit different about Google compared to a lot of other companies is that we like to build our own tools in a lot of scenarios. For example, if you're trying to run a server-based application or you're trying to write a server application, we have our own set of frameworks and tools that we want our developers to use.

So the issue here is when you're new to Google. We call new folks to Google Nooglers. Generally if you're about a year or under, you're generally categorized as a Noogler. You have to learn a lot of things. For example, I've been at Google for a little over a year now, and my whole first year has been coming up to speed with a lot of different tools and technologies, especially in the experiment space that I work in.

So now that you have a little bit of context, let's step into what internal DevRel is and how it's different from external DevRel that a lot of folks have heard about.

Our org defines internal DevRel as: internal DevRel aims to increase the internal developer productivity and success. So we're more focused on developer productivity and success, about what folks are doing with the various tools that they're working with or various frameworks as well.

It's very similar to external DevRel in terms of we still do developer advocacy internally, work on developer experience, making that better, as well as building communities from an internal point of view. I think the one thing in this chart that I probably don't focus as much on is developer qualified leads, because our audience to us is more static. We're focused more on an internal audience rather than trying to get new folks externally to use products, etc.

So from a high level, the most important things that we do is we champion the end user and we try to remove a lot of friction that folks have with respect to onboarding. For example, in my area with experiments, a lot of folks have trouble onboarding with how to write an experiment or maybe how to do an experiment analysis. So trying to understand where people get stuck and then try to remove that friction away from the different areas that we would be working on.

Keeping up with documentation and materials is also super critical. We'll talk about this a little bit later on, but things get stale pretty quickly. And so we want to at least make the best effort to make sure that things in terms of documentation are still relevant for what folks are trying to read.

Also just normalizing that asking questions is okay. There is a lot of imposter syndrome. I know it's pretty rampant in our industry, but also at Google, where you're like, is it okay to ask a simple question, like, is this use case supported for the different tools I'm using, or is this the right way to instrument my application for logging, for example? Those might be ways that people are scared to ask questions. So saying, you know what, that's okay. There are no silly questions. You can feel free to ask whatever you want.

It also blends into education and knowledge sharing. Folks end up learning in different ways, so supporting different learning paths for users as well as being able to share knowledge between different sets of users that use the experimentation platform or other platforms that we support from an internal DevRel point of view.

Last but not least, education and knowledge sharing also ties into building stronger communities and being able to build stronger communities, and then once you have a quorum, you can start advocating for it and making it stronger.

So I like talking about this from a lifecycle perspective. If you're an end user, for example, when I started, I was advocating for experiments in the house, so being able to run A/B tests, being able to run feature flagging, things like that. So from an end user point of view, the very first thing I did was like, okay, well, I am going to be the DRE, or the developer relations engineer. The DRE is the acronym that we like to use. I'm the DRE for experiments, and I want to be the zeroth customer.

So what is it that folks do when they're trying to run through to build an experiment? I went through the pain points of that to learn what a customer would do. I put on my engineer hat and ran through the different scenarios of how do I instrument my app to build an experiment, and then later on, what do I need to do to do experiment analysis as well?

Phase two of this is looking at the documentation. When you're trying to onboard onto creating experimentation, like, hey, look at the getting-started docs. Where do things not make sense? Are things still relevant over there, or are things out of date? Being able to understand what a user is going through from a documentation point of view.

Once those two pillars are in place, you also want to look at things from a community aspect. The third thing I started doing after a while was understanding from a high-level user standpoint where folks are getting stuck, bringing folks together to say, hey, let's talk about this in a conference setting. We have internal conferences at Google. So try to build a quorum or a community of folks that wanted to share their different knowledge that they had with respect to experimentation, etc.

And last but not least, feedback. Anytime you get a bunch of folks together, whether it's engineers or users of different tools, they'll give you a lot of good, really valuable feedback about your tooling. A good example of this is one of the teams that we have that does a lot of the analysis stuff. We ended up redesigning some portions of the app, and we were at a conference, and a lot of users were like, hey, we really like the improvements that you have made, but how come you changed the color scheme of some of the things, some of the icons that we had?

When I started digging down into it further, I realized that the users had been using a lot of these tools for a long period of time, longer than the actual team that supported it. And so we got some valuable feedback that we would never have known had we not done a little bit of reach-out that way.

So you might be asking, why is all of this important, and from an organization perspective or from a large corporate perspective, how does it all build together, or why does it matter?

Two things. One is growth. When you're in a large enterprise, you'll end up generally having a lot of products. From an engineering point of view, you're going to have different organizations and a lot of different products under the organization, etc. Each product has its own lifecycle associated with it. Some might be MVP and just product inception, and some might have been there for a really long time. For example, experiments, our portfolio, has been there at Google for a long period of time. A lot of folks have worked on that code base.

From an engineering perspective, folks are excited to write new features. I said here that eng teams like to chase features, and there's nothing wrong with that. It's a natural part of product development, where you're trying to build things for customers. Sometimes what happens is there might be one set of users that strongly want specific features for their own needs. It might not necessarily jive with all of the different users that use the same product, but you might have to work with different users on different needs.

Also, from a high-level perspective, what does it take from an end user to go from creating an experiment to doing some data analysis for the experiment? When teams end up chasing specific features, they might not look at the high-level impact of when there are two large use cases and you're going down into making sure that experimentation works really well or experiment analysis works really well. From a high-level user standpoint, as a user, you want to do both, and you don't want to get lost in the weeds of, it was easy to create an experiment but now I have no idea how to do an analysis. What's the bridge that folks have to cross? Sometimes teams end up forgetting the end user from the entire lifecycle or the end-user experience.

From a DevRel perspective, one of the things that we do is end up being supportive and giving users a voice. We prioritize developer journeys in the specific product area, and we help navigate change. I think giving end users a voice is super important because a lot of end users will come back with really good feedback if you give them a good chance to give you good feedback. And then, last but not least, holding product accountable. In some ways, what I like to think of it as is if I am the DRE for the experiment space, I am able to say, hey, well, I'm talking to a lot of users, and a lot of users feel this friction from an end-to-end point of view. We need to really address this as a set of problems. Maybe these are some feature requests, maybe this is some technical debt that we need to pay down in order to make it better for users. Maybe there's a lot of documentation that we need to create in order for users to understand what they're doing a little bit better.

So one question that I get a lot is how does this work from a team point of view, and what is the composition of an internal DevRel team?

There are a lot of different roles. Primarily, however, we end up having a lot of technical writers. In our org, I think there are more technical writers than any of the other roles that we have. Technical writers are primarily in charge of documentation, and so they're looking to make sure that there are different kinds of documentation that different users can have and progress through.

Developer relations engineer, that's my role specifically. I work with the team, the product team, and with end users to make sure that their lifecycle actually makes sense, and what kinds of pain points people are running through when they're working through different scenarios.

We also have program managers and instructional designers as well. Instructional designers are folks that help us really build great content. Google internally will have courses that a lot of folks can take. For example, we're building an internal course for experiments, and so I work with an instructional designer to make sure that the content is actually going to resonate with the end user or with folks that are new wanting to learn more about experiments, that the course actually ends up resonating.

Last but not least is also user researchers. Making sure that we understand more about what users are wanting and thinking, so doing a little bit of user research is also super important.

So from a modeling internal DevRel team perspective, I have some stuff over here, how we've evolved from a small team into an organization. Let's take a look at that.

Back in the day, before this was an organization, we started as a singleton DevRel. This was a team model: team roles staffed for one product area. I think in our case it was the server platform team that came and was like, hey, we have a lot of docs and no one's really paying attention to this documentation. We should probably hire a tech writer.

That's how it started. Then they're like, well, docs look good, but we might need somebody to actually talk to users to understand how they're using our tools or using our code, what's missing in the framework, for example. That's when this transitions into a singleton team where you might have technical writers, potentially one or more DREs. I don't remember when we ended up hiring program managers and instructional designers, but it became a singleton team for one product area.

Then from a singleton team, you scale out. You say, well, we want to support more of server platforms, so we definitely need a lot more tech writers. We also need a lot of developer relations engineers to help with all of the different things that we have in server platforms. A lot of times different product areas will talk to each other. They're like, hey, how is this DevRel idea going in server platform? The experiments folks asked server platform, and they're like, oh, it's actually going really well. That's when they're like, well, maybe we should start having a DevRel team as well. So you start gaining a little bit of momentum from a team standpoint.

Then that's today. This is our current evolution where we have an organization. We support different product areas. I exclusively work with experimentation. We have a really mature team for server platform, but we also work in different areas like mobile, continuous integration, continuous delivery, and a few more areas as well. One of the cool things about this that I've learned is we also share common tooling inside of our organization, patterns, and best practices.

The really exciting thing is you can bring organizations together a little bit. An example of this is we were looking at server platform developers who were having a hard time running experiments or learning experiments. One of the things that we did between developer relations folks in server and developer relations folks like myself in experiments was figuring out what a common thread that we could tie together would be for the folks that were struggling, like server developers struggling with writing experiments. So we were able to bring together these two orgs to fix up some of the things between the tooling on the server side and the experiment side, to make the experience a little bit more seamless.

From there, let's talk about a few getting-started strategies. These are not really strategies, but maybe some questions you can think about or ask yourself or ask your organizations.

Probably the first thing to start is: what is the state of the documentation that you have? I put this as the very first thing because docs are the primary way that folks generally onboard onto different platforms. If you're not sure, you can ask a question like, hey, are there even any docs? Sometimes it's surprising: you might not have anything there, and so that's a normal place to start. But if you do, one of the ways we classify it is: are there documentation for getting started? Are there codelabs that somebody can go and run for a specific tool or for a specific experiment and whatnot? For your pro users, do you actually have developer docs? Do you have documentation more like reference manuals for different use cases that folks have, as well as code samples?

Are they up to date? The up-to-date part, one of the things that we do a lot is we'll timestamp our docs and look at it on a periodic basis to make sure that things are still relevant in there, as well as what are user complaints with documentation. If we have a methodology where it's really easy for users to look at specific documentation and file a bug against the product team or a follow-up bug against the developer relations team, it helps us get this quicker feedback loop to keep our documentation more current.

Also, how do developers ask questions? In here it's making sure that it's okay to ask questions. Are questions actually searchable? Can folks go in and be able to search questions that somebody else might have asked before? How quickly do developers get unstuck? Try to classify this with a heading, some set of metrics, to know when somebody asked a question, how quickly was it answered, did it actually solve the problem, and then what kind of training do developers have, and what might they need?

From there, what is the getting-started experience like for somebody starting off in experiments or in that specific product area? How easy is it for folks to onboard? Can they go try something pretty quickly and spend a day to onboard onto the platform, or does it take longer? Can you shorten it to less than a day? Are there good getting-started guides? Are there good training labs or courses? Questions like that.

And then how do products get feedback? This is also big. I think of this from two perspectives: pre-release, something before it's gone out to everybody, and post-release. Are the SDKs built with the users in mind? Is there early testing feedback? Is there a way that people can give feedback earlier rather than later? Are you able to release your product to a small subset of users before it goes out to a larger audience?

Post-release, it comes more back to: is your community able to have a voice, to be able to voice their feedback back at changes, whether it was good or bad, or what things do folks like? Also periodic user feedback for products. One thing we do a lot of is we try to give users a way to give us feedback on a periodic basis. From my DevRel point of view, we actually look at surveys to see how things are going with users for specific products as well.

The last two things I put in here are a process for users to report bugs, and are they able to leverage other folks in the community who might be experts at using a specific product to understand best practices and things like that.

So to summarize, the points here are: when organizations get sufficiently large, sometimes users get forgotten. The internal DevRel team, the organization, really ends up championing the users. It keeps the product, engineering, and users all accountable to each other, and honestly, it just makes the knowledge a lot more accessible and visible. Finally, the other thing we do and spend a lot of time on is helping build communities internally. If you ask me what is a success criteria of my job, I would say I make sure that users are happy and they're productive, and that's where we go.

If there are any questions, hit me up in the chat and I'll be happy to talk more about it. Thanks so much for listening. Appreciate it.