My job is as a Chrome Developer Advocate at Google. Starting last week (April 2013), Google Japan began hiring for this Chrome Developer Advocate position. We are also hiring for similar roles across Google+, YouTube, Android, and other products, but since people often ask me about it—and I've had several requests—I'd like to take this opportunity to explain what a Developer Advocate actually does.

What Is Developer Relations? #

All of the roles mentioned above belong to the Developer Relations team (DevRel) within Google. It is likely the team at Google that developers have the most opportunities to interact with. DevRel is further divided into product-specific teams such as Chrome and Android.

As the name suggests, the core of our work revolves around building relationships between Google and external developers. The roles include Program Manager, Developer Programs Engineer, Developer Advocate, and Technical Writer, and my role is Developer Advocate. Very few people immediately understand what the job entails just from the word "Advocate"—which is entirely natural, as it isn't a word taught in school. The closest equivalent at other companies would be an Evangelist. For those who still don't quite get it, I often explain it as: "A job focused on outreach to help external developers make use of Google's technologies."

The origin of the title "Developer Advocate" goes something like this:

The word "Evangelist" originally comes from religious preachers. When a role similar to an Evangelist was created at Google, however, they chose the word "Advocate" to convey that it isn't just about one-way communication to developers, but also about Google itself learning and growing through dialogue and feedback.

Below, I'll dive into the specifics of the job. Please keep in mind that this article describes what I do around Chrome, and may not necessarily apply to other products. I'll share some of what I'm currently working on, within the bounds of what won't get me in trouble.

Advocacy and Outreach #

The primary focus of DevRel is "to help people who want to build apps on top of Google's products as a platform." When it comes to Chrome, that mission is "to help people who build apps on the Chrome platform—in other words, websites and web apps"—or put another way, "to energize the entire web, including HTML5, and especially the frontend ecosystem, not just Chrome." That's a very rough summary and no one has ever explicitly told me that, but that's how I envision my job.

Public Speaking #

This is probably the most visible part of the job: giving talks at external events. The topics are usually introducing Chrome technologies or HTML5 features (by the way, these days I find myself using the term Open Web Platform, or OWP, more often than HTML5). Naturally, I create my own presentation materials, which requires a substantial amount of research beforehand. Preparing while anticipating potential questions also takes up quite a bit of time. If the talk is outside of Tokyo, it also involves business travel.

Social Media #

I share the latest updates through social media like my blog, Google+, and Twitter. Many of you probably follow these already.

HTML5Rocks #

I write articles for HTML5Rocks and help maintain the site. Since HTML5Rocks itself is open source, we accept Pull Requests, review articles, and review Japanese translations when they are submitted.

Google Developers Live #

Google Developers Live (GDL) is a monthly live web broadcast on YouTube Live. As those who have tuned in probably know, it features guest speakers presenting technical sessions. While there are staff members who help with studio setup, everything else—booking guests, choosing topics, hosting the show, and moderating—is handled by myself. On GDL in the US and UK, the Advocates themselves deliver the sessions directly instead of bringing in guests, but in Japan, we currently invite guest speakers.

Thinking about how to amplify the content we've created is also an Advocate's job. I previously wrote a blog post like this. I think it was a win-win idea, beneficial both for our viewers and for us creating the content.

StackOverflow #

Providing support on forum-style platforms is another part of the role. For Japanese, I answer questions on Google Groups, but globally, StackOverflow serves as our official support platform. Just like hosting open-source code on github rather than Google Code, I really appreciate Google's (or perhaps DevRel's?) pragmatic approach of not insisting on building everything on our own internal systems.

Community #

DevRel only has around 200 people worldwide (currently just 4 in Japan), so scalability is essential. Because of this, there are many situations where we become part of external communities to help energize the technology scene together.

Google Developers Expert #

As many of you probably know, there is a program called Google Developers Expert that recognizes outstanding external developers, similar to Microsoft's MVP program. Exchanging information with GDEs is a crucial part of my job.

This program was previously known as Google API Expert. It originated in Japan and went global last year (thanks to Naoki Ishihara and Fumi Yamazaki!). Incidentally, I was an OpenSocial API Expert myself before joining Google.

Working with Communities #

Since I'm the only person covering Chrome in DevRel Japan, what I can accomplish alone is naturally limited. Therefore, collaborating with like-minded developer communities—including the GDEs mentioned above—and sometimes becoming an active participant to help them out is an important part of the job. Brainstorming ways to help communities thrive is genuinely fun.

Event Operations #

As part of supporting communities, providing Google's event spaces and facilities, and helping out on the ground as event staff is another key duty. This includes hosting study sessions and other events, having engineers involved with our products give talks, and more. In 2011, we collaborated with html5j to host the Chrome+HTML5 Conference. Chrome Tech Talk Night has already reached its 5th edition. We are also planning to host an event called Test The Web Forward in June.

Partners, Input, Hacking, and More #

In reality, the work involves many more miscellaneous tasks, but the main duties not covered above include:

Working with Partners #

While working publicly with the broader developer community makes up a significant portion of the role, there is also behind-the-scenes work with partners. This can involve negotiations to get a product built, or taking confidential technical issues back to the team to improve Chrome features. Serving as a technical liaison between partners and the team is another important role for a Developer Advocate.

Continuous Learning (Input) #

I haven't talked much about technical depth so far, but this job naturally demands cutting-edge technical skills. You can't produce output without input, so constantly staying on top of the latest developments is an absolute requirement.

Hacking #

There's no point in just taking in theoretical knowledge, so I also write actual code. While I don't build large-scale applications very often, I frequently build demos that directly contribute to technology advocacy, as well as internal tools.

Some of the things I've built so far focus on areas covered by the Tokyo Chrome engineering team, including demos for WebSocket, Forms, and recently, FileSystem-related APIs. I also build things that combine hobby and utility, like a Chrome Extension and a Chrome App. My code is published on github. I generally don't write production-level code myself, but some of my colleagues kept submitting patches and eventually became WebKit (now Blink) committers.

Chrome Experiments #

Did you know that some of the widely discussed Chrome Experiments actually originated in Japan? For example, World Wide Maze, which was announced recently, is one of them. Providing technical support for projects like that is also something Developer Advocates handle.

Collaborating with Engineers #

The Chrome engineering team at the Google Tokyo office is fairly sizable. As mentioned earlier, they mainly implement OWP features such as WebSocket, FileSystem, Forms, and WebComponents. Quite a few of them author the standard specifications published on W3C and IETF websites with their own hands. Bridging these engineers with external developers is also my job. That can mean having the engineers themselves present at GDL or conferences, or relaying feedback from external developers back to them.

What Makes the Job Fun #

That's what my day-to-day work looks like. However, this is strictly my own example and doesn't apply to every Developer Advocate. My fellow Chrome DevRel team members are scattered across seven countries around the world, centered around headquarters in Mountain View, and each brings their own strengths and does different work. At Google, work is not something that is handed to you; it's something you create yourself. Therefore, it's completely natural for different people to do entirely different things. You can pursue anything you think is worthwhile, and you'll still be properly recognized for it.

Here are two memorable projects I've worked on in the past. One was Developer Link at GDD 2011. Along with handling two sessions and a keynote, I led the project from planning through production and partner negotiations to deliver the service in time for the event day. I also wrote some of the code.

The other is an ongoing initiative: my involvement with Web Music Developers Japan (though it feels more like a hobby than work). As someone who has always loved music, I was thrilled by the Web Audio API, which lets you build synthesizers in the browser. Getting to connect not only with developers through it, but also with well-known figures from industries I previously had no ties to, feels like an incredible perk of the job. Once the Web MIDI API arrives, I'm excited about the even more interesting things we'll be able to pull off.

The Challenges #

The people around me operate at such a high level that, honestly, I'm constantly scrambling to keep up—both technically and in how I work. On top of that, all the types of work mentioned above run concurrently, making time management and staying focused quite difficult.

What compounds this is being Regional (remote from headquarters). Since I am the only person covering Chrome DevRel in Japan, communication with team members is mostly via email or Hangouts. Hangouts are convenient, but technology can't overcome time zones (right now, 9 AM in Japan is 5 PM at headquarters, and 5 PM in Japan is 9 AM in London). Email is text-only, so you can't see the other person's expressions, and the nuance doesn't always come across.

That leads to business trips, but then face-to-face communication brings its own challenges. My English level was near-perfect on the TOEIC three years ago, but that's still not quite enough. It might be less about the language itself and more about personality or cultural differences, but that's a longer story for another time.

The Work Environment #

I've worked at several companies throughout my career, but in terms of work comfort, Google is by far the most accommodating. Free lunch (and actually breakfast and dinner, too) gets talked about a lot, but parental leave is available for both fathers (Paternity Leave) and mothers (Maternity Leave), vacation time is flexible, and it's not uncommon for people to take a full month off at once. There are frequent activities to strengthen team communication, and Tech Talks and interest clubs are constantly happening internally, creating a wonderful atmosphere. It really is something you have to experience from the inside to fully appreciate.

Who We're Looking For #

As I mentioned the other day, Chrome DevRel is looking for someone who is "fluent in English and Japanese, confident in their negotiation skills, technical prowess, public speaking, and event organizing." If this article helped you understand what those words really mean, it was worth writing.

Of course, what I've shared here is just "my case." I don't expect the new hire to do the exact same things I do; rather, I want—and expect—them to create their own approach.

Someone who can define their own work and execute on it. Someone with strong communication skills who can proactively push things forward while having fun doing it—that's who I'd love to see join us.

So with that, we look forward to your applications! :)