How to scale a developer relations team

Google’s Uttam Tripathi shares practical advice on how to scale a developer relations team to meet your programme’s growing needs.


  • Principles for building developer programs and strategy.
    • Feedback.
    • Community first.
    • Diversity and inclusion.
  • Four Pillars to scale your DevRel Teams
    • Team
      • Personas
      • Type of Role
      • Expanding Globally and Scaling
      • Pipeline for DevRel Hires
      • Org your DevRel is a part of.
    • Outreach
      • Know what are developers that are most relevant for you.
      • Online channels.
      • Influencers and community managers.
    • Operations
      • Vendor partners as an extended team
      • Swag
    • Feedback


  • If you get unlimited resources and a budget...
    • Probably bad news for your company because they’re not being thoughtful about how they are investing and the floodgates are literally open.
    • Doesn’t really focus one to innovate as it should be.
  • What is really scaling?
    • Preparing the ground for the next wave of growth.

Principles for building developer programs and strategy.

  • Feedback.
    • Dev rel traditionally has been an outward-focus function.
    • There needs to be two-way advocacy.
      • Need to be able to take the developer feedback and bring it back to the Product & Eng Team.
  • Community first.
    • If you’re able to do it the majority of the time, that itself is good news.
    • Did you have influence in your Product & Eng Teams to block a product launch if you think that launch is not going to be beneficial for your developers?
    • If you have strong signals and feedback that the product is not ready, are you able to make that call?
    • When you are sharing content for meet-ups or events among your developer community, is that the content that you and your Product & Eng Team want to push out?
    • Focusing on the needs of the developer community really helps you win their trust in the long run and that really pays back also in business value.
  • Diversity and inclusion.
    • Important -- developer community that we’ve worked with and engage are also representative of these developers that we want to eventually engage with.


  • What kind of personas exists in the DevRel world?
  • What kind of roles exists?
  • Developer Advocate is a much more common word being used now.
    • Folks who go on stage.
    • The ones that go at events.
    • At meet-ups and talks.
    • Go behind the camera and record talks -- share more scalably
    • Public face for your developer programs and your platform.
  • Community Manager.
    • Very quickly, if your product is starting to get traction, there will be a community that will build around it.
    • Folks who are helping swags for meet-ups, helping buy pizza for the hackathon.
    • Helping run events if your company has to run those first-party events themselves.
  • Other roles -- Developer Program Engineers, Developer Advocates are going and talking about the vision of the platform, getting people excited.
  • Specialized roles like Developer Program Engineers exist.
    • In many companies, especially if the dev rel team is fairly small, Developer Advocates will be doing the same responsibility.
  • Tech Writers.
    • Call-to-action.
    • Inspiring someone with a key message.
    • Experience that that developer website has is key.
    • Having a really solid technical writer team is important.

Expanding globally and scaling.

  • Dev rel teams typically get started wherever the host organization is based but then very quickly realize.
  • The challenge is hiring leaders in these key hubs who can really grow your dev rel presence over there.
  • Focusing on hubs.
    • Figuring out the demographic that works best for your program and needs.

Pipeline for DevRel hires

  • Where do we hire for Dev rel?
  • Traditional interview formats of either hiring for a software engineer role doesn’t really help.
  • LinkedIn
    • You look at people with dev rel titles, that pool is growing.
  • Software engineers in your company who are keen
    • Offer them a rotation opportunity or a short-term project for them to explore dev rel as a practice.
  • Hiring some of the community managers from the broader developer community that your org. works with.

Which org is your DevRel part of?

  • Doesn't matter which organization your dev rel team is part of.
    • The obvious ones are marketing.
    • Irrespective of where you are, you can be successful if your dev rel organization.
    • Use your influence to land your dev rel team where you would be most comfortable with.
    • If you strongly think that your dev rel team should be part of marketing, make that pitch early on.


  • That number around 20 million has not shifted in the last five years.
  • Know what are developers that are most relevant for you.
    • Are you really engaging with developers that are relevant for your platform?
  • Online channels.
    • Events are very expensive, expensive on time, expensive on resources.
      • Don’t give you a channel to constantly engage with your developers.
    • Explore online channels.
      • Helps you get a lot more traction.
  • Influencers and community managers.
    • Identify key influencers and community leaders in those markets and build relationships with them.
    • Reach a lot more developers than a traditional channel will probably offer you.


  • Dev rel is a job that requires a lot of travel for example.
  • Vendor partners as an extended team
    • Are you booking all your travel yourself or is there someone, a vendor or an agency who can help you?
  • There are organizations that can help you.
  • Swag.
    • Procblem when we have swags being produced centrally, not headquarters. And we’re trying to ship it worldwide.
    • Way too expensive if your developers are in emerging markets.
    • Shipping cost.
    • Producing locally.
      • Has a positive impact on the environmental footprint.


  • A key part of the developer ecosystem, the work that we do is gathering developer feedback.
  • This is an area where sometimes it’s okay to not focus on scale.
  • Face-to-face conversations where the developers were sharing their pain points.