After meeting at Web Summit 2016, GitLab developer advocate Amanda Folson sat down with Jasmine Anteunis of Recast.ai to chat about how GitLab approaches community-building, including a deep dive on developer advocacy.
Some key takeaways include:
- Public speaking is only one facet of dev advocacy; nurturing communities is the most important thing.
- It’s important that dev advocates aren’t just additional sales people. They should seek to be genuinely helpful for developers’ education and experience.
- For people who happily use a competitor’s product, dev advocates should have a ready value proposition for whomever they’re speaking with (e.g. developer or manager).
- It’s tough to put metrics to events, but you can develop “fuzzy metrics” like event attendees or traffic to certain site pages over time.
Jasmine: What exactly do developer advocates do?
Amanda: It really depends on your product. The universal thing is finding out where the developers actually are, which is harder than it sounds sometimes. They may be hanging out in specific communities – we found out we have a lot of people in the JavaScript community, we’re starting to see more people in the PHP community, and we get a lot of attention in the devops space as well. I generally call ours the ‘spray and pray’ approach since developer relations is relatively new here. I’ll submit talks to a bunch of events, we’ll sponsor a few things, just to kind of see where we fit in and the kind of feedback we get. Public speaking is the most discussed facet of dev advocacy, but it’s only one of many. I spend a lot of time responding to people on Twitter – people ask me things or hit me up for stickers and our tanuki t-shirts.
Once you find developers, you want to work on nurturing those communities in any way you can, so we also do a lot of developer education stuff. I’m working with people in the PHP community to help solve their problems, but not necessarily in a way that means GitLab is the answer. I just gave a talk about scheduling on-call rotations to help prevent burnout, which has nothing to do with GitLab directly, but it provides a window to talk about things that are affecting developers.
Jasmine: So how does developer relations interact with the sales process?
Amanda: I don’t ever want to approach developers like I’m selling something to them. The focus instead is to educate them and add value on something else, because it helps build a good relationship. Developers don’t really respond well to traditional marketing and sales. My job is really developer happiness. That means that I’m rarely selling them on GitLab itself, I’m finding something else that might meet their needs, so I need to have an understanding of that competitive analysis and be willing to speak frankly with them about it. The product marketing and content teams do a lot of things to take care of the buzz and lead generation. That works pretty well, because it’s not coming from a developer but developers still pay attention to it. And at events, if I’m talking to someone who starts asking pre-sales questions, I find a sales team member and bring them over.
Jasmine: How do you talk to people in the community who already use a competitor of yours, especially if they seem happy with that competitor?
Amanda: We have value propositions that we give to explain why it’s better to use GitLab; this really depends on exactly whom you’re speaking with. If we’re talking to a manager then we talk to them about pricing and how GitLab might help their team perform better. We have a whole series of tools with messaging framed around each specific use case.
For developers, we talk about how we can help solve their problems. So, for example, GitHub has this issue where you kind of piece together your own experience. If you want to do testing, you have to bring in a secondary service like Jenkins or CircleCI or something. Or if you want to do issue tracking, previously they didn’t have any sort of issue board, and people had to bring in something like Trello. Because you had to go to all these secondary services to make GitHub work for you, our value proposition there is, “You don’t have to do that with GitLab.” We have all that stuff included; you need private repositories, great, GitLab.com is fine for you even if you want to run your unit tests and things like that.
Jasmine: If I talk to my CEO and have to make a plan for the next month for how to attract developers and keep them happy, how do I measure which actions are really impactful? For instance, how do I prove that networking with a few people at an event is worth the time spent?
Amanda: That’s actually the million dollar question in developer relations, because it’s really hard to attach dollars to individual actions. You can do a lot with what we call “fuzzy metrics” because you’re not going to figure out the ROI of something like chatting with people at an event, but you can get a better sense of how you’re doing overall. For example, we look at the number of people who attend an event or your talk at a bigger event. That’s a fuzzy metric but it tells you something about your reputation in a community. For example, if you’re at a 3,000 person event, and only two people show up to your talk, then maybe you need to work on building up your reputation in that community. But, if 500 people at that 3,000 person event show up for your talk, then you’re doing pretty well. Similarly, if you spent $5,000 sending people and setting up a booth, but you land a $250,000 account, that was a great event for you.
I like to put links to content in various places in my slides, and you can see how many people actually visit and click through. So for example, we had 50 people attend this talk and 70 people clicked this link, that means people probably shared it. We look a lot on social media as well – if we see a lot of unhappy people then we work on that; if we see a lot of happy people then that’s great feedback too. We also look at traffic over time to different things, like the forums or even different parts of the website. You might create a landing page for developers or some developer education topic, and you want to see that trend upward over time of course.
Jasmine: We are a small team, and our developers are also our support team and developer relations team. How does it work when support, developers, and dev relations are separate teams?
Amanda: There are a few ways this can work. Our support team now primarily takes care of our enterprise customers. They became too busy to respond to questions on social media, and our developer advocates also had a hard time managing questions from the broader community because we travel all the time for events. I have a personal policy of not having my head down in my laptop constantly at events, because I want to be free to talk to people while I’m there.
So we created a community advocacy team. They do a lot of community management things like responding to people on the forum and on social media. The interview process for that is very similar to the process for support; they need to have experience with Ruby, they need to be pretty technical, we like them to have some development experience. It has been a learning experience, but that’s how we tackled it.
Jasmine: If you had to choose, would you say it’s more important to devote resources to online engagement or to attending and sponsoring “real” events?
Amanda: The best approach is to do both, because one way is enterprise focused and the other is more grassroots focused. Enterprise includes large companies that might be willing to give you a lot of money, so you definitely want to be paying attention to them. The grassroots-focused events might be language specific, like PHP conferences and meetup groups. The enterprise group tends to respond more to the blog, press releases, and traditional marketing and sales stuff. Grassroots community members, on the other hand, appreciate the much more technical content; we’ve done a lot of posts on “Here’s how you use GitLab CI utility to run your tests and deploy your code.” The technical audience really responds to stuff like that, they also really like when someone is paying attention to them on the forum and online. If you had to pick one, you can get to both of those groups online. Ideally you would do both though, because it helps people to put a face to the name.
Jasmine: How do you recognize users who are influencers in your community? How do you identify them and make sure to keep them happy?
Amanda: We’re working on making this a bigger part of our strategy in 2017, but right now we recognize people who contribute a lot. Contributions come in various forms, but we have a Hall of Fame where we list the MVP from each release, along with people who contribute the most per month, for example. We actually tend to hire a lot of people who end up on that list, I think all of the top 20 now work at GitLab. We also pay attention to people who help out on the forum a lot, and people who don’t work for us but respond to questions on Stack Overflow and Twitter. We like rewarding people who boost the signal a little bit, we try to say thanks or send them swag, or we invite them to our Summit meeting. There’s no threshold for number of contributions, because it also depends on the nature of the contribution.
Ultimately we’ll create a group of ambassadors who want to talk about GitLab, at local meetup groups for example. We’re trying to create a system for sending them materials to help them get started. We’d like them to become developer advocates of a sort, in a way putting myself out of a job. We’re not paying them, they’re just doing it because they’re really passionate about the technology, which adds a bit of authenticity because they really care about what we’re doing.
Jasmine: What’s one last big tip you might give me?
Amanda: Keep tabs on what’s going on in the broader tech community - I look at Hacker News a lot, and Reddit and Twitter as well. Definitely keep track of what people are talking about; this helps you strike up conversations at events and gives you a little bit of developer cred as well. If you’re a developer at all, then keep those skills sharp. Over the past three years I stopped really shipping code and I feel like it’s been detrimental. One of my goals for 2017 is to write more code so I can stay in the weeds in conversations. You’ll get lots of language-specific questions across the whole spectrum, so ideally you’ll be somewhat familiar with Ruby, JavaScript, golang, and PHP, and at least be willing to go look for the answers when you get questions. That’s where it helps to have a great network of people – I know people in the community who I can poke when I don’t know the answer to something and ask for help. So keep those skills up and look out for the next trend in technology; that way you can be ready to predict where developers are headed next.
Recast.AI is a french artificial intelligence startup focusing on conversational interfaces. Built on a strong language processing technology, Recast.AI allows developers to easily create their own bots through a collaborative platform and API.
Follow Recast.ai on Twitter.
Tweet @GitLab and check out our job openings.
