Early Approaches to Community & Content with Mux, Apollo GraphQL, and Camunda
In this session from DevGuild: Software-Defined Movements, our panelists outline a framework for engagement and how to forge a path to developer trust and love.
What are the advantages of developer communities and dev-first go-to-market? What role does content play in building value and loyalty? If a manifesto gets no Medium claps, does it make a sound? In this session from DevGuild: Software-Defined Movements, our panelists outline a framework for engagement, early strategies to systematize and scale community, and examples of how others have forged a path to developer trust and love.
- Matt McClure, Co-Founder/Head of Developer Experience, Mux
- Peggy Rayzis, Director of Developer Experience, Apollo GraphQL
- Mary Thengvall, Director of Dev Rel, Camunda
- Patrick Woods, Co-Founder/CEO, Orbit
Patrick: I’m very excited to kick off the event with a panel of extraordinary community builders and leaders from places like Apollo GraphQL, Camunda, and Mux. First, we have Peggy Rayzis. Peggy is the Director of Developer Experience at Apollo where she leads the developer relations and education teams, and she has a massive hand in planning and executing the annual GraphQL Summit which recently attracted more than 6,000 developers.
Mary Thengvall is Director of Developer Relations at Camunda, an open source process automation platform. She’s the founder and co-host of Community Pulse. She curates DevRel Weekly, my favorite DevRel newsletter. She’s also a founding member of the DevRel Collective Slack Community. And as if that weren’t enough DevRel things, she’s also the author of The Business Value of Developer Relations, the first book on DevRel as a discipline. I highly recommend for anyone here.
Finally, we have Matt McClure. Matt is Co-Founder and Head of Developer Experience at Mux and is the organizer of the SF Video Tech Meetup and Demuxed, the community for engineers working on video. The Demuxed conference has grown to attract more than a thousand attendees annually and helps to support independently run meetups in more than 25 cities worldwide.
So we have an illustrious panel with us today of folks who have been there and done that in terms of building communities and scaling them to massive size. So very excited to dig in. First of all, thanks to all the panelists for taking the time today to hang out with us and share your wisdom.
So I guess first to dive in and share a bit more context with the folks listening in, can we talk a little bit about the size of your communities today and the main ways people find them and get engaged? So Peggy, we’ll go to you first to kick us off.
Peggy: This is a hard one to pinpoint exactly, but we know that several hundred thousand developers are using Apollo’s open source tools. So kind of downstream of that, the actual number of developers who are actively participating in our community, attending our events, engaging with us, we estimate between 50 and 100,000 developers.
Developers are finding us through many different channels, obviously interacting with our open source repositories. GitHub is a main way. They’re also coming in through our content channels like the docs and the blog and our new learning platform Odyssey and through social media as well.
Mary: I think all of us are probably going to say it’s hard to pin down, but I will second that from Peggy. We have a couple different products as well as open source projects at Camunda. So when I’m looking at people who are aware of Camunda, using our products, contributing back, I kind of bucket things into a few different ways. We’ve got around a thousand people who are significantly contributing activly in our forums on a regular basis.
But then beyond that, we’ve got people who are contributing or starring repos or using the software, looking at the software, things like that. So I kind of take that 1,000 as this is a good starting point and people that we at least know a little bit about and then multiply that using the fairly common belief that
for every one person who’s actually active in your forums or active in your community, there’s 10 or so others that are lurking or using your software and kind of there, but you might not be aware of as much.
And that’s actually a goal of mine this year is to figure out a little bit more of who are the people that we don’t know, what don’t we know about our community members.
Matt: It’s similar situations with the others. We’ll talk about this more later, but there is kind of this difference between– we look at it as almost two distinct communities. There’s our community that we’re more of the shepherds, that’s the Demuxed community, this meetup community that we very intentionally don’t do the hard Mux sell into. It’s just a public community for video engineers. And then there is the Mux community of people that are using our products and thinking about it.
So on the Demuxed side of things, the video tech slack org is think around 8,500-9,000 people. Not all of them active but I think it’s probably a fifth of that is people that are monthly active users. The conference again as you said, it was like 100 people in 2015 but I think we had 1,200 last year.
Then the actual Mux community, we have much less numbers in turn because it’s less structured. We don’t have a public forum there. That’s all just developers using the products and thinking about it. Much like Mary, that’s something that we’re thinking a lot about this year is like, what should we be doing to foster that a little bit more because we have been so focused on that public community, but now we do have that need for the more Mux-specific folks.
Patrick: Cool. Thanks for sharing that context everyone. So I guess the level set a little bit for those in the audience, what would you say are some of the key tasks and goals of your community teams?
Mary: I can start here. We’ve got three main things that are top of mind at all times for us. Awareness, enablement, and engagement. And the main reason why I see that as our main focus is because that applies internally as well as externally. So as far as awareness goes, we’re making sure that external community members are aware of the fact that we exist as a company. They’re aware of our products and our offerings, the solutions that we have as well as our resources.
The community team is essentially a pre-sales team of sorts. My gut reaction to that was, “No, we’re not sales.” But from the sense of “we’re growing the community,” we’re making people more aware of the fact that we exist. We’re bubbling up adoption and all of that, it makes sense. So that’s the first awareness piece externally.
Internally, awareness-wise, we’re making sure that our co-workers know here’s what the community is saying, here’s the feedback that they’re giving us, communicating that to the right people and making sure that people are aware of the trends in the tech industry. The enablement piece is focused around making sure that people have a good experience. They have the resources that they need. They have the right steps to get set up with the product, all of those types of things.
What’s the best possible way that people can experience our product for the first time? How many barriers can we remove? Things like that. That enablement piece also goes not just for people who are new to Camunda products, but also for folks who are core contributors. So how easy can we make it for them to give back, for them to speak at conferences, or contribute code, or contribute on the forum, and making sure that both sides of that are easy whether they’re brand new or they’ve been around for a while?
Enabling internally looks like making sure that our marketing team is aware of what’s the messaging people are looking for. If our sales team is having a hard time explaining one of the latest features, let’s help out there. Let’s give some internal tutorials or create some reference guides, some examples that might help with that conversation a little bit more.
And then lastly that engagement piece, making sure that people feel like they have a place to come and engage with other community members as well as a place to engage with us employees of Camunda. And likewise allowing and enabling and facilitating those engagements, those connections between our co-workers and the community members. So it really is to me
one of the core things of developer relations and community as a whole is being that interstitial layer between the company and the people who are using your product.
Patrick: Mary, quick question on that point. You outlined a lot of stuff that you’re working on, so I’d be curious about what’s the structure of your team. Is this all you? Is this 100 people? What’s that look like so we can level set?
Mary: Sure. So I currently have a team of 12 people. We just onboarded a new person last week and we’ve got things split up into three different teams. So I have a team of developer advocates who are largely focused on the awareness and a little bit of the enablement developer experience, which focuses heavily on that enablement piece both for new folks, new to the products as well as our core community. And then community management focuses heavily on the engagement side.
So I’ve got five developer advocates, three people on developer experience, two community managers. I am lucky enough to have a larger team compared to a lot of companies.
Patrick: Cool. Peggy, what’s it look like at Apollo?
Peggy: Piggybacking off of what Mary said, our mission is to inspire and equip developers everywhere to be successful with Apollo. So my org, developer experience, we tackle that from a couple of different angles. So the developer relations team is all about how do we help developers at scale, how do we talk to them, figure out their pain points? Either create content maybe to help solve those pain points or bubble that feedback up to the product and engineering teams to help solve those.
We like to think that we represent the community to Apollo and we’re kind of bridging that gap between the developer community and our internal teams.
And then the education team is all about educating developers at scale. So how do we make sure that every feature that we ship has really high quality, awesome documentation to help developers be successful? We also built our new learning platform that we launched at the end of January, Odyssey which is really fantastic. It’s just this like super immersive video, code challenges, interactive place for developers to learn and to get them inspired and excited to be Apollo developers.
Matt: This is one of those things where if you ask 10 companies, what developer experience means to them, you’ll get like 18 different answers somehow. But for us, the way we’ve structured developer experience is, the high level mandate being, just make sure every developer knows about Mux and then when they find us, they love us.
So we actually structure where we have a full marketing organization. So comms, all of your marketing functions and then a full DX engineering organization, that’s everything from community engineering, which is more of your typical like DevRel type activities there, solutions architecture and support engineering, with that goal being a really, really tight relationship between anything that’s publicly messaged to a developer.
So the first time somebody sees something through paid search ads through to landing on a landing page to reading documentation and guides, to trying out that SDK example, through to signing up, onboarding, getting those funnel emails and then asking a question either as part of a sales call or coming into the site needing support.
And everywhere along that way, all those steps holistically are what creates this developer experience, what makes people excited to partner with you. It all needs to be authentic, and genuine, and messaged in a way that developers aren’t going to start feeling like it’s not the relationship they want.
So a little bit of a unique structure there. Maybe at least seven of those 18 answers would be something along those lines. Specifically on that community side of things, all of DX engineering plays some part in a lot of what Peggy and Mary have said. So there’s a shared responsibility of that documentation, guides, writing content, getting out there.
The community engineering folks are really the ones that are primarily focused on it. And their goal is both Mux-specific, but also just to evangelize video as a medium. So what cool things can we think about in terms of video at large? It’s great when it’s involved with us, but just in general we want people to be using video and thinking about it as something that’s more than just Netflix and YouTube but also what experiences are exciting for you to build around it and how can we facilitate that either through open source or our product specifically or things around the edges of our product.
Patrick: You all just described a bunch of high impact activities across your organization from awareness, education, onboarding, evangelizing a category. When it comes to community, how do you summarize success? How do you talk about it internally? How do you frame it up for your team? What are the top things you’re looking at as it relates to community and success?
Mary: I can start. It’s interesting. One of the things I’m actually struggling with right now is, what’s a single success metric that works across the entirety of my team with all of the goals that we have? It’s difficult. My team, no matter what division or department they are, we have the same mission, we have the same ultimate goals, but we’re working on a variety of projects at all times to push toward that goal overall.
So it’s hard to say here’s the one single metric that we’re tracking as a team to make sure that we’re heading in that direction. Something that’s actually on my plate for this quarter, this calendar quarter is figuring out a metric that denotes community health. So things like how active is our community? How much engagement are we getting? How quickly are questions being answered? And all of those types of things.
The approach that I’m taking to it is let me gather different metrics from different teams within my department and then use those to inform this overall community health metric because things like our community hub, GitHub org has its own success metrics to track. What’s the engagement that people have for the community contributed repos that they’re facilitating and maintaining? That’s completely different than the champions program we just launched a couple weeks ago which has completely different success metrics.
But if I can say, here’s the success metrics and the level of engagement for the community hub, and then here’s the success metrics that we’re seeing as for how well received the content is that the community champions are putting out, those can be two metrics that go into evaluating what’s the overall community health. And that to me isn’t a like pass fail metric. It’s more of a, I want to understand how healthy are we based on the specific goals that we have for our community? Can we consistently be improving on that quarter over quarter?
Patrick: So it sounds like a baseline to sort of build from versus like a KPI. Yeah, that makes a lot of sense.
Peggy: Just to piggyback on what Mary said, again, I think it depends, right? It’s so hard to kind of find that number one kind of like North Star success metric. I think the closest we’ve come is looking at monthly active users and seeing, are they engaged with the product? Are they adopting certain features? What does the open source adoption rate look like as a percentage of the react community for example. That’s something that we look at.
Then it just varies like program to program like the way that we measure success for an event, which we look at how many people attended and then NPS, did they have a great time? That’s very different than the success metrics that we use for our education platform where we look at the number of trained developers who completed 100% of the course and then looking at like course quality metrics. So I think there’s a number of different inputs. We’re still working out exactly what is the best, but definitely marching towards that goal this half.
Matt: I think, again, there’s kind of two different things here for us. On the Demuxed side of things that really all boils down to, and this will change over time as it expands, but currently it’s attendee count for that main conference, and NPS as well as the makeup of the speakers and the audience. Whether we reached new audiences, those kind of things. And that really ultimately helps us follow the track line of the size of the slack org. With every year there’s the big spike because we do Q&A and everything through Slack.
So everything ultimately comes back to the event size and then kind of funnels down from there. And that’s just, again, kind of growing that public community. Can we get more people involved in video engineering and help them feel supported? It used to just be that the primary people that we were bringing in there were those core video engineers, the codec engineers, the people working specifically on the player.
It’s been nice that it’s kind of grown to the edges of people working in that more application layer and are just more interested in working with video and thinking about it as an interesting technology. So that’s something I’m really trying to push and grow. That’s on the Demuxed side of things.
On the Mux side of things, ultimately the north star for us, especially for this year and on, is that customer count number. Just because that’s so tied into getting somebody all the way through that process successfully. Have we done our job making sure that we wrote the content that they found? Have we done a good job with making them successful when they did start using us? So really every piece of developer experience org from those awareness functions, all the way through to every piece of DX engineering plays a critical part in getting that developer from initial find through to a successful integration because customer for us is it’s all utility pricing.
Once somebody crosses that $5 threshold of usage post credits. Obviously, that’s like the one objective, here’s that metric that we’re really north starring against and then obviously things like organic mentions on Twitter and making sure that our response times and support are good, and that we’re getting back to people in open source projects and issues and pull requests that we’re actively feeling engaged and helping people feel supported on those fronts.
But all of that ultimately rolls up for the Mux side of things into that. Are we supporting people all the way through to a successful integration?
Patrick: Super interesting. So Matt you talk a lot about on the Mux side leveraging community as a path, putting people in the happy paths, product adoption, becoming customers. I didn’t hear that so much from Peggy and Mary with regard to product-related or revenue-related goals when it comes to success organization. So I’d love to hear some perspective on that.
The community is working if I get a lot of leads. Why shouldn’t I just say that because we’re a business? That’s just me putting on a silly hat. I don’t necessarily believe that. But I would love to hear some perspective on that world view.
Mary: I will jump in there happily, because it’s a conversation I have often. Luckily not at Camunda these days, but when I was consulting for different companies and also just as I’ve worked throughout developer relations, one of the top issues that I’ve seen with community teams not going in the right direction– I would say failing but that sounds too drastic but that’s probably also true where DevRel team is failing is– really when they’re forced to mix the community building side of, “Can I truly create the best experience possible for you and meet your needs?” With the, “I have money metrics. I have sales quotas. I have leads I have to deliver on…” Something along those lines.
Because while you might have the best sales team who truly cares about your customers and your prospects, at the end of the day their goal is money oriented. And at the end of the day, I firmly believe for developer relations community it’s “how do we create the best experience.”
When I worked at Chef software, we had a few different use cases and internally we all understood it, but externally there were companies that didn’t understand what we were doing because if people would walk up to the booth and say their use case and we knew we couldn’t fulfill their use case, but one of our competitors could, we would literally refer them to our competitors.
We’d send them over to the Puppet booth that was across the hall from us and Puppet employees would come back over to us later and be like, “What? You sent us leads.” Well, we can’t meet their needs. You can. And we actually had people that came back to Chef and use Chef at future companies because they remember that interaction, because they know you’re going to shoot straight, you’re going to give the truth, you’re going to tell them what they need to know to meet their needs rather than just what you want them to hear.
I feel like there’s a lot of that that goes hand in hand with goals. If the company goal is increase ARR this year, a community or DevRel team can still help contribute to that by awareness metrics, making sure that more people are aware of the products that you offer and making sure that more people are aware of the resources that you have, and the use cases that you can serve and the problem areas you can fit, and all of those types of things, which then embiggens the size that the sales team is pulling from, right?
But I’m not looking to my team to ever have those sales oriented questions around, “Okay, how big is the check that I have to write? Can I negotiate a contract?” Nope. I will introduce you to the right people to do that and we’ll hand off people to the sales team on a regular basis. But having the community or DevRel team responsible for those sales numbers at the end of the day is not generally speaking a good way to handle things, and I haven’t seen that go well for several teams in the past.
Peggy: To echo that, it’s all about building long-term relationships for us. I think like
today’s open source developers might be enterprise customers a year from now or they might not and that’s okay too. They might move to another company and then become enterprise customers down the line. That’s not the end goal for us.
It’s all about making sure they have a really great experience with Apollo and stay engaged in our community so we can keep building that relationship and just building upon it. It’s all about being authentic and having that long-term goal in mind, Apollo has been very supportive of that for our teams.
Mary: Yeah, and I’ll add on to that for a second. Even the folks who “only ever use the open source version,” if they’re excited about your product, they are now external advocates on behalf of your company because they’re excited about it. They’re talking about it at meetups. They’re mentioning it when someone says, “Hey, I have a need for X,” they go, “Oh, Apollo. That’s where you want to go. Oh, Camunda. That’s the product for process automation. Oh, Mux. Video stuff, yes, go there.”
They’re now advocating on your behalf and if your sales team is constantly reaching out to them or pinging them for, “Hey, you might want to upgrade.” It’s like, “Well, no. I don’t want to upgrade. Now, I’m pissed off at your sales team and now I’m less enamored with the product.” Right?
So I think learning that at the end of the day we can still impact the bottom line, absolutely. But having that barrier of “we impact the bottom line by growing the overall community, by reducing churn, by keeping people really engaged, by producing content” that is helpful for people to get on board which encourages them to adopt. Then potentially pay for the enterprise product down the line.
Matt: Thou hast slandered me, Patrick.
Patrick: Not intentionally.
Matt: No, I’m kidding. Internally, we don’t really use the phrasing “community” around that. Those are customers. Those are developers and we want to make them successful using our product when they’re on that path. When we talk about community internally, Demuxed and the video engineers are who we’re talking about, which is very explicitly: sales does not get emails to those things.
We treat the relationship in the same way that any other company treats the relationship. In some of those cases, we have to because we don’t even own some of those things. We are just a member of that community and consider ourselves, hopefully, good shepherds of it. But yeah, I mean, I completely agree with all that. I just want to clarify.
Patrick: I think the architecture of the relationship between Mux and your community, I mean you draw very firm lines between the folks that are in the video community and the customer community side of things. So I think that’s important to highlight, that you sort of bang the gong internally around that separation. It leads to another question, around how do you all evangelize the role of your community, or your different communities internally, and also protect them at the same time?
So Matt, maybe you could take that first one since I know you’re pretty intentional about evangelizing & protection as well.
Matt: We are admittedly in a weird position because Demuxed, the meetup, all this community stuff was built years before Mux started in some cases. Demuxed came a year before. So yeah, it already existed. It just had this core group of people. It’s organic and really special, honestly. I think in general, once you have that organic community that is working, it’s really, really precious whether that’s specific to your company, a support forum that turned into like a really great community, an IRC channel, whatever that might be.
Once you have that legitimately good authentic community feel, like it’s precious and should be cherished and treated really, really specially, because once you lose it, it’s gone.
So we had that organic community built up. We’re really proud of it. We love being a part of it. We think it’s really critical for the ecosystem. So as such, I do draw really, really firm lines internally around where, who has access to what. Like when we send out a sponsorship perspective for Demuxed, We started doing this last couple years when we started putting ourselves on the sponsorship list as an organizing sponsor.
In that sponsorship perspective, we send out to other companies including Mux, as an organizing sponsor here are the benefits that you get as that sponsor. It includes the number of tickets. It includes booth space, whatever else that might be. And if we want more tickets than that, we buy them as a company. We give ourselves the benefit of buying in bulk, so we’ll just put a bunch of tickets and then buy them all at the end. But we do actually buy all of our own tickets.
The revenue there doesn’t matter. Most of that is actually just to make sure that we’re crafting that narrative internally of this isn’t our conference. This isn’t our community. This isn’t your sales pipeline. We should be treating it the same way other companies do. We have that booth. We should be talking to the community. We should be using that. Sales can use that as a way to build sales pipeline.
But the community is the community and we are a part of it, not vice versa. The success there, people see it, people notice it, people appreciate how we think about content, how we think about the community. They see us being involved. They see us not ruining it. I think that that has led to a great halo effect. I think people respect us. People want to join the company. People want to work with us because of that relationship we have with that community, and feeling genuine, people not getting that hard sale, people not getting that pushy sales person because they attended a meet up one time.
Mary: I’m just going to say plus one. I agree.
It all comes back to developer trust. It takes years to build it up and you can lose it in an instant.
So it’s so important to evangelize to other teams at the company like sales and marketing, the value of developer trust and why it’s so important to our company’s success and helping them understand what do developers do? What turns them off? and helping them kind of infuse that into their work as well.
Mary: I think having those explicit boundaries as well as implicit understanding within the company helps when your company starts to grow. So one of the things that we implemented when I joined… I wanted to make sure that there was a place for my team to keep track of conversations they were having, engagement they were having with community members. “Hey, so-and-so spoke at this conference.” And it’s relevant for us to keep track of it. And instead of creating a whole new database just for my team, we have HubSpot accounts because that’s what the company uses to set off the MQLs and that whole process.
But when someone gets added to that database as a community lead, they are not a marketing lead, they don’t get any drip campaign emails. There is nothing that gets kicked off as far as their marketing generated lead. None of that process starts.
So my team can go in and add Peggy as someone who gave a talk at this conference, and we interacted with her in these ways. This was fantastic and we should follow up with her down the road. Here’s her programming languages. Here’s the thing she’s interested in, all of that. We have a way to keep track of the information. And if Peggy at any time then goes and signs up for CamundaCon, now she can start receiving emails about Camunda. And then if she happens to then click through on an email after CamundaCon about, “Hey, we’ve got this webinar,” then she’ll start earning those points to get toward that MQL status.
The reason why I feel so strongly about having that all connected is because then if someone winds up in the sales pipeline, our sales team now has all of that background history of Peggy has spoken at these events. She’s been involved in the open source community for years. She’s done these things. Here’s her main point of contact on the DevRel team, which gives them so much more context.
So they’re not suddenly just blind calling her, they can call her and go, “Hey, I know you were talking to Mary recently about these things. Would you be interested in hopping on a phone call? Mary could join us as well or this other person. Is there anything I can help with?” It helps everyone throughout the company, but those boundaries are also there to make sure that when Peggy first gets entered into our database as a community lead, the sales team isn’t going. Wait. Hang on. We have to grab her. Let’s talk to her tomorrow.
Matt: That’s almost like champion creation, which is really cool. I like that.
Patrick: We’ve talked a little bit about high level stuff, operational relationships between other teams in the company, getting a little more tactical, you all have thousands of people in your community. You have large teams to some extent. 10 or 12 people on your teams or more, but it’s still not thousands.
How do you manage those relationships? Do you segment your community? Do you have programs for champions for other things? What does that process look like so you can actually work with different segments of the community?
Matt: Let’s talk about this from the Mux perspective. We are in a simpler place than I think a lot of other folks that also have that big internal community, that big forum, that big Slack like the public Slacks, all those kind of things. I think we’re in a little bit of an easier place there because of not having those things, it allows us to have more of that one-to-one relationship with the folks that come through.
I don’t mean that in terms of like we have a better relationship. I mean, more like we know exactly who these people are and what they’re doing and like why, and there’s not kind of the complexity that comes with trying to figure out how to authentically manage that big public presence and community.
For us, it’s really like we can segment that into very clear lines of communication around what the medium is because we’re using things like Twitter, using things like GitHub issues, getting involved in Hacker news and Reddit comments, things like that. We kind of sidestep some of the difficulty there and we can be proactive in the sense of where we want to get involved and how, and what we want to put out there.
It’s a little easier for us to segment who can be reactive in the different organizations and communities and who owns what parts of open source repos and who owns getting involved in social and things like that. Then again, video dev and all this sort of stuff, we don’t try to segment it, we just try to get involved in the conversation. So that’s much, much easier. That’s just chatting and stuff.
Mary: My team has kind of an interesting challenge. I mentioned earlier, we’ve got a couple different products and projects. So we’ve got Camunda platform that’s our on-premise platform. We’ve got Camunda Cloud, which just went GA. We’ve got bpmn.io which is a process design platform that’s fully open source.
On my team, we’ve got two developer advocates that are dedicated to Camunda platform, two for Camunda Cloud and one that’s kind of a generalist that covers a lot of the topics on a variety of levels. So they definitely have their focus areas, but then we’ve also got within the developer experience team a role that we call technical community builder. So it’s someone who is on the more technical side and handles a lot of the back and forth with our core contributors from the code aspect.
So Rin is responsible for our community hub and making sure that that’s a good experience for people. They’re often getting feedback from core contributors and processing that and bubbling that up to the right places. And then our community team is kind of split between taking care of the meetup organizers, taking care of the champions program that we just launched. So they’re far more focused on the real core community members as well with some oversight on things like what’s the experience for the LinkedIn group? What’s the experience for the forums? How do we handle the general onboarding for those things?
I’ll be honest that we don’t have great ways right now for tracking like, “Patrick just joined our forum and within the first two weeks, he posted 18 times, which is a huge advantage spike kind of a deal.” We are using Orbit which helps us segment even further and kind of track some of those anomalies to a certain extent, but we’re still trying to figure out how do we catch those new people who are suddenly unexpectedly very engaged and we know nothing about them.
So that’s kind of our mystery area to a certain extent right now. But one of the advantages of having a bigger team is we have more people to have additional eyes on those places and go, “Wait, this is a new name. This is a new person. How do we make sure they’re feeling taken care of.”
Peggy: For us, we talk a lot about the GraphQL developer journey as a way to talk about our community. So we look at three stages and we orient those around a problem a developer is trying to solve. So the first stage is like zero to shipping, a proof of concept at their company then the second stage is shipping their first graph to production. Third stage is composing multiple graphs together.
So we have one dev advocate focused on each stage of the journey, so they can really immerse themselves in their pain points, figure out what problems are they having. Is there content that we could write to help solve them? Should we have more talks about this journey stage at our events or even host a separate event catered towards those developers? That’s been a really great way for us to map our content strategy to real developer pain points.
Then just to echo what Mary said about onboarding, we have so many different channels and open source projects between GitHub, and Discourse, and Twitter, and our learning platform, and our events. There’s so much. So onboarding is definitely one of those things that we’re looking to improve and make sure that we have a really awesome first experience for anyone who joins regardless of what journey stage they’re in or what channel they come through, but I think it’ll be really exciting challenge for the team to tackle in the months ahead.
Patrick: So you’re all very experienced community builders. We probably have a lot of people listening in that are just getting started or trying to decide if they should have a community, should start a community. They want to get going, but they don’t know how. So I’m curious if you could zoom out a little bit and introspect a little.
What’s some advice you would give yourself thinking back to when you were just getting started? If you only knew then what you know now, what are some things you would share either nuggets of wisdom or things to avoid or points of inspiration? I’d love for you to sort of introspect a little bit and share some of that wisdom with some of us noobs out here who are just getting started.
Mary: I think the biggest thing for me is something that I’ve been saying for a few years now. I mentioned it in passing earlier that I really believe that DevRel and community work is that layer between the company and the users of the product. And the mantra for lack of a better word that I go back to so often is, “to the community, I represent the company. To the company, I represent the community,” and I have to have both of their best interests in mind at all times.
And that’s such a difficult balance, but I think it’s so important because if I’m not representing the community internally, if people aren’t aware of the conversations that I’m having or the feedback that I’m being given, or the things that I’m seeing, they don’t have a way to act on that and provide a better product or better resources, but vice versa, if I’m not doing a good job of truly representing the company externally, whether I agree with the decisions the company is making or not, then the community isn’t fully informed and aware of the choices that they need to make and I’m not able to respond and react to what they’re saying or what their needs are.
Anytime anyone says, “Well, how much time do you spend externally engaging with community members versus internally with the company?” To me it has to be 50-50 because if it’s not, then someone’s losing out and it usually at the end of the day is the community members who aren’t getting the responses they need or the product that they’re looking for or the help that they need to get onboarded, and that’s not a good situation for anybody.
Honestly, not bringing up that engagement internally is what I believe leads to a lot of community or DevRel teams being let go because the company doesn’t understand the value that they’re bringing because we aren’t spending that time internally saying, “Here’s, what I’m hearing. Here’s what people are saying. Here’s what’s going well. Here’s what’s not. Here’s how this contributes to the overall value of the product.”
Matt: My advice would be from the side of not having a community coming into the company, which would be document more. Make more things explicit rather than implicit. I think for years, all of this was just my personal force of will and not letting anybody else touch it, which is not healthy or sustainable. I just held the community relationship and logistics around that really tight to my chest and the people that did start working on it, I would say really scary mean things to them about abusing it.
There was an aha moment where we did write down, when we put ourselves in that sponsorship perspective for the first time and enumerated our benefits. I think it really helped a lot of people internally better understand more explicitly the relationships we had as opposed to me just being like, “Don’t mess it up.” So in retrospect, if I could go back in time to 2015, I would tell myself to really think about writing down and documenting what you feel strongly are the core tenets of the relationship between the existing community and the company.
And in the terms of like things like in events explicitly bestow the benefits and enumerate them so that everybody’s on the same page, it makes community members feel better, makes other sponsorships and other corporate entities feel better. But just in general, I wish that I had done more to explicitly document and write down and talk about the relationship earlier, because I think would have helped me share more of both the work and the enjoyment of the interaction more if I’d done it.
Peggy: I have two big lessons. The first is just to be really clear about goals and intentions with your community. I think when you try to mix those community goals with maybe sales goals or revenue goals that’s where things start to get messy. I remember the first GraphQL summit I ran, I took it over from someone else with about three months to go. It was our least successful summit ever. We had these sales pitchy talks in there and the NPS scores were not good.
The next year we had to look and say like, “Where did we go wrong?” And we were very explicit that, “Hey, this is not a sales event, this is to push the GraphQL community forward.” We want developers to have a really great time and to have best practices that then they can bring to their teams on Monday and have it be really practical, technical content. And that’s what we did. In the next year, the NPS scores were wildly better. So just be super crisp and clear about goals and intentions.
You always want to give back more than you take from the community. You shouldn’t be using it as a broadcasting channel, it should be more about “how can I create value for my community and give back” whether that’s paying open source developers for their content contributions and work or evangelizing their efforts and giving them a platform. You should always be thinking about giving back and creating that value.
Then I think the other lesson is just I wish I would have gotten more serious about metrics earlier. Granted, the tooling didn’t exist so much. Now that we’re using orbit, it’s this single pane into our community efforts and being able to see like Twitter and GitHub and Discourse and events activity all in one place has made it really great for just like evangelizing our efforts across the company and now we have the open source engineering teams using Orbit. Like customer success kind of looking in even like the talent teams are scanning that as well.
Patrick: That was unprompted pitch from Peggy there, just to be clear.
Matt: Can I ask how much you’re paid for that, Peggy?
Peggy: I’m not getting paid, I swear.
Matt: We’ve got paying community members.
Patrick: Speaking of above board community management here. If anybody else is interested in product placement, slide into my DMs. We’ve got a few more minutes here. It leads us to one of our favorite questions. It’s about tooling and what else is in your community stack. So some of you have mentioned Orbit. Thanks for that.
Aside from that tool, what are some of the things that you rely on or that you’re excited about? At Orbit, we talk to people all the time and they’re asking about who’s using X for Y. What’s the hot new stuff? So we’d love to hear either hot new stuff or things that maybe aren’t hot or new, but that you rely on for your community stack.
Mary: I’ll mention an internal tool that we’re using. Internally my team is using it, not that we built it internally. And it’s less about tracking metrics or tracking community members, but we use Trello for our team task board. I used to have far more of a love hate relationship with Trello from the standpoint of like, “I don’t fully understand what’s going on and the documentation isn’t great.” But there’s so many add-ons these days and so many things that help us as a team keep everything straight.
And for someone who’s managing a fairly large team and almost every single person is doing something different, being able to see at a glance with labels, for instance like, “Okay, what’s all of the content that’s in the pipeline from my team directly right now. What are all the speaking opportunities that are in my team right now? What’s the main focus of our quarter?” If I have an executive come over and say, “Hey, what are the three top things that you’re focusing on, not project wise but just goal wise?” I can look at the task board and go, “This, this, this.”
So it’s a huge help for me just keeping a bird’s eye view on what the team is responsible for when there’s so many different projects that we touch. The other piece of it that I love is that as someone who’s managing a global team, we’ve got people in the states. I’ve got people in Germany, in UK, in New Zealand having a review column, means that we can leave asynchronous feedback.
Someone can tag me in a comment, in a card or tag the other community manager or tag someone else entirely on the team and say, “Hey, when you have a minute. Could you look at this blog post? Could you make sure my process model is correct?” We can leave that asynchronous feedback in a single place that everybody’s in day to day rather than some things are in slack, some things are in email, some things are over here.
Whether you use Trello, or Jira, or Asana or something else entirely, having that single place where you can go that has the labels, the information on what everyone is working on that people can comment on has been life-changing. Sounds extreme but for someone with my organizational brain, it’s been life-changing.
Peggy: I think for us it’s been Zapier. We have so many different channels, so many different programs that we’re running. The more that you can automate, the better. So we’ve been using Zapier a lot to just like, “Someone signs up for this event. Send the data here. Send it there.” The less manual work that your team is doing the better because that glue work, it takes up a lot of time. And if you want your developer advocates to be spending more time relationship building instead of building data plumbing infrastructure, definitely try to automate as much as you can.
Matt: We use a lot of Notion for both documentation and editing. Our tracker is all like a giant Notion board. It actually really sucks for that. And we’ve scaled well past it being okay for that as a usage. So we’re exploring other ways there. That’s not a knock-on Notion, it’s just like we’re past it.
Mary: It no longer fits your use case.
Matt: We’re past that. We’re past the Notion Kanban Board working for what we use it for. The really special one that I’ll shout out that I’ve loved is Tito as a ticketing app. So if you ever do an event, I think I’ve tried all of them, but Tito is reallyy great. We wouldn’t able to have the events we have. Like Meetup, it’s an abomination, but still a necessary evil for us. And we’re excited about hopefully one day being able to switch to Tito for that.
Patrick: The video platform we’re running on today is called Vito. It’s the second product from the people at Tito. So a little synergy there. I’ll give a plug to a couple since we’ve got a couple seconds here. One, we’ve had a lot of success with a tool called Icebreaker. This is a fun thing where you basically invite anybody you want, your community and everybody sort of shows up in a waiting room and then the matching platform actually randomly drops people into one-on-one video calls.
And you can set the timer, so we typically do like five minutes. So you got five minutes, here’s some prompts and then the best part is that at the end of the video actually slowly fades to black and there’s nothing you can do about it. You can’t extend the conversation. It’s just over. It’s been a great way to facilitate many-to-many conversations between people in the community. So plus one for that one.
There’s a new audio platform called Racket. It’s basically like a nine-minute podcast where you can jump in. It’s sort of like a clubhouse kind of a room thing, but it records it and then you can share that link out. Our community lead, Rosie Sherry has been doing these with people. She’s got this thing called Communitree, which is like branching community-based conversations. It’s a very Rosie thing, if you know Rosie. But she’s using this thing Racket to just jump into a room, have a chat with someone in the community and then share those insights around.
So we’re big tools people. Always happy to talk about tools. Conversations always go that direction.
Mary: I’ll bring up one other tool if that’s okay.
Mary: To end our community summit a couple weeks ago, we had a networking event in this platform called Wonder.me. I thought it was okay when we were doing the testing and like, “Okay, sure, fine. It’ll be fun to try out we have an hour to hang out with community members and whatever.” Essentially, you hop into this online forum and you have video and audio. And as you get closer to somebody, your video and audio turn on, so that person can see and hear you.
But the thing that I thought was really cool, because we figured people would just be bumping around talking to each other if they want to and people aren’t going to hang around very long, but we had designated topic areas. So if you want to talk about this product, come on stand over here. If you want to just talk about this other random thing, talk about animals here. Totally random, non-conference related conversations.
But standing at my computer, watching people kind of like, “Oh, they’re over here. Okay, now they’re going to go to this side of the room. Now, they’re going to head over here. Now, they’re going to go in this direction. I had such a huge grin on my face that my face hurt for like an hour after we’re done with it, because it felt so much like a conference hallway track, where the circle automatically expands to include more people. And once you’re done with that conversation, you can say goodbye and go see your other friends over here.
It was just such a cool online way to bring back some of that conversation, hallway track actually getting to hang out with people that we miss with the online events.
Patrick: Great add. We might give that a try. That sounds like a lot of fun.
All right. So we’ve covered a lot of ground today in the past 53 minutes or so, everyone. Thanks again for joining the panel. We covered rules of engagement, how to build trust, how to communicate internally, tools, tactics. I love it. This conversation was every bit as dense as I expected it to be. So thanks again to all of you for joining. It’s been a real blast.