In Part 1 of Building Blocks for an Innovative and Inclusive Developer Community, we covered what an early-stage developer-facing startup needs to consider in order to put in place an early framework that supports and fosters a welcome and healthy developer community. In Part 2, we’ll discuss real examples of do’s and don’ts and how to take this framework to the next level as your company grows.
As you scale and/or approach your Series A, your developer product has made it through the make or break early slog. It has gained traction, and you may even have an active developer community. You likely know some of your early adopters well and are starting to see some of the same faces show up at multiple events. Congratulations, you’ve got an active developer community!
Now that you’ve defined some community spaces, both online and off, and folks are leveraging them, you may be tempted to sit back and let the community continue to grow on its own. But fostering a community is a long game – if you neglect it today, you may not feel the consequences tomorrow or even next week, but you’ll feel them next year. So what should you be doing to ensure that your newfound developer community is not only growing but thriving, both today and down the road?
Having an active community gives you a tremendous opportunity to listen and learn from them. Failing to do so can result in product oversights that can derail progress and impact revenue and future runway. Seeking out and addressing feedback and reflecting the realities of your community members can reduce friction and increase developer output.
An example of a missed feedback opportunity was shared by experienced UX researcher and project manager, Nancy Douyon when I attended Tech Inclusion San Francisco in 2016. Her talk was on Inclusive Product Design, where she showcased a glaring example of unconscious bias oversight and a lack of diverse feedback for the Oculus VR headset, which was essentially unwearable by folks with thick hairstyles, turbans or other modalities outside that of the largely white, male product team and beta community testing it. While this is a hardware example, it showcases how easily glaring feedback omissions can impact a product’s user experience.
Chances are, as you approach this next stage of growth, you’re already creating and publishing content regularly for your audience. Perhaps your engineers are contributing blog content and you may even have a Developer Advocate on board creating content, sample code, documentation and more. Your company is adding value to both your own developer community and the developer community at large. However, similar to the product design oversights caused by unconscious bias that we saw in the Oculus example above, unchecked content (explicit example & implicit example) can unknowingly alienate members of your developer community. How can you mitigate this?
AI may have its fair share of inclusion challenges, but when developed and designed to be inclusive, it can be a powerful ally in helping us fight our own unconscious bias. Once such example is Textio, a writing platform that is typically used to optimize the hiring experience but can be used to vet any human-facing content. Based on ever-improving algorithms and data, Textio will output tactical feedback on word selection and propose alternatives to make your content more welcoming and inclusive. Use Textio across all of your widely consumed developer content: job descriptions, blog posts, documentation, even readmes.
As much as you need to ensure that your written content is inclusive, the visual cues your content and community activities convey are equally important to get right. However, choosing inclusive imagery may not be as simple as running content through an AI engine. The visual choices you make need to actually be representative of your community.
For example – there are many fantastic image sets featuring folks of color in a tech setting available for your use, but if you use them on a job listing, for example, and don’t actually have any folks of color working at your startup, you’re setting a potential applicant up for disappointment and deception. However, if you’re considering images to go alongside more generic content, such as a feature update, open-source project page, event invite or knowledge-sharing article, the use of these images can send a signal that the representation of all developers is important to your company.
Some of the image collections that are available include the Women of Color in Tech Flickr set, available for use with attribution, and Broadly’s Gender Spectrum Collection (note that these images cannot be used for commercial purposes. In other words, these can be used in the context of open source projects and personal developer blog posts in places like dev.to or medium, but not on company websites. Please be sure to read these guidelines completely in order to use these images mindfully.) All of these resources, as well as new ones that emerge, can be found here.
As your developer community activates and multiplies, be sure to make space for underrepresented members of the tech community. Ensuring that these members feel welcome and represented in your community can accelerate product growth and result in surprising, delightful and game-changing outcomes now and down the road.
In the final post in this series, I’ll examine what areas of community you’ll need to keep on going tabs on as more and more developers rely on your product and build on your platform, and as your company approaches profitability, exponential revenue, and an exit or an IPO!