First year as a Developer Advocate š„
Before doing DevRel for a living, I used to pay the bills by being a data scientist. Today I can say that I successfully switched from being a Data Scientist to be a Developer Advocate for a whole year! š
Me on the first day of work March, 2021
So I thought I share the learnings from this year with you. Also, full disclaimer, this will be a long one, so sit comfortably. š
What I used to do before being hired as Developer Advocate
A little history before we dive into the learnings since you may not know me or what I used to work with.
So a long time ago, I used to work as a data scientist. On the first job I ever had, I actually gave over 13 talks about the open-source civic tech project I was working on at the time called Serenata, including one talk in Taiwan and all of that in just one year. The project relied on us, the devs and data scientists, to spread the word about it so it could thrive.
Me presenting about Rosie, Serenata's AI, on a Meetup back in 2017
Besides talking at a number events and meeting many people, we would also create a lot of technical content to make the project more accessible to those without the technical knowledge to read and understand code. You can check out the page of the project right here.
Around the same time, I even created, with friends, a podcast about data science in Portuguese called Pizza de Dados. Sharing knowledge in various formats became a passion. I love to give talks, do workshops, and just talk to people and help in any way I can.
Turns out that this is a huge part of being a developer advocate. I just didnāt know it at the time. Notice this was around 2017, now it is 2022, and developer relations is still pretty new in Brazil, so imagine how it was back then.
What is Developer Relations or Developer Advocacy?
I think the first question I get asked when I say Iām a developer advocate is ādeveloper what?ā. People usually donāt get it. Developer advocacy is so new here that it doesnāt even have a name for it in Portuguese. So it isnāt surprising when people donāt get what I do by just stating my job title. What also happens is that they feel like they understand what it is once I explain it. Based on my community work some people usually are aware of, I get theĀ āoh yeah, it suits youāĀ comments.
If you also donāt understand what DevRel is, hereās the short description: I make friends with developers to help them understand complex topics and work more efficiently. Now, there are many ways you achieve that, I do it by giving talks, creating blog posts, videos, podcasts, etc.
You may be wondering why I say I make friends though, am I right? Well, thatās because people tend to ask their friends for help, and that is my utmost goal, be someone anyone can reach out to and ask for help, especially when coding is involved.
Talks, written tutorials, workshops, podcasts, videos, and so on are only part of the process of being an advocate. The part people usually see. Thereās also the other part, the part where you have to do reporting on events and initiatives you worked on. You have to test out new features and provide feedback internally. You document processes internally and help structure ways to help the business succeed. And all of that while you spend some or most of your time traveling to reach developers where they are.
Developer relations is a complicated topic if you think about it. You have to have a lot of skills: technical, communication, and interpersonal skills, also business sense, be data-driven while still being an active participant of any tech community and putting people first. This reminds me of this tweet:
Developer advocacy is simple. You just need skills in engineering, marketing, business development, product management, content creation, and be a skilled communicator, both written and verbal. After that, the job really takes care of itself.
— Sean Falconer (@seanfalconer) February 4, 2022
If you are considering what skills to improve to become a DevRel, think of the ones I mention in this post and try to develop them along the way. Turns out that most of these skills can be used no matter what job you have, and if you start working on them earlier, it will make your path to become a DevRel a lot easier. š
And how did I decide DevRel was my thing?
Other than talking at many events and meeting a lot of people while working at Serenata, I would also create a lot of technical content seeking to make the project more accessible to those without the technical knowledge to read and understand code.
After moving on from Serenata, I made sure I was active in the Python community, no matter where I worked. In my spare time, I gave talks whenever possible, maintained my blog, and kept recording episodes for the Pizza de Dados podcast.
Me, Lele Portella and Ceci Vieira on a live stream
Long story short, some day I decided to change my day job to have more knowledge sharing instead of it just being a spare-time effort. Luckily around the same time, Auth0 was hiring a new developer advocate. So, I decided it was time to give it a chance.
Before the hiring process started, I did what I usually do: research. I researched what DevRel was, and guess what? Sam Julien, at the time, head of DevRel at Auth0, had an ebook called āGetting Started in Developer Relationsā, which I read in two days, and thatās when I had that a-ha moment: I did this beforeā¦ and loved it!
How is the day of a Dev Advocate?
Instead of speaking of my day, Iāll talk about my week as it draws a fuller picture of what one might do daily as a DevRel.
| Day of the week | Activities |
|---|---|
| Monday | ā¢ Go through the collaboration requests ā¢ Check in with ambassadors questions ā¢ Practice a talk Iām giving the following day and make sure that no adjustments are required |
| Tuesday | ā¢ Attend the 1:1 meeting with my direct manager ā¢ Attend the 1:1 meeting with a colleague from another team about a new initiative ā¢ Give a talk at an event ā¢ Prepare a draft of a talk for a CFP I need to submit by the end of the week |
| Wednesday | ā¢ Attend the team weekly meeting ā¢ Write documentation for a new process ā¢ Draft video outline for the new video I need to record ā¢ Review the work of a localization specialist |
| Thursday | ā¢ Data analysis on the results for the newsletter that came out last week ā¢Ā Draft blog post that will accompany the video ā¢ Draft the sample code for the video and blog post |
| Friday | ā¢ Attend the company all hands meeting ā¢ Attend the team weekly happy hour ā¢ Review the blog post of a colleague |
You might do all of that in a week and have a very different schedule for next week, especially when traveling to attend in-person events. You might even squeeze in some community work during your week or work on personal projects.
One thing I can guarantee, even if this may seem repetitive ā it is always about sharing knowledge and helping someone out ā thereās never a dull moment.
Where does the DevRel team land in an organization?
From what Iāve seen, there are three main locations in an organization for placing a developer relations team:
- Engineering: as part of the software engineering team
- Marketing: as part of the developer marketing organization
- Product: as part of the product development
Where you find the team usually speaks to how the developer relations team is seen by other peers in the organization: Whether it is a technical role and if it is compensated as such. In Auth0ās case, the DevRel team is under the Developer Marketing umbrella, and it is seen as a technical role.
What I learned as a data scientist and I still use daily?
If anything, data science helped me develop the skills for communicating complex concepts with ease for any audience, something I keep close to my heart at all times. But other than that, I still have some skills I learned as a data scientist that I use daily. Is worth noting that some, if not all, of these skills can be developed in other jobs too. š
šĀ Prioritization
The question my colleagues and I always ask ourselves every planning session is:Ā āWhat will bring the most impact to what we are trying to accomplish?ā. Ā The data scientist in me always says: Well, it depends on what we are trying to optimize for, which always gets me thinking about the area we want to grow. What is the foundation we need to build to collect the fruits from it in the future?
These questions apply to any development role, to be honest. Data science taught me to find the answers based on data and observations from the past. It also taught me to define a healthy path to grow based on such information.
š£Ā Communication skills
Most of what I do is understand pain points and provide guidance for easing or getting rid of them. To do this, you have to know how to communicate and adapt your communication based on the public.
In a year, you may speak at more the 10 events, all of them varying in audience skill level, knowledge, preferred stack, and so on. I may work on a talk content to present at next monthās event while finishing up a workshop for a sponsored hackathon that will be held next week. Both have very different formats of communication.
I have to write reports about the events and initiatives I did or contributed to from time to time. I need to reach out to other teams in the company to provide feedback on projects and features. So communication is at the core of DevRel.
ā±Ā Time-boxing and creating sample apps
This I learned way back in the day when I used to do data science for that open source project, and I still use it daily, especially to know when to ask for help. For example, I had to code a sample app to demonstrate the new feature: Auth0 Actions.
I had a plan.
I wanted to make an app based on one of the tutorials we have on the Auth0 Blog, and I set aside time for it: āI have two full days to get this working, and if it doesnāt work, Iāll get back to the drawing boardā. Two days passed, and I couldnāt get it to work the way I wanted. I realized I was overcomplicating the sample application.
The good thing is, I was not alone in this. I discussed it with a colleague and we figured out a way to do the same thing in a simpler environment. You can check the result here:
Time-boxing is fundamental to make sure that I test things, know when to ask for help, and I have time to go into a different path when needed. It also helps me effectively test new things and create my sample apps in a timely manner.
šĀ Basic data analysis
One constant question in DevRel, no matter what company you work for, isĀ āHow do we measure success?āĀ And that is sometimes hard to answer. So having a basic understanding of data is important.
For example, I lead the Zero Index Developer Newsletter. It comes out once a month, and it contains curated content for developers ā by the way, you can sign up for it here. You could say that one definition of success would be delivering the newsletter to more and more developers, but the way I see it is much more than that.
We want to reach more developers, sure, we also want to provide relevant information. So how would you do that if you donāt understand how to measure it? You probably would partner up with the data people in the company, right?
Still being a data scientist at heart, I decided to flex my data analysis muscles and try to understand how developers interact with the content we share. I did some basic visualizations, a few bar plots here and there, and took a look at the structural changes in the content. All of that put together gave ideas on doing some A/B testing to deliver more quality content to subscribers.
You may leave data science, but data science never leaves you.
So from time to time, I still take a look at data to make sense of the world around me. š
What were the new things I had to learn?
There were a lot of new things, especially in the business of identity, authorization, and authentication, which was brand new to me. But there was also a lot about creating content for a company and not for myself.
Repurposing content
Funny thing, as developers, we learn to apply the DRY (donāt repeat yourself) principle to our code, but when the goal is to share content, we do the opposite. It isĀ goodĀ to repurpose content. A blog post can become a Twitter thread, a talk, a podcast episode, or even a video on YouTube.
You need to scale your content by distributing it on many platforms, mainly because different people learn in different ways. For example, some prefer written content, others prefer video, and so on. To be effective, you will probably do more than one format or partner up with colleagues so that one of them can take care of other formats.
Identity, authorization and authentication
Since I worked on data science most of my life, the challenges of the identity world werenāt something I was in contact with, at least not until I started working at Auth0. Identity is hard. It is complex and has various subtleties that sometimes eludes even seasoned developers.
Letās be honest, because of how hard it is, authentication and authorization are usually an afterthought for most developers. We arenāt used to an identity-first approach ā be aware that this may change in the coming years.
The good thing is that I welcome the challenge of those complex concepts. I like to understand them and break them down into digestible pieces of information. The way I see it, it is the same thing I used to do when I started a new data science job: I would study the data and the business, understand what problems the company was trying to solve, and build from there.
So not only I started doing DevRel, I was also learning new things, new complex things. I find it really fun to understand concepts like MFA and single sign-on now as a developer and not as just a user. Iām still far from being an expert in the field, but Iām enjoying every little bit of the learning journey.
Brush the dust off of the API and WebDev knowledge
Apart from identity, there was one other little thing I needed to remember how to do: APIs and web apps. Other than data science, I spent some time being a web developer, so I did, at some point, understand APIs and knew how to build them.
The truth is that even though the models I used to ship on AWS Sagemaker had endpoints in them, it had been some time since I really used or developed APIs. So I had to remind myself things like RESTful, OpenAPI, and what other HTTP methods there were other than PUT, POST, and GET.
Deliver content and not code
If I had to say, out of my daily responsibilities, only 10% of the time I spend coding. Even though I do still code from time to time ā I even wrote some JS the other day ā it is a lot less than when you have to deliver data analysis notebooks and machine learning models.
Even in my team, this is not the case to all of the dev advocates, some of us code a lot more depending on what initiatives they are involved with, we are still developers, and we maintain sites like jwt.io or webauthn.me, which means some of my colleagues spend more time coding than I do especially to maintain these initiatives.
The thing is, my goal isnātĀ to codeĀ but to teach people how to implement things on their applications. Eventually, I have to code. After all, it is a product for developers that Iām driving adoption, but more than coding, you have to understand how to build an applicationĀ to help othersĀ do so.
Me presenting my first talk ever about Auth0 on 2021's Developer Day, click here for the video
So instead of regularly fixing bug, I might deliver a blog post that teaches developers how to implement login/logout flows in a single page application in Python, for example. This does not prevent me from making contributions to our SDKs, is just that I focus more on other things than just coding.
For Auth0 usage in particular, the coding is mostly done. We have a great library ofĀ code samplesĀ and quick-starts. It is like sitting on the shoulders of giants. I can build on top of what has been created to do new things while focusing on sharing knowledge, and if you can make it fun for the ones learning, you get extra points.
Smaller companies may also have responsibilities related to community tasks like managing forums and comments on social networks, as well as some involvement in developer experience, this is not my case at Auth0, we have different teams for each of these things, but we all work together to help our customers.
Is worth pointing out that Auth0 has a very seasoned approach to DevRel, which may not be the case for younger organizations. In this case, I foresee that all advocates would spend more time coding than I usually do.
The career path
The good thing about doing Developer Relations at a well-established team, among other things, is that it makes your life easier when you think of what you want to do in a growing career.
At Auth0 there is the individual contributor (IC) path that takes you up to the Staff Developer Advocate and Lead Developer Advocate, and thereās also what I like to call the leadership path, where you can follow the manager ladder and can take up to positions such as Director of Developer Relations. Is worth noting that these divisions do not prevent you from becoming a manager or an IC later, is just a guide so you can make sure you are developing yourself.
Other companies may have different career progression in their sights. These positions can be changed or adapted as the team grows. Some day I might be Director of Developer Relations Latin America. Who knows? The possibilities are endless.
Wrapping up
This has been an exciting year. I feel even more creative when I look at the work I do. I see that I can help people. I also love what I do at work. Creating content to help others has been my lifeās mission, and it is awesome to do that for a living.
I canāt wait to see what the future holds.
