In the past few weeks, I've seen a few podcasts talking about building developer communities. As I listened to them, I wanted to share my thoughts on building developer communities.
For background, I ran the Growth team at Serverless, Inc. for part of 2017 as the Serverless Framework was really taking off. I also spent all of 2018 & 2019 in a different role at Serverless but still heavily engaged in the community.
In this post, I'll cover how our team worked to engage and grow the community over time.
In particular, I'll discuss:
- The importance of sincerity
- The three engagement strategies: Micro, Macro, and Network
- My thoughts on other strategies, like conferences and viral posts
The Importance of Sincerity
In the notes below, some of the strategy notes might seem very transactional -- do thing X so that you can get benefit Y. And it's partly true -- the entire aim of doing the work to build a community has an underlying goal of helping your company. And the company is what is paying your salary so that you can do this job in the first place.
But you cannot approach community building in a transactional way. If you approach every interaction wondering what's in it for you, your assistance will be shallow and fake. You'll ignore parts of the community that don't seem sophisticated or cool, or you'll roll your eyes at users that are having trouble with basic syntax.
Sahil Lavinga summarized this pretty well:
If you help without expecting anything in return, you will eventually get something in return.
— Sahil Lavingia (@shl) January 27, 2020
The best advice I can give on this is to hire passionate people that get energy from helping others. I was lucky to work with some awesome people on the Growth team (Andrea, David, and Rupak), as well as other great folks at Serverless, Inc. that wanted to help the community. These people consistently went above and beyond in helping others.
Passion, sincerity, and care for others is hard to fake. Make sure you find people that have these traits.
Once you have the right people on board, you should focus on a three-pronged strategy to build your community: the Micro, the Macro, and the Network. We'll cover each of these in turn below.
The Micro Strategy: Help people directly
The Micro strategy is pretty simple: your team should find people that are having problem with your tool and then help those people directly.
This may mean help with beginner issues like installation or improper syntax. It might be something more sophisticated such as advanced configuration or best practices. Perhaps the problem doesn't even deal with your tool directly, such as a general programming issue or a problem with a complementary tool. Whatever the problem is, listen to them and help them solve it.
At times, this can feel draining. You might fall behind on your work because someone in the Slack channel had an issue with their Node installation on their Windows machine. All your efforts will feel like a drop in the bucket, like it won't ever scale.
And it's true! The Micro strategy cannot be your entire strategy. But the Micro strategy is great for three reasons.
First, it helps build empathy for your users and helps you to understand the rough edges of your tool. If you only work with the experts inside your company, it's hard to get outside the curse of knowledge. You forget that there's a huge community of programmers that are still learning. Direct assistance of users brings you closer to their concerns.
Second, it prevents your community from seeming like a wasteland. If I'm new to a tool, I'm running into errors and Googling to see how to solve it. When I come across GitHub issues and forum posts where someone had the same issue as me six months ago and no one responded, it leaves a bad taste in my mouth. You want to establish a community where common problems are addressed and explained.
Finally, it helps to build devoted followers. There's a great book by Kathy Sierra called Badass: Making Users Awesome. The key takeaway is that your tool must give your user superpowers. And if your users are getting stuck without getting help, they won't get those superpowers. If you unstick them and they become badasses, they'll become devoted followers and share your tool with everyone.
One more bonus reason: for the right person, the Micro strategy can be downright fun. There are few things better than the dopamine hit you get from solving a hard programming problem. When you're helping others with a coding issue, you can see them get that hit, and it's just as enjoyable as solving a problem yourself.
The Macro Strategy: Share the Knowledge Widely
The Micro strategy is great, but it doesn't scale. Your company can't hire enough people to help everyone directly.
This is where the Macro strategy comes in. With the Macro strategy, you take the things you've learned from the Micro stategy -- what's hard? Where do people keep tripping up?-- and you create content that can help more people.
Creating content like blog posts, instructional material, or documentation is a more scalable strategy than direct assistance to individual users. Creating this content will help your team in two ways:
The next time you are asked the question (and you will be!), you can link to your blog post rather than re-typing the entire explanation to a second, third, and fourth person.
For all the people that are having this problem but aren't asking questions (and trust me, there are 100X more of these people), now you have something that is discoverable by other means.
When working on your Macro, content-based strategy, keep the following tips in mind.
Focus on SEO
Huge thanks to David Wells who taught me these lessons initially.
The key bit with the Macro strategy is to get your helpful content to all the people that need it, and the best, most reliable way to do this is via search. When developers get stuck, they run to Google to get unstuck.
Some developers turn up their nose when you suggest they should think about SEO during content creation. This is a huge mistake.
Your goal is to:
- Create helpful content.
- Make that content discoverable.
I don't know whether a tree that falls in an empty forest makes a sound. But I do know that writing helpful content that a developer can't find is a waste of time and money. If you want to write something that no one will read, go be a college professor.
A few SEO-related tips:
Get your SEO house in order. Make sure you have all the on-page SEO basics configured for your site. This means you have a proper title, description, and other HTML tags that search engines will look for.
Write a search-friendly title. One of the bigger mistakes I see people make with technical content is to try to create a funny, clever title. Maybe it's a bad play on words or a pop culture reference, such as an intro to Typescript article called "The Compiler Strikes Back".
The big problem is that no one is searching for a clever title when looking to learn. Page titles are an important factor in SEO rankings. Think about how you would search for your content if you were looking for it and name your page accordingly.
Create a web of content. Your content should be related to each other, so make sure you connect pieces to each other via links. Not only will this help your users find related content you've written but also it will boost SEO as you're showing the search engines how your content relates to each other.
Simplify your complements
There's a classic tech strategy article by Joel Spolsky about commoditizing your complements. It introduces some basic economic theory, such as:
The less something costs, the more people will use it (laws of supply & demand);
Cost includes the entire solution, not just your component piece.
Combining these two thoughts, if you want to sell more units and/or be able to take more of the total spend for a solution, you should work to drive down the cost of other elements that are necessary in your solution (your "complements"). This will either drive down the total cost of using the solution (resulting in more people buying), or it will give you room to increase your price while keeping the overall cost the same (resulting in higher profit to you). P.S.: Do yourself a favor and read the entirety of Joel's article.
These principles are also useful in creating developer content. Think of all the elements that a developer needs to learn to use your tool as the total 'cost' of using the tool. If these other elements are difficult to learn, you can reduce the total cost of using your tool by explaining how to use the other elements.
Let's bring this home wth an example. In my previous company, we built a tool that made it easier for developers to deploy certain applications to the cloud. One of our core audiences was full-stack developers that were pretty new to the cloud. Many of them learned about AWS from our tool. And AWS is a complicated beast! Our tool helped make it easier, but there's still a huge surface area.
To help with this, we wrote a lot of content that was AWS-specific and only tangentially related to our tool. This includes posts on understanding the permissions model of AWS or a workaround for key service limitations.
By giving our users information about these trouble spots in supporting tools, we lowered the total cost of using our tool which increased the number of people using our tool.
Know the goal of each piece of content
The final tip around the Macro strategy of content creation is to know the goal of each piece of content you're creating. You can only hold the attention of your user for so long, so keep your content tight and focused. Don't try to boil the ocean in a single post -- link out to other pieces for additional context where needed.
I read a great piece recently on different types of technical documentation. That post mentions four different types, but I really think about three:
Tutorials: This content takes a reader from start to finish on a particular project. It's unlikely to solve an exact problem for them. Rather, it's going to teach them how to get to a specific outcome in a way that they can extend to their use case. It will probably be written in a specific programming language, so you might have similar tutorials for different languages. An example here is a post on Using Express.js with Serverless applications.
Guides: A guide does a deep dive on a particular functional area. It will teach users how to solve a particular problem but is not specific to any one use case. Examples here would be a deep dive on CORS with API Gateway or a post on adding a custom domain to API Gateway. Both of them are related to a singular area around Serverless & API Gateway. Neither one will take you from zero to 60 on a use case. But it will fill in the gaps in a gnarly area.
Additionally, guides are a great way to trim down the length of your tutorials! In the Express tutorial above, it would overwhelm the user to add concepts about CORS and custom domains in an intro post. However, because you have guides as well, you can link out to these guides in your tutorial to provide jumping off points for users that need it.
API reference: The final type of documentation I think about is the API reference. This is dense, technical material that describes a particular module or configuration in great detail, including all of the method arguments or configuration options. The target for this is usually a power user that already knows what he or she wants but needs to check on the exact syntax that's required. This is another piece that's useful to link to from other content as it can provide additional specifics in a narrow area.
The Network Strategy: Build a Community and Boost Champions
As we moved from the Micro strategy to the Macro strategy, we moved up to a more scalable mode of education. Rather than helping users one-on-one, we're now creating a permanent document that can be discovered and used by loads of users over time.
But even this strategy will hit its scaling limits. There's only so much content your team can create. Further, if all the content about a tool is coming directly from the company that owns the tool, it can seem inauthentic.
In the final part of the strategy, you want to boost the network of people that are talking about and writing about your tool. People from the community can vastly increase the amount of promotion about your tool that's out there. Plus, a post from an impartial community member feels more real than a post directly from the company.
More and more developers are writing blog posts, recording videos, or tweeting about tools they like to use or problems they're solving. For someone that's new to creating like that, it can feel intimidating to put yourself out there. What if people don't like what I say? Or worse, what if no one notices at all?
It's likely that your company has a bigger audience than an individual new to the content game. Use that audience to promote content from this individual. Act as a megaphone to shout about new people.
As a creator, nothing feels worse than feeling like you're shouting into the void. If someone is talking about your company's product, make sure you retweet it, link to it, include it in your mailing list -- whatever you can to increase the reach of that content.
Thoughts on other strategies
The notes above are heavily skewed in a particular direction -- generating content that can be found online via search. They were influenced by my experience at a Series A funded startup that didn't have bundles of money to spend on every effort under the sun. Thus, my recommendations focus on low-cost options with higher bang for the buck. That said, there are a few other strategies worth discussing. I'll address these below.
Conference sponsorships
There are a ton of developer conferences, and conference organizers are always hungry for sponsors. Many developer tooling companies are mainstays on the conference circuit, with booths, swag, giveaways, and more.
Conference presence can be nice, but it's expensive -- probably the highest cost form of marketing you can do. Not only are you paying large sponsorship fees to the conference organizers, but you're also flying a team out there for multiple days, buying swag and booth materials, and distracting your team with planning and prep ahead of time.
Generally, I would avoid conference sponsorship unless you're a giant company or have a well-defined sales funnel that fits with the attendees of the conference. Conferences will probably be the easiest to track return on investment as you should come back with some solid leads from the conference that (ideally) lead to product sales. If you're having trouble tying sales back to conference sponsorship, I'd be wary of continuing to invest in conferences.
Conference talks
A cheaper conference strategy is to have your developer advocates speak at conferences. Write up a bunch of talk proposals and send them to the various CFPs. When a talk is accepted, send your advocates jet-setting all over the world to pump the virtues of your tool to the masses.
This is another one that I'm more bearish on than the industry in general. I just don't think the cost-benefit analysis will work out in your favor with it comes to conference talks. Talks take a lot of time. It's not just the in-person time of traveling to and attending the conference. It's the time spent building your slides and practicing your talk. And the benefit is pretty low. Your talk might be attended by a few hundred people at most, whereas a good blog post will be read by tens of thousands of users.
That said, conference talks can give you some nice visibility in the community. Many conferences are full of people with decent Twitter followings that will live-tweet your talks. Plus, it's hard to replace the in-person connection you can get by talking to users.
To get the most out of your conference talks, use the following tips:
Prefer conferences that record & share talks. An artifact of your talk that can be shared around will boost the permanence of your talk and increase the benefit.
Repurpose your talk's content. Your developer advocates probably spent a ton of time researching and preparing for their talk. Don't let that go to waste in an hour long talk. Have them write up a summary of their talk that can be shared on your blog.
Engage with conference attendees. While your advocates are at a talk, make sure they spend some time working the hallway track to engage with other attendees. This is your community, and you should hear their concerns and problems. Treat this as an extension of your 'Micro' strategy -- it's hard to find a substitute for real, face-to-face interaction with people to understand their pain points.
'Viral' content on social media or Hacker News
The content strategy I mentioned above in the 'Macro' section was heavily indexed on evergreen, SEO-focused content. Try to write on a topic that will do well over time rather than aiming for short-term bursts.
I see a lot of companies that try to win the viral lottery by writing content that might get a lot of shares on Twitter or perform well on Hacker News. And I get why folks do this -- nothing can goose your website numbers quite like the front page of Hacker News. You can easily get tens of thousands of page hits in a single day.
But the viral lottery is just that -- a lottery. It's hard to know whether you'll win, and you might have wasted a bunch of time creating some content that didn't catch as well as you liked. It's not a repeatable strategy.
Further, the type of hits you'll get from Hacker News won't be as valuable as the type of hits you'll get from elsewhere. They're significantly more likely to be curious lurkers who will poke around and move on. In contrast, users that hit your page from a targeted search query are very likely to be in your target audience. Further, you've (hopefully) built up some trust that you can solve their problem.
The way I think of social media and Hacker News is lottery-based brand marketing. It doesn't cost much to buy a ticket by promoting your posts on Twitter or submitting to Hacker News, and the payoffs can be huge. But it shouldn't be the core of your strategy. Even if you do hit, the biggest effect is going to be to raise awareness about your tool & brand rather than directly convert a bunch of new users. And that's fine! Brand awareness is useful. The more times people see the name of your tool pop up in the different settings, the more likely they'll think to try it out at some point in the future.
Conclusion
In this post, we covered my thoughts on how to build a community around developer tools. As noted, I'm an advocate of a three-pronged approach:
- Micro: Directly help individual users to build empathy and find pain points
- Macro: Write long-lasting, evergreen content to share knowledge more broadly
- Network: Encourage members in the community to create content and use your megaphone to amplify them
We also discussed some alternative strategies that companies use and how I think they do or don't help.
Finally, we discussed the importance of sincerity and a strong team in doing this stuff. If you don't have the right people working on your community, you won't get anywhere.
If you have questions or comments on this piece, feel free to leave a note below or email me directly.