One Year In Developer Relations
I’ve been a Developer Advocate at Google for a bit over a year now. I was really unsure when I took this position but now I feel like I finally starting to figure it out. So if you are looking at a position in Developer Relations (training, evangelism, advocacy, or whatever else a company calls it) here are some of my thoughts.
What the heck is Developer Relations?
Every company seems to have a slightly different take on what constitutes Developer Relations and Evangelism. At Google there are three main Developer Relations titles (Developer Advocate, Developer Programs Engineer, and Technical Writer). Developer Relations at Google is also under the engineering department which is somewhat unusual (often evangelism is part of marketing).
As a whole Developer Relations is responsible for acting as a bridge between Google and the outside world. Part of that is creating tutorials, examples, talks, and documentation that help developers use Google tools. Part of that is reviewing and testing new products, documenting community wants and needs for PMs and designers, and connecting internal folks with current or potential users.
But what do you do all day?
For me, one of the best parts of the Developer Advocacy role is that no two days look the same. To make sure I’m hitting all the important bits I keep my todo list divided into the following categories: Speaking & Community, Code, Advocate & Write, and Learn.
In an average week I might do some of the following:
- Speaking & Community
- Submit a few proposals to an event I’d like to speak at
- Create a Cloud Minute Video
- Spend a few hours on Reddit, HackerNews, Slack, Twitter etc seeing what folks in my areas of interest are excited about
- Attend a meetup or run office hours to meet with other nerds
- Code
- Run through new tutorials documenting places I get confused and entering bugs
- Explore a dataset I found in BigQuery to see if I can write a talk or a blog post about it
- Prototype a crazy idea that uses Google Cloud Platform products and might be interesting to others
- Advocate & Write
- Start working on a blog post (I don’t publish often enough)
- Meet with the UX team to give feedback on some changes to the developer tools
- Meet with the Ruby on Google Cloud team to discuss what is important to Rubyists in a cloud provider.
- Review content for others both inside and outside google
- Learn
- Work through part of an online course to improve my public speaking
- Study a new programming language (Python, Swift, and Go are on my list currently)
- Attend an internal talk on Machine Learning 101
- Read papers/articles/books on topics related to DevOps to try and backfill some missing knowledge
Mixed in with all of that is a lot of just sitting around talking to people. Talking to people and building relationships is probably the most important part of the job and frankly I struggle with it at times. Even so, I know how important it is in so many situations. If a customer comes to you with a really thorny issue knowing someone on the product team who can help them debug is important. If you want to host an event at the office knowing the folks who run the event space is handy. If you need someone to solder blinky LEDs together for a demo having friends who can use the makerspace is key.
Advice for thriving during your first year
I have some advice for folks starting out in this type of job. I hope someone other than me finds it helpful.
Get a mentor
I was lucky to have an official and unofficial mentor inside Google (Thank you Brian and Julia. I was also fortunate to have a few friends who work in advocacy at other companies in the area. These folks gave me practical day to day advice, helped me fine tune talks, reviewed blog posts, and answered enumerable questions.
More importantly I felt like I had a group of people I could go to with problems no one else seemed to understand. I think the biggest was a period this summer and fall when every social event in my off time started to feel like work instead of fun. I had started to put on my Developer Advocate persona to go to a friends movie night. I talked to a couple of mentors and their sympathy and tips help me figure out ways to keep work and social time separate so I could enjoy hanging out with friends again.
Set aside time for code (and your other passions)
In order to be a Developer Advocate you have to be a passionate developer. If you want to give interesting talks you need to know or build interesting things. If you want to be able to stand up for the best interests of developers you have to really grok their needs, wants, and pain points.
I’ve really struggled to keep my technical skills fresh during the last year and I’m trying to find ways to do a better job of that going forward. One of the biggest hurdles is simply time. Conferences, videos, and blog posts are the things that others see. The hours I spend coding on throw away projects probably won’t make it on my performance review. The other hurdle is a lack of direction. After spending 2 years at a consultancy where everyday started with “let’s write this feature” staring a blank editor has been a bit intimidating. I’ve half started a dozen projects during the last year and published only one of them.
Going forward I’ve tried blocking off one day a week for coding. I tend to code better away from the office and I’ve tried going to a coffee shop to help me focus on the task at hand. In 2016 I’m also trying to do more volunteer coding. Most of this will be small websites for local organizations I support. I hope that having someone else specify the requirements and the deadline will get me to actually buckle down and write some code.
Finally, don’t let travel and new job stress let you forget your other passions. Some of the best blog posts and talks I’ve seen come from the place where someone’s hobby intersects with technology. Julia’s series of blog posts about using Kubernetes to run a Minecraft Server is a great example. Even more importantly hobbies can help you manage your stress. Knitting is one of the ways I de-stress and so I rarely travel to a conference without my knitting.
Know your limits
The last big piece of advice I can give is to know your limits. In order to stay happy and healthy I need regular stretches without travel. In 2016 I’m planning on two no travel months (January and July most likely). I also prefer to sleep in my own bed (and I don’t mind getting up early) so I’ve done several events in SF as day trips from Seattle. Other folks on my team know that they’ll do better arriving the night before so they do that.
One of the best examples of knowing your limits came up recently. Most of the Google Cloud Platform Developer Relations team was having an off site that included chances to socialize with folks we don’t get to see very often. I had every intention of staying up late chatting and playing board games with folks but when the time came it was clear that I had hit my limit for noise, socializing, and I was starting to get sick. So I made the decision to stay in and watch a movie instead of getting out and about. A few years ago I would have felt guilty about choosing to avoid the social situation but I’ve learned that self-care in all forms is super important and necessary if I’m going to do my best most of the time.