Building Communities - My Top 5 Learnings

Developer Advocates are the Swiss Army Knife for building Developer Communities; highly versatile, support users independent of developer expertise, and able to get users on-boarded into the wilderness of developing with a specific stack. Considerations

This post highlights my experience of developing community programs to work towards building a thriving developer community. The key takeaways are:

• We can learn a lot from community engagement in social projects. When we want to provide support to local communities, we tend to make assumptions based on "needs assessment" and then provide outside services and resources to address these perceived needs. This approach often leads to misunderstandings between program managers and the community.
• If you do not steer and respond to expectations of community members, they will become disengaged and leave the program altogether.
• When building a developer community, focus on unique experience and 1:1 engagement before scaling too quickly and losing highly valuable community members in the process.
• While you design and before you iterate your program, think about what stage your program is in. Iterating on your program too early or too late may reduce the quality for its current members.
• If you or your team members are not excited to engage with the community, provide support, and share initiatives, then you should iterate on your program and community strategy. Ultimately, your team-members should be your toughest critics and super-users.

The Story

I am working as Developer Advocate with an open-source blockchain project since about a year. My original job description was something along the lines of contributing to content management, working closely with our developer communities, on-boarding new developers and contributing to the documentation and product features.

After our community manager left the project, I picked up the efforts of coordinating and engaging our community. Within that role, I launched two Community Programs that focus on empowering developers within the community to take ownership and contribute to the project's vision. Developing the programs required lots of:

• Background Research – I needed to know what everyone else was doing and what seemed to be effective;
• User research – Developing a community program is one thing but understanding the experience and effectiveness of the program for contributors is a complete different story.

The next sections highlight my top 5 learnings in the process of building the programs.

Shut-up and Listen!

Listen and if you are done, ask questions and listen more.

While building communities we tend to make dozens of assumptions without continuously verifying those. We make assumptions about our community, their interests, and the experience we provide. We might have ideas about who our ideal community persona would be, their motivations and the resources they want to provide, but the reality is often quite different.

Before developing our first community program, I had several calls with ambassadors and contributors in other community programs to listen to their experience. This allowed me to match the information provided by the company that was running the program with the experience for program members. Based on this information I made several design choices for our own community program; one of which is outlined in the next section.

We can learn a lot from community engagement in social projects. When we want to provide support to local communities, we tend to make assumption based on "needs assessment" and then provide outside services and resources to address these perceived needs. An alternative approach would be to enter a community with the premise that the community possesses various assets that can be used and leveraged to work for desired change.

This TedTalk provides a great overview of what can go wrong if you fail to listen.

To learn more about community management in social projects, I highly recommend the following course on Community Engagement by the University of Michigan. The screenshots below are taken from the course program.

Key learnings include:

• Try not to make assumptions. If you have not met your community, don't decide who your community is;
• Integrate yourself in community programs of other projects, this will allow you to be on the receiving-end of the program;
• Contextualise your learning – aim to make connections between your actions and the response from the community.

Steer and respond to expectations

Taking a step back, when you first start interacting with a community, you will have expectations, the people around you, such as team members, will have expectations, and ultimately, the community will have expectations on you and on each other.

If those expectations are not managed properly, non of the stakeholders involved will be happy nor engaged in the process and outcomes. Before you start profiling your community persona and building a program to engage those, take a step back and try to answer the following questions:

• Why does my company or project need an engaged community?
• What are the expectations we have internally on the community?
• What do community members (if they already exist) expect from us?

Throughout answering those questions, you will want to think about whether the expectations are realistic, are they aligned with each other, and ultimately, can they be met? Depending on your answers, the design of your program and the process on how you plan to answer those questions will vary.

Before I started to design and plan our community program, I had several calls with participants of Ambassador Programs at comparable projects. Most of them detailed a similar on-boarding experience:

I applied, I got accepted, I got dropped into a Slack Channel with other Ambassadors and that was it.

Don't get me wrong, there is generally nothing wrong with this approach IF that is what applicants expect will happen from the program. If the project, however, praises a unique experience in which ambassadors can design their own initiatives and receive support from the core team, then expectations and reality are likely not aligned.

Long story short, I decided to not take this strategy. Instead, I planned to provide a unique on-boarding experience that consisted of an email exchange, a 15min to 30min call and weekly follow-ups. The community members, who were adding the highest value to the program, usually joined with high expectations. If you do not steer and respond to those, they will become disengaged and leave the program altogether. However, when you provide a clear direction both parties are able to align without encountering surprises.

I admit that this strategy was highly time intensive but it allowed me to build a working relationship with a small set of contributors (25 to be precise). In the case of my project, we were not able to extend the program beyond those members anyway since there was not much they would have been able to get involved with. Thus, the design of this program met our expectations.

This leads me to my next learning...

Quality over Quantity – Don't Scale too quickly

What are you aiming for? Is your goal to involve as many people as possible and reach the quarterly objectives? Do you want to have a selective group of people talking about your project in the right channels or do you want to blast your message out and hope it sticks?

Depending on your community and project, your strategy overall will vary quite a lot. Having worked with and been part of a variety of developer communities, I am arguing for a smaller, highly engaged, and targeted group being most effective. This does not mean that there should not be high focus on reaching diversity of mind-share, skills, skill-level and interests. I don't perceive those to be mutually inclusive.

Here are the benefits I found while working with a few amazing individuals through our community program:

• Unique work experience over everything. On-boarding new members into your community program takes time. Based on my experience, the drop-off rate is much lower if you invest in each member who you want to onboard.
• Better use of resources. How many community managers are working on the program? If it is just you or you are investing part-time on it, you likely don't have the capacity to support a large number of members.
• Incentives have higher importance. By nature, we are more interested in scarce resources. If everyone wears your swag, it looses importance to receive that as perks.
• Members are empowered to step up. They see that you are invested, so they are automatically more invested in the community. For instance, I can now go on vacation and know that community members will be present to provide support to other members.

A program focused on a few members might be overall more qualitative. One way to measure quality of your program is through the Net Promoter Score.

Net Promoter Score (NPS), for folks who are not familiar, asks customers to rate a product on a scale of zero to ten, where zero to six are “detractors”, seven and eight are “passives”, and only nine and ten are “promoters. To calculate NPS, you subtract the percentage of detractors from the percentage of promoters and you will end up with a score from -100 to 100. NPS is useful because it’s objective and can be compared over time and across products. To me, the delta in NPS over time is more important than the absolute score. Source

Especially at the beginning, I would prioritise sentiment and experience of engaged members over a score. Once your program has reached a certain point, quantifying the quality of your program will be more meaningful.

Don't be afraid to iterate - at the right time

Iterating on your community program does not mean that you have done a poor job the first time around. Company objectives change, especially within a start-up. You will likely understand your community better over time, and different community members will join as the program thrives. These factors and more will likely place you in the position where you have to iterate on aspects of the program.

A great example is The GitHub Student Developer Pack, which provides students and teachers with free access to a variety of platforms, tools and other resources. It started off with a landing page for students and teachers where they could access frequently asked questions and connect with the program managers. A lot of the work that went into it was manually. Once the program scaled beyond its capacity, the team wrote guidelines and automated the on-boarding process.

To get to where the program is today, the team had to define processes and iterate on those to come up with a framework that works both for the team running the program and for their target audience. Automating the on-boarding process, which is for most members the same allowed the team to focus on one-to-one developer support.

The on-boarding process does not provide the note-worthy experience but the fact that somebody has time and is able to help you with your queries does.

Going above and beyond will help you win the hearts and minds of developers. – John Britton

The team was in a position where they were required to scale out of the program to keep providing a unique experience. Arguably, if they would have automated the program too early, they would have not provided a unique experience for the first members. In this case, community members might not be encouraged enough to stick around.

While you design and before you iterate your program, think about what stage your program is in. Iterating on your program too early or too late may reduce the experience of its current members.

via GIPHY

Your Team is the Community

Who is going to try your product and experience first? – The person designing it.

As a kid I was told "don't gift others a present that you would not want to keep for yourself".

Similarly, don't design a community program experience that you are not super excited to be part of yourself. This becomes even more prevalent in open-source communities since most members are not financially incentivized to spend their time on the project. If you or your team members are not excited to engage with the community, provide support, and share initiatives, then you should iterate on your program and community strategy. Ultimately, your team-members should be your toughest critics and super-users.

If developers within your project are present on your forum, Discord, or other community channels to share ideas, provide feedback, and be part of the community, more community members will be interested in checking out what the hype is all about and ways for getting involved. Ideally, the developers hired to maintain the project, are likely the ideal audience. By keeping team members engaged, you might find it easier to bootstrap a community that is aligned with your values, goals and initiatives.

Outro

Please take everything that I have written with a grain of salt. These learnings are based on my personal experience. Every community is unique, and, just like a child, it does not come with an instruction manual that you could follow. You might have experienced the opposite with your community and taken a completely different strategy. In this case, I would love to hear from you and jump on a call.

Thank you for reading. You can find me on Twitter.