Accelerated DevRel: Developer Relations from a Startup Accelerator Perspective

If you've spent enough time in developer relations you've undoubtedly run across some of the excellent content put out by Heavybit, a 9-month accelerator and fund that helps startups scale their go-to-market. Dana Oshiro @DanaOshiro is GM and General Partner at Heavybit.

While she's far too quick to throw out that she's "not in DevRel," her deep knowledge of scaling methodologies for developer-facing products makes her skillset so complementary to developer relations that the differences cease to matter. I sat down to chat with Dana about DevRel, startups, and how to scale both at the same time.

Table of Contents

• Q: How do you define developer relations?
• Q: What should you look for in your first DevRel hire?
• Q: What do you tell your portfolio companies to focus on?
• Q: What's new in DevRel for investors?
• Q: How did you get into developer relations?
• Q: Where is the DevRel ecosystem heading?
• Q: Who in DevRel would you like to call out?

Q: Developer relations is a notoriously difficult discipline to define. Different companies have different definitions of success, aspirations, and organizational structures. How do you get the vocabulary right?

We often see Series Seed and Series A startups look to DevRel to either increase product contributions and support for an open source community, or to build momentum for a bottom-up go-to-market. My advice to companies is to identify their org-wide objectives and areas for opportunity for the next year, and ensure that key results for all departments and individuals cascade from there. Hiring managers need a clear picture of how their org, and a role will be measured, and how to train new Dev Rel hires for success.

Q: You mentioned hiring, and missteps that companies can make hiring for DevRel. What about choosing strategies and tactics around the time of your first hire: should those be defined by the company in the job description, or defined by the first DevRel hire?

Regarding hiring your first DevRel person, it’s risky to choose someone who is an incredibly talented specialist when you're staffing an early stage company. Most companies in the early stages lack product/market fit and their referral channels and product activity metrics aren’t well baked. This means the DevRel hire needs to be flexible and cannot be married to a specific tactic or platform. Eg. If field marketing or content aren’t performant for the larger org, then they’re not viable specialties to hire for at this time.

Sometimes the first hire’s task is to log and reduce repetitive and unnecessary support requests. Many of these requests can be passed to product to make onboarding more intuitive, or they inform the creation of better documentation, tutorials, and landing pages.

Q: What do you focus on with your Heavybit portfolio companies when it comes to DevRel?

There are a lot of early stage companies who are being told that the most efficient way to approach developer relations is to build an efficient bottom up go-to-market strategy. Perhaps the founders will write a few blog posts, publish them, not see the results they wanted and then throw up their hands and say, “We tried community, it didn't work! Our company must have a top-down strategy!”

But top-down sales requires some knowledge of hiring a sales team, acceptable sales metrics, and building a demand gen and support function. It’s not impossible when you’re early, but it’s tough and very expensive. In most cases, we urge companies to explore opportunities to gain useful developer-first conversations to inform their product, marketing and sales before abandoning community strategy completely. Topics we often help with include first hires, testing first working inbound channels, areas for product optimization, content and editorial strategy, platform growth, 3rd party partnerships and integrations, support/request triaging, and where needed, category creation and education.

Q: I loved your talk at DevRelCon San Francisco. What has changed in the ensuing six months?

In the context of DevRel, I recognize that there are different stages of growth for companies, but the funding numbers that I threw out during my talk at DevRelCon SF fluctuate and are less important than the whole picture. Venture-backed companies need to be sustainable and profitable. The TLDR is that if you’re running a corporate venture-backed community, there are ROI conversations that need to be had. Increasingly, this is easier to do when you’re able to attribute a lead or a major product insight to your work, but with DevRel that attribution can still be nebulous.

Q: Your work at Heavybit covers such a variety of fields. What career path brought you to DevRel?

I’ve worked in community-building for a long time including advocating for environmental health regulation, educating publishers, helping Heroku partners, and as a marketer and community recruiter for Code for America.

With Heavybit, I wanted to work on the core curriculum for the 9-month accelerator and knew that our community of devtool founders and advisors was a big part of the draw. Now it’s 5.5 years later and we’ve got sub-communities of content marketers, JAMstack enthusiasts, and even CISOs. Also, the nice thing about having worked with 50 companies all in the developer space, is that we’re able to benchmark companies against each other and founders are able to help their fellow peers in their own sub-community channels. In total, we work with 120+ founders, 600 active program advisors/contributors, and we have tens of thousands more attend our events and view our content.

About a year and a half ago we closed our first fund and started investing in companies who join the accelerator. Our focus is seed and Series A dev tool and enterprise companies and we invest $250k to $2M. The goal with this fund is to try to help propel these companies from seed-stage to Series B with community frequently being a part of that mix.

Q: Where is the DevRel ecosystem heading, and how will we collaborate with other groups in the future?

Del Rel is becoming increasingly more important as developer success is often tied to product success and revenue. In the past though, dev rel has been siloed from other departments or has been an addendum to product and marketing. This means it’s been hard to optimize between departments and show ROI from this group. At the end of the day, we all want to build a great user experience - dev rel wants to support the success of developers, product wants to find new ways to optimize platform success, and sales and marketing wants to extend value for customers. I think we’ll see more processes and tooling to connect the dots between these orgs in order to get a better picture of the user’s journey from start to finish.

Q: Who else in the DevRel ecosystem is doing a good job? Who should we pay attention to?

We just invested in Orbit - a company we believe will help DevRel teams and companies better manage their communities. We’d worked with the team at Keen, and they’re prolific in shipping product and community features while also building a strong community. Based on what they’ve done in the past to build organic communities through their data science happy hours and the camps they would run,we expect big things from them.

People I admire and think are great community builders:

• Mary Thengvall: Literally wrote a book on the Business Value of Dev Rel communities, continues to publish DevRel Weekly, and is an admin for DevRelCollective.
• Martin Gontovnikas: VP of Marketing and Growth at Auth0, continues to produce great talks and content, maintains a fresh perspective on serving his community and the dev rel community in general.
• Simon Maple: VP of Dev Rel at Snyk, core in building DevSecCon and the DevSecOps movement, has created a platform for security-minded devs and open source communities to connect. Beyond that, I’d say David Spinks from CMX and Matthew and Tamao from DevRelCon have been fairly instrumental in moving the profession of dev rel forward and keeping practitioners abreast of the latest strategies.