External advocate programs are an increasingly popular tool for dev rel teams. In this talk from DevRelCon December 2017, Joe Nash discusses the development of the GitHub Campus Experts, looking at process, empowerment and ways to scale.
So, when I first started at GitHub, in my first three months I did 39 events. That works out to roughly one event every three days, and I’m sure I don’t have to explain to many of you why that’s completely unsustainable. In the three months following those three months, I only did 12 events, and you might be asking, “Did he have a nap? Did he abandon his developers?” The answer to that is, “No.” In fact, what we did was we rolled out an external advocate program, and while I was doing 12 events, a group of student leaders called the GitHub Campus Experts were doing a further 22. That means in the three months following my first three months we delivered 34 events compared to 39 almost matching the level of support we were able to deliver our developers, but in a way that didn’t result in me driving myself ragged. We were able to sustain our community in a sustainable way.
In the year since we started Campus Experts, it’s gone a lot further than merely maintaining our numbers. We now have over 60 Campus Experts in 16 countries and in the last year, they’ve done over 140 activities. We currently have over a thousand Campus Experts in training. As of last night, it was 1020.
So, we’re now able to tell stories and support communities we wouldn’t be able to before. The education team at GitHub is three people. There’s no way we would be able to support our community of 1.3 million developers with us alone. And those Campus Experts are true superheroes. They do amazing things like speak at our conferences on three continents. Here is Amy speaking at GitHub satellite this year in London. They organise multiple thousand people hackathons, they throw women in tech conferences, they teach workshops in rural Cameroon. They do truly fantastic activities. And for the next 20 minutes, I’m gonna be telling you how you can build and scale your own external advocacy program.
We’re gonna do that as a five-step process. Those five stages are gonna start with G. We’re gonna talk about your groundwork. How an external advocacy program, and the need for it has to grow naturally out of your strategy. We’ll then are gonna look at outcomes. How much strategy, your outcomes, how you measure the success of your program should grow naturally out the need of your users and then serve the need of the business. The core pillar of this framework is gonna be trust. It is impossible to scale without trust. We’ll come back to it repeatedly but micromanagement does not scale. So, we’re going to talk about how we can establish trust with these third-party candidates, with these third-party advocates and how we can work with them to scale our program.
We’re going to look at operations. You’ve designed this fantastic program, now, let’s automate everything we can, and finally we’re going to iterate and go back through and re-apply everything we’ve just done to build upon our existing program. That leaves me with the fantastic acronym. Go-to-one which is mainly to set myself up for DevRelCon next year because when this doesn’t work I can come and give a talk called Go.to considered harmful.
So, before I get started, I want to call out the fact that there are about 10 Campus Experts in this room right now. So, if I tell you any lies, I trust they’ll check me on my nonsense. We’re gonna come back just in the trust section but I’m able to give this talk giving you the insights to the strategy and the meaning behind this team because we have complete trust in our relationship between me and the experts. So, let’s get started and talk about groundwork.
Groundwork, as I mentioned, the need for an external advocate program needs to grow naturally out of your strategy. What we’re talking about here is how an external advocate program fits into the existing metrics and existing things you’re trying to drive. Much like hackathons, video content and podcasts, external advocate programs tend to grow out of teams that are under pressure, under metric pressure, under stress. We wanna make sure that that’s not the case and they’re not being a misused tool.
Back at DevRelCon Tokyo late last year or when was it. Summer this year. Wow. It’s been a long year. Back in DevRelCon Tokyo, the leader of my team, John Britton, gave a talk of marketing to developers. And in that talk, he presented the SCOOP framework which is how the developer marketing team at GitHub plans out work and measure success. And it’s this framework, this way of planning work, that gave rise to the need for an external advocate Program. So, I’m going to give that example. We’re gonna walk through the SCOOP framework, all five letters of it, and see how the SCOOP framework resulted in us needing this external advocate program. As you can see my team really likes acronyms. I copied John just to be clear. So, let’s start with the S. Support. As a developing marketing team, obviously, we’re supporting developer users. So, as we’ve got our support channels they could be stock overflow, they could be email, in our case probably GitHub. We’re getting regular support queries. For me, in particular as student program manager, I’m looking out from the ones from students.
So, I’m getting regular in support queries from students. While those queries are coming in every now and then I’m finding myself answering the same question or having to basically repeat myself. As those questions come in, we’re starting to notice patterns, and a really interesting set of patterns start emerge, where we were seeing hackathon organisers and club leaders ask us of things like, “Can you come and give a workshop at our school? Can you support or fund our hackathon? Can you send a swag? How do we get into Open Source?” And we identified that we were ending up with another subset of our users here. Our support inbox identified the group of student leaders. These student leaders had very clear needs in GitHub. They were looking for workshops and content. So, when they came to us asking for that support we would direct them to the right place. They were looking for sponsorship and swag, and they were looking for access to Open Source and the industry.
So, with those support needs very clear to us, we started to address that with content. When they were asking us for workshops, obviously, as we’ve already covered, I can’t be on every university campus in the world. So, I’ll provide them with links to our Open Source training kit that our professional services team used to train real companies. When it came to sponsoring the hackathons, obviously, again I can’t sponsor every hackathon in the world. So, we came up with the first-time grant, which enables us to support first-time hackathons on campuses. When it came to open source we partnered distillations from Hacktoberfest and we worked from resources that made Hacktoberfest easier to access for students. So, we’ve had a support need and we made content to address that need. We’ve helped developers help themselves.
Let’s now talk about outreach to get those content out to the developers. So, with the grant, we wanted to make sure that grant got to all of the new hackathon organisers. And where do you find new hackathon organisers? For us, that was a partnership with Major League Hacking. Major League Hacking provide our grant to all first-time hackathon organisers so we don’t have to think about anything. The grant gets where it needs to be. With DigitalOcean, to make Hacktoberfest more accessible, we started a Meetup program. So, this year was the first year it’s probably on the website. Meetup organisers could sign up to hold an official Hacktoberfest event whether it be on campus or in a local city and get a specialised Swagbox.
When it came to actually getting right to the core of this audience and getting the measures where you want it to be, we’d sponsored HackOn in a very similar partnership to this one when we have a lounge and everything. HackOn is the conference for student hackathon organisers. We went direct to that audience and we told them, “Hey, you had a need and we’ve addressed it. Here’s how we’ve done that.”
So, then obviously we need to start automating these things, and there’s a couple of ways that we did that that really helped us out. So, the first one MLH, with this partnership they actually fully took up the load of that process. They do all of the vetting of an event to make sure it’s a first-time event, to make sure it’s worthy of the grant and is actually gonna happen, and then they just send us an invoice. It’s a super great process. Canned replies, it sounds obvious but having canned replies in your ticketing systems or even on GitHub is really helpful to scale. So, for example, when people ask us about workshops or Swag, it’s really easy for us to just say, “We can’t come visit your campus but here is how you host one of these workshops yourself.”
We also have contractors that help us with fulfilment. These are contractors we’ve hired and they do things like, for example, check for Swag requests in our inbox, and if we’ve approved that Swag request, they go ahead and place that order. I cannot tell you how important this is to me. At one point, I forgot to send stickers to an event and I had a nightmare about not sending Swag to events. The contractors changed my life. This is so important.
So, we’ve found a support need, we’ve made content to address it. We’ve done outreach to communicate the content we’ve made, and we’ve started to operationalise things and automate those. Now we come to the P, which is programs. This is about wrapping it all up and putting a bow on it and giving it a name. So, with this program, we’re looking at student leaders who have content needs around workshops, sponsorships, and opportunities, and what’s really interesting here is the reason they were asking us for those things. They were asking us for those things to help their peers learn about GitHub, help their peers learn about Open Source, and help them become better software developers.
And that leads us onto the O, in Go-to, Outcomes. Your outcomes of your program, what you’ve measured the success of your program on, should come and be derived from the users. Obviously, it needs to suit the business needs. We’ve all heard dreadful tales of dev rel teams, as Matt started off with a joke this morning, our dev rel teams have been let go because they haven’t been meeting the business needs. But actually making sure that the outcomes grow successfully out of your would-be external advocates is extremely important for their satisfaction and for their engagement with the program.
We found out from our support queries that the reason students wanted these resources was because they wanted to build a technological community on their school. They look at events like DevRelCon where we’ve got loads of like-minded peers in one room and they say, “I want that on campus.” That is an aim that, we at GitHub, can get behind. That is something that helps us. If we’ve got a group of people who want to help teach collaborative software building, and we have a platform for collaborative software building, obviously those aims are in sync, and that became the end messaging of the program. The outcome was so perfect for us it literally translates into messaging. And here is the cool thing is that the win for the students translate into a win for GitHub. You wanna make sure that, just as your strategy is growing naturally our support needs, your outcome grows naturally. And the framing in terms of the users is super important for other reasons.
We talk a lot in dev rel, we had a talk about authenticity. No one is gonna listen to your external advocates if they’re just Swag-wearing leaflet followers, right? They need to be able to talk about what they’re talking about passionately and with conviction. And I guess another way of saying this is don’t expect your external advocates to use tactics you wouldn’t use yourself. If you, as an evangelist or an advocate or a public speaker, would be uncomfortable doing a certain activation, don’t expect this unpaid representative of your company to do so. That’s just not gonna work.
And that brings on to trust. Trust is the center of Go-to because I think it’s the most important pillar, and this sounds like it’s gonna be a very soft section to talk, but actually this is super material. Without trust you cannot scale. We’re gonna hit back on this repeatedly. Trust is a two-way street here. Your external advocates, again, they’re probably gonna get unpaid, they don’t want you to take advantage of them. They’re not unpaid salespeople. But, equally, you’ve got to trust them to represent your brand. They’re not employees, you don’t have as many quality control as you otherwise could do. But having that trust is all about giving them the power to make the right choices.
They are local people with local context, we’ll come back to this in a minute. But if you trust them and you enable them to get on with the work they’re doing, and that gives them the power to make the right choices which can help you scale. Again, micromanagement doesn’t scale. If you have to constantly check in on decisions they’re making, if you’re constantly saying to them, “Hey, you organise this event right. Have you done this talk properly? Have you got this in your slides?” That’s not going to work at 10, 100, 200, a thousand external advocates.
So, to give a very real example of this, let’s talk about Columbia 4.0. This is a huge software development conference in Columbia and they reached out to us to speak. GitHub kinda suffers from this problem where, because we’ve got 26 million developers using the platform, people think we’re really huge but like we’re barely 700 people. So everyone asks us to come to their events and we just can’t. And in this case, it was a personal ask from a conference organiser to GitHub. In this case, they asked John Britton. They’ve worked with John before and they knew he delivered great talks, and they wanted John’s content for their program.
We weren’t able to make it at the time, we were all too busy. So, John offered up a student, a Campus Expert in his place. He was able to do that safely or able to offer a student in place of himself to a professional software conference because we trust the Campus Experts to do a great job. The organiser accepted the substitution because the organiser placing faith in us that we trust that student to deliver quality at the same level as John, a professional speaker would do. And this worked out fantastically. We sent two Campus Experts, Kim and Melanie. Kim wrote this amazing book about her first time speaking. This is Kim up on this massive stage. Between them, they delivered four sessions and talks and some workshops, and they had a really enriching experience as students who were participating in a professional conference.
But more than that it was great for the conference because being able to send these Campus Experts gave us another way to say yes. Without these external advocates, we would not have been able to help this conference. We wouldn’t have been able to go, the attendees miss out on content, we would have let down this personal contact of John, but instead, we were able to actually help them out. This is, again, helping us scale in a way that’s really impactful where we can say yes more often. And I mentioned earlier local knowledge.
Local knowledge is important because this is a way you not only save time but you also save money. You are not on that campus, you are not in that city, you are not in that meetup, those external advocates are. They know the best deals, they know where to find the best catering for the best price. They know the local Meetup organisers and can get great deals. My favourite example of this is we have a Campus Expert in Taiwan who somehow convinced a professional conference to give him like a free booth. Then he just kind of did it and had a booth, just because they were like, “Yes, Pete is cool. Let’s do it.” I, as GitHub, approaching that conference would not be able to do that, right? And equally, we had a fun thing earlier where one the Campus Experts came up to me at the conference and said, “Hey, the pizza from my event last week was a bit more than I wanted.” And I was able to say, “Look, I know you’ve tried to get a cheap price. I know you know your local pizza joint for students, of course, you do.” So, I was able to just say, yes, great leave you to it.
So, how do we establish that trust? So, I’m gonna go through some advice here on how to establish trust but it’s really important to note that these techniques, don’t take them too literally, they don’t work for every audience. We’ll kind of follow back around on that. With the Campus Experts, because we talk to my students, we deliver training. And this training takes them through a variety of things. It takes them through skills that they need to actually perform the duty in the field. For example, our training incorporates public speaking, community management, a workshop development, but more than that it really communicates our expectations and our outcomes.
Our community management module hits upon the need to include civility and the code of conduct. Our public speaking module talks about preparation. That’s why the Campus Experts know exactly what we expect from them and we have this really neat badge systems they can get around. But also, the training actually communicates, again, what the program is for and what we consider a successful outcome. Every student starts the training by analysing their community and deciding what they need to add to it to result in success. And then the skills they take, the other skills they study during that training, are based upon that outcome. So, right from the start, we’re saying, “Your goal here is to make the best community possible. We are here to help you do that.” They know that they’re not gonna be like schilling GitHub all day so they understand what they’re there for, they understand about the authenticity aspects, and we know that, at the end of it, we’re only gonna be adding people to the program who truly know why they’re there.
Next up is on application. Students can take part in the training without having actually applied to be a Campus Expert. I’m going to talk about why this is in a minute. But having this application enables us to screen for understanding. They’ve done the training, so in theory, they know everything that we want them to know about why the program is there, about what we expect of them. Now we run them through a really short screening, and because we’ve had that training, the screening can be pretty short. We essentially ask two questions, “What do you think Campus Experts is for, and why you want to be part of it? And why do you think the issue of inclusivity and diversity is important in tech?” And that tells us most of what we need to know to know that, after they’ve done the training and we’ve watched them interact with the community, those two parts combined tell us most what we need to know about whether they’re gonna be successful on the program.”
The next part about building trust is keeping it real. External advocates are your MVPs, your VIPs, they are all your savviest users. They are going to know if you’re lying to them. You should tell them exactly why they’re here, and that means telling them how the work they’re doing affects the bottom line of the business. If you don’t tell them that stuff, they’re gonna work it out themselves and they’re gonna wonder why you didn’t tell them. Just tell them how their actions affect the program. For example, during a Campus Expert onboarding, we got for a section where I tell them, “Hey, here is the app we use to track how many events you’re doing. Honestly, every time you put an event in here, it helps me advocate for the program internally, which may result in more budget in the future.” And that helps them again make the best choices, which is what it’s all about. Everything in trust is about helping them make the best choices. And, again, if you don’t tell them the truth, they’re gonna figure it out themselves, and they’re gonna wonder why you just didn’t come out with it. So, make sure that you establish that trust, or they’ll just work it out.
So, to run back in. The core part here, one of the things I said was training. This isn’t for everyone. For example, if I was running an external advocate program based around Meetups, where I was having developers run Meetups in their local cities. This is something that Docker and DigitalOcean do. I wouldn’t expect those Meetup organisers who applied to go for training on how to organise Meetups, right? That’s probably condescending. So, what are the alternatives we can use to replace this training step? To get to those, we have to think about what is the training is actually doing, what function the training serves. So, firstly, is it straight-up valuable to participants? Before they’ve even applied to be part of the program, before they’ve even applied to be a Campus Expert, they’re all getting a tremendous amount of educational value from us.
So, whatever content you substitute in place of training should be a core valuable to the people who interacting with the program. It should be a nice surprise and delight when they join. It should expose you to the work of the individual. Through the course of the training, I see not only how Campus Experts approach difficult topics like analysing a community, but how they go about writing talks, how they solve problems, and I know to review those in a really neat way. We’ll talk about how I do that in a moment. But it lets me know a lot about them as a person. So, whatever alternative you use, again, should expose you to their works, you can learn a bit about them.
They should set their expectations. For whatever method you use, it should be something that enables you to kind of hammer home, again, like what you expect to the company, what your standards are. So, if we take the Meetup organisers, something that achieves these things. Maybe it’s, “Hey, I’ve had 30 Meetup organisers apply to host Meetups. Let’s get them in a roundtable to talk about why… or to talk about how you ban a typical community member from a Meetup or to talk about how to enforce the code of conduct.” That’s a discussion that could be extremely valuable to the members. It shows you how those individuals cope with that situation and it sets your expectations. It shows that that’s something that you would expect to happen under a Meetup under your banner. And, again, come back to outcomes. You need to communicate your outcomes. People need to walk away from that experience knowing exactly why they’re taking place in this program.
So, we’ve found out that we need this program. We’ve laid our groundwork. We have derived our outcomes. We’ve established trust. How do we go about actually scaling this thing? How do we take those dials and turn them all the way up to 11? So, the first way is to use what’s already there. When we started the Campus Experts training, sorry there’s a bunch of them in the audience in this photo.
When we started the Campus Experts training, Hi Roxie, we were doing it via asynchronous training, which meant for eight weeks, Campus Experts had to join me in a weekly call to have a chat about the topic for that week, and this was just a nightmare for a whole bunch of reasons. Firstly, it meant to talk to the Indian students, so I was up at 4 a.m. on a Thursday, it was not great. Secondly, it just didn’t scale. We had a limit to the amount of students we can include on these batches and that limit was probably capped around 30. In the first month of the training being opened, of the applications being opened, we had over 2000 people apply. We were never gonna get all 2000 of those students who wanted to be involved through those 30-person batches. So, we had to kind of flip things around to think what does a scalable training look like. We wanted something a little bit like a MOOC, so something like Coursera or edX and it had these qualities. It had to have a way for us to deliver content to participants. It had to be a place they could get support, a place they could submit their exercises, a place I could review their work, and a place where we would get easy metrics on automation kind of for free.
I don’t know about you but this may be me seeing everything is a nail with which to hit my hammer with, but that looks like GitHub to me. So, that led us to our open training solutions. So, now we have a GitHub organisation and a repository. This organisation has over a thousand student members in it and this enables us to do some really cool things. So, firstly, on the topic of use what’s already there, it gives us all those things. GitHub has those. Secondly, it lets us use the tools built by the open source community for open source to help us. So, during the training we have this really neat little OAuth app built by, actually at GitHuber called Ben Bolter. All this app is doing is checking whether someone coming to our training has GitHub student discount. If they do, we know they’re a student, we can add them to the training. Happy days. They get added to the org. They can see the private repo where the training lives. Because GitHub renders ReadMe’s, that’s a really great place for us to display our content. We actually have our designers make these beautiful badges and banners, and I’m using this really neat thing called GH polls to get like a YouTube-esque thumb up thumb down immediate feedback.
We can use the features, again, built for open source developers to help us. So, this is the Sinatra repo. As a new contributor to Sinatra, you see I get this banner here that says “Hey, it’s your first time here. Why don’t you read our guide?” We can make use of those features to guide people for our training. New students coming to our training for the first time get this same popup which links them to our documentation so they know how to go about completing the training. Poll requests are the most important part of this. Students go through the GitHub flow to complete our training. They fork over our repo and then they open up or request their exercise. Those poll requests enable us to do a line-by-line review and we make use of things like canned replies. Here you can see one, our Campus Expert in Mexico reviewing someone. We may use of canned replies to speed up our review process. So, when we’re able to really quickly, I say really quickly, currently, the queue is really long, but right between theory get to students really quickly and review their work in a way that’s really helpful to them. And students love this training.
For those of you who are familiar with net promoter score, we have a net promoter score of 60. For those of you who aren’t familiar, Disney’s is 50 so we are clearly better than Disney. So, the Campus Experts also say some really fantastic things about the training. Particularly feedback like this where they say… Their feedback actually encapsulates our core outcomes. We want them to improve their communities, and here the student is saying that the training let them dig deep into the problems of the community and identify how to solve them. That’s hugely awesome feedback for me and another piece of feedback that I particularly love is this one. This one is great from a product perspective because this is on our module about Atom. Here we can see that student, after watching this module, has published their first Atom plugin. Another great thing about this is you’ll see here they mentioned Kim explained. Kim was the Campus Expert I mentioned earlier. This is content actually created by a Campus Expert which has now got a student to this point, which is just a super awesome outcome for me. We used to use the same system in the backend, we don’t use it for the training, we use it for people who’ve become an expert.
Here you can see how we track our events. Whenever a student does an activity, they open an issue. Those issues on the topic of helping me get metrics for free. You’ll see this very aggressive labelling here. I can use the GitHub API to immediately pull these out into a dashboard so I can see exactly what’s going on. Well, what’s really neat about this is, because they’re opening issues in the community space to talk about the activities they’re doing, it’s not just me who is able to help them. Other members of the community do and regularly dive in. A great example is Amy organised a Women in Tech conference in Nottingham, and two of the other Campus Experts Sarah and Alexandra actually were able to go down to that conference and help out.
My favourite example is Sandra, at HackIllinois, Sandra was asking us if we had any talk templates and at the time we didn’t. So, five Campus Experts jumped in with their existing GitHub talks. They were like, “Here you go. Use mine.” And that was just a super nice thing to see and those interactions are happening every day. And again, this is really important to scale. If I don’t get to an issue, if I don’t have the answer, that’s not a big deal because the Campus Experts probably do. We’ve built a community of community builders that are providing themselves as support network. Again, to the theme of using what’s already there, we can use the tools used by open source developers to help ourselves. Here I’m using probot to set myself a reminder because I’m a literal garbage fire so probot will actually drag me back into that issue in a couple of days to provide the support I said I’ll provide.
And a lot of this comes down to making use of open source methodologies. During the onboarding, I make it very clear that Campus Experts is not something that has 12 people have gone around the table and designed and said, “This is how it shall be.” It is something that’s grown organically from the needs of the students, and they are welcome to make any changes. And they do that in the ways that are most effectful. We are an under-resourced team in terms of engineering but we’re talking to a bunch of students who are keen to be developers and they do things like add amazing new features to the website. A really cool feature, the displaying of Campus Expert badges on profiles, was built by a student. So they’re able to fill in the gaps that I’m not able to do. They frequently catch my awful Ruby bugs and it’s really great and super helpful.
The organisation, although we follow open source methodologies, all of our repositories are private because of the presence of student data. So, we keep everything private. Only students can get into the repository. So, we’re actually closer to something called inner source which is basically practicing open source methodology in a company setting. If you haven’t heard of it, I highly recommend reading it. We did this really great PDF that you can get here. It’s really useful, there’s an O’Reilly book about it as well, I think, that’s like 20 pages. It actually publishes like a full book but it’s really short so I highly recommend checking into that.
And the issue of plan for future scale, and the badges are a great example of this. Our badges are, in theory, that access control for the benefits. So, in order to access a particular benefit, you need to complete the training module. There’s a reason for that. The main reason is that if we link resources to training, we know those resources are gonna be well used. For example, if we talk about the fundraising module, this module teaches students to budget efficiently and to budget responsibly. So, if we then sponsor a student that has done the fundraising module, we know they’re gonna use our cash well.
When I talk about planned future scale, I’m talking about these badges because we don’t currently enforce this system. This is a system that’s in place. Students are earning badges as they complete the training but with 60 Campus Experts, we don’t need to gate the benefits in this way. When we get to 200 Campus Experts, 1,000 Campus Experts, maybe we will have to gate them, and we can just flip the switch and turn the system on. And this is all about giving me a really easy way to say yes or no and not having to think about anything in between. With the combination of the trust and systems like this badge system, when a Campus Expert comes to me and says, “Hey, I need XYZ,” I know, “Cool, you’re qualified. I trust you. You’ve done the right training. I can say yes if we’re interested in that thing.”
And that’s a really great thing about these programs in general. And going back to local knowledge, it lets you be objective rather than subjective. When all these hackathon organisers send me their prospectuses, like, I have no way to know whether that is valuable and whether we should be engaged in it. But with the Campus Experts, if it comes from them, I know it’s probably gonna be great.
I’m running out of time, so I’m gonna nip through this bit. So there’s a great scale you can use. Basically, you run alphas and betas. As you make the new feature, make it invite-only. As you start to hone it, make it open. But if you’ve got something where you want to, kind of, test something in a friendly environment, make it invite-only. So, for example, when we made this new training, we initially found that the training wasn’t teaching everything we wanted it to teach. But because we had slowly scaled up using the scale, it wasn’t a huge drama.
Final, really import part here. Scale does not imply inclusivity. Just because you’re bigger doesn’t mean you’re reaching all the right audiences. Plan for diversity in your scaling. Make sure you’re still doing proactive outreach. We actually found, when we changed to the open training model, that our diversity went down in a pretty significant way. So we’re now doing outreach programs to address that. So make sure that you plan for the same.
I’m really sorry. I’m nearly done.
Okay, so iterate. I’ll nip through this really quickly. Once you’ve done all that, go ahead and do it again. There will be new support needs from your users, from the external advocates, that will let you build new programs.
Our example is, we have Campus Reps. We found out that, for users in the United States, it was hard to get a hold of me at key times. So we solved that support need by, kind of, promoting experienced Campus Experts to a paid position that enabled them to be the face support in their region. From that, a Campus Expert, now turned contractor on their engineering team, actually also built Field Day.
Field Day is the solution to two problems that we identified. One, that schools weren’t collaborating in their cities or regions, and two, that Campus Reps were struggling with a channel to get the word out to people in their regions. So, Field Day is a student-run conference when we bring technical communities together to talk about best practices around building communities. It’s a program that came out of support needs for our users. We built content to address it and then wrapped it up in amazing branding.
Our latest example is…as I mentioned earlier, our review queue on open training is actually pretty big. It’s currently 160 exercises that we need to mark, and it’s a bit like marking homework. Luckily, a bunch of Campus Experts realised that that wasn’t good enough and they’ve asked me if they can help with reviews. So we’ve now built reviewer training based directly on their ask to help them get involved with scaling the program.
So let’s briefly recap. So first, start with your groundwork. Make sure that the need for an external advocate program is actually coming out of your strategy and not just panicking due to metrics. Make sure that the outcomes are coming out of the needs of your users. Why are your users asking for the things they’re asking for? Make sure your program addresses that.
Trust is the central pillar to this framework. Without trust, you cannot scale because micromanagement does not scale. Operationalise everything you can. Use the tools that are already there and make use of robots and anything you can, wherever you can. And finally, don’t forget that’s not the end of your program. You should keep on looking for inbound support requests and iterate and build new layers.
Before I end, you should work with us. So a couple of things. Firstly, we have partnerships. So I’ve mentioned we have this training. We have training modules. A cool part of those training modules is providing content to students who, I kid you not, are desperate for content. Students who deliver weekly workshops on their campus, which is a lot of them, can never get enough amazing content.
This module here, the “Get Tips and Tricks” module, came from our partner GitKracken. They gave us a module about solving common Git problems using their software. I wanna work with you to provide those modules as well. So if you’ve got anything interesting to teach new developers, come and chat to me and we’ll find you a platform to basically distribute your content to universities all over the world.
Secondly, I mentioned this morning that you could do what I just said, work for open source maintainers. Doesn’t that sound great? You should find out about that at github.com/aboutjobs.
And finally… Did you have a hand up? And finally, if you’re doing this as well or you’re building external advocates, in this 20 minutes I haven’t been able to mention half of the things that we do to help scale this program. I wanna talk to other people who are doing the same thing, and I wanna make sure that we don’t reinvent the wheel. I’m hoping to start, kind of, a Slack GitHub community for people who are doing a similar thing. We’re almost there. My logo didn’t get here on time. It’s fine. But if you’re interested in that, come and ask me, and I’d love to involve you in that.
Other than that, thank you very much. I’ve been Joe Nash.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?