Although I wasn’t searching for a new role, one found me, and after a long period of accumulating scope and responsibilities at Google, I’m excited to try something new.

I’m incredibly grateful for the 15.75 years I’ve had to work side-by-side with some of the most amazing engineers and storytellers I’ve ever met… and to do so on a global scale. I first learned about Developer Advocacy when I ran into Mano Marks at Google I/O in 2009. He had just returned from a talk at the UN, where he spoke about combating deforestation by empowering indigenous peoples with mapping platforms. I knew right away that it was my dream job, and I applied to Google.

I started as a Developer Advocate working on the social web. First there was Open Social, then Friend Connect, and Google Buzz. The +1 button was one of our first major launches leading up to Google+, and it ended up being on a shockingly high percentage of page loads on the Internet (the TL used to say, “it’s not just a f#$%ing button”). I changed teams to work on Google Glass and gave the first public demo of Glass alongside an introduction to our developer platform. That was probably the only time I’ll ever be the subject of a Saturday Night Live parody. After Glass, I helped evolve the DevRel structure at Google a few times. First leading a small team of DAs for “ubiquitous computing”, then all of Developer Advocacy and the Google Developer Studio, then a portfolio of DevRel teams. That portfolio of teams evolved over the years, and I had the privilege of starting full DevRel teams for Flutter, Firebase, TensorFlow, and evolving many others, such as Maps, Apps, Search, and Material. Later on, I was able to build Google’s first Internal DevRel team and take on responsibility for the Developer Ecosystem team and the Open Source Programs Office. Throughout all those years, I helped stretch Developer Relations at Google through projects like growing our online video presence, founding the annual internal DevRel Conference, coauthoring the Developer Relations Engineer role profile, evolving the Google I/O online experience and developer keynote, helping reinvent perf, and more recently helping evolve our craft in the age of AI. Together, we helped grow Google from a handful of platforms supporting consumer products to what it is today.

Here I am today, wondering how I was so fortunate to have worked on so many amazing technologies alongside so many extraordinary humans. Thank you to all my Google colleagues for everything you’ve taught me and all the crazy ideas we turned into the state of the DevRel art.

As for what’s next, well, that will have to be a different post.

I’ve been doing Developer Relations at Google for over 15 years. In that time, I’ve gone from an individual contributor to building, growing, and leading multiple DevRel teams. Currently, I oversee Open Source and Ecosystem for all of Google, as well as Developer Relations for the Developer X platforms. One thing has been true throughout that entire journey: whenever I start working with a new Product Manager, especially if they come from a history of consumer products, they inevitably ask the question, “So, what does DevRel do?” or some variation of it. I first created “The DevRel Lifecycle” as a single slide to share during those moments. Over time, I found it to be an incredible asset for starting discussions on DevRel strategy, regardless of the platform’s maturity. I’ll bring it up when first meeting a new stakeholder, when coaching a team leader through prioritization, and throughout annual planning. I’ve added slides to demonstrate the multi-disciplinary nature of Google, the hierarchy of DevRel needs, and adjusted the representative activities here and there. I hope you find it as helpful as I have and that you share your variations and suggestions.

Lifecycle slide

The DevRel Lifecycle is meant to mirror a simplified version of a Product Lifecycle. Imagine that to look something like building, deploying, maintaining, and iterating. Then ask yourself, during each of these periods, where can DevRellers help the most?

• Build → Be the customer
  During the Build step, DevRellers will “be the customer” before the customer is available. We’ll test, identify friction points, deliver feedback, and start filling gaps in the experience with critical path developer materials.
• Deploy → Materials & GTM
  When it’s approaching time for the product to be released, DevRellers will finish all the developer materials, build a Go-To-Market strategy, and begin to raise awareness and kickstart engagement programs.
• Maintain → Community
  A healthy community fosters a sense of stability and accessibility while also directly supporting one another in adoption and success. DevRellers will establish the right communities for the platform’s audience and maintain them through direct programs, sponsorships, and surrogates (such as top contributors).
• Iterate → Thought Leadership
  All platforms require a context in which to be successful. Through external thought leadership, DevRellers will help bring about and maintain that context. Then, leveraging their familiarity with the customer base, they’ll influence internal teams on product strategy and ongoing development.

Multi-disciplinary slide

Developer Relations is inherently a multi-disciplinary art. Developer Advocates, Developer Relations Engineers, Technical Writers, Community Managers, Program Managers, and others collaborate to orchestrate the comprehensive set of strategies and deliverables necessary for customers to achieve success with a platform. Here’s a version of the lifecycle that illustrates some of the shared responsibilities:

Prioritization slide

Prioritization is essential to any high-functioning Developer Relations team. Some activities can be dismissed based on the type of offering. For example, you likely wouldn’t need a training course and certification for a RESTful API. After that, you’ll want to evaluate the platform’s maturity and build up DevRel responsibilities from the foundational elements. The last slide in this series illustrates a Developer Relations hierarchy of needs. Basic reference materials and code snippets come before solutions and customer empathy sessions.

The Deck

These three slides have helped me navigate countless conversations with leaders across engineering, product, marketing, comms, and more. They reduce the unpredictable complexity of what DevRellers could do down to what DevRellers typically do. You can then build a DevRel team on a solid foundation, layering in complexity for the unique needs of a particular platform or offering.

Why now?

You may ask why I’m sharing this now. I’d like to get some feedback and have a conversation with other DevRel leaders on how they approach lifecycle planning and early DevRel team building. But that’s not new. The new thing is that this lifecycle is now significantly changing because of the impact of AI tools on the DevRel workflow and the changes in developer materials because of the impact of AI tools on the developer workflow. I’m in the process of updating the lifecycle to represent this change better. I would love to start the above conversation with an eye towards this new future where, for example, developers visit an assistant instead of documentation.