This January 2021 marks 3 years for me being a Developer Advocate. During this time I've been very busy. Being in DevRel is a lot of fun, & of course it's also a lot of work. For me it's been the most fulfilling job I've ever had & I look forward to being in this space for the foreseeable future.
As I write this post (March, 2019) I'm sitting in a coffee shop in Barcelona preparing for a workshop. I'll then head to Finland to wrap up a total of 9 days on the road that included 5 events (conferences, meetups & workshops). During this time away I've spent time in Berlin, Geneva, Barcelona, Cluj & Helsinki.
During this trip, and over the past year, people ask me how they can also get into DevRel in some capacity (also I get a ton of DMs asking this question). I don't blame them, it's an awesome role for those interested in what it entails.
In this post, I'll list the things that I believe will help you land a position in this space.
The conclusions drawn in this post are comprehensive of what I've seen from other successful people doing what I do as well as what I did in my roles prior to becoming a Developer Advocate & are not necessarily the only way to get into this space!
1. Learn how to write
When I say learn how to write, I am not saying you need to be sophisticated perfectionist that never makes a mistake spelling or in your grammar.
What I do mean is that you should learn to feel very comfortable spilling your thoughts onto a page. For me, this came with a lot of practice. I made a habit of documenting things that I learned, both in the form of blogs but also in the form of READMEs in GitHub.
The more that we write, the more comfortable it becomes. You will learn to be less of a perfectionist & your writing style will organically materialize.
Writing also makes you understand ideas on a deeper level. It is one thing to be able to do or understand something yourself, but it is another thing to actually teach & explain that thing to someone else.
Writing or teaching something makes you address the questions you don't yet know the answer to. It forces you to deep dive on topics & gain the knowledge you probably wouldn't have otherwise.
The more you write & publish to the world, the more that you also will be creating an online presence.
Communication
One of the most important things about being in DevRel is communication. You will be communicating with your team, other developers, community leaders, conference organizers & countless others.
More than likely this communication will come in the form of tweets, emails, direct messages, or some form of written communication.
Being comfortable writing will extend & improve your ability to communicate, in turn making you better suited for the role.
2. Build Bridges
One of the most influential talks that I've ever seen was from Aaron Frost at NG Vegas in 2015 (yes, I used to be an Angular developer).
The talk was called Building Bridges. In it, he laid out the fact that other people had paved the way to his success, & now that he has the opportunity to pay it forward he is doing just that.
The only reason many of us are where we are today is because of the work other people have done, the tutorials they have made, the open source projects they have created and tirelessly contributed to. The idea is to also build bridges & pay it forward once we are in the position to do so.
Depending on your confidence and level of expertise, building bridges could look like many things. For me this has been free one on one mentorship, writing blog posts on things that I’ve learned, hosting and paying for a local meetup for over 3 years, & answering questions on Stack Overflow among other things.
This philosophy in action is what developer relations is all about.
3. Don't be married to a specific technology
Many people that get into DevRel because they are specialists. For me, I was a React Native specialist & still am active in the React Native community. But this is something you need to keep in check.
When you get into DevRel one of the most important aspects is building trust. There is no way to fake this authenticity.
Being too loyal to a specific technology or a set way of doing things will make you lose perspective of the objective of the technology in general. Our objective is not to show our undying love for our framework or language of choice.
Learn to be curious about competing technologies than the one you are most comfortable with. Many times you'll find that you either can learn a lot from their way of doing things or that you like their way of doing things so much better that you change your specialty.
One of the things I take the most pride in is the React Native Radio podcast that I have been running for over 3 years. I've gone out of my way to showcase competing technologies like Ionic, Xamarin, Flutter & NativeScript. I also helped launch the OpenGraphQL publication in order to open the GraphQL community to ideas other than what were being promoted by people pushing mainly their own agenda in other properties.
When you run something like a podcast, newsletter, or community property you are asking people to give them their trust. When you show bias in your opinion or prevent others opinions & ideas from being heard you are doing your community a disservice.
Again, the objective is not promoting things you like, it's about enabling people to build things & advance themselves. Do this by being open minded about & learning from other tech than what you specialize in & be ready to switch at any given moment.
Having a track record of being community focused & trusted will go a long way.
4. Speak
This one seems like a no brainer right, but how can we get started?
I got started speaking at a local meetup in Mississippi. These are perfect places to start because the crowds are usually small & supportive. They've usually not invested a lot of money to attend so will be less judgemental if you have a hiccup.
There are also local (albeit nerdy & awesome 🤩) Toastmaster groups that are all about helping people practice public speaking & improve communication skills. These are a great place to get started & test the waters.
Lightning talks are great places to start as well because it's much easer & less stressful to put together 5 minutes vs 50 minutes of material & practice. You'll also gain experience speaking at a "real" event & can use that talk reference to get into larger events if you so choose to.
To get into your first big event I would recommend putting together what I would call a "Production-ready" talk. Something that you practice & have down like the back of your hand, one that you've spent a lot of time on polishing the title & description. You can use this talk to apply to dozens / hundreds of events, & if you get accepted to more than one you will not have so much stress delivering the same talk over & over but you will gain the experience from it.
Nerves
Here's a secret about public speaking: It never becomes easy. It does become easier, but you'll probably never walk in front of a crowd to talk about the thing you're really excited about without having at least some anxiety.
I know this because I've talked to many other people who feel the same way. Sure, there are probably outliers to this but this is the rule. You need to, like Nike says, Just Do It. Once you open your mouth & start talking, the anxiety starts to go away anyway.
Here are a couple of tips for when you get started speaking:
- Prepare & practice (a lot)
- Talk about something you're truly interested in
- Start small
When interviewing for this role, you'll usually be expected to have at least some experience. Even having some light experience at meetups / small events may be enough.
5. Teach as You Learn
I vividly remember writing my first "real" blog post on Medium. It was Beginner’s guide to Webpack. I was in the process of creating new React prototype for my company (this was before create-react-app was out) & I was struggling with learning webpack.
As I learned & went through the documentation, & started writing what I knew down in this blog post & before I knew it I felt like I had something worthy of sharing. Remember, when I wrote this I was by no means an expert! At the time, I had dozens of people reach out to me telling me how much they learned from it. That post, my first post, has now been read by over 485,000 people around the world!
This kind of goes back to number 1, teaching or writing about something forces you to understand it at a sometimes uncomfortable level, which at the end of the day is good if your objective is helping others understand it as well.
Learn in public
This comes from Sean Swyx Wang, a Developer Advocate on my team at AWS Amplify. I really like this approach & think it is an idea you should consider adopting as well because it fits right in with helping other developers.
6. Encourage people
One of the easiest things that we can do, especially with the sheer amount of negativity out there in the world today, is lift people up & encourage them. This becomes especially important as you grow your network & have the opportunity to help those with less of a voice or those with less privilege.
Being one of those people that is relentlessly helpful & encouraging will not only benefit you as a community member, but you are genuinely helping people get over mental hurdles, land jobs, land freelancing contracts – even helping them to ultimately share their knowledge & ideas as well.
One of the most important things to remember as someone involved with DevRel is that your main job is to enable & advocate on behalf of other developers and community members, not the company that inevitably hires you.
7. Act like one
I would say the most important point of all of these is to just start being one, regardless of your current role. Follow other people doing what you'd like to be doing, learn from them, & start doing what they are doing.
If you do so you are already on your way to landing the role. When you apply or interview, it will be a no brainer if you already have some sort of track record.
Who are some people in DevRel that you should follow?
There are too many literally fantastic people to name, but here are a few that I would recommend following & learning from:
Wrapping up
Most people think that DevRel means your title is either Developer Advocate or Developer Evangelist. This is not the case. There are more & more people in traditionally engineering roles that also take on the role of an advocate. Many times these people are using their talent & position in community as an opportunity to help others.
Helping & empowering people is what this role is all about.
Top comments (22)
It turns out I have been working towards a DevRel career and didn't even know it!
Thank you for writing this post!
Same here.
I just started doing things I liked and some day I got a mail asking if I wanted to do it for a living.
Was it like getting an owl with your letter to Hogwart's? :D
It's so interesting to hear about this branch of development I hadn't even realized existed!
Pretty much.
I wrote blog articles almost every week for two years before someone hired me to do it for money.
I find it interesting too, it's a mix of many things I like.
Same here!
I'm so gonna read this!
I got job for writing tech articles for a startup so I guess I got the first step right :D
This is one of the best blog posts I've read in such a long, long time. I've been wanting to get into DevRel & it seems like I'm headed that direction if I just keep going. This was a really great post
Awesome to hear, I'm glad you enjoyed it! Best of luck in your journey! :)
I still haven't figured out what devrel is. People have been talking about it for years, and I'm still mystified.
Depending on who you work with it could mean a lot of things. Typically it means helping developers be successful using a service or some type of technology.
Part of that is education & another part of that is giving feedback to the engineering team & project managers about what people like, dislike, & want.
We also help developers / teams in general make decisions & sometimes even prototype solutions for them.
That's called consulting no?
A lot of things in technology outside of actual development seem to overlap, so I guess this could fall into that category if you were billing for this sort of help.
Great post.
Number 3 is very iffy to me because no one can be knowledgeable about everything so you do have to pick your battles. Sticking to just one piece of tech is definitely going to hurt rather than help though.
/#7 is very true! Most of the people I know in Dev Rel had incorporated a lot of what goes into a job in that field either into their day job, their work with the community, or both. I know this was the case for me.
Great stuff. I totally agree that one doesn't have to have the title of Developer Advocate. Many people speak publicly and teach others while working a traditional engineering role. If one wants to do these things they shouldn't wait for someone to give them the permission to do it. They should just start doing the things they think will help others.
Yep, this is so true. It seems as though many roles seem to be converging, sharing responsibility, or less defined when looking at this space.
What do you actually do, though? It seems like people in devrel talk about devrel in broad terms, but after a couple of years of it being a buzzword I still have no clue what it is. The closest I think I've come is "sometimes say nice things about other developers".
Other than that it's all a bit like the rules of Fight Club.
It depends, but for me I create a lot of example projects & reference architectures & open source them, create videos, write blogs, speak at conferences & have meetings with developers using the services & tools that my team builds.
To do what, though? I mean, I have meetings with developers all the time. We create example projects as part of development work all the time. I don't write blogs, but I know other developers who do. Same with conferences. I'm missing something here!
Wow, an awesome post I didn't know that I'm working towards it as well. It's really interesting to know that there's a job that allows you to move towards a career like DevRel.
Thank you for the post! I have finally managed to understand the aspect of a DevRel and unknowingly I have been walking down the similar path.