HashiCorp has one of the most loyal and evangelical developer communities in the world. From its earliest days as an open source project built by its two co-founders, Mitchell Hashimoto and Armon Dadgar, to its current incarnation as one of the largest commercial open source companies in the world valued at more than $5 billion, HashiCorp has grown from the bottom-up via its passionate practitioner community.
GGV recently sat down with Adam FitzGerald, Vice President of Developer Relations at HashiCorp, at a Founders+Leaders online roundtable to talk about what it takes to build a massively successful developer relations program. Before joining HashiCorp in 2019, Adam led developer relations at Amazon Web Services, Pivotal Software, VMWare, and BEA Systems, so he’s been at the forefront of fostering and growing developer communities for over 15 years. His insights into how to find, nurture, support, and grow a developer community who are absolutely passionate about technology platforms are invaluable. Below, we share five key takeaways from a fascinating conversation.
Developer relations can mean many things to many different types of software companies. The key to running a successful program is to clearly define what it means for your company, and then build a practice that serves and supports your developers and upholds your values. Whatever format a developer relations program takes, at its core, it should be the continual process of establishing and maintaining the trust of the technical end users of your company's product.
There are plenty of companies that just layer developer relations on top of marketing as a sort of afterthought, but they don’t put developers at the center of everything they do, and that’s usually a recipe for failure. Developer relations is something you have to practice and evolve every day, because the whole point is building and maintaining trust among technical end users. All developer relations programs should avoid marketing buzzwords and should never overpromise on what they can deliver. It’s about being honest, humble, and consistent.
There are four main components of a successful developer relations program:
Every developer relations program should have these four elements. When it comes to staffing these areas, if your developer team is 10 people, five should be working exclusively on content, as that is the most labor-intensive and most important part of any program.
Developers are constantly seeking out articles, posts, and tutorials on how to use new technologies, so you have to ensure when they Google terms related to your sector, they will discover a plethora of well-written, technical, and approachable content about your platforms.
Three of the 10 people should be focused on evangelism, and one on events. This isn’t a hard-and-fast rule, and these numbers could shift if, for example, your technical team is great at writing content, or if your CEO does the bulk of evangelism, but it’s a good starting point to structure your team.
Quite often, the best place to find your head of developer relations is within your company, or alternatively, it’s someone who is a very strong member of your external developer community. You want to make sure the person leading developer relations understands the developer mindset inside and out, but also has a clear sense of the business model and goals.
Too often, developer relations teams only think only like coders; they don’t think about the business side of the equation. But a truly excellent developer relations leader maps every decision about fostering community and building evangelism back to the company’s business goals. Of course, developer relations should first and foremost be about supporting the technical end users of your products, but your program should also deliver value to the company. Otherwise it’s just an expensive external exercise unrelated to your business goals.
Always ensure your developer relations leader is a respected part of the business team, giving them a seat at the executive table. Their input is invaluable to help define product and company strategy.
There is no exact science about when to formally create a developer relations program, but in my experience, the right time is when you have about 25-50 people. That might seem early, but for developer-focused software companies, they’ve been focused on developers since the beginning. Their founders are likely developers themselves and have been pounding the pavement for years to build up a loyal developer community, probably contributing code, articles, and tutorials to open-source projects, speaking at conferences, and going to hackathons.
That was certainly the case at HashiCorp, where the two founders spent the better part of the company’s first two years focused almost entirely on developer relations. But somewhere around 25-50 people, the founders usually begin to think “it would be great to have a dedicated person doing developer relations,” because the company is growing quickly and they need to shift some of their focus to business development, fundraising, and customer success.
By the time you have 100 employees, you almost certainly should have a head of developer relations, if you don’t already.
You can put your developer relations team under marketing, product, or engineering—it really doesn’t matter as long as your head of developer relations has a seat at the executive table and can continually prove the value of their team.
One of the main jobs of the head of the developer relations team is to clearly show the business value of developers to the company—that having a loyal tech user base generates leads, drives traffic to the website to read tutorials and engage with product demos, fosters word-of-mouth uptake and customer retention, and so on.
Whenever an executive says that developer relations are expensive, it’s the head of developer relations’ job to show them it’s the most cost-effective investment they can make. After all, if you’ve got a community that’s willing to go to bat for you, to convince their bosses they need to buy your enterprise products, and to wear their hearts on their sleeves for you—that’s invaluable. You just have to prove this worth by showing the impact on the company’s bottom line.
