How Brian Douglas’ Team of 10 Developer Advocates Supports GitHub’s 65 Million Developers

Brian Douglas, GitHub

Today’s business climate is filled with disruption, whether from a global pandemic or competitors constantly pushing the envelope, and it is forcing companies across all industries to adjust or be forever left behind. Modern customers demand seamless end-user experiences (eg: mobile or web apps for customers or employees) that are composed from the Integration of two or more systems, but that ultimately hide that underlying complexity (appearing as though the entire experience is delivered from a single back end). To meet this demand and stay ahead of the competition requires organizations to execute with greater agility and innovation and to be able to do so at scale. APIs are key enablers for companies looking to meet these challenges. But before an organization can reap the benefits of APIs, it must set up an API strategy.

Developing an API strategy can be broken down into four stages: establishing your business strategy, aligning your organization and culture to the idea of a composable enterprise (where experiences are derived from a combination of digital business competencies), installing the technology needed to support the strategy and engaging with your ecosystem of developers, business partners, and other constituencies. This series of articles examines the fourth stage.

All successful API providers make it a priority to actively engage with their developer communities. Doing so helps build vibrant ecosystems of developers and partners who, in turn, can extend the reach and success of those API strategies. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article will focus on GitHub, a code hosting Platform for version control and collaboration used by over 65 million developers worldwide. We spoke with GitHub Staff Developer Advocate Brian Douglas.

It might seem like a daunting job to help support 65 million developers and a natural assumption is that GitHub must employ an army of developer advocates to keep up. But this isn’t the case and according to Douglas the team consists of about 10 people. In fact Douglas was clear that the focus at GitHub isn’t about growing its developer numbers and that he doesn’t “pay a lot of attention to that number...because there’s not much I can do to make that number grow or shrink.” Instead his focus is on making meaningful connections with developers throughout the ecosystem. He employs two main strategies to accomplish this.

First, Douglas and his team are able to act almost like matchmakers. He stressed that to be effective in the role, one needs to be actively engaged in the community. This engagement means that team members are aware of and in contact with the developers that are experts in various niches. When someone has an issue, if Douglas can’t answer it himself, he’s likely to know someone that can. In this way the GitHub team is able to leverage its massive community for support.

Second, the pandemic forced the team to re-examine how to approach events. Instead of relying on a handful of major events throughout the year, the team learned that it can host regular events that are smaller and more targeted by using video platforms. This is further supplemented by creating livestream content featuring members of the DevRel team, Project Managers as well as project owners from the community.

To find out more about how GitHub approaches developer engagement, read the transcript of the interview below.This interview has been edited for clarity and length.

ProgrammableWeb: Hi this is Wendell Santos, editor of ProgrammableWeb and today I’m joined by Brian Douglas of GitHub. Brian, thank you for taking the time to chat with us today. GitHub is one of the biggest players in the API space so I’m looking forward to hearing your approach to Developer Relations. Particularly I’d like to focus on the API portion, and how you get developers to engage with your API. To start, could you tell our readers a little bit about yourself, your background and how you ended up in this position at GitHub.

Brian Douglas: Yeah. I'm a staff developer advocate. But zooming back, I have professionally programmed for about six, seven years actually, since 2013. Got my role in start-ups using Ruby on Rails, doing web apps, web development. At my last employer, Netlify, I just wrote blog posts, and one of my goals was to be on stage and do conference talks in the React space. And there was a correlation between me speaking on stage and user growth.

So they transitioned me, without me knowing, into DevRel. I wasn't even familiar with the scope of the role or the space, but ended up transitioning from full-time engineering to DevRel, to the point where I gave a talk at GitHub Universe three and a half years ago on the GitHub GraphQL API. 

At the time I built a project, which I still manage and maintain today, called Open Sauced. From there, I made connections with people at GitHub, and now I'm here. As of three years ago, I joined as their first official developer advocate and the goal was really to start a developer relations team. And that's where I've been since I joined GitHub.

PW: So you've been there three and a half years in the role. Let's start from the 10,000 foot view of your developer relations strategy, and I’d like it if we can talk about it from the API perspective.

What is your strategy as far as how you engage with developers, bring them into your ecosystem, and get them interested in your API? What are some of the things that you guys are doing from the highest level?

Douglas: I think from the highest level, we've got the number that we announced recently, 65 million developers worldwide. So when I joined GitHub as a developer advocate, a lot of my friends and colleagues were kind of like, "Why would GitHub need an advocate? You already have a ton of developers using the platform." So DevRel in particular, our goal is not really to grow that 65 million number. And when you talk about the focus around the ecosystem and the API, our goal is really just to get people to be excited about the API and the ecosystem.

When I first joined, I spent a lot of time, obviously in the GraphQL API because of my background, but also in the GitHub app space of encouraging integrators and future integrators to integrate with the platform using GitHub apps. And within my tenure at GitHub, we launched this feature in 2018 called GitHub Actions. And Actions is sort of like, if you take the primitives, you take GitHub API, you take the web hooks, you take Authentication and you compile it all in the same thing, embed it into your Repo in a YAML file, then you have GitHub Actions. And that's the answer. That's really giving people access and information to interact with the API, without them even knowing it, because it is interacting with the API. You can do GitHub Kit, Octokit too as well, within Actions. 

But we've taken this Framework or this feature, and we've handed it over to everybody who uses GitHub. And now you can actually interact with not just your CI and CD, but you can do automation. Being able to say every time they open up an issue, I want this to happen, I want these labels to be applied.

I've got an action that I've been talking about for the past couple of months, which I call Take Action, which is essentially, I use it during Hacktober Fest where anybody can write .take and then they assign themselves an issue. So it's a feature, if you're not in the organization, my organization, you can assign yourself to an issue. But during Hacktober Fest, I knew I wanted people not to not make me the bottleneck for you contributing to my project. So in my CONTRIBUTING.md [file], you write .take. You don't have to know it's an action, that's the beauty of this. You just know that if you write this magical keyword that you will assign yourself an issue. (Editor’s note: Douglas reviews this process in one of his posts which includes a video)

PW: Let’s talk about Actions a little bit. What the response has been, and what does it tell you that you're doing right, and some of the lessons you've learned along the way?

Douglas: Yeah. So Actions got launched, I think Universe, GitHub Universe seems to be the pinnacle of my career at GitHub. I joined GitHub because of Universe, I've spoken at the Universes. But back in 2018, GitHub Universe, we announced GitHub Actions as a thing from [the] stage. And it was something that was really going to change the way of how we think about GitHub as a platform. We've had the GitHub app, and we've been expanding the ecosystem, but now you can actually arbitrarily write code on the platform.

So if I zoom back to you as well, Action is an automation tool. It's really to enable people to do things that can get them back to writing code as fast as they can. So if you have automation that basically gets your code to deployment, now you can leverage Actions to do that. So you end up with a CI and CD ( Continuous Integration/continuous development). If you have automation to make sure you have consistent code bases across different repos, so if you have a template repo that needs to stay consistent across all your other repos, you can leverage Actions now with that.

Our new CD workflow, one of the CD features that we shipped was organizational secrets for GitHub repositories and actions. So now we have access to look at actions on the higher level of like, "Hey, I am home kid, or I'm this project Kubernetes, I can see what's happening here and we can set up stuff that works for our entire organization moving forward. So hopefully that explains Actions a bit. I guess I can go into more detail if you want to follow up on that.

PW: So Actions was announced in 2018, what did you see? How did the community take to it, were there positive lessons learned? Lessons not so positive? 

Douglas: Yeah. Right out the gate, we saw people really jumping head first. One thing I learned as DevRel at GitHub, and being focused on the ecosystem side of things, when you look at the 65 million developers worldwide, not a huge percentage of those are people actually using the GitHub API directly. I had the benefit of working for two companies prior who used the GitHub API to integrate with GitHub, so I had knowledge. But the majority of that knowledge just really came from the person sitting next to me. I happened to work with someone who used to work at GitHub, or just knew the API well. So I knew how to integrate with it. But the majority of people I talked to just didn't really have a pathway into building on top of GitHub in a way that I was already accustomed to.

So right off the bat, it was really about educating folks of the existence of Actions and getting them to try it out. We saw the hockey stick adoption curve really shoot up. And then one thing that we also noticed within the first year of launching Actions, we had a version one, we're now in version two, right out the gate people asked, "How can we do CI with Actions?" Because we have CI as a feature today with Actions, but it was something that we didn't ship out the gate or think that we should ship. So that was a lot of the feedback we got, to the point where we ended up shipping CI with Actions. So now you can 100% have hooks inside of your GitHub repo as a CI and have that entire development operations process from start to finish directly in GitHub.

PW: We were talking about the API and you said that a lot of developers aren't necessarily aware, or don't even necessarily work directly with the API, and Actions gives them a way to get to that point. How are people made aware of Actions? Is that something that is just baked into the overall platform or is that something that you guys really make a point of saying, "Hey, here's Actions, and this is what it can do for you, and this gives you some visibility into the API so you can start leveraging that."

Douglas: Yeah, so the one thing that I love about GitHub is, we're a power tool. It’s sort of like, you kind of just know what you're doing once you get in there. So with Actions, we don't present you with [something stating that] this is your best action that you can take when you open up your new repo. I like that GitHub doesn’t inject marketing inside of where I write code. So we don't have any of that. But what we really do is we just have a lot of examples and communities.

I think what was really great is seeing the adoption of Actions in open source. So things like getting Ruby on Rails projects up and running with GitHub Actions. There's a lot of great examples, a lot of great blog posts from the community mentors, from open source maintainers of very large projects. And the beauty of that is that those actions are all open-sourced. So, if I want to ship a Rails project today, I can go to the Rails repo and see how they're leveraging Actions. Now their Actions are going to be way more intense than I need, but I can go to any other open source company project and take a look at what they have.

And I would say the introduction, I guess the best part about us not injecting marketing in front of your face inside of your repos, is that the word of mouth marketing is pretty high on Actions. So if I did an Intro to Actions video on YouTube for Node.js. And because it's trivial, we have heuristics and go to the Actions tab. It can find out if you have node.js in your project, you add it, now you have tests running on node.js inside your repo. So it's like the entry point for Actions. And then really quickly, you'll find out inside the Actions tab or the Documentation, there's other actions you can use. Interactions like I said with assigning the issues, the interactions to basically add in screenshots, or Test Automation at the time of PR. Those were all really nifty things that are built by people in the community that are open source. So go in the GitHub marketplace, I can just scroll through looking for test automation actions and find Apple tools has one ready for me, ready to go. I just plug and play and yeah, none the wiser.

PW: Let’s step back outside of Actions for a bit. With respect to engagement of developers, I want to hear about some of the other channels that you have gone to outside of Actions. How did you drive that awareness? How did you get people engaged? If that's a back door of sorts to the API, how are you getting people then into Actions so that they can do that? I assume it's more than just, you made it available on the platform and people found it there, there had to be some kind of a push on your end too. Can you talk about that?

Douglas: Yeah. I come from open source and doing some contributions and being in the JavaScript space, React space quite a bit. So what I did is I went to my friends, I went to people that I looked up to and respected and said, "Hey, are you interested in trying out GitHub Actions?" It was more just me having conversations, and I think that's the beauty of GitHub is that we're all pretty well connected with the community, that we can just have the conversation and  say, "Hey, Node[.js], would you like to try Actions out? And let us know if there are missing features. And if there are missing features, we'll work on them." So we ended up getting a lot of feedback that way, just being a part of the community.

But it also came down to noticing a lot of folks out on Twitter, I know in the last year Twitch streaming and YouTube has really exploded in engagement. So [reaching out to] some of the people I just naturally watched code. Actually Michael Heap who's recently a GitHub star, he's someone who wrote a book on Actions. I reached out to him and was like, "Hey, I love what you're doing. You're solving problems that I haven't even solved yet, because you have projects that don't look like my projects. So let's chat, and let me answer your questions." So being able to see people do really unique things with Actions out in the wild has helped me as a better advocate.

I think what it really comes down to is, we're roughly around a team of 10 here at GitHub. But we only have a handful of advocates here. So when you look at that 65 million developer number, one reason I just don't pay a lot of attention to that number is because there’s not much I can do to make that number grow or shrink or whatnot. But what I can do is reach out to Michael, and make him an advocate for Actions and give him all the information that he needs. Give him intros to the PM team. There have been some really good conversations. I met with a project [owner] and they actually presented me with an Action that was so large, their workflow file was so large that it actually hit the limit. I have never written an Action to hit the actual KB limit of the processing power for GitHub Actions. But they did. And they presented to me, they asked me questions  and I said, "Hey, you all are doing some serious business. Let me introduce you to the PM." And they were able to have the conversation with the PM and find out how to rewrite it in a way that it's not going to overload the GitHub server every time they want to write an Action or the Action runners.

PW: One of the things you mentioned is that you only have a team of 10, which to me that's very surprising. When I hear 65 million users, that's just so many users for such a concentrated team. I would have imagined a fully loaded team. Is it fair to say that a big part of your whole team's job is leveraging that community, and like you said, making the community members your advocates going forward? Or is that just more a byproduct of what you do, because you have such a good relation with the open source community that that happens. Is that an accident, or is that just the actual point?

Douglas: No, it's not a mistake. It isn't intentional that we scale our team. I think rather we enable our users by having conversations with them. And then we also can scale those conversations into other conversations. So it has to be based on the size constraint of our team, it has to be something that we have to be conscious around. 

So I can't be an expert at C++ development, and how to get GitHub Actions working, because I've never written a line of C++. So the first thing I'm going to do is ask my friends who know C++, “can I run something by you? How does this work?” I'm going to be very confused on a lot of their responses and stuff like that. I've sat in meetings before, and had to say, "Let me get somebody else who can answer some of these questions." It just has to be that way, otherwise you just get burnt out. I think when I first got into DevRel, there was a lot of burn-out happening, where folks would go through DevRel and then be like, "I'm going to go back to engineering for a couple of years." I honestly thought that would be me in a couple of years, once I decided to do DevRel from doing engineering. But what's really saved me in being able to continue to do this role, even at a company like GitHub, is that I do leverage community. I do leverage folks who are more expert than I am. I don't have to be the expert.

I joke that I'm the Beyonce advocate of GitHub. I love having the stage, and I love talking about myself, but there are times where I need to step back and make room for the community to grow. Otherwise I become the constraint or the bottleneck. I think when we talk about Actions, we talk about features, we talk about the user base of GitHub, we just need to move out of the way so you can get your job done, and it doesn't have to be the GitHub show. We definitely want you to use our platform. But we want you to be able to get your job done. And if Actions is not a fit for you, let us know why. Let us know where are opportunities for us to improve the product, and I think what really helps me in my job is knowing that I can have open conversations with people I consider as my friends, people as colleagues in other companies, and other projects that can give me honest feedback about it.

PW: So help to walk me through an example workflow here. You’ve seen there's some need for C++ help with Actions. And since you’re not the expert at that you say, "I need to leverage my colleague here that can give me a better understanding." You talk to this person, they give you the feedback that you need. What happens? Do you then give them a platform to put their knowledge out there, or do you take back what you're hearing from them and act as the mouthpiece for that. How does that go?

Douglas: A better example would be Rust, which is a very similar linked system programming language. Rust had some public articles about them leveraging GitHub Actions, and we've had some conversations with Rust. I very quickly found out that all I could do is take notes, because I was not a system programmer or doing Rust. But I happened to know people in the Rust community that I can ask questions of and say, "Hey, this community member is having this issue. Are you having a similar issue? Is there somebody else in the community that you can point me to, that we can have a collective conversation?"

Then the other beauty of GitHub is that I've had conversations with people in the Java space that work at GitHub, and I can drop in an engineering channel and say, "Hey, Java question. Actions, how do we make the two work together?" And then I can basically remove myself from the conversation, so that way people can get problems solved. I don't have to be the mouthpiece of having that conversation, I can connect people through email pretty easily. 

In that same sense, I love it when someone mentions to me on Twitter and they say, "Hey, I have a problem with Actions, Brian." The first thing I always try to ask them is, "Did you open an issue in your repo or did you open up a community forum, a message?" And then that makes it easier for me to walk that around through the Slack channels and say, "Here's a link." And I've actually had PMs jump into GitHub issues once I point them to it, and provide a response directly in thread of the actual question that's actually happening at the moment.

PW: So it sounds like a sizable portion of the work that you and your teammates do is essentially being that connector, that matchmaker between those in the community having problems, and those either at GitHub or in the community that are experts. You find out how to kind of bring them together to get those problems solved.

Douglas: Yeah. I would say yeah. We're party planners, we get people in a room and have conversations. But also there's this notion of authenticity in DevRel that is 100% needed. If you've never been a developer, it's hard to advocate for developers. So because I have a background as a developer, specifically in the JavaScript and the Rails and Ruby space, I do know who are the thought leaders and people who can answer questions for me. But also I do contribute. I had a contribution to a couple Node projects in the last couple of months. So actively being a part of the community also helps.

And I just want to make clear because authenticity is something that I hold strong to me. I wouldn't be doing this DevRel position if I couldn't be authentic and be myself, and actually write the code I want to write, but also have the conversations that I want to have. And be able to introduce other people to the conversations I just can't have. So just being active in the community is something really, really powerful for our team, but it's also really respected too as well within the DevRel team at GitHub.

PW: I'm very curious about your team. When you are hiring for your team, and I don't know if that's you specifically, or if there's someone else that does that hiring, but what are some of the traits that you're looking for, for someone that's going to be part of the DevRel team?

Douglas: Yeah. That's a good question and hopefully we'll be hiring. But I think really just having people who are already doing the job is always the easiest thing. So I would say, I don't want to make any promises, but we have this program called GitHub Stars. And the GitHub Stars is really, it's people who are already doing the job out there in the community. So we had an open call earlier this year for anybody who wants to be the first cohort of GitHub Stars. And this is I guess our "MVP program" for GitHub. And these are folks who are actually creating content on YouTube. People who are live streaming on Twitch on a regular basis. People who are already doing blog posts, speaking at conferences, experts in different fields.

We haven't done this yet because the Stars program is brand new. But it's going to be super easy for us to make conversations when we do end up hiring for this team and saying, "Let's have conversations and do a call out and make sure the stars are aware that this job posting is out there." And it's something that is really valuable to us, because at the time that we started the Stars we weren't hiring. We were in the middle of the 2020 pandemic, travel had been cut back, but we are able to grow and scale our team despite that. And thanks to the GitHub Stars.

PW: Going outside of making the connections that you do, are there actual artifacts that your team creates, whether it's blog posts, going to events, webinars, Twitch, GitHub, I've seen all those and heard that from other people. And do any of those things help drive more engagement or useful engagement with your community?

Douglas: Yeah, for sure. I would say, for the first couple of years at GitHub, we did basically the same thing everybody else did. Conference talks, every now and then we wrote a blog post, we'd help out with documentation when needed, and some of the guides and stuff like that. And I think 2020 has been an interesting year in the sense that all of the travel was completely cut out. Now, I'm of the practice that you plan your content, let's say Actions. So you're going to build some examples around Actions, maybe write some blog posts or content. You shop that around to give talks. And then you create videos, maybe do a workshop, and then just have a stream of content around everything you've been doing.

Well, with the conference thing being the pinnacle place where you finally get to the conference, you have the talk, it's out there, it's on YouTube, it exists. I think that's changed a bit. So in the last year those inventory items where we have content have changed a bit. So now, where our team was less active on YouTube, I know a lot of DevRel teams have been active on YouTube since forever, our team's been way more active on YouTube, and participating in getting content.

We've had this content piece called the GitHub Checkout, which is an opportunity for us to talk internally to PMs and give walk-throughs around features. So these are great companion pieces to our tweets and blog posts around product announcements and releases. And I've been hosting a thing, since last May, called Open Source Friday. This is really similar to GitHub Checkout, but this is with community members. So this is a place where I can talk to open source maintainers, contributors, people who built Actions. People have interesting stories around GitHub, and I can talk to them for about an hour about their story, and really dig in. We've built some projects live on the stream as well, live code together, and be able to see what happens. So that's been an experiment that's now become a thing, Open Source Friday for our team at GitHub.

Brian Douglas hosts an Open Source Friday session

Those are two of the consistent things that we've been doing in the last year. And we have even more to come now that we’ve pivoted into really focusing on this content piece. I would say on top of that too, we've also had this GitHub change log that we do on Twitter, primarily. But this is meeting our users where they are. Not everybody's going to sign up to the RSS, RP, Google reader, wherever your RSS Feed readers are today, but people are on Twitter. So we take the same blog posts, and we make them into videos, short form two minute video content. I think, for whatever reason, last year has really been around video. Mainly because our in-person, conference interaction has been removed. But we've just replaced that with the video piece.

And then the blogging, the conference speaking and the remote versions, those are all still existent as well. But I think now we're really, really focusing on how we continue to meet our users through video platforms.

PW: It’s hard to know when in person events will happen again, but now that you've had a taste of doing it through video, is that something that going forward, will be more core to what you do? Or do you hope to, or anticipate getting back out to events once those are happening again? What are your thoughts?

Douglas: Yeah. Zooming out, my thoughts are, I think DevRel as a whole is now re-thinking what events look like. I've seen a lot of companies who now have Twitch streams, including GitHub, who can now bring an audience. But my focus is really not around getting 2,000 people to show up on my live streams for Open Source Friday. If I can get a hundred people to show up, and be engaged, and actively participate in this conversation, then that's a good cohort of people to hang out with me.

This would be the same thing we would do in the GitHub office. We would host events there regularly in San Francisco, and we'd get like 120, sometimes 200 people showing up because it's San Francisco. I'm basically recreating that same experience, but online and not just San Francisco. So I think the shift has now been, we can actually do our own events. So then when it comes to sponsoring third-party events, now we get a little more picky about which we decide to do, because now we can basically build our own platform for engagement. And then when I talk about the GitHub Stars, and I'm looking for the next wave of GitHub Stars, I'm going to go directly to the Twitch stream, or the Open Source Friday cohort of people and say, "Hey, you've been showing up every single week, giving me great ideas and building GitHub Actions in between."

There's one individual, Crazy Max, that's his actual GitHub handle. I use GitHub Actions that he built that he shared with me. He would just drop them in the chat, give me GitHub repos and I'm using those for actual projects that GitHub is supporting today live. The reason this happens is because he just shows up, he has a conversation, he's a familiar face. It's the same thing as if we were in the GitHub office. I just give him part of the stage, because when he comes in I take time to say, "Hey, Crazy Max is back."

I think that is the goal looking forward. We don't need 40,000 people to show up to an event. We'll probably still do GitHub Universe and we'll do GitHub Satellite. But if we can have these small cohort events, now we can engage in a way that we could not before. And one thing I forgot to mention was our regional events. GitHub Africa, we started this meet-up using meetup.com and we have a stream that we do on YouTube, specifically for developers in Africa to showcase their skills and talents. We'll spend the intro talking about GitHub Actions, or code spaces, or a new feature. But then we have a meet-up where we have talks from people in Africa who can then showcase their skillset.

We did this for Russia, we did this for Brazil, and for Latin America. Now instead of having to spend $2,500 to get down to Brazil and hang out with people for a week, we can take half a day out of our schedule to hang out with people. This lets us engage the community on a consistent basis without having full-time staff there. And then going back to my original point about hiring, when it comes down to the time when we do hire for Brazil or Latin America or Africa, we already have a hundred people who show up every single week for this event. We should just ask them to apply and let's have a conversation.

PW: So it really doubles down, not only as a community building tool, but in a way as a recruiting tool. It works secondarily as that.

Douglas: Yeah, and to circle back to the ecosystem, I gave a GitHub Actions talk to GitHub Africa. I ended up doing a very similar version of what I did at GitHub University, it was sort of my preamble to the actual main event. So I was able to practice my content, just as I would do in a normal meet-up, with GitHub Africa. We did the next GitHub Africa the following month, and we had three Actions talks right after that. So to be able to see the adoption grow, if we talk about a specific feature, we have a platform for that.

It seems like almost a no brainer for companies and DevRel teams to start really seeing what this looks like. That way when we do open up and have in-person events, we have a different lens of what we're looking for out of events. I think I would push for smaller meet-ups, and let's do that more consistently than do the big rah, rah, rah expensive conference, and just destroy a city for a week. Instead, let's have a very intimate engagement that we can actually get to know people in the community.

PW: I know we're up on time so let me ask one last question. I want to ask about some of your KPIs. I’m hearing this theme where you aren’t necessarily focusing on growing the number of developers or have these massive blowout events. Instead, you’ve talked about hosting smaller events where you can truly engage with developers, have more intimate conversations and really empower them. How do you actually measure that? How do you know that you are actually successful, besides simply feeling like attendees were engaged.

Douglas: So again, we have a huge number of users, 65 million. To focus on that number would just deduct it, and be disingenuous for our DevRel team. So we're not really hyper-focused on numbers. For DevRel, the goals focus on being the face of the platform, encouraging the growth of how folks are engaging with the product, and getting people excited about the ecosystem. This could come to fruition in a number of different ways, from serendipitous content creation from GitHub users, working with the community to build unique feature use cases, event engagement and participation, and more.  

Another goal is strategic feature adoption. So when I mentioned Actions or code spaces, we just want people to use it. So we don't have any hard numbers on what that looks like, but we do know, we want to make sure that when GitHub is the home for all developers in open source, are open source projects using this feature, how are they using it? How can we get that story out there? And do we have any stories to share at the next conference about how a product like GitHub Discussions is being leveraged? And those are all answers that my team should be able to answer pretty quickly, because we've just been so engaged and have all these avenues to be able to interact with the community.

I'd like to thank Brian Douglas for taking the time to speak with me and share the company's approach to developer engagement. This is part of a series of interview with developer relations experts such as Gregory De Jans at TomTom and the team at Signable. Be sure to keep an eye out for future interviews coming soon.