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.

Sarah-Jane Morris at a booth

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.

Sarah-Jane Morris

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.

Sarah-Jane Morris staffing an event

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?”

Sarah-Jane Morris building community

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 fine line — 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: