Getting Started in Develop Relations Notes

by Lucas Minter

← go back to all posts

These are my notes Sam Julien's book Getting Started in Developer Relations. Sam is the Director of Developer Relations for Auth0, an instructor for egghead, and the author of Getting Started in Developer Relations. You can buy that book here.

What is Developer Relations?

What is DevRel?

The main task of developer relations is to build relationships with users and potential users, mediate between them and the company, and advocate for their best interests.

What does this look like?

  1. Awareness. a synonym for marketing, but marketing to developers is somewhat of a different angle than traditional marketing since developers by and large hate to be sold to.
    • Awareness means letting people know about the product, including features, broad use cases, updates, a product roadmap, and anything else relevant to using it. A big focus here is on problems that the product solves.
  2. Education. Users and potential users need to know how to use the product, how to solve problems with it, and where to go for help.
  3. Feedback, also known as product advocacy or developer advocacy.
    • One of the most critical goals of developer relations is to gather feedback from users and potential users.
  4. Community. Community is the chameleon of the bunch, as it can be part of developer relations, branched into its own department, or mixed in with customer support.
    • community is the backbone of all dev rel.
      • help solve problems, celebrating their successes (with and aside from the product, and empowering them to improve in their careers.
      • Lip service or inauthentic community pitches can be spotted a mile away

There is an omission on this list: sales. Dev rel can lead to sales but it is not the primary directive.

  • The neutrality of dev rel is critical here. It has to be unmotivated by sales to keep clear judgment and explore feedback with an open mind.
  • Dev rel does have to provide its value to the organization if it's not based on pure revenue due to sales.

The Developer Advocate Job

The daily job of a developer advocate can vary widely, especially depending on team size. 

9-10 am: Prepare talk for upcoming conference.
10-10:30 am: Meet with content team for collaboration on GraphQL article.
10:30 am-12 pm: Respond to DMs, Slack messages, and forum posts asking
questions about the product or talks and articles you've written.
12-1 pm: Lunch (you've gotta eat!)
1-1:30 pm: Meet with SDK team on feedback you've gotten from early access users.
1:30-2:30 pm: Collaborative live stream with a compatible company on how
your products work together.
2:30-4 pm: Work on new features for internal tooling.
4-5 pm: Write quarterly report on conference and meetup impact.

While Traveling: 

7-8 am: Meet with program participant (only overlap in time zones).
8-9 am: Last minute slide tweaks and practicing.
9 am: Speak at conference
9:30-12 pm: Hang out in hallway answering questions from attendees.
12-1 pm: Sit with conference attendees at lunch but forget to eat because
you're answering questions!
1-3 pm: Sit in hallway answering DMs, messages, and forum posts but
pausing to say hi to people and answer questions.
3-5 pm: Sneak back to hotel room to attend meetings with various teams
and teammates.
5-6 pm: Collapse for an hour to recharge.
6-8 pm: Dinner with attendees and other speakers.
8-...?: Hang out with attendees and other speakers.

Speaking and listening:

  • Speaking: Awareness and Education
    • This is largely content. Blog articles, recording tutorials, live streams, podcasts, conferences and meetups (in person or remote).
    • Running or sponsoring events.
  • Listening: Community and Feedback
    • Talking to event attendees, reading/responding to forum posts, managing forums, running incentive programs to empower developers in their own careers, working with the SDK(Software development kit) team on product feedback.
    • This is the supportive part of the job.

Maintenance and logistics

  • building and maintaining internal tools, wiring reports, documenting strategy, managing open source libraries or microsites, self-education.
  • Admin work, emails, paperwork

Do I need to switch jobs entirely to do dev rel?

  • Well, how do you know you want a full-time job in dev rel?

The hidden treasure of your current job ( and the downsides of dev rel.

  • First, your best learning comes from solving difficult problems and being forced to solve a difficult problem is the only way it gets done.
    • Exposure to a lot of new concepts and patterns
    • Solving difficult problems in less than ideal constraints
    • All of your code could be obliterated, something all software devs need to learn one day.
  • Most of the time in dev rel you don't have the same level of forced problem-solving.
  • Second, it's entirely possible to do dev rel work as either part of your current job or on the side until you figure out if it's what you want to do.
    • Start with some presentations for coworkers on relevant topics.
    • After getting comfortable with that, search for local meetups to start giving talks.
    • You can dip your toe into the waters without jumping straight into a full-time commitment.

What Employers Look for in a Developer Advocate

  • dev rel is a new set of skills you can learn
  • If you feel totally overwhelmed or like you suck at your job, this is not because something is wrong with you as a person — it's because you need to learn and practice a new set of skills!

What are the core character traits that you really need going into this?

  • First and foremost: EMPATHY.
    • Empathy has to be there from day one.
    • You HAVE to care about your community, users, and customers.
    • We want "That sucks!" to be our first response.
      • Empathize with the users. Understand their pain and acknowledge it.
  • Second: Love of learning
    • You're going to learn a lot, like all the time.
    • There's not a lot of comfortable bug fixing or familiar codebases lying around.
  • Third: You have to be able to manage several projects at once, sometimes in vastly different skill domains.
    • Adding new features, writing/creating a new slide deck, recording tutorials, creating quarterly reports.
  • Fourth: You're a good communicator
    • Can you convey info to others?
    • good at teaching?
    • Your preferred medium of communication is up to you.
    • NOT EVERYONE HAS TO BE AN AWESOME WRITER OR KILLER SPEAKER, especially starting out.
    • Do you listen to people, make them feel heard, and convey your ideas in a way that's easy to follow?

The Dev Rel Career Ladder

This is still being worked out.

Mary Thengvall's key areas are as such:

  1. Functional skills
  2. Delivery
  3. Teamwork
  4. Leadership
  • A Level 1 Dev Advocate can run the demo built by someone else on the dev rel team.
  • Level 2 can build the demo.
  • Level 3 can design the demo.
  • Level 4 can coach the person designing, building, or running the demo.

Some good questions to ask during an interview:

  • How do you measure a developer advocate’s performance?
  • How does a developer advocate advance in their career here?
  • What opportunities for leadership or mentoring do you have here?
  • Do you have a career ladder for developer advocates (or do you plan on creating one)?

Here’s the secret: don’t forget that in dev rel (as in most things in life), you are the prize.

Variations and Related Jobs in Dev Rel

For example, you might see positions that are solely in Community

You may also see content or product education jobs

  • These might be just writing or producing educational content.
  • Might be documentation, marking, or dev rel teams.
  • It could be solely a speaking role

Technical writing and product education can be entire careers in their own right.

III. Measuring Impact

"One of the most difficult things to do in Developer Relations is prove that the investment is worthwhile." - Mary Thengvall

This is one of the hardest problems in dev rel.

How do you know if dev rel is doing a good job?

Impact: Measuring Dev Rel's ROI

Impact is the total return on investment of dev rel work, measured both quantitatively and qualitatively.

  • How many people affect you and how you affected them.

The impact can mean:

  • Someone learned something from something you said or wrote
  • Someone bought something from you
  • You made someone's day
  • You recommended a tool or a resource that someone appreciated
  • You helped someone solve a problem

We need to measure negative impact as well.

Take the inverse of each of the examples and remember to look out for those.

Examples of quantitative measurements might be:

  • Views on a video
  • Attendees at a talk
  • Signups
  • Sales (sometimes called “conversions”) or revenue (note that it’s just one dimension of measurement here)
  • New followers on any number of platforms

"You can be the smartest, most noble person in the world with the best product ever made, but you won't make an impact if you don't have a voice and an audience."

Qualitative measurements are ways of describing the activities you’re doing and the feedback that you’re receiving.

  • Goodwill in the community. How liked/respected are you or the brand?
  • Meaningful conversations
  • Depth of relationships. This can be with users or with other members of the dev community.
    • A good way to gauge depth is whether you'd feel comfortable asking each other for help with something.
  • Influence: The standard example of influence is always Apple: when they made the decision to remove disk drives from computers, the rest of the industry followed. It could be highly regarded members of the dev community ask for my opinion or ask to collaborate on content.
  • Technological area: Are you focusing all of your content in one area? Where are the questions coming from? Ruby? Django?

What a report looks like after a work trip:

Quantitative:

  • Number of attendees at each event
  • Number of new speaker/organizer/sponsor relationships
  • Number of new developer relationships
  • Signups (of any kind)

Qualitative:

  • Examples of deepened relationships
  • Examples of goodwill created
  • Examples of new opportunities created by this trip, whether speaking, co-marketing, collaboration, or anything else
  • Product feedback you received
  • Questions you were asked (and all of their qualities, such as which technology or feature they were about)

Using Impact Data

If you don't do anything with your measurements, it means nothing.

Use your data to start to set goals that can be both quantitative and qualitative.

Identify trends and use those trends to improve your content and the product. For example:

  • Is a talk/article doing particularly well? Try creating more content along those same lines.
  • High number of questions on a feature? Check out the docs to make sure it's easy to understand or possible issues that may have been missed on GitHub.
  • Getting requests for content on a particular topic? Listen to your community and create something great!

IV. Building a Personal Dev Rel Strategy

You can use this in at least three different ways:

  1. To start building a body of work that you can take into an interview and talk intelligently about, including how you’ve measured success.
  2. To apply to your day job as a way of leveling up in your current company.
  3. To use as a basis for your personal content creation or “personal brand” (think of personal brand as your collective portfolio that you might use to get a job or consulting clients).

Dev rel and personal brand are really two sides of the same coin.

We’re going to go through five steps to building a personal dev rel strategy:

  1. Pick a tool or SaaS product that you absolutely love and that you feel has some level of credibility in the community.
  2. Dig into the wins, friction, and pain associated with this tool.
  3. Use that research to create a strategy around the four key areas of dev rel.
  4. Create content to support your strategy.
  5. Measure your impact and use the feedback to and improve

Step 1: Pick a product.

What software tool or service that you absolutely could not live without?

(first sentence of page 34 has a typo): "it might a software product..." should be "It might be a software product..."

The point of this exercise is to build experience, so you can always change your mind.

Once you’ve got a product or tool picked, it’s time to pretend that whatever company made that tool or service hired you to do developer relations for them.

  • What would you do?
  • What is your main goal?

Step 2: Wins, Friction, and Pain

We need to get in the heads of our users and understand how they view egghead.

  • Who uses egghead?
  • What issues are they having with installation and usage? Bugs?
  • What problems are they trying to solve by using egghead?
  • What's the onboarding experience like? How quickly can they go from "what is egghead" to "wow this is cool!"

Just do your best and gather what you can from your own experience, forums, documentation, discussions you might be a part of or GitHub issues.

Since this is a product you love, you could start by asking yourself similar questions:

  • Why do I find this so indispensable?
  • Where do I get frustrated using this?
  • What would someone new to this tool find difficult? (Is there a steep learning curve for anything?)
  • How could this be even better?

Step 3: Use Your Research to Create a Strategy

To build your first strategy, you’re going to do the following:

  1. Pick one of the pain points or friction areas that you’ve found in your research.
  2. Come up with three different content ideas from different angles.
  3. Create and publish the smallest iteration of all three of them as fast as you can.
  4. Revise and improve on them over time.

Step 4: Create Content in Support of Your Strategy

It’s helpful to look at the issue from a variety of angles.

  • How do I solve the problem?
  • How can I avoid the problem entirely?
  • What’s the opposite of the problem?
  • What’s an example of where this problem matters?
  • What’s a real-world use case for solving this problem?
  • What other technologies might be commonly used when this problem is encountered?

Step 5: Measure Your Impact and Use the Feedback to Improve

Now that you’ve got some content written out, you’ll want to define some quantitative and qualitative metrics to track.

  • Tweets
  • Likes
  • thumbs up
  • views
  • conversions
  • Sentiment/Perception: Tweets, emails, forum posts
  • Feedback

In all likelihood, your initial numbers might be pretty small or you might not be getting good data. That’s okay! That's valuable feedback you can use to improve.

** Don’t stress too much about the results when you’re first getting started.

Negative comments -

Don’t respond when you’re in an emotional reaction!

Cool off and ask yourself some questions:

  • Who is this person?
  • Do they have a valid point, or are they just a troll?

Take negative comments as data. See if there is validity to their point and something you can learn, and watch for trends.

Respond with kindness! Sometimes people are just having a bad day.

Expanding Your Content: Tools in Your Dev Rel Tool Belt

Here’s a rundown of where different types of content work:

  • Podcasts are personal.
  • Written tutorials are long-lived.
  • Conference talks in person can be huge for getting attention.
  • Small Meetups, whether in person or online, is the high level of engagement and interaction you can get.
  • Live streams are short-lived but great for community goodwill and relationships.
  • Video courses are fantastic for showing hands-on tutorials or explaining something in a way that documentation doesn't quite nail.

TAKE NOTES

Think about how you might be able o improve in the next iteration.

Blog about the process!

V. Skill Focus: Applying to Conferences

Getting into speaking.

empathy, persuasion, and persistence

Your Perspective is Valuable

The best technical speakers are not always the best engineers.

Speaking is about storytelling, emotion, and breaking down complex concepts.

Is there a level of experience needed with your subject matter? Of course.

  • The audience can tell the difference between a junior and senior dev based on subject matter expertise.
  • If you’re a beginner, don’t sign up to give a talk on how you’re an expert at something. Frame the talk as a story about something really awesome you learned or an idea you had while figuring something out.
  • People love authenticity.

The more of an expert in something you become, the more you start to forget all of those quirks and rough edges that confused you as a beginner.

Speaking is (Another) Set of Skills You Can Learn

Crafting a CFP with Empathy

CFP means “Call for Papers” or “Call for Proposals.” These usually include basic biographical information, a title, and a description of the talk (often referred to as an “abstract”).

Conferences want to sell tickets.

  • They want solid, educational, entertaining content

Vetting

“But wait, how can I be vetted if I’ve never given a talk before?” There are a number of ways you can do this. One way is to start giving talks at local meetups and recording yourself giving them.

Community involvement.

  • Be public. Twitter, Gitter, StackOverflow, other forums.

How do I come up with a topic?

  • Many great speakers submit proposals on things they want to learn about but haven’t had the time or the opportunity yet.

VI. Four Strategies for Dev Rel Sanity

  • Writing a blog post
  • Answering questions on Twitter, Slack, Discord, or various Discourse forums
  • Making videos
  • Figuring out how to integrate a product with X language or Y framework
  • Building and improving programs
  • Collaborating with other companies on content
  • Streaming
  • Building a talk
  • Applying to events
  • Giving a talk (whether in person or online)
  • Appearing on a podcast
  • Working with the SDK team to provide developer feedback and improve the product

Strategy 1: Focus on shipping and improving instead of waiting for perfection.

Perfection is the enemy of getting things done.

"Perfectionism is the voice of the oppressor, the enemy of the people. It will keep you cramped and insane your whole life, and it is the main obstacle between you and a shitty first draft. I think perfectionism is based on the obsessive belief that if you run carefully enough, hitting each stepping-stone just right, you won't have to die. The truth is that you will die anyway and that a lot of people who aren't even looking at their feet are going to do a whole lot better than you, and have a lot more fun while they're doing it."

Strategy 2: Don't try to automate too quickly.

Go slow now in order to go fast later.

I'm sure you know what I'm talking about: after six months or a year, you come back to the code you wrote and realize you can drastically simplify it. Why is that? It's because you know what's important and what's not due to experience.

Strategy 3: Repurpose content to prefer depth over breadth.

One of the best lessons I've learned so far is to use your content in multiple places. This can mean giving a talk multiple times, but it can also mean splicing and dicing that talk into blog articles, emails, videos, or anything else.

I know some people are hesitant to re-use talks, but I think that goes away fast when you start doing dev rel full time.

  • The other thing I've noticed is that audience overlap is very rare, and even the few that see the same talk twice don't remember everything from the first time you gave it.
  • I'd much rather polish something repeatedly and give a really great version of a talk than keep testing out raw material. It's better for everyone.

Remember: popularity is not the same as impact, which is your real goal.

If you look at the people who are truly at the top of this field, you'll notice that they do both: they are great at moving fast on popular topics, but they also genuinely provide deep knowledge and value.

Strategy 4: Increase throughput by fine-tuning your systems.

What's throughput? It's the rate of production. You need to be able to move faster.

  • Optimization of your workflow and systems.

Here are some examples of that I've done in the past:

  • Getting a better A/V setup (a mic stand, a better audio interface, fixing some resolution issues) in order to reduce the friction of recording videos. This also drastically reduces my editing time.
  • Adding a trackpad to the left of my keyboard to speed up editing.
  • Automating meeting notes creation with Shortcuts.
  • Rebuilding my personal site so that I can quickly write and publish articles that have a nice, accessible reading experience.
  • Using apps like Focus to block out distractions.

Bonus: 14 Quick Wins to Get Started Right Now

1. Find your first CFP to apply to
2. Write your first CFP
3. Find a local meetup
4. Contact the organizer of that meetup and ask about speaking
5. Create the first slide of a talk you want to give
6. Set up a Twitch or YouTube account (just sign up, don’t worry about
anything else for today!)
7. Sign up for a ready-made blog on something like [dev.to](http://dev.to/) or HashNode
8. Install a note-taking app like Evernote or Notion to hold your dev rel
notes
9. Set up ConvertKit or TinyLetter for building an email list
10. Look at one forum post to use in your research
11. Look at one GitHub issue to use in your research
12. Make your first 30 second screencast
13. If you don’t have any equipment for making videos, spend 15 minutes
researching a starter microphone
14. Write down and publish something you’ve learned today, even if it’s
only a few sentences. You can always revise it later!