A lot gets written about community growth in terms of tactics and strategies, but how do you get the buy-in necessary to scale your community? And at scale, what little issues come back to bite you in a big way?

We spoke to Kurt Kemple, Founder and Principal Advisor at Forthright, who was previously Developer Relations Manager at Apollo GraphQL and helped grow their community from 17,000 to 50,000 members in 18 months. We also chatted with Abby T. Mars, Chief of Staff to the CTO at Orbit, who spent over 10 years at Stack Overflow in various community-facing roles, including Community Growth Team Lead and Director of Community Operations and Management. Together, these two community experts delve into their firsthand experiences, giving us an inside look into what it takes to successfully scale and manage a thriving community.

Getting the buy-in necessary to enable growth

Apollo has long understood the value of community as an organization, but in late 2019, they made their first dedicated developer relations hire. Up to that point, community evangelism had been a shared responsibility with everyone in the company helping out. 

"That was just the start. To grow the community, we first had to make community not only be a concern for DevRel, but make it a companywide priority,” says Kurt. “To do that, we needed to change our culture and become community-first.”

“We started by making everybody aware of community issues, what's going on, highlighting trends, and things like that.” The goal here was to "consistently update the company on community activities, customer pain points, and use that platform to actively seek advocates for community across the company by getting them to see the benefits. We did this by establishing a community strategy meeting. That's where I started introducing community to other teams and showed the value community could provide them.”

One company-level priority, for example, was hiring. Kurt showed Apollo’s talent acquisition team how they could help source candidates using community data and recruit from within the community directly. 

“We'd find active people on GitHub, look at their engagement history with us, and refer candidates for roles the Talent team was looking for,” he explains.

The other thing they did was make their community reporting just as data-driven as other teams. 

It becomes way harder to get buy-in for initiatives that are not backed by data”

“Qualitative data has a limited life expectancy. You can't rely on anecdotes and stories forever. As companies move from being startups to scaleups, they become more data-driven. And not having systems in place to measure community engagement in a way that's consistent with how other teams report their data holds you back. No one has the time to dig through 15 pages of Discord messages. They want to see reports and trust that those numbers result in driving impact. It becomes way harder to get buy-in for initiatives that are not backed by data.”

“Something else we did was get our community data flowing into our data lake. That way, community data could be included in all decision-making. We spent a lot of time setting up data pipelines to get our data into downstream systems. With that groundwork laid, we needed to show the importance of community to the business so that we could make a big push in getting community initiatives included in our yearly planning.”

The key to that was “showing that there's no separation between our customers and our community,” says Kurt. "The two groups overlap almost entirely. So we had to break down the idea internally that customers and community were somehow these different things. Once we’d established that connection, it opened up the door for us to access a lot more resources — from getting help from customer success and sales teams to marketing, product, and others. It helped us advocate for expanding our community initiatives and why they're so important. Our team grew from me as DevRel Manager and one other developer advocate to having a director of developer relations with a developer advocacy team and a dedicated community team comprised of a community manager, a DX engineer, and two community advocates.”

Aligning company-wide on community strategy

“We then established a companywide strategy for community,” says Kurt. They tackled this in two ways. First, “a community team dedicated to the actual tactical day-to-day work of community building. The role of that team ultimately is to gain insights from the community and provide that invaluable context to the rest of the organization. That context is useful in finding alignment, or misalignment, between our company goals and our community's needs."

“Apollo has many touchpoints with the community across different functions,” explains Kurt. So the second thing they did was create a community working group to help disseminate that context and insights throughout the rest of the organization. That working group was formed with internal champions from each team interacting with their community. That "included representatives from Open Source, Sales, Customer Success, Marketing, and DevRel," notes Kurt.

No one has the time to dig through 15 pages of Discord messages”

As they scaled, some issues began to arise. For example, “messaging and tone would become fragmented across platforms,” says Kurt. “We needed a way to fix that, so we used the community working group to provide training.”

“While one of the community advocates would spend their time working with the community directly — being active in the Discord and on the forum. The other advocate split their time between the community and working internally, providing training to working group members who would carry that knowledge back to their departments.” In this way, the working group proved to be an essential part of successfully growing the community. 

The ranging needs of community segments

Stack Overflow has been a vital part of the global developer community since its creation in 2008 and now averages over 100 million monthly visits. Operating at this scale highlights a number of issues that might not be apparent within smaller communities. But as Abby explains, it’s important to catch them early before they turn into problems. 

“For a long time, we didn't understand that different users have different needs from a community team. A community is not a monolith. There are people with different levels of engagement, different histories with the product, and different experiences of the company. They don't all need the same thing from us. Depending on who you're talking to, you need to change your approach.”

“An ongoing issue for us was clearly defining what we meant by community. It could be anyone who touches the Stack Overflow site or anyone with an account. It could also be anyone who is a moderator or the people who go on 'meta,' which is where users discuss the workings and policies of Stack Overflow itself. We didn't have a framework like the Orbit Model to give us the language to describe the different levels of engagement between users, which led to a lot of coordination issues. Who should we focus on, who is the community team responsible for and accountable to?”

With millions of users the little subgroups that emerge within the broader community aren’t so little anymore. They can be vociferous groups; eager to have their opinions heard and be understood. “Our most engaged and long-tenured members often demanded the most attention,” explains Abby. “But we weren't always able to provide that. Product priorities might mean that we needed to focus on making the site more usable for new people, for example. Our core users would feel abandoned when the company focused on features for other groups. So it could be difficult at times to know who we should be listening to.”

Using quantitative and qualitative data to gain understanding

These issues did not emerge due to a lack of data, though, it was more about the limitations of it.

“Data was everywhere inside of Stack Overflow. We'd look at several Stack Overflow-specific stats, like the number of questions and posts created and how many new questions were unanswered or downvoted. But that only told us about users who were already engaged enough to have an account and write a post,” says Abby. “So we introduced an NPS-like survey in the sidebar that anyone could take. Then we could track anonymous people, those without an account or not logged in, and how satisfied they were with the site.”

"We also had voting tools to see that, for example, 500 people had voted on a particular feature and only two downvoted it. But only a small subset of the entire audience would bother to create a feature request or vote on stuff. So we needed to undertake research through surveys, focus groups, and UX studies to target all types of members, those we might not have heard from otherwise, so we could ask them one-on-one [questions like] what do you want? and how can we make things better for you?”

We needed to create space for different kinds of voices”

“Something that did help was our core value of defaulting to public,” Abby explains. “We'd socialize ideas as early as possible, showing people what we were working on so they could give us feedback. That saved us from going down a lot of wrong paths. Some of our most painful lessons learned were when we didn't do that and ended up spending months building the wrong things.”

Given the size of the Stack Overflow community, increasing top-line numbers was not a priority. Instead, community growth for them was more about increasing the diversity of its membership. 

“It was too homogenous,” notes Abby. "It was just one audience controlling everything. We needed to create space for different kinds of voices by making the community more hospitable for any kind of user, not just the main group that made up our community at the time.”

Adapting team structure to community needs

To try and fix these key issues they tried adopting different team structures. 

"We tried one built around the different sites that comprised the Stack Exchange network and the International Stack Overflow variants. We had specific community managers for each international site, like for Portuguese-speaking members, etc. That lead to each community getting a different kind of approach, or standard of care.” 

“Some community managers would be super engaged with members, talking to users all day. Whereas others were better at getting issues unstuck, navigating the company internally. And others preferred the product liaison stuff. We realized that each group of sites was getting a different experience of the company. So instead, we switched to using each team member’s skills across the entire audience, which was more successful. In that approach, the team was divided by type of work instead.”

We discovered early on that community operations was critical”

"We discovered early on that community operations was critical. It was something that had not been done before internally as a discipline. Before that, everyone shared a little of the responsibility. Community operations was our first specialization. Specific people were assigned to synthesize the community's product insights and handle the support tickets filed and tools used. Then eventually, we broke out other areas too, like trust and safety, and those focusing on product liaison. Title-wise, everyone was still either a community manager or a community operations manager, the other designations like product liaison were just used internally.”

Stack Overflow landed on a 'Jobs to be Done' inspired model, and “community operations was the big key that unlocked all of it,” says Abby. “Community operations is a role that you sometimes don't think of until it's too late. Being clear about who is managing the flow of information, the tools you're using, and how you're doing the work is essential. Those things become painful at scale unless you've got people dedicated to paying attention to it.”

Healthy growth needs more than tactics

Community growth is a multifaceted thing. As Kurt and Abby have made clear, while we can employ different tactics and strategies to increase the size of our communities and strengthen member relationships, that is not all we need to focus on. We should also ensure we have the resources, team structure, and processes to support that growth, along with a deep understanding of all parts of our community so that we can continue to deliver a great member experience even as we scale.