a16z recently dropped a podcast that every developer relations professional needs to digest: "a16z Podcast: Measuring & Managing Community Orgs, Developer Relations and Beyond".

2021 Update: this is now given as a talk on GitHub's OCTO speaker series:

This is audio from a workshop held in 2018 - no video is available, but I was able to obtain a copy of slides from Amir Shevat, the presenter. Amir formerly was the VP of Product and Developer Experience at Twitch and former Director of Developer Relations at Slack, and he was previously an evangelist at Microsoft and Google. So... quite a resume.

TLDR

Top takes for the TL;DR crowd:

• Most startups don't need devrel - but that can change once you start doing integrations
• Product feedback is the most impt job - put devrel in product org, triage top 3 issues EVERY WEEK
• Decide on Breadth vs Depth and hire accordingly

Growing Dev Community:

• Offer fun, growth, belonging
• People want recognition - put their names in badges and release notes and make it fun
• Dinner with community leaders EVERY MONTH
• Swag works

Make docs/site easy to contribute to, create a pipeline to grow contributors.

Notes

• When should Startups start Devrel?
  • Only do it if you HAVE to. Startups need to save their budget for engineering hires.
  • Devrel is expensive, it is a one-way door.
  • More than 90% of startups don't need devrel.
  • It IS required when you are building a developer platform, when they are your users.
  • You also want it when developers drive value for the core audience: Slack started without Devrel, but quickly opened one when they discovered that users' top favorite thing about Slack was the integrations - built by developers.
• How to Devrel?
  • Advocacy: 1 to many. Create dev tools/experience/awareness.
  • Partnership: 1 to 1. Create great partners releasing on your platform.
  • Enterprise Architects: Post sales support.
  • Content Writers: Docs. Measure this team by "mean time to hello world".
  • Voice of Developers: The job of a devrel is to inspire devs (sell the reason), educate them (tutorial), enable (tools, sdks, api, devtools), but the most important thing is feedback. Evangelists don't take feedback. Never hire evangelists, hire advocates to give bidirectional flow of info.
• Developer Engagement
  • Dev Funnel: Interested -> Trying -> Testing -> Prod -> Paying
  • Nail 2 things: Measurement (how people move thru your funnel), and Levers (what activities you can do to move them thru).
  • People often measure the wrong things:
  • Developers "engaged/touched". Who cares? If it doesn't move anything it is an empty metric.
  • Developers registered. Who cares? Hackable. You'll turn devrel into salespeople. Devs don't want to talk to sales people.
  • Right metric: Weekly active developers, and % of paying customers who are using the platform. You also want diversification of integration usage as well.
  • Decide on breadth vs depth - few high value partners or broad? Choose partners who can be your "lighthouse wins" - your partners who can tell your story - esp if they make money with your platform.
• Where in the org to put Devrel?
  • Put it under product - gives the feedback loop
  • if put under engineering - will compete against engineers
  • if under sales - becomes sales
  • if budget comes from marketing - devrel becomes marketing
• The future is Streaming? Devs want to see another dev at work, live

Q&A with Amir and Mikeal Rogers

• Be careful about paying for developer interactions - "best way to ruin a marriage is to pay for sex". Can backfire really hard. Devs want belonging, fun, growth - tie it into overall vision.
• Who to hire first? Depends on breadth vs depth.
  • Breadth: Content Writers and Advocates
  • Depth: Partner Engs
• Interview: build on the platform, describe how the platform sucks. Seek empathy, willingness to admit room for improvement.
• How to choose between easy to measure but less effective things vs hard to measure but potentially more impactful things? Do the right things over the easy to measure things. Sometimes it can take >6 months for developers to try you out after first hearing about you.
• Swag and dinner expenses are worth it. Slack socks worked great. Creates belonging.
• Devrel know how to message to developers, have the most empathy. If you don't build the feedback loop to product, will create a lot of frustration. At Slack, every week both support and devrel can bring 3 issues to product, and product HAS to triage them. Every week there is a PM accountable.
• KPI to describe health of community: If a community leader leaves, how likely is the community to disperse? A community lead needs to have an apprentice, a second in command. Dinner with community leaders every month - to engage them.
• Big Partners are great for initial launch - beta program before launch is high value, low cost. Bring developers to the office to do what you ask them to do - it's humbling to watch the confusion. Cost $50 of amazon vouchers.
• How to trust your team? Tie them to a single metric: Twitter reactions -> blogposts -> landing on dev sites. "Show growth of 20% week on week" (!!!?!)
• https://devstats.cncf.io/
  • amount of time to get a response in an issue
  • how long does an issue take to get resolved
  • connecting open source to a service - can measure that
• Application devrel vs Core devrel
  • People contribute to your OSS because they want recognition, some incentives on your platform.
  • Don't assume devs are going to show up with all the skills they need to contribute - need to build a pipeline to get there
  • Make docs and website very easy to contribute to.
  • Most people show up to fix 1 thing, but they stick around bc of community. It's not even about external recognition - internal recognition can be enough, if they did something hard that is recognized by core devs.
  • People like to see their names pop up in badges.
• Developer as customer vs Developer as community member - there is a lot of overlap
  • As Customer: it's about value exchange, e.g. Twilio, Stripe
  • As Community Members: it's like "miniemployees" - they are kind of working for you - it's about fun, growth, and belonging.
• Create release notes that are really funny, helps to make feeling that you aren't "managing" the community, you're a member of the community. You can't "manage" a community from the outside - you have to be a part of it.