A little while ago, I passed my first year mark of working for Google. This also marked the first anniversary of me moving from a (long?) career as a software engineer, into a full time position in Developer Relations, and more specifically Developer Advocacy.
I wanted to write a post about this, as when I often talk to my fellow tech-community members, I discuss the transition from a software engineer, into that of a Developer Advocate, I normally get a response along the lines of:
“Oh, I don’t think I could stop being an engineer”
“How is it going not writing code anymore?”
And various things along those lines. Usually at that point, we go into a more detailed and nuanced conversation about what it means to be a Developer Advocate, at least from my, somewhat limited perspective, and those sort of comments tend to fade into the background.
So, in lieu of having this conversation with everyone over and over again, I thought I’d write down some of my thoughts and feeling about what I feel it is to be a Developer Advocate, the transition from being a full time software engineer, and some of what I’ve been up to for the past year, since joining Google, and more specifically Google Cloud Platform – hopefully you will find it interesting.
Before I get started, I’ll throw out a big disclaimer – the whole developer relations space, and the various roles that are found in it, seems to vary quite greatly as you move from company to company, team to team, and even within individuals within teams – please take this as my own personal opinion, and feel free to take it with a large handful of salt (I’ve only been professionally at this for a year!!!). What I call “Developer Advocacy”, other people may call other things, and may blend into other jobs in other places.
So what does it mean to me to be a Developer Advocate? I feel that at its most core level, it means that my job is to advocate for external developers of a given product. Which is about as literal a meaning as you can get.
This means that I want to communicate to external developers, and tell them about the product that I represent (in this case Google Cloud Platform), both to get them excited about our product, but also to give them enough information about it, so they can know whether it fits their needs. To belabour this point a little deeper – I advocate for developers – so if there is a better product for your needs, I feel my job as a Developer Advocate is to point you in that direction. My job is not sales (which is a totally different, yet just as important role), I don’t have quota, so if you are happy using the tools and services you use, then that is fantastic, if I can just give you some more information that may be of service down the line, then great, if it’s not, that’s totally fine as well.
Advocating for developers also means internally as well. This is the part that many people don’t see, and often the perception can be that as a job, we are entirely outward facing. I want to be able to hand a developer the best version of a product that I can, because I am on your side, so that means providing feedback as well internally – to Product Managers, documentation, engineering, and anywhere else I can see where there is a place to make an improvement.
I’ve found this role has suited me quite well. Even when I was a full time software engineer, I always had a strong interest in how to build community, how to effectively engage with people and the whole world of social interaction. In many ways, the open source projects I started, and subsequent communities I helped build up around those projects was a natural extension of that interest I held. In that open source arena, I quickly learned that the greatest project in the world wouldn’t have any users if all you did was whisper its praise into a well. Getting the message out into the world, in an interesting and engaging way was the only way to (a) get people interested in the product and (b) get people to be invested enough to contribute back to the project, via feedback, pull requests or otherwise, and thereby improve the project overall.
On top of that, I invested heavily into the communities I was involved with. I was an Adobe Community Professional for many years, I presented at a variety of conferences, including Adobe MAX, I ran a conference in Melbourne for a number of years, as well as quite a few other endeavours in similar vein. So when the opportunity raised its head to move into the developer relations space, it was really just a flipping of software engineer being greater than advocacy, to having advocacy be greater than software engineer in my day to day life.
I will readily admit that it was an interesting mental shift making that flip. I know that I personally (and from anecdotal evidence I have from talking to peers, many feel the same), self identified strongly as a “software engineer” first and foremost, and it was an initial struggle to think that I was going to be giving that up, before I truly understood this role, and also let go of some cognitive dissonance. Now that I’ve had some time in this position, I can say that in this job, I’ve never felt that I’ve stopped being a software engineer. In fact, being a software engineer is a critical part of me being able to do my job effectively, but now I just use it in a slightly different way. Yes, I do sometimes miss solving the large architectural problems or consistently writing code all day long, but the flip side is, the code I write is generally only the code I want to write. If I want to spend some time working out how I can use Haskell on Google Cloud Platform, I can make that decision to do so (this is on my todo list, once I get a better understanding of Haskell). On top of that, no one is going to call me at 3am to let me know a server is on fire, and I need to get up and fix it. So there are pros and cons both ways.
So, given the above – what does a typical “day at the office” look like for me? Honestly, and one of my favourite things about this job, is that there are really no “typical days”. Each day vastly differs from the next, but here is a most likely incomplete list of thing I’ve been up to in the past year just to give you an idea of what sort of things I’ve been involved with.
Doing a Lot of Research
This may not be immediately obvious from the outside, but I spent a lot of time reading articles, running through online training, building proof of concepts, just to learn new things. I was thankful that I had had prior experience with Google Cloud Platform before joining but I quickly found (a) that I really only had a small understanding of the platform, which was naturally biased towards the types of applications I was previously building on it and (b) Google Cloud Platform is constantly releasing new things, so choosing which products were going to be relevant to the audience I feel I identify with and learning about them is a constant, ongoing task.
This wasn’t just limited to Google Cloud either – I spent an inordinate amount of time playing with Docker containers, in some rather bizarre and interesting ways, to try and get a deep understanding of the platform (and also because it’s a ridiculous amount of fun).
On top of that, in the past five months or so I’ve been increasingly game development focused. Over the past few years, I’ve had a romantic notion of one day getting more involved with game development, and working on Google Cloud has allowed me to foster that. Which means I spent a lot of time both reading and playing with various tools and libraries, but also talking to various people across Google and outside from sales to marketing, product management and game developers to get truly understand what game developers need out of cloud infrastructure, and also how having an internet connected game changes the types of games that can be built and how they are developed in the first place. I’ve still got a lot more to learn in in this area, as it is massive and varied, but it’s been an absolute delight to get involved in something I’ve been getting increasingly passionate about as I get older.
It’s true! I do spend time writing software! Crazy!
More often than not, this usually consists of building fun and interesting demonstrations of Google Cloud Platform, which eventually ends up being content for presentations, and also as a perfect avenue for truly having an understanding of the product(s) that I’m talking about, so this goes hand in hand with the research section above.
Sometimes this is just open source, for open source’s sake, because it’s an interest, or useful to what I do. The demos I build also become open source projects as well, although that being said, I’m currently behind on releasing about 3 things, just because I’ve got to send them through code reviews and the like.
Presenting at Conferences and Events
Unsurprisingly, I do a fair amount of presentation at conference and other events, such as meetups. I’ve had the pleasure of attending some fantastic events, and particularly enjoyed having the opportunity to present at Google I/O this year.
I find a distinct pleasure in getting up on stage and building a narrative that people can use to understand a topic, and having them be able to walk away having a deeper understanding than they had before. I work very hard to make sure people can walk away from a presentation with enough of an understanding to know whether the topic at hand is something they are keen to explore further, or if the given topic is not relevant to them at this time, which in my mind, is just as important information. Also, getting a laugh out of an audience is just a great feeling as well.
Creating Online Content
Online content has also been an interesting adventure. I’ve always been a relatively intermittent blogger, and while this job has me writing somewhat more than before, I’m nowhere near what I would call “prolific”. That being said – I did have the wonderful opportunity to start the weekly Google Cloud Platform Podcast with my teammate Francesc Campoy Flores.
I’ve been an avid podcast listener for a long time, and started the randomly released 2 Developer Down Under podcast with Kai Koenig several years ago, but the Google Cloud Podcast has become a far more professional endeavour, and a much larger audience. It has given me the opportunity to interview both a wide variety of people inside of Google, and a slew of customer and users of Google Cloud outside of Google as well. We’ve had guests from from San Francisco to South Africa, and feedback to the podcast has been consistently positive, which has been incredible.
Interacting with the Community
Interacting with the community is also an integral part of what I do as a Developer Advocate. This can be in person at meetups and conferences, via Hangouts for in depth customer meetings as well as online via Twitter and the Google Cloud Slack community that I founded with teammates Sandeep Dinesh and Ray Tsang.
If you are interested in Google Cloud Platform, the Slack community has grown by leaps and bounds, and is a great place for Google Cloud users to interact with each other and share experiences. There are also a large number of Googlers that usually hang out there for you to chat with as well. I’m very happy to see how much the community has come together through a shared passion for Google Cloud Platform, especially considering how widely dispersed they all are.
Overall, community interaction is a hugely valuable activity for me, because this is where I really get to see what software people are building “out in the wild”, ideally help them find solutions that will aid them in their endeavours as well as mentally match that back to what we are doing at Google so we can build a better service.
Doing all of the above, gives me the research to effectively provide feedback to the right people in Google Cloud platform. Without my external facing endeavours, it would simply just be solely my opinion (and feel free to give that the level of respect you feel is appropriate), and nowhere near as valuable as it is when combined with the voices of people I meet at events, interact with online and talk to on the podcast.
Feedback takes the form of reports from events, that are shared far and wide, regular old bug filing, to reporting just general pain points. It can be sit down meetings with product managers to discuss existing features, or even proposing new features that I feel would be a great addition to a product.
I feel this is the part that most people don’t think of when they think of developer advocacy, which is totally understandable, it’s not something that is immediately obvious to the outside world, but I feel that closing this loop, from external to internal advocacy is an important part of what I do in my job, and developer advocacy in general – because if I’m not making sure the product is getting better, I’m not making sure the people I advocate for – the developers – are getting a better product.
Overall, I have to admit, I’m adoring this new role. I feel like it’s been a very natural progression for me, and most importantly, it’s an incredible amount of fun building crazy-silly demos, running around and talking to people and generally just spending every day involved in some super, super cool technology at Google.
On top of that, this is honestly, the best team I’ve ever worked on, with the widest variety of incredibly intelligent and creative people I’ve had the pleasure of being in a team with.
Hopefully, that gives you a better understanding of what it means to be a Developer Advocate, or at least my current perspective on the subject. Please add comments, questions or suggestions below, this is a fascinating topic for me, so always keen to engage in meaningful discourse around it. Alternatively, if you want to talk privately about developer relations, pretty much anything to do with the cloud, or are looking for a speaker for an event, or almost anything at all vaguely related to tech, don’t hesitate to drop me a line via the the contact methods above. I love to talk to people, and am always looking to have a chat.