How to Become a Developer Advocate

In What is a Developer Advocate?, I laid out the key responsibilities of a developer advocate, which is a person who works in developer relations. I broke this down into speaking and listening:

Speaking: Awareness & Education: Content of all varieties, running or sponsoring events, and all of the marketing required for all of these things.
Listening: Community & Feedback. Talking to event attendees, reading and responding to forum posts, managing the forum, running incentive programs to empower developers in their own careers, working with the SDK team on product feedback, and going through and answering DMs on various platforms like Slack and Discord.

Let's now look more closely at becoming a developer advocate.

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

One of the questions I get asked most frequently at conferences is, “How do I get a job in dev rel?” My first response is usually another question: “How do you know you want a full time job in dev rel?” I don’t ask this to gate keep — I think anyone and everyone should have the opportunity to have whatever job they want — but I think a lot of the time folks think they have to get a full time job in dev rel in order to write, speak, or do community or product advocacy work. They may see dev rel as glamorous compared to what feels like a boring developer job. Let’s talk about this a little more.

The Hidden Treasures of Your Current Job (and the Downsides of Dev Rel)

At my last normal full stack dev job, I started to get a real “grass is greener” mentality after a couple of years. I was tired of working on bugs and features, tired of daily stand-ups, tired of going into an office, and tired of working in a legacy codebase. I wanted to be speaking, teaching, writing, and working on new, shiny tech. I wanted to be remote and autonomous. I eventually got my wish, but there were some hidden upsides to that gig that I wish I had taken the time to appreciate before switching to dev rel.

First, your best learning comes from solving difficult problems and, for most of us, being forced to solve a difficult problem is the only way it gets done. Looking back, my biggest times of growth in my dev job were when I was tasked with something that was either boring or difficult but that I had to finish. I remember once I had to write an encryption plugin for a CMS platform. It sucked. I had to learn how to use this really bizarre C# SDK, I had never done anything with encryption before, and I really didn’t want to do it. Guess what? I didn’t have a choice. The icing on the cake? Just as I finished it, a consultant told us what we were doing was a terrible idea and we scrapped all of the code I wrote. Looking back though, I learned a ton from that project:

I was exposed to a lot of new concepts and patterns I had never seen before.
I had to solve a difficult problem in less than ideal constraints (no shiny tech here folks).
I had to grapple with the fact that all of my code was obliterated, something all software developers need to learn one day.

In dev rel, most of the time you don’t have this same level of forced problem solving. Much of the job involves building simple demos in new technology, so keeping your skills sharp through real world problem solving requires effort in dev rel. I couldn’t see that at the time.

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. This is sort of what I did, although at the time I didn’t realize I was doing it. I talked to my boss about wanting to get started with speaking and teaching. He suggested I first lead some presentations for coworkers on topics relevant to what we were doing. I led a few sessions on Angular, authentication, and RxJS. After I had gotten comfortable with building some basic presentations, I sought out local meetups to start giving talks. You can dip your toe into the dev rel waters without jumping straight into a full time commitment. I lay out a step-by-step process for building a personal dev rel strategy in my book Getting Started in Developer Relations.

What Employers Look for in a Developer Advocate

Let’s say for now that, after you read these articles and my book, you’ve decided you want to look for a developer advocate job. Is there anything you can do to prepare yourself?

Well, if you’re at all overwhelmed yet by the seemingly endless array of tasks in a developer advocacy job, don’t worry. That’s normal. Here’s a secret: developer relations is a set of skills you can learn. When you first transition to dev rel, it can be incredibly overwhelming. Often, the reason people move into dev rel is because they were reasonably good at their engineering job but wanted to do more teaching and community-building. Suddenly, they’ve gone from "competent engineer" to "brand new developer advocate" and that sucks. Remember: dev rel is a new set of skills you can learn.

When you start a job in developer relations, you are once again a beginner! You're back at square one (or square zero since we're all devs here). 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! Once I realized that, I felt so much better. So, first and foremost, cut yourself some slack (not Slack)!

The real magic comes when you not only accept that reality, but learn to embrace it. It's not that often in life that we get to learn new skills (though as developers we are incredibly lucky in that way). New skills mean new opportunities for creativity, new ways of looking at things, and new relationships. And that feeling of discomfort and discontent? That's growth as a human! Growth is good!

So then, what are the core character traits that you really need going into this? What makes a good developer advocate, anyway?

First and foremost: empathy. It might be counter-intuitive to list a non-technical skill first for this, but it’s the truth. Technical skill can be learned quickly on the job, but empathy has got to be there from day one. You have to truly care about your community, your users, and your customers. You’ve been there before: you’ve nearly thrown your laptop across the room because you’ve just wasted six hours on something that turned out to be a single missing line from the documentation. That sucks. We want “That sucks!” to be our first response, not wondering what they did wrong or trivializing it because of how simple the solution turned out to be. If you try to just get into dev rel for fame or glory, you’re going to burn out quick (or maybe get fired eventually).
Second, a love of learning. I think most developers love to learn on some level already. It’s definitely one of the most amazing parts of coding, that constant curiosity and exploration. In dev rel, you’ve got to learn a lot. Like, all the time. There’s not a lot of comfortable bug fixing or familiar codebases lying around here. Most of the job is playing with new shiny tech and then trying to retrofit that into complicated, real-world scenarios. If that sounds awesome, great!
Third, you’re able to manage several projects at once, sometimes in vastly different skill domains. At any given time, I’ve got something like 5-10 different work projects in the air. I may be adding a new feature to an internal tool, writing and creating a new slide deck for one conference, recording a new tutorial video, and creating a quarterly report on program metrics. I have to context switch rapidly and be able to keep track of a lot of different things at once that often use totally different skillsets. This is super different than my job as a full stack developer adding features and closing tickets! This isn’t to say one is better than the other, just that the day to day is really different.
Fourth, you’re a good communicator. Are you reasonably good at conveying information to others? Are you good at (or interested in improving in) teaching? Your preferred medium of communication is totally up to you. Not everyone has to be an awesome writer or a killer speaker, especially starting out. But do you listen to people, make them feel heard, and then convey your ideas in a way that’s easy to follow?

These are the core characteristics of a good developer advocate in my opinion. I think if you’ve got the heart for it and are interested in it, you ought to be able to take a crack at it regardless of experience level or who you are or what you look like. That said, some jobs may also be looking for certain levels of experience with types of content creation or community engagement in addition to technical skill (which is usually at least a couple of years of full time dev experience depending on the job). That’s what the second half of this book is all about helping you build, in addition to getting some practice in those qualities we just looked at.

The Dev Rel Career Ladder

One of the issues still being worked out right now in developer relations is the career ladder. A career ladder is your path forward in a job. Where will you be in 1 year, 3 years, 5 years? How can you progress in your career so you’re not just treading water?

In engineering, a career ladder might look like this:

Levels 1-6
Level 7: Staff Engineer
Level 8: Principal Engineer

These levels are based on things like technical expertise (usually measured in several ways), collaboration, leadership, mentorship, and impact to the company. As you progress through annual performance reviews, you should become more proficient not just as a developer, but as a leader who takes ownership and mentors others.

Dev rel career ladders are harder to come by, but they are starting to gain traction as advocates stay in their jobs longer. One of the best examples of a dev rel ladder was created by Mary Thengvall for Camunda. She lays out four stages of a career path, each measured in four key areas:

Functional Skills
Delivery
Teamwork
Leadership

Each of those areas contains several specific attributes and values. In short, Mary describes these four stages like this:

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.

Many companies haven’t yet formalized a true career ladder for dev rel, but if you find yourself in an interview, be sure to ask questions like:

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

The answers to these questions will definitely give you a good feel for whether the company knows how to support the career development of their developer advocates.

Red Flags in an Interview: When to Walk Away

Alright, let’s talk about something a little less fun, but really necessary. Here’s the thing about these dev rel jobs: it’s really, really easy for companies to take advantage of you or be super toxic.

Dev rel jobs are basically all about traveling, making content, and improving a product. They are almost entirely remote jobs with a high degree of autonomy, so they are also in pretty high demand. The company knows this. This means that it can be really easy for companies to suck the life out of you and give you zero work life balance.

Here’s the secret: don’t forget that in dev rel (as in most things in life), you are the prize. You are the asset. No company owns you or your reputation.

Here are some things that are not healthy in a dev rel job:

Requiring you to make meetings in the middle of the night on a regular basis (unless you dig that or agreed to it) because you’re in a different time zone
A manager putting you down for needing a day off after a long trip to recharge or connect with your family
Pushing you to work more than your legally required or agreed upon hours on a regular basis (in America, that’s 40 hours a week)
Basically, in any way making punishing you or making you feel guilty about your very human need for downtime and family time

Of course, there are many other signs of a toxic work environment and many terrible things that can happen there, but I just want to focus here on the remote dev rel side of things. You are not just a content producing machine or a corporate automaton! You are interested in dev rel because you care about people and solving their problems. That’s a good thing! Sometimes you have to come through for your team in a big launch or occasionally take a meeting in an inconvenient time zone, but the pattern and the expectations should be mutually agreed upon and let you have a healthy work-life balance. I’m just here to tell you that it is indeed possible and to accept nothing less!

Here are some interview questions you can ask to feel this out:

How much vacation does the average employee take?
Do you enforce a minimum number of days of taken vacation per year? (Secret: a lot of “unlimited vacation day” policies actually lead to employees taking less time off because they feel guilty.)
How often do members of this team work more than the expected number of hours?
What’s the expectation for asynchronous communication? Do you expect me to respond immediately to Slack messages from coworkers? Am I expected to be available 24/7? (Spoilers: that should be no!)
If I’m traveling for 72 hours, is that all considered work? If I take a day off to recharge since I technically worked through the weekend, would that be a problem? (Not saying you need this every time, but it’s a good conversation starter.)

No matter how badly you want a job, if you get a bad feeling about any of this, swipe left and move along. Find a job at a company that values you!

I mentioned at the beginning of this chapter that, as companies get bigger, the different roles in dev rel can split out into individual, specialized jobs. For example, you might see positions that are solely in Community, which might be part of a support department or the marketing department. These jobs may be related to running building and running forums, for example.

You may also see Content or Product Education jobs. These are jobs where you solely write or produce educational content (video tutorials, for example) on the product. These jobs may be on documentation, marketing, or dev rel teams. Technical writing and product education can be entire careers in their own right, so I won’t go too deep here, but keep an eye out for those jobs as a good way to either specialize or get your foot in the door of dev rel.

If you think you might prefer writing or doing community support 100% of the time, you might check out some bigger companies that have specialized roles like that. Likewise, some companies consider “developer evangelists” solely speaking jobs, or maybe mostly speaking with some writing thrown in. Think of “developer advocates” as generalists who are the hub of the wheel, with all of those other positions being more specialized spokes.

Where to Go from Here

In this series, we've covered the definition of developer relations, the responsibilities of the developer advocate, and how the dev advocate career path. If you're interested to learn more, pick up a copy of my book Getting Started in Developer Relations. In the book, I dive deeper into:

Measuring the impact of developer relations
How to build a step-by-step personal dev rel strategy
Quick wins to get started in dev rel right now
And much more.

You can also hop on the Developer Microskills newsletter . Each week, I send out a practical, actionable way to improve as a developer and developer advocate.

Thanks for reading and see you soon!