I recently read a thread in a Slack community where someone asked, “How can I incentivize my community members to answer questions from their peers?” I could write more in-depth thoughts on this topic if there is interest but, for now, here are some general notes I was asked to publish.
The Data
Before you read this lengthy response I’d suggest viewing and digesting the attached chart above, first. After all, telling you what I’ve been up to means nothing without results.
I also wish I had a short, easy answer on how to do this. But, in my trial-by-fire experience, building a community (and an active one that scales no less) is not easy. This took over two years of obsessively focusing on my users, their experience, and my team, too. No one part of what my team built was a “set it once and forget it” situation. We constantly fine-tuned and adjusted our approaches and configurations based on the information we had. Some things every quarter, some every month, and sometimes by the week.
This data does show that we’ll eventually be outpaced as a team at our current trajectory (unless I come up with new ideas!), but it also shows that we are effective and that what we are doing is working!
Our Program’s Goals
Before I talk about just some of what we’re doing, I first want to talk about what our goals are. We are very fortunate to have great executive buy-in—we have a great deal of trust, coverage, and support in our endeavors. I know this is always one of the biggest struggles in Developer Relations, so I do want to clarify: this is not a fight we’ve had to fight.
Our goal with our developer community is to educate our customers and partners, delightfully, on how to extend our platform and build scalable solutions. That’s the mission. Everything we do goes back to “Is this the best solution for our users, and will they be genuinely delighted with it?”.
Uncategorized Thoughts on This Subject
You’ll almost always hear, “It depends” when you ask this question about incentivizing community. While the answer is almost always, “It depends”, here are just some of what worked for me. If you let me know what particular item interests you, or that you have questions about, I’d be happy to go deeper into it.
Prerequisite Notes
- 99% of our developer community engagement happens in our forum, which is built on Discourse, and our forum home base for our community. We did have our first developer conference this year, but other than that all of our engagement is through our Discourse forum. While other platforms exist, and I’m sure many likely have good experiences with them, I have never seen a platform (and backing company) that compares to Discourse.
- I don’t have a dedicated community manager and have played that role (in my free time!) for my team since we started over two years ago. This has been great because I feel as though I’ve received a decade of learning in just the last year alone.
- …and I’m still learning. I am constantly in a state of having no idea what I’m doing, only seeing one foot in front of myself while going 100mph.
I’ve been tackling this problem for a while now and I’m so proud of my team’s results. Even though you can see we’re having an exponential rise in new users joining our community, we’ve shockingly been able to:
- increase our number of new contributors linearly
- have exponential decay upward of our topics without responses
- decrease our time to first response
So, What Are We Doing Then?
The first thing you should do is understand why your users are coming to ask technical questions in the first place. Nobody inherently wants to ask for help, right? We ask for help because we find ourselves in a place where we can’t solve our own problems. Us, we have a severe deficiency in our company on education for our customers and partners on our platform. Two years ago, we took a deep look at what was being asked, and then we did the following:
Product Engineering
- Created an API Guild in partnership with product engineering, which was comprised of engineers across different teams
- Created API Guidelines, or our “10 commandments on how to build an API” to ensure all product teams were on the same page
- Created an API Linter to ensure that all engineering teams were adhering to the guidelines, placed as a gate between engineering and releasing public API specs
- Engineering gave us write access to our internal API specs, which we’ve made hundreds of commits (and probably thousands of lines) to
- We fix almost every bug here ourselves without having to involve engineering
- We wrote all-new documentation in the API specifications
It turns out that when our APIs improved, people asked fewer questions about them. We would go on to use this short cycle for everything we do:
- See what people are asking for help on
- Fix that thing/write that doc/improve that whatever
- Repeat
Our Landing Page
Three years ago, when I joined to build this program, a landing page for developers was non-existent—we had no place for developers. We had nothing for developers—no documentation, no community, nothing. In December 2020, one team member and I, both having next to zero front-end knowledge, created a very terrible site. But it worked. We began migrating all of the tribal knowledge we could find—random pinned Slack messages, confluence docs, interviews with architects we’d set up, etc. and put it all on developer.sailpoint.com along with our API specs. While it wasn’t pretty, we made a pact that we would make it open source, update it often, and make it something our users would trust.
In September of 2022, our team released the new developer.sailpoint.com you see today. While still nobody on my team is a front-end engineer and we are all too far from perfect, it’s usable and our users trust it. This—our consistency and the quality of information—had overwhelmingly positive feedback.
While, like most teams, we are spread micrometer thin at times, we make sure that our docs are updated often, trustworthy, and open source. I believe this had a major impact on our developer education, leading to a decrease in the need to ask questions (and an increase in the number of knowledgeable users who can answer the ones that do come up!)
Okay, Now the Big One—Our Forum:
Everyone here is going to have their different opinions, thoughts, and feelings on different community platforms, and that’s okay. I’m not going to delve into that, and just say that Discourse was the best solution in my eyes and the platform is a major player in our team’s success in solving this problem: How do we create a community that is self-enabled? Discourse is a Swiss army knife, and the company that runs it (CDCK) is the best group of product people I’ve had the pleasure of working with. So, in no particular order, here we go:
- Platform matters. Discourse has a user interface that makes sense and resembles old bb forums (in a good way) but with all the modern amenities. We’ve been able to bend it in every conceivable way we’ve ever wanted to create exactly the experience our users want—big or small.
- I spend a great deal of time researching how to organize information effectively. I am still terrible at it, but I am educating myself on the subject every single day and I adjust my categories, subcategories, and tags accordingly. If your information isn’t organized effectively then things will be hard to find. If things are hard to find, then then they’re harder to contribute to.
- I talk to my users. A lot. I email them, have calls with them, send them PMs, find out who’s local to me and get dinner with them. I go into Salesforce and see what customers are successful, and I contact them to learn why. Inversely I go see who’s not doing well and contact their CSMs (et. al.) to learn why not. My team and I are ALWAYS talking to our developers and our adjacent teams, and we always ask them directly, “What do you want out of a community like this?”.
- My whole team understands that “community manager/moderator”, to an extent, is a part of their job description. They aren’t required for major community management/moderation, strategy, etc. but they are required to know how to use the tools in their tool belt, and for us, that means understanding the basic principles of community management, Discourse, etc. Everyone knows the nuanced features of the platform, like how to split posts into different topics. Everyone is a “junior community manager”. I believe when people come in and see an active community, and not one just run by a single person all over the place, that activity inspires people to participate.
- We listen and read. As I mentioned earlier above, we spend a lot of time reviewing what people are asking. Why are they asking it? Did our docs not cover it? Is our product not working right? We go fix things at the source probably 7/10 times within a week.
- We made contributing easy. Every single thing my team produces is open source. Our docs, tools, developer.sailpoint.com itself—everything.
- We try (I say try because I’m still working with my team to be better at this) to never just give an answer, but to tell them how we got the answer. Rather than answering a question of, “What is the API rate limit?” with “Our rate limit is 100 requests per hour.”, we would say something like, “Hey John, that’s a great question and it’s awesome to see that you’re using the API to create your own triggering platform. It looks like our current rate limit is 100 requests per hour. You can find more about rate limiting, and anything else you may need to know about our API, right here: [link]. If you ever don’t find what you’re looking for there in the future next time, always come back and let us know!” I believe these kinds of responses, over time, gently reeducate our users on going to read before posting.
- I have many more thoughts, but these are just a few that came to mind.
Discourse-Specific Ways That We Encourage Contributions
We’ve done so much in Discourse that I won’t come close to remembering everything, but I’m going to try my best.
- Effective categories/tags as mentioned earlier. Whether you use Discourse or not, I’d recommend reading this blog post from Discourse CEO Sarah Hawk: It’s Time We Talked About Tags.
- I designed a Discourse plugin that, when a users answer is marked as the solution, they get an automated message from me (that feels genuine, and it is, because I wrote it!) thanking them for providing a solution, and it gives them a list of other topics they might be qualified to answer. This has led to a noticeable uptick in responses and marked solutions.
- We have been diligently designing our first ambassador/contributor program that rewards our top contributors but also is designed such that it encourages others to participate. We piloted this program with ~60 invites to our top contributors, and we worked closely with many to understand why they contribute, what they want for contributing, etc. This pilot happened in Q2 of this year, and we launched publicly in July. The results have been overwhelming. For the last five months (at the time of this writing) our community forum has been 99% self-sustained, our ambassador program is growing, and we’ve been able to focus on serving our ambassadors.
- This program gives them badges, social share packages, they’ll be highlighted on developer.sailpoint.com as an ambassador, they get early access to features and private test tenants, swag, and so much more.
Conclusion
These are just some short notes that I put together, but if you have any questions about something you’d me to discuss further (Discourse, ambassador programs, community automation, information architecture, etc.) just reach out and let me know.