I get a lot of questions about what it's like to be a Developer Advocate (DA). I love these questions because each one is an opportunity to advocate for developer advocacy itself!
Recently a colleague who's considering some DA positions reached out to me for advice, and their questions so nicely summed up every question I've ever been asked about my job that I figured I'd answer them here.
(Also, it ended up being way too long for an email).
A bit about me: I'm a Developer Advocate at Google, where I focus on advocacy for the Python community. I have a BS/MS in Computer Science, and spent many years working in university/government research labs until I decided to take a break from academia. After doing a number of non-software things, I joined a software consultancy where I spent a fair amount of time building custom software, before eventually joining Google.
Also, a disclaimer: I've only been a DA at Google. While I'm aware of differences between what this role means at other organizations, I really can only speak for what it means at my organization. I've also only ever been myself, so I also can't speak for all DAs at Google, either, but I don't think my experience is totally unique amongst us.
So, first, I'll answer a question which wasn't on the original list, but is one that I get asked the most:
What is a Developer Advocate?
The way I like to describe this is: I help represent the Python community at Google. When we build products that people in the Python community will use, I help make sure those products are right for those users.
This means that part of my job is to be deeply involved in the Python community. The way I do this is basically entirely up to me, so this usually manifests itself as the things I like doing in the Python community, like working on the Python Package Index (PyPI) or other packaging tools, organizing PyTexas, and attending and giving talks at Python conferences.
Being an advocate also means I don't want to "sell" you a product, but I do want you to know that it exists, but only if I think it might help you. I really don't want to show you tools you don't actually need, and I'm far more likely to tell you to use a simpler or cheaper tool if I think it's a better fit, even if it's not one of our products!
More importantly, if you are using the products I work with, I care a lot: I want to know what you think about them, if you've tried them, what your first impressions are, what your challenges have been, etc. And, I want to be a resource for you in the future.
How did you feel about leaving a traditional engineering role?
I get this question a lot; in fact, one of the first things a friend said to me after I told them I was going to be working in developer relations was: "So does that mean you aren't allowed to code anymore?"
I actually consider developer/user advocacy a part of a traditional engineering role, just one that is often neglected by traditional engineering organizations. So, while this usually means "how do you feel about not coding all the time", in fact it's entirely up to me: if I wanted to, I could be coding as much as someone in a "traditional engineering" role.
At Google, we currently have two titles: "Developer Advocate" (DA), and "Developer Programs Engineer" (DPE). The stereotype for a DA would be that they spend their time working with content, talking to customers, and giving talks. Similarly, the stereotype for a DPE would be that they build and maintain our client libraries, write code samples, and work on our open source projects.
But the truth is that these two titles just represent the extremes of a gradient of a single role, "Developer Programs Engineer". This means that some folks who are DAs still write code, and some folks who are DPEs give talks at conferences.
And while each individual does have a given set of responsibilities, the "slider" between these two extremes is more or less up to us. If I wanted to do more engineering than I currently do, there are plenty of opportunities for me to do so, and finding that balance is more or less up to me.
Do you feel that if you chose to go back to 'traditional engineering' that it would be possible?
Given all the above, I'd say yes, not only do I feel like I could go back to a "traditional" engineering role, but I probably have an even better perspective now and would be an even better engineer than before.
Being a DA has given me the ability to connect with such a wide and diverse group of users, and it constantly makes me reëvaluate whether a 'good idea' is what I, the engineer want, or what the user actually wants.
Are you finding a good work/life balance? I know DAs tend to travel quite a bit.
Absolutely, but this is heavily influenced by the culture at Google. The nice part about my job is that, contrary to popular belief, travel is not actually a requirement to be a DA at Google. There are DAs that are constantly traveling, and there are DAs that only travel once or twice a year, and both are totally fine and will be successful in their careers.
This means that I travel exactly as much as I want to, and at any time I have the ability to adjust how much I'm traveling to suit my work/life balance.
What do you find to be the biggest challenges with a role such as this?
The biggest challenge: measuring your impact.
Measuring impact is challenging because it's hard to connect the outcomes we want to achieve with the things we do. Things like "developers have more confidence in our products than a year ago" is not only a hard metric to measure, but also hard to find the source of the shift even if we could measure it. Was it all the talks we gave? The YouTube content? The Guinness World Record?
This makes it hard to know what's worth working on, and also makes it hard to prove that you're doing a good job. View counts on blog posts are a decent proxy for popularity, but since "having a popular blog" isn't our goal, beyond that it's hard to quantify.
What does the day of a DA look like at Google? What do you spend your time doing?
The impression is that a DA spends all their time writing talks, traveling to conferences, and speaking. This makes sense, because the DAs you probably see the most are the ones that are doing these things, and you don't see them doing anything else.
A lot of people are surprised to discover that traveling and speaking is actually a very small part of my job, given the number of talks I give, and how often they see me at events. And, like I mentioned before, the main reason I do it is because it's one of my ways to be part of the community, and something I enjoy.
I think part of this perception comes from the conflation between an advocate and an evangelist. There is endless debate about what these terms mean in the context of developer relations, but at least in the context of Google, the difference is this: an evangelist wants users to know that a product exists; advocates want products to know that their users exist.
(In my opinion, good way to tell if you're looking at an evangelist position or an advocacy position: who would you report to? Is it an engineering director? Or marketing?)
For example, you might notice very few of my general conference talks are actually about our products. This is because my talks are simply a means for interacting with my community, not a venue to inform you about our products.
So, if speaking is actually optional for being a DA, and I do it optionally, but takes up a small amount of my time, what the heck am I doing? Well, a lot:
Talking to customers: When I travel to events, I usually try to set up some meetings with local developers that use Google Cloud, or try to meet some while I'm there. I also occasionally sit in on calls with customers, either to check in on how their experience is going, talk about a specific issue, or help them determine how best to use our products.
Talking to non-customers: I'm generally and genuinely curious what everyone's working on, and the tools they're using, and whether these tools are effective or not. This helps me build a general sense of what people expect to be able to do with our products, strengths and weaknesses in other products, and new trends in the industry.
Talking to our product teams: Usually this is around a launch of a new product or feature, but sometimes is to set general strategy for the Python community.
Being "user zero" for new products or features: This means playing with new things and seeing how intuitive they are, and whether there are any edge cases we haven't considered, but might be valid use cases for our users, and filing bug reports as necessary.
Keeping an eye on places where users might raise issues: I am constantly trolling StackOverflow, and have various ways to keep an eye on mediums like DEV, Twitter, Hacker News, etc. for people talking about their experience with Google Cloud, and then taking that feedback and turning it into actionable issues for our engineering teams.
Working in open source: This generally satisfies my desire to write code, and has the added benefit of keeping me involved in the community, and also giving back to it.
Creating content for Python developers: This may be anything from blog posts, to launch announcements, to YouTube videos, to podcasts, to documentation, to workshops/tutorials/codelabs, to stunts like this.
Setting strategy for the Python community: I help determine our presence and sponsorships at events, but also contribute to wider plans for the future of our products.
Serving as a general source of expertise at Google about Python and the it's community: One of the most fun parts of my job is that I get pulled into discussions with teams all across Google who want input about how to work with the Python ecosystem, target Python users, and make things work in a way that they would expect and appreciate.
Leading a team of people who work on Python advocacy: I'm not the only person at Google who cares about Python! In order to coordinate our efforts, I lead a team of people who do all the same things I do (and often, much more).
Do you have any tips or advice for someone considering this role?
1) Work on your empathy.
At the very least, start doing more advocacy at your current organization. Attend or observe some user experience studies of your product, or just sit down with a friend who's never used it and see if they can make it through your quickstart. I promise, it will be eye-opening.
2) Pick your community, and deeply understand it.
Maybe you've already done the first half, but have you done the second? You need to be the voice at your organization for a huge group of people, and you need to be able to accurately represent what they want.
Keep in mind that the class of people who make up your community are not "everyone who uses our product" or "everyone who uses our competitors product". That's not a community, it's a market segment.
3) Consider joining a software consultancy first.
To quote the person who's taught me a lot about doing developer relations in the last year:
Obviously I'm biased too, because this was my route to my current role, but I totally agree.
As a consultant, if you're not doing "client advocacy" with your team, you're gonna build something the client doesn't want. And if you can't educate the client, they're not going to know how to use what you built. Either way: you're not gonna have that client very long.
Finally, another question not on the original list, but one I get asked a lot:
Are you hiring?
There are developer relations teams across just about every product area at Google, and we're always looking for new colleagues. Take a look at this job search query to find a role that might suit you, and feel free to reach out to me on Twitter (@di_codes) or in the comments if you have any questions that aren't answered here!
Top comments (0)