DevRel Engineer One: Building a Developer Relations Team from The Ground Up

It sounds like an exciting challenge: join a company and shape the entire developer relations strategy as their first DevRel engineer hire. How do you shape a modern and effective DevRel program, while making sure you include accurate metrics, diversity and community building.

Today I'm interviewing Sarah-Jane Morris, developer relations team lead and community building expert. Sarah-Jane spent 6 years in San Francisco building inclusive developer communities at companies like Mashery, Intel, Keen IO, and most recently, Shopify. She has worked on marketing, community, SEO and branding at both B2B and developer-facing companies. She’s driven by an audacious vision of a diverse and welcoming tech industry. I was curious how she would you address community and effectiveness -- especially in, say, in an early stage company where you are the first dedicated developer relations hire.

I met Sarah-Jane most recently at DevRel Con San Francisco and when she spoke at ForwardJS Ottawa. She currently runs Listen Community Consulting, and she has graciously agreed to share her knowledge with me in this interview.

Table of Contents

• Q: You're the first DevRel hire. Where do you start?
• Q: Let's talk events: meetups, conferences or trade shows?
• Q: How do you determine a content strategy?
• Q: How do I select the best DevRel tools for my team?
• Q: How do you create metrics for DevRel?
• Q: How do you choose an effective content platform?

Q: Pretend you're the first developer relations hire at a company. You have a huge task ahead of you on many fronts: docs, lead gen, events, content, product. Where do you start?

As a new DevRel, your first touchpoint is going to be the existing community. One of your first mandates before even starting to think about internal touchpoints would be to understand the needs of your current community so you can get the baseline: how happy are they with the docs? How do they feel? Have they come to events so far, what do they want to see more of? SDKs?

Whether that’s a series of one to one conversations after looking at the data, or seeing who is most active based on how your product measures activity (API calls, cloud accounts, etc.) Whatever the metric is, talking to folks who are indicating that they are getting some sort of value out of your tool.

Additionally, connecting with the folks who are not hitting those metrics will help you paint a full picture of how the community is currently interacting with some product. Connecting with the community will let you create very high-level personas — through surveys, e.g. the survey work I’ve done with keen — We got a lot of data and we were really surprised that a lot of the assumptions about our community were wrong, even assumptions as simple as the languages our community was speaking, or how useful users found our community spaces such as Slack.

This baseline research will help you figure out what you should focus on in your first six months: which programming languages, which sample code, which strategies you should build out to reach out to communities. What frameworks or tools are complementary to your product? What kind of events should you go to? This baseline research is critical to determine these crucial next steps.

Q: It seems like everybody in the company has a different idea about event strategy: for example, the CEO wants to do conferences, Sales wants to do trade shows, Engineering wants to do meetups. How do you craft a cohesive vision for events?

From a Devrel perspective, you have to make sure that your meetups, workshops, and talks align with the overall goals with DevRel. Maybe it’s the community goals, maybe it’s to build out a “defensive moat” of awareness for your company. In that case, you’re not measuring directly to RoI: How many badges did we scan?

Or, you’re working with marketing and perhaps you’re the one who can speak in a most compelling way about the product in a technical sense. It’s important to defend your goals as a DevRel team even while working in collaboration with marketing. Make sure you surface your community goals and product feedback goals into the event strategy that you decide on collaboratively.

When interviewing with the company as devrel hire #1, ask these questions and get an idea of something that they want out of you. If they only want you to go to marketing conferences, for example, you’ll have to work with them to find some common ground.

Make sure that your vision of DevRel is aligned with the company. You’re going to wear many hats, but you’ll have to advocate for the goals of the community and product feedback that show the true value of what DevRel can bring to a company.

As Mary Thengvall says, “to the community you represent the company and to the company you represent the community.” Make sure your events drive your core mandate as a company and in the community.

Q: Some organizations are throwing all this weight behind content and content syndication, and others are just getting into the game. How do you determine what’s right for a new company?

Going back to our baseline research, one of the important things to do is not only weave in interviews with users and stakeholders of the company. From there, you’ll extract the “bigger picture” themes of what kind of value your community is adding back to the tech community.

For example, at Shopify, our app marketplace was really helping us to fulfill our mission to support entrepreneurs at a high level. So how can you—as a company—start to raise brand awareness around certain high-level value topics. If your company does continuous delivery, maybe you’ll be talking about accelerating software development and making developers more effective.

Think about do you want this content to live mostly on your blog, or at more neutral places like dev.to or external blogs? (This is something to work with marketing on.) It’s less about generating leads and more about generating conversations that will drive users to your website, let them research and eventually download a whitepaper and generate a lead.

If content strategy seems too difficult, start by weaving your content starting with your events strategy. Record talks at your events, do recaps at events and post them to your blog, take pictures and post them to social media. By weaving these two strategies together you can get more value out of each strategy, which may be more accessible than creating a content strategy in these large theme areas.

Q: There is a myriad of tooling out there to manage communities, metrics, and DevRel workflows. Where should you get started?

This widely depends on factors like your budget. There are open source tools out there, e.g. Vanilla has an open source forum. One thing I’ve seen a lot with early-stage DevRel teams is they’ll start with a Discord or a Slack. I would recommend that early on you start to build out an evergreen Forum that you start to seed for developer information.

One thing you can do as part of your early stage baseline research is to ask developers about what kinds of data they want and how they want to interact with devrel in your company. Through those conversations, you can roll out an alpha version and incentivize your power users to seed these tools with questions, answers, and information.

Early on, your Slack or Discord will be amazing because your team will be engaged and people will get questions answered, but unfortunately, eventually, this will not scale. Eventually, you’ll want something that keeps answers available and makes them available via SEO.

I hesitate to encourage devrel teams to rely too much on external communities like StackOverflow. They should definitely be monitored, but having everything living on StackOverflow takes awareness control away from your hub. External forums can also be a less friendly place than a moderated community hub that you control, and you don’t want new users shot down every time they ask a question, which is the stereotype with some of these external resources.

Q: How should you create metrics for your DevRel team?

The number of attendees at events is an easy metric, but the way you measure the success of your events should be based on a survey at the end of the event, similar to an NPS event score, just to get a sense of whether people will attend future events and whether they liked the content. Over time, you’ll start to notice patterns.

Another thing to look at: repeat attendees. These days I find myself mostly talking about a series of meetups because you can get good data. However, for a conference, I’ll always point a developer company away from a booth or as an exclusive way of engaging developers. Sign up for a workshop in addition to your booth, or a really tactical talk that lets your company educate and give value back to the community. Maybe the metric there is “How many folks actually made it through what you were teaching?” At Shopify, we did a series of GraphQL workshops and we measured how many got through each step in the workshop. Then, from a business perspective, measure how many of the attendees actually built out something with your tools.

Hackathons are similar to Workshops in terms of their engagement metrics. That being said, you can also track the “cliche DevRel numbers:” how many stickers did you hand out? There is a little bit of swag fatigue in the community these days, but you can also (for example) raise money for a nonprofit, and measure how much money attendees and people donate.

In the end, be realistic. Events are about building things, like brand engagement, that is immeasurable. These little touch-points over time really start to build momentum for your brand, because developers know who you are and have a good feeling about you. Track these in ways that are as short and sweet as possible: “Did you like it?” “Would you come again?”

Q: When publishing community content, your metrics can be impacted by the platform you use: internal or external. How do you choose wisely?

Jeff Lindquist has a slide that says “Go where developers are!” Our tagline at Mashery was the same, and that has always guided my strategies. If there is a concentration of developers reading a certain publication and you can add value there, it just makes sense to craft content there. There will be a lot of novel things to keep in mind: Dev.to is a great place to syndicate your content because you can put in a canonical URL, so you’ll be able to get that SEO juice.

There’s an ongoing tension between DevRels as “personality” individuals that agnostically work with the company and try to be as neutral as possible, versus the DevRel that is purely inside the company, so where does the content live to reflect that?

By using an external tool inside the company, you can walk that line a little finely — some companies historically did that by having a Medium publication for that corporation, but recently Medium has been pushing their paywall. These days you’ll also see a number of people using dev.to, but you don’t want to rely too much on one tool, and your publication tooling will change as your tooling changes and your company changes.

Thanks to Sarah-Jane Morris for this interview.

Next Steps:

• Follow Sarah-Jane on Twitter
• Reach out to Listen Community Consulting