My family’s originally from the Czech Republic: They escaped from a communist regime in 1985 and through sheer luck ended up in the San Francisco Bay Area, where my dad found work at LSI Logic. He soldered and built computer chips while I played games on his Mac. To this extent, I was exposed to the tech industry early, but when I went to college in Colorado in 2004, “tech” wasn’t a readily available path or career. 

I graduated in 2008 during a period of recession in the U.S. and it was difficult to find a job. Like many new graduates at that time, I was confused about my future, so I moved back home to Berkeley to figure out what was next. One of the few industries still hiring at the time was tech, and I found a position at my first early-stage startup doing customer support and sales. 

In that role, I quickly learned that cold calling or spamming developers was the worst way to get them to adopt your tool or service. The industry was slowly starting to recognize the growing influence developers were having over what tools, products, and services succeeded. Freemium and open-core models started to gain traction, with companies like Red Hat, Redis, MongoDB, Chef, GitHub, Heroku, and New Relic leading the way. 

I was lucky enough to discover the power of building community and the open source ecosystem early on in my career. Even though I’ve always been empathetic, organized, and deeply connected to the human spirit, I never imagined I could create a career out of those skills. I stumbled upon the open source world in 2009, and fell in love with what it represents: People building things to improve each other's day to day lives and making friends along the way. 

After a few years, I was hired in my first community manager position at a time when many people didn’t fully realize the benefit of this type of role. I was a community builder before “VP of Community” was a thing, and I feel so grateful to have helped to drive the importance of seeing and serving developers as a greater community. It’s only been the last few years that community-led growth (CLG) has started to carry the same weight in driving and growing the business as other go-to-market functions.

Developers are extremely intelligent. They smell bullshit, don’t want to be sold to, and hate marketing jargon. They want to learn from their peers and feel like they’re part of something. This speaks to me: I deeply believe in authentically engaging with people. When all you’re thinking about are ROIs and KPIs, it’s easy to forget about humanity. My empathy and genuine love for the developer community is my superpower: Never forget there’s always a human on the other end of whatever you’re doing.

Planting the community seeds for a healthy ecosystem

I learned how to authentically engage with the community and how that brings value at Engine Yard (EY), which still holds a special place in my heart because of all the lifelong friends I made. When I started at EY in 2009, we were direct competitors with Amazon Web Services, GitHub was still a small company, New Relic and Heroku had just launched, and Ruby on Rails was at its height in popularity. We actually hosted some of the largest Ruby on Rails websites back then, including GitHub, Bleacher Report, New Relic, and Groupon. 

We contributed to the open source community more than people realize. I had coffee in Dublin recently with a friend, Eamon Leonard, whose company Orchestra was acquired by EY in 2011. He said he went through and calculated that EY spent around $5M over its lifetime contributing to various open source programs we ran. We hired core developers like Ryan Dahl, Yehuda Katz, Ezra Zygmuntowicz, Evan Phoenix, and Brian Ford: They contributed to open source projects while working full-time at EY. 

At EY, we ran an OSS program to sponsor important contributors and projects that continued to advance the Ruby on Rails ecosystem, which is where I first heard of HashiCorp co-founder Mitchell Hashimoto. We sponsored him to work on Vagrant, (HashiCorp’s first open source tool) for a summer while he was still in college. We sponsored every Ruby on Rails conference and meet-up in the ecosystem. This is where I learned the foundations of how to build developer communities and the importance of open source.

Throughout this time, while living in San Francisco and working with local developer communities, I met and formed friendships with early GitHub employees, or “Hubbers,” and saw how committed the co-founders were to community-building. It was part of their company DNA and came naturally to them. They were so obsessed about what they were building that they wanted to share it with the world. All the early employees were encouraged to speak at conferences around the world, contribute to open source, publish their own OSS, and write about it—the kind of work we would now call “developer relations”. 

Even successful startups can encourage work-life balance

After EY, I worked at New Relic for a few years building their community programs, and launched their community conference FutureStack. Through my connections to the open source world, I was able to get some incredible speakers on the lineup over the years, like Julia Grace, Artur Bergman, and Mitchell Hashimoto. 

After New Relic went public, it was my time to move on. I am someone that thrives and craves the unknown and chaos of the early days. I was going to take some time off, but Mitchell and his co-founder Armon Dadgar wanted someone to help them organize their first HashiCorp community conference. HashiCorp was around eight people at the time. Even though I wasn’t “technical” in a traditional sense, they always treated me as an equal and made me feel valued. Mitchell and Armon were incredibly smart, kind, approachable, and empathic. They may have been young at the time, but they respected those who were married and did have kids. They showed me what a healthy working culture could be: When we were at work, we were focused and engaged. When we closed our laptops, we could be present in our lives and with our families. They proved you can still work at a fast-working rocketship and build a culture of balance. 

The power of discerning developers 

I consider genuine human connections a pillar for community building: This is how I bring value to technical companies even though I’m not in technical roles. I don’t approach people thinking about what they can do for me. I start by recognizing they’re a human trying to solve similar problems and looking to make authentic human connections. 

I’ve helped build communities around HashiCorp’s six open source projects: Terraform, Vault, Nomad, Vagrant, Consul, and Packer. Over time, we decommissioned projects like Otto and open sourced new ones Waypoint and Boundary. The success metrics, or goals you set for an open source project, are different from the ones you set for the community and company. For a project, you’re tracking GitHub stars, engagement on GitHub discussions, the number of people contributing. 

But let’s say you have an open-core model and want paid users to sign up for your product. Education and peer-to-peer knowledge-sharing are the two most important pillars to get people to discover, understand, and adopt your project. When we open sourced Terraform in mid 2014, the first few years our download numbers were fairly low. This surprises people, but we spent the first two years educating the industry on what Infrastructure as Code (IaC) even was. Mitchell and Armon gave 40 talks alone on the subject over those years. Education programs included workshops, training, helpful guides, tutorials, regular YouTube and Twitch streams, and robust up-to-date documentation. Now you say IaC and everyone gets it. Producing this kind of content is far-reaching, adds value to the broader community and surfaces the knowledge held within an organization’s developer teams.. 

Knowledge-sharing programs revolve around the fact that developers trust their peers more than they do companies. They want to learn from each other and see use cases. One of the many benefits of building a community is that you create super fans that help amplify your message, spread the word, respond to other developers on your behalf, and become an extension of your company. 

Don’t bluff developers. If your product brings value and your programs are sound in terms of education, you’ll help developers by empowering them and connecting them with other people. That’s what will inspire them to adopt your tool—not through webinars or pressure from sales. It’s the community that convinces someone to be part of something.