Hi, my name is Alex, and I'm an... Advocate. A Developer Advocate. With Developer Advocates being one of the most sought out commodities on the market this year, I thought I'd write up the answer to one of the questions that I answer frequently in my DMs - mostly because I read this thing from @swyx.
How did you break into Developer Relations?
If I knew what I did exactly to end up here, it would probably be an easy answer. But it isn't because I didn't wake up one day and decided this was what I wanted to be when I grew up. My idols and role models were Developer Advocates, and I didn't think I was good enough to be the same. On top of that, I was a Senior Developer with quite a few years of experience under my belt. I didn't feel like giving that up to be a "Junior" anything again.
If you ask other people in the industry - and I asked quite a few of them in a survey - everybody has a different story. Because Developer Relations is such a new industry. Even defining it is tricky because it depends on which side of the aisle you're asking. Phil tried to define Developer Relations a while back, and when you look at it, it's got so many roles that overlap. Evangelism versus Advocacy, Marketing versus Community, Technical Writing versus Developer Experience. And they're all a part of DevRel, but the skills required for the role depend from company to company, not necessarily from role to role.
Josh said that not all journeys are the same, and I tended to agree with him. But then I got the chance to meet and interview many other Developer Advocates, Community Managers and Technical Writers, and some patterns emerged. Turns out, while not all journeys were the same, all roads lead to Rome.
I've spent some time identifying a set of skills each of us in DevRel had before joining the industry. Here's a list that also tells you how you can acquire them now, outside of DevRel. Because it turns out you don't have to give up your career progression and start all over, you can break in. Not a single one of us had all the skills we use today.
We've all started out with only one or two of the required skills and learned the rest on the job. So don't worry, you can make do with picking up only a few of these skills!
There are open-source programs explicitly designed for building community. I'll share a list of my favourites, but I'm pretty sure most open-source projects won't say no if you start helping out. It doesn't have to be something as minor as code. It can be something truly helpful, like commenting on old issues to see if people still care about them. Or getting together with some people to test a project. For example, the Reps program even sponsored pizza or coffee for people to get together and help out around the Mozilla mission. Fedora does the same for its Ambassadors. I'm pretty sure I missed a few, so let me know on Twitter, and I'll add more.
With a pandemic, travel bans, and no in-person events, public speaking is a different beast than when I started. There are different challenges involved in speaking in front of a live audience as opposed to a camera. Most learning communities there haven't yet adapted to online speaking, so if you find yourself stuck while picking this one up, please reach out. I'm more than happy to have learning sessions. We've been training people online to speak in public for a few years with Mozilla Tech Speakers, happy to pick it up again.
I must admit, writing, in general, was something I struggled with. But new resources and communities for technical writing keep popping up. It's getting easier to get started. What helped me was transforming the writing bit from a skill into a habit. I've struggled with writing consistently for 3 years, tried various things, but I think I've finally figured it out. For the past 189 days, I've challenged myself to write at least 100 words every day. And you (and me both) would think that's not a lot. It seemed like a manageable quantity when I started. Turns out those 100 words add up when you do it every day. So far, it's been 42,687 words and 19 articles published in those 189 days. I've Tweeted about it https://twitter.com/lakatos88/status/1321423080095469568, but there are other communities to help you be accountable while you learn or to help improve your writing style.
If helping out a group isn't your thing, you can always put on a show of your own. In the age of online events, you don't need a space or a sponsor. You can do it with a Zoom call, a speaker, and an audience. If you're looking for groups or a place to find your audience, here's a list.
I'm afraid I don't have a lot of options here. The only thing I can tell you is to build things. What things? It doesn't really matter. The goal is to pick up something new, experiment with it for a few days, and then tell other people what you did. It doesn't have to be a next career move, it doesn't have to be useful to anyone but yourself, and it doesn't have to be maintained for years to come. Build things, and that's it. If you've stumbled upon my GitHub profile, you'll see I'm part of a dozen organizations, most of them abandoned, and that's OK. I've also got almost 100 repositories that are just there, with only a handful actively maintained. Some of them are so cringe-worthy, with hacked-together code, that I still haven't made public. And that's ok.
All this experimentation got me a valuable skill: I can build something with a clearly defined scope and throw it away as soon as it served its purpose. I don't get overly attached to a piece of code or a project just because. And it doesn't have to be perfect.
Yes, definitely, of course!
I know this might sound controversial. A lot of the Developer Advocates out there will tell you to be a Solution Architect before thinking about being a Developer Advocate. I'd like to formally and unequivocally call "BullShit!" here. Just because it took some people forever to get here (me included), it doesn't mean it was right or that you should suffer. No! There are Junior Developer Advocates, Junior Community Managers. I'm not sure about Junior Technical Writers, but surely there are some, so let me know in the comments section below!
The quality that makes a successful devrella is being able to understand developers pain points. Sure, some slower people like me need to suffer first before we can understand the problems, so we can fix them. Some smarter people, like Mary, could figure out this one without going through the grind. That means anyone can get there, so Junior Developer Advocates are a thing! Next time you see an opening, don't let the fact that you haven't suffered in the industry for the past ten years discourage you from applying. This field needs a fresh perspective a lot more than it needs dinosaurs like me.
As Shawn put it, "DevRel is a not generalizable skill, or rather, there's such a thing as devrel-company fit". You might have noticed this blog post was technology agnostic. And that's because it requires a great deal of passion and empathy. Those skills are not as easy to acquire as functional skills. Try to find a product or community you're passionate about or something you've used or been part of before. It's easier to get your first job in Developer Relations for a company when you've already got some domain knowledge. There's also some degree of credibility involved. I couldn't get a job advocating for an iOS company, for example. You should try to get some experience in your space, really understand the domain you're trying to break in as a devrella.
I also co-curate, alongside Julia, a weekly email roundup of Developer Avocados 🥑 Call-For-Papers, resources and articles. If you want to learn more about DevRel, you should definitely subscribe to Developer Avocados 🥑 Weekly!
If you've read this far, or you're considering getting into Developer Relations, reach out on Twitter! I'm always happy to answer your questions or help you land your first role in DevRel.
Previously published at https://alexlakatos.com/avocados/2021/05/04/breaking-into-devrel/
Create your free account to unlock your custom reading experience.