The Developer Relations Lifecycle

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.