Between the three of them, the co-founders of Orbit have decades of experience in engineering and developer relations, building products at companies such as Accenture, Algolia, Apple and Keen.io. After launching Orbit, they spent the last year talking with people in the DevRel space about proving the value of DevRel. January is a common time for executives to ask what kind of investments they should make in developer relations including what the hires to make, and what the business case is.
- Q: What are the biggest missteps companies make when it comes to DevRel?
- Q: What parts of DevRel should companies outsource?
- Q: How do you leverage partnerships?
- Q: How can DevRel partner with business development?
- Q: How do you balance creation vs promotion?
- Q: Who in DevRel would you like to call out?
One big mistake is trying to hire a developer advocate before the company has learned to do at least a little DevRel on their own. In the consulting world, companies would come to us and say "we’re ready to hire, we just need help writing a job description and sourcing candidates." At that point, sometimes these companies had not given a talk or created developer-facing content.
By contrast, at some companies, every engineer is doing some aspect of DevRel from the time the company starts, like giving talks and contributing to projects. If a company tries to hire a DevRel-specific role but doesn’t have experience in that area, it’s going to be difficult for them to be successful.
Companies and teams have to define their internal expectations for DevRel. It’s common to read a job description for DevRel that isn't focused -- it could span dozens of key activities! If a company has done DevRel themselves, they typically surface a more focused job description. For example, do they see this role on the road giving talks, or being an internal advocate? We want to help companies avoid writing job descriptions that are “be all the things.”
It depends on which parts of the DevRel process you need help with.
On one hand, your DevRel person who has the touch points with the community -- that person should live and breathe inside your organization and embodies the organization's culture. If a company has contracted with an outside firm, you may not get the same experience talking to them, versus talking with employees embedded in the culture of the company.
If your advocate echoes your values, it leads to a better developer experience. That’s a risk when making a contract hire, especially on the community side. I’ve seen contractors do social media for a company’s developer community and it all goes wrong — it’s mind blowing why companies do this with little training and oversight.
However, if you’re working solely on content, tutorials, etc, that can be a great place for outside help, since there will be other people in the organization that are reviewing the content to make sure it falls in line with the company's positioning and values.
We consulted for the past year so we have some bias here, but using outside companies to generate strategic, third-party content can give you a lot of leverage. They can lean on your internal teams to amplify the content and bring the messages to market. We’ve done this a number of times with different companies -- it makes developer advocates inside the company feel like superheroes because they have a lot of great content that they can bring out and share with the community.
Q: How can we in developer relations leverage internal partnerships to increase our reach and effectiveness?
We think partnerships can be one of the most impactful parts of a successful DevRel strategy. A single advocate or DevRel team serves as a force multiplier across the entire company. The internal impacts of a team that’s working well are enormous when multiplied across the entire company. We can give tons of examples, but to focus on a few: in marketing, DevRel can help keep the brand voice true to the developer personality. In return, marketing helps DevRel be more data driven, driving value in both directions.
In larger companies, there is an opportunity to bring the voice of the developer into internal conversations. You can imagine bringing stories from the field into the walls of the building and giving the company a few into how developers interact with your product.
Historically there has been somewhat of a mismatch between teams like sales and marketing and community teams like DevRel. Often this is based on a mismatch in funnels. DevRel can evangelize alternate models of measuring impact of community instead of the standard model of pushing people into a funnel and measuring purchasing events. The Orbit model allows you to rewire the way companies think about community, not just a standard marketing funnel, but allowing you to create metrics around your community efforts.
We also see DevRel and Sales working well together — historically, this isn’t always the case! We've seen that they can be very collaborative and complementary when there is clear communication. In large organizations it's rad to see individual developers participating in the community -- if a company's developers are contributing to your project, that’s a strong signal that the company may be interested in a commercial relationship. From a sales perspective, you probably don't want an SDR emailing those developers, but the SDR would love to have feedback about that developer’s activity that they could reference when calling the developer’s manager. Of course, that requires data and tooling on the back-end to surface that information, and that’s something we see a lot of companies moving towards in 2020.
We actually wrote a whole series for Heavybit covering different tactics for internal collaboration.
Q: How about business development -- where are the opportunities for developer relations teams to partner there?
Agency partnerships come to mind pretty quickly. For companies with a developer-focused platform, part of the BizDev model is to partner with agencies who can build the platform into products for clients. Algolia had relationships with agencies implementing all the different ecommerce and CMS platforms. Creating formal partnerships with these companies can be useful for BizDev but can also help your DevRel program by encouraging the agency developers to be involved in the technology ecosystem. DevRel can also partner with complementary companies and projects. This can keep things fresh and make sure you’re not talking too much about yourself and your products -- you're bringing some fresh voices into the conversation.
Q: Where do you draw the line on creating new assets, such as content and talks, and promoting those assets? Should 100% of your DevRel budget go to creation, 100% to publicity, or somewhere in between?
Looking at DevRel as a whole, generally we think that more re-use would be smart. Writing a new presentation each time you give a talk is very expensive in terms of effort and mental energy. Many developer advocates are hesitant to re-use material, but they shouldn’t be -- there are millions of developers out there who haven’t seen your presentation before. If stand-up comedians can re-use the same jokes for years, you shouldn’t have to worry about giving the same talk twice in the same city. One trick I have: give talks to engineers inside the company, and then let the engineers give that talk elsewhere. Make your assets and presentations so that others can re-use the deck and script. That’s a nice way to get engagement in the DevRel effort from others in the organization — three months later, someone is speaking on stage, maybe for the first time.
Often there are engineers inside your company who want to get started getting talks, and as developer advocates who do this multiple times per week, we can facilitate these engineers and also cover more territory. (There are a lot of events I want to speak at, but I can’t be in two places at the same time.)
- Doron Sherman, VP DevRel at Cloudinary has a great DevRel program
- Stefan Judis at Twilio for being data-driven, he’s got a great approach and dashboard for his content that is pretty impressive
- Tim Berglund and Ale Murray, Confluent team