When choosing a developer champion programme there are four archetypes to build on: reward and motivate, force multiplier, content factory and land and expand. Hoopy’s Matthew Revell and Carla Sofia Teixeira look at which one might suit your strategy best in this talk from DevRelCon London 2018.
Matthew: The four archetypes for developer champion programs. We use the word archetype because it makes us sound clever. But what we’re talking…well, let’s talk about who we are.
So, hello. We are Matthew Revell, that’s me. I work at Hoopy, doing developer relations things consultancy. And this is… –
Carla: Hi, I’m Carla I work also at Hoopy doing research.
Matthew: Okay. And so, we’re going to talk about developer champion programs, otherwise known as ambassador programs, MVP programs, external evangelist programs maybe as well. And you might be wondering why because a lot of companies seem to be doing these champion programs in order to extend their program.
But is there to say about it? You know, surely, it’s just find some enthusiastic people, give them a badge, and send them on their way.
Carla: All right, so let’s start off with a question. Who here works with developers? Not very surprised. And who here likes working with developers? That’s good. And who here doesn’t know what a champion program is? So everyone else can leave, we’re done, we’ll just talk to them.
Just kidding. So are you ready?
Matthew: Let’s start.
All right, let’s go back to basics. And I don’t want to do the old DevRelCon okay-I’m-going-to-define-what-developer- relations-is-for-20-minutes talk and then tell you the new bit afterwards But let’s very quickly look at why we would even care about this. So why do companies run dev rel programs? That’s the first question. And okay, it might be obvious but let’s have a look. The first reason is people don’t know about our product, the second reason is developers need education and support with the products that we have, and the third reason is, and this is why it’s advocacy and not evangelism, we need to close the feedback loop.
So it’s a two-way conduit, our role. So we represent developers back to the company, as well as representing our products and company back to developers. But developer relations, as good as it is, has two constraints in just about every single example. The first is budget and, related to that, is hiring.
So even if you are one of the biggest companies in the world and have hundreds of developer advocates, you are still limited by the amount of budget that you have. And really, for the big companies, the constraint is how many people you can convince to come and work for you.
And having those constraints makes it really hard to scale your program. So, you have all these great ideas, you want to go out into the world, you want to take your program to new places, to new communities, but you can’t get the budget or you can’t get the people.
And the great thing about champion programs is they let us scale in a way that doesn’t necessarily involve hiring new people, doesn’t necessarily involve spending lots of money. Instead, they allow us to leverage people’s excitement about our products and give them something back in terms of building up new skills, building up new contacts, building up a profile for themselves.
Why would developers want to take part?
Carla: So we started off a little bit on why champion programs can bring us a lot of value. But why do developers actually take part in it, given that it’s a lot of effort on their time? But let’s look into what they value, what we can give, as developer relations teams, to someone who is so enthusiastic about our platform that they’re crazy, they want to help and give extra time?
So, the first thing is access to key people. Any developer who will be able to talk with someone directly from R&D to have questions answered, or from the product team, it’s great, it’s a dream come true. How often do you get requests of developers saying, “Can I please talk with someone in R&D?”
Pretty frequently, I’m guessing. More knowledge will allow them to progress in their career so they will become the experts. By being champions, the companies are also saying, “These are the experts in this technology. We vouch for them.” And, as developers, sometimes it’s hard to find people with similar interests.
Being able to be in these groups, these champion programs, they will be able to find people that they have similar interests with and they can identify with them, share opinions, and, sometimes, they end up creating friendships that will last a long time.
And with the access to key people, obviously, access to knowledge. But this can go a little bit further. So, for example, champion programs often can offer access to roadmap, which is something that, as a developer, knowing where the technology is going will help them.
So these are, what we found, the four biggest values that developers find and why they participate in developer champions.
Matthew: Okay, so let’s unpack some of that a bit. Who here is familiar with the term social capital? Yes, you’ve all read Jono Bacon’s book. So social capital is this idea, for those who haven’t read that book, that when you work in a group of people, that you build up a certain reputation, kudos, whatever it might be, and you build up an idea with these other people that you have learned something, you’ve contributed something.
Why it’s called social capital is that you can then spend this effectively by furthering your own aims or whatever it might be. But social capital is perhaps a fancy way of saying that people are interested in building up value to the communities that they work with.
And I mentioned that this is something that Jono goes into in quite some detail in ‘The Art of Community.’ So if you want to read up more on social capital then take a look at that. But here is kind of a graphic illustration. So you, as an individual, are participating in a developer community and you’re doing your thing. And okay, you can be somewhat useful by yourself, as an isolated person, but you’re not going to reach your full potential for how you can contribute to that community but, also, for how that community can impact on your career, on your personal goals.
So let’s look at it in context then. You do some stuff and that brings you closer to other people, that affects other people positively, and that enables them to grow. And then, they’re able to do things that then benefit your community and that then comes back and benefits you as well.
And that enables us to, basically, as a group of people working together, as a community, that enables us to harness that power of greater returns on our activity to benefit the community but, also, to help ourselves. And a champion program is basically a framework for making that happen, enabling people to grow and benefit from social capital, and enabling your community to benefit from this growth in social capital without it being something that’s just left to chance. Instead, you create a framework that enables people to do this systematically.
And so, if we’re looking at the different types of champion program that you might have and that we’ve observed, seem to describe most of the champion programs that exist right now, then you need to come back to what is your developer relations strategy?
Why is your company pursuing developer relations? Now let’s look at some bars. Broadly speaking, the reasons you’re going to do developer relations relate to awareness of your product, education about your product, retaining developers because, you know, after a while, people might feel like they’re not being appreciated or they might grow bored, but also it’s about adoption.
So we have these four areas, these four pillars. But your priorities, as a company, will differ from another’s. If you are a fairly mature product with a fairly mature community, you might not be looking to grow awareness or adoption but you might be looking to enable developers more to get them to be more productive with your software, in which case, you’re going to focus on education.
And if you are perhaps a mature community, you want to make sure that you’re rewarding your developers and that you’re doing everything you can to make them feel that they’re getting as much out of this interaction as you are. And so, you’re going to look at focusing on retention as well. But perhaps you’re brand new, nobody’s ever heard of you, you’ve got VCs breathing down your neck asking for the 10x.
And so, you can really go for awareness, you’ll do some education, because you can’t live without it, but also, you’re going to focus on getting people to actually sign up and adopt your tool, whereas retention might not be something that you worry about right now. So, ultimately, we’re asking, “What problem do you need to solve in your developer relation strategy?” And once you know that, it’ll feed into what type of champion program you end up selecting.
Carla: So keeping in mind what Matthew just said, and there’s different needs, that’s where the four archetypes come from. So what do you need in your developer relations program? Let’s see which ones they are. So we start by Reward and Motivate, and we’ll go into depth in all of them in just a short while.
After that, we’ll have Force Multiplier, we have Content Factory, and last but not least, Land and Expand. So let’s take a second to look at Reward and Motivate. This is a program that will help you keep your community engaged.
So it’s very, very simple. You can almost consider this program the building block for anything else that you want to build on. So, it’s based on recognition, based on telling your community members, “Hey, you did a great job. You went to that event, you’re awesome. So let us recognize that. You’re not just doing this in vain.”
The reason why developer relations exists is because we care and we care for the developers. So this is one very easy way to show that. And it can be, for example, as simple an initiative, as just having a swag box. And you see that someone does an event and you say, “Hey, I’d like to send you something cool,” it can be as simple as that.
And trust me, it goes a long way in building relationships with your community and making sure that they stay and that they’re happy. So the goal here is to encourage community participation. And also, one of the benefits will be encouraging specialization in some of your products.
And, like we were saying, it keeps them motivated, it keeps them engaged. And one of the other benefits, is that it’s low-effort. Like I said, putting together a T-shirt, a couple stickers, a handwritten note, it’s five minutes out of your day. But the risk of it is that it’s maintaining rather than progressing the community.
You’re making sure that they stay there, so it’s more reactive than proactive. Which is not necessarily a bad thing. And if you don’t have a lot of resources, this is a good way to go.
Matthew: And just to add to that, so this is where you select people from your community who are doing a great job and you give them the status of a champion. And it’s because you want to recognize what they’ve done and you want to make it kind of formal.
Carla: So going to the second one, the Force Multiplier. So this is quite a different one. These are for developer relations programs that need a little bit of help in everything. So we can say that you sometimes, especially if you’re a person of one, two, or three, you will need an extended team. And as Matthew said before, there’s problems in hiring.
So this is a great way to achieve that. So, how is this different from Reward and Motivate? This program is a little bit more complex in the way that you can work in different areas. So you not only recognize but you will support them and help them take a further step.
So, for example, if you have a community member that likes to go and do meetups, rather than just saying, “Thank you,” you’ll say, “Thank you, now, how can I help you? So what can you do to make that meetup go to the next level?” If they like to write articles, “Okay, let me help you. We’ll help you with someone from content to review it.” Make them be better. So the goal of this really is to direct the community participation.
And here is, also, where if you need more content, if you need more events, you can kind of play around with it a little bit. One of the biggest benefits, through an extended team, you can scale growth. It is slightly hard sometimes because you will need internal buy-in because this will take a lot of resources.
And, if you’re not careful, you’ll have community burnout. And this is something that I’d just like to take a moment to talk about. Because sometimes we forget that people have lives. We forget that, you know, a developer who’s doing an event or who’s being active on social media or…that they also have their full-time job, they have their families, they have their hobbies.
And sometimes, we keep asking for stuff, “Oh, can you do one more? Can you go to this event?” because there’s a huge opportunity and you can’t make it and it’s in his city. So please remember that, if you want to maintain these programs working and healthy and have a healthy community…because if someone’s tired and you’re just abusing them, they will leave. Their wellness is also important.
We keep talking about how much wellness and well-being is important for dev rel teams but it’s also important for the community. So, just when on this note, this is a program that requires a lot of resources, it’s quite high-effort.
Matthew: Okay. So we looked at two program types there that are about maintaining or rewarding what people were doing and maybe channeling that into a way that better meets your particular dev rel program goals. But let’s look at Content Factory, this is one that you see, I guess, quite a lot.
And this is where you are, as a developer relations programmer overall, you’re looking more at building awareness, educating people, but also driving adoption. And this is really about spreading your reach in a very specific scalable way, which would be through content. So why content? Well, what can your team do in a week? You know, maybe you’ve got three people, you could perhaps, ideally, get one or two good blog posts out a week.
Because you’ll be doing events, you’ll be doing, you know, office hours, you’ll be doing whatever else your team does. So if you’re doing maybe one or two well-written blog posts a week and maybe a how-to guide, you know, you might slip a video in, but really, how far can you get with that? And also, if you do have the sort of events program that Laura was talking about earlier, then actually being able to get that done is very much a maybe.
There’s no guarantee that when you’re on the road, you’re going to feel like, or have the mental capacity, to write good content. So with the content factory, you motivate your community to help you produce more and more content. And that allows you to boost awareness because it will reach, hopefully, areas of the world or technology communities that you wouldn’t reach otherwise.
But it also allows you to focus or cover topics you wouldn’t have covered otherwise because you don’t have the internal speciality to do that. And so, you end up with a situation where you put up content, and then that touches one group of people, they become excited, you motivate them with your content factory, and then, they then, in turn, help spread the word and you end up basically winning more and more people, either just on an awareness basis or an adoption basis, for your program.
And the great thing is that, more and more, you will find that you have less need to do the content yourselves and the people in your community will be reaching new communities that you would never have reached. You won’t get everyone, but that’s fine. And then, you kind of come together and you’re all working as this amazing synchronized team, in theory.
So that enables you to create things that, previously, you would never have been able to create. So, you know, you’ve done those two blog posts but maybe now you can write an e-book, perhaps you can do something with some fancy graphs, do some movies, whatever it might be. Some experiments, who knows. And these kind of programs basically tend to come down to one word and that is influitive.
If you know influitive, then you know what I mean. But what I mean is that it tends to be that you’re running a program where you are gamifying the production of content. And it might well be that you’re using something like influitive, which is a tool you can buy, and you can rank people by the number of blog posts that they’ve written or the number of e-books they’ve written.
And what happens then is, in some communities, such as the MongoDB community, the way that they were doing was that you could then cash in the points that you’ve won, or you’ve earned, for actual real world swag. And that may seem, for some people, that may seem too commercialized, too gamified. But it certainly worked for MongoDB in getting a whole bunch of content out there.
Okay. So Land and Expand. This is the one that I think is particularly interesting because this is where you’re looking for awareness, you’re looking for adoption, and then, you have a very focused program on leveraging…I said that word again…on using other people’s ability and time to help you spread the program to places it just wouldn’t otherwise go to.
So, you know, if you’ve got an office in the Bay Area, in London or Berlin and Tokyo, that’s great, but you might also be thinking, “Well, I want to target India. And I know that there’s loads of good things going on in Brazil and, also, Australia. But we just don’t have the team to reach those areas.” So, you know, you’re sad about that, so what are you going to do? As the beer advert used to say, “Land and Expand lets you reach the parts that other programs cannot.”
So basically, this is about your community members becoming your on-the-ground reps in a particular city or tech community. You give them a program, you give them a framework, you give them everything they need to roll out the activities that are appropriate to your program, appropriate to your community, but they become the people on the ground who do it with your support.
And, effectively, the whole point of this is that they sign up new community members and this becomes a self-reinforcing program. So, you know, content is great online but it doesn’t necessarily give you personal connections. Reward and Motivate allows you to make sure that you’re doing the bare minimum to recognize people in your community.
But this one allows you to have a self-reinforcing, self-multiplying community program. So suddenly, you know, you can reach those areas and those technology communities, that you wouldn’t have been able to reach otherwise. And I think a really good example of Land and Expand is the GitHub Campus Experts.
And I think Joe agrees with me that this is a good definition of Land and Expand because it’s all about taking your program into places you would never go otherwise, either because of resources or because you lack the speciality or whatever it might be. And the great thing, obviously, is it gets you to new places, but the risk is that…well, there are two risks, I think, primarily.
One is it’s resource intensive. So okay, you’re getting returns from people who don’t work directly for you and they get something out of it. But also, it takes a lot of effort to manage this, to make sure those people feel that they’re not being exploited and that they’re getting something from it, but also, to maintain quality. The other risk is that, not only do you have to have a really strong program and put lots of time into it, but you’ve got to be very, very careful that you trust the people that you recruit into this program to act as your ambassadors on the ground.
Because they’ll be wearing your swag, they’ll be presenting themselves as, “Hey, I’m from so-and-so program.” So, effectively, they are an extended part of your team so you’ve got to put them through a recruitment process almost as vigorous as you would for someone that you were bringing on as an employee.
Okay. So how do you choose which of these archetypes is right for your program? Well, on a very simple level, look at what are the particular priorities of your developer-relations program overall and then try and plot it out.
Now, I’m not going to call this a magic quadrant, I’m going to call it, “A mystical four squares put together,” so that we don’t violate any trademarks.
Carla: It’s way better.
Matthew: So imagine you have a real bias towards awareness and adoption, then, you know, plot where you think you are, on this graph, and, you know, it’ll give you the answer. So anything over there is going to be, broadly speaking, Land and Expand. Anything that’s more to do with retention and education, or way down to retention, is going to be Reward and Motivate, most likely.
If you want to cover all bases, then Force Multiplier because you’re getting people to really just help you execute. And if you in particular are looking at awareness and education, then content is a really nice scalable way to do that. And if you’re rewarding people and motivating people to create great content, then you’re going to build awareness and, hopefully, you’re going to educate.
Carla: So we’re almost running out of time but there’s this really cool thing that we want to share with you. So everything that we’ve been talking about, we’re actually doing research on it. And we will have an analysis report, coming out in March 2019, about champion programs, so based on what the industry is doing, what trends, what’s working in what situations.
So, exciting times. Very easy to keep up to date with it, just make sure that you are subscribed to our newsletter. If you’re not yet, shame on you. Just kidding, just kidding, but make sure you do…get a lot of cool stuff. And that’s it.
Matthew: Thank you very much. If you want to get in touch, then [email protected]. Thank you.
How much do we think about the experience developers go through when learning new tech? How can we serve them better?
Naomi Pentrel from MongoDB talks through a framework for defining dev rel strategy for your team in this talk from DevRelCon San Francisco 2019.
Write for us