Five Pillars of Building Developer Communities at HashiCorp
Even from the very early days at HashiCorp, community building was deeply ingrained in our company’s ethos. I remember Mitchell Hashimoto, HashiCorp Co-Founder, telling the story of when he released Vagrant in 2009, HashiCorp’s first open source tool, it didn’t have much traction initially. Once he started speaking at events and conferences, blogging, responding to community questions, and being more active online, he saw the download numbers start to take off. He experienced firsthand the results of authentically engaging with developers. The founders always deeply understood the importance of building an active and vibrant open source community, which became part of our company culture and freed us to run programs that helped us achieve that. Every employee at the company was a community builder. This is an important distinction companies miss when they talk about wanting to build a community. Sometimes a company will hire a lone community manager or developer advocate and put them off to the side. That person is not being set up for success. What they need is support and buy-in from the entire organization. I wouldn’t discount the type of commitment and investment needed to start building a community in the early days. This process is a long game, my friends. Dave McJannet, HashiCorp CEO, recently announced during the HashiConf Europe keynote that all of the HashiCorp tools have been downloaded 250 million times in the last 12 months. It took years to get to this moment.
The makeup of HashiCorp in early 2015 when we were 10–15 employees was: Mitchell and Armon (HashiCorp Co-Founders), senior engineers, a customer success person, a head of sales and marketing who was technical and understood our community, a head of partnerships, a designer (web, print & brand), a developer advocate (engineer, teacher, writer, & public speaker), and me (community & events). Every employee at HashiCorp interacted and engaged with the community in some way. We were always very thoughtful and deliberate with how we engaged. This ranged from being helpful guides in our responses to questions on Twitter or GitHub issues, being transparent with which community contributed code we would merge, who staffed our user conferences, how we answered support questions, talks we gave at events, emails to our database, and much more. This all mattered. We had a HashiCorp style guide that gave us a consistent writing style and voice across the company that made our brand strong and vibrant. The HashiCorp tone was documented in that guide. Here is how we wanted to make sure we came off:
- Highly technical
- Open and honest
- Humble but confident
We also defined a set of five pillars we based every community program on. The five pillars were education, knowledge sharing, trust building, genuine human connections, and design with empathy. These pillars allowed us to easily decide if we should move forward with a program, activity, or experience. There was a reason we never had ball pits at our conferences, gimmicky campaigns, cash prize hackathons, drink-ups, or parties. While fun and sometimes effective, those programs didn’t fit under one or more of our defined pillars. Now that I work with more early-stage founders, I realize these pillars can be applied to anyone building a developer community. Let me dive into each of the pillars and we applied them.
This pillar is all about user education. The HashiCorp tools weren’t super easy to get started with. We needed to make sure our documentation was robust and always up-to-date. To developers, your documentation site is your marketing site. We had to ensure we had relevant tutorials, guides, and videos that helped our community members. We started organizing trainings around the world staffed by our engineers, support team, and DAs. We taught workshops at conferences and events. Our user conferences only featured speakers that gave in-depth technical talks and specific use cases. We encouraged our engineers to submit conference talks. We had high standards for the technical blog posts we published from our founders and engineers. This content was far reaching and helped establish us a company with smart people you wanted to follow and products you wanted to use. This pillar is the start of building a developer community and the most important to focus on from the early days.
But you can’t be the only one that is talking about your solution. Developers want to learn from each other. They trust each other’s word more than a company. One of the many benefits of building a community is you create super users or fans that help amplify your message and spread the word. This is why we invested a lot of time and money in developing programs that featured our community members discussing in-depth how they implemented our tools. For example, we had programs like guest bloggers, champions, HashiCorp user group meetups, HashiDays, HashiConf, webinars, and YouTube Live streams. At the first HashiConf in 2015, CapitalOne was the first large enterprise company to talk about how they were using our tools in production. You can still watch Keith Gasser’s talk HashiCorp Tools in the Modern Enterprise on YouTube. Years later they became a multi-million dollar a year customer. Having well-respected developers or developers from Fortune 500 companies share how they are using your tools has a massive impact on adoption.
I recently published a blog post Are You Building Developer Trust? on this specific pillar, so I won’t repeat myself. Here is the main point to takeaway from the post:
It takes many touch points to gain developer trust and one action to destroy it completely. Once you’ve lost trust, getting someone to give you another chance will be difficult.
This was extremely important to us at HashiCorp. Trust is critical if developers decide to deploy your tool, product, or solution into production. They need to know your shit works. They need to know you are building a legitimate long-term business that won’t disappear in a year. We always wanted to ensure we came across as mature, professional, and that we were building the next generation of infrastructure automation tools. We did that through messaging, tone, brand, programs we ran, and the high caliber of tools we shipped. It took years of constantly shipping and improving a tool before we deemed it worthy to be called version 1.0. You wouldn’t think user conferences would have that big of an impact on perception but ours did. I always made sure our user conferences had a level of polish that made us seem more established than we were. I leveled up the experience every year to match where we were heading. It surprised people to learn that we weren’t a big company yet.
Genuine Human Connections
I attribute this pillar to my good friend Seth Vargo. He was my counterpart at HashiCorp, and we created magic together. I miss working with you, buddy.
One of our motivations for building tools that automate technology and process is so you can spend time doing the important things in life like being with your friends, family, and loved ones. We want HashiConf to embody that spirit. We are encouraging a new type of communication, one that involves face-to-face interactions, called Genuine Human Connection. — Seth Vargo
This part of Seth’s opening emcee remarks made the entire audience laugh and nod their heads. It’s always been important for us to create safe and welcoming spaces online and in-person that encouraged and enabled genuine connections amongst our community members. We, as employees, made sure we interacted with our community in an authentic, kind, and helpful way. This helped set the tone for how others interacted and treated each other. Community building is all about connecting people to each other. You’re just the facilitator. I loved attending our user conferences every year and seeing the same people coming back year after year. We made it about them and they could feel it. I published a blog post in January about leaving HashiCorp and I got hundreds of messages from community members thanking me. It still blows me away. You can’t fake authenticity.
Design With Empathy
If you go to DevTool websites today, many of them look the same. They have black backgrounds, use Helvetica and Avenir fonts, one line company description, and some type of image in the hero. We’re seeing that everyone is screaming for visual attention, so people decide to be even louder through colors, animations, and videos. We’re doing it with the goal of seeking attention, instead of thinking about how the person feels. Cris and I have been talking a lot about how this time could/should be a turning point in designing for developer audiences. What if we went back to simplicity, colors, softness, and having a more human-centric approach to design. What if we tried different ways to engage instead of following what others are doing. I’m excited by this prospect.
To us, designing with empathy always meant keeping the individual in mind. This pillar didn’t just stop with the visual language; this thinking also permeated into all aspects of our community programs. We made sure that the music wasn’t too loud in the mornings. We made sure there was plenty of delicious coffee at the HashiCafés. The chairs might not have looked good, but they were comfortable to sit on. You couldn’t see the HashiCorp logo across the room, but the shirt design was cool and felt great. When we sent that email, we communicated with the person like a human. That handwritten thank you note with a personalized gift goes a long way versus sending another water bottle and t-shirt. When we launched our digital conference platform, you could easily log in. Do you understand what I’m getting at? It was always about putting people first.
Wow. This was a fun blog post to write. I’d love to hear your thoughts, ideas, and findings. Of course, I’m always down to jump on a call to do a brainstorming session. I love this stuff if you can’t tell. Message me on Twitter.