Let's start with you. Who are you, what do you do, and what does your company build?

I'm Jason Mayes, Google's Web AI Lead, representing the art of running all those AI models you know and love entirely locally within the sandbox that is your client side web browser! We can now run these models (from LLMs like Gemma 4, to object detection, and everything in-between) almost as fast as native, via technologies like WebGPU, Wasm, or WebNN. This enables real-time results, with total privacy, and zero inference costs. Great for industries like finance, legal, healthcare, government and beyond where those superpowers matter most.

You can learn more about me in 60 seconds in this short video:

What does DevRel actually mean to you? Is it marketing, engineering, product, or something else entirely?

DevRel engineers are essentially software engineers who are also good at presenting and sharing knowledge to multiple types of stakeholders - from C-Level, to other engineers, or even students - and everyone between. They should be hired to the same bar as a software engineer, but with additional interviews for their ability to present technically advanced subjects in a manner that is understandable to all. Quite often I see SWEs "graduate" to being DevRel after they get asked to speak more about their work, often growing a following for that niche area, and those that also enjoy that public speaking aspect tend to find themselves in DevRel after some time.

Developer Relations Engineers (DREs) at Google are expected to be the zeroth developer to first-party (1P) product teams, being the first eyes on something new (often helping shape new APIs and product decisions — we are in the design docs with the SWEs), while also being the face of product to the whole world (being on the front lines with third-party (3P) developers who are actually using it, while shielding the product team from the noise that is the rest of the world, and only surfacing the important bits back to them to drive changes that matter most).

For this reason DREs often find themselves at the intersection of innovation (creating reusable prototypes or code examples that inspire action for an emerging technology), shaping product direction (almost like a PM but often with a 3P lens instead of 1P), with the confidence to give talks at large scale events (elements of marketing and storytelling). So it's all 3 to me - you are the glue between all of them.

A good DRE should be positioned within Engineering, integrated tightly with the product team(s) they represent, even working alongside the SWEs and PMs, and really are part of the core team - even contributing code to that project too that ends up in production. If I had to break it down I would say 40% Engineering and prototyping (going deep on the thing you represent), 35% Marketing (storytelling, presenting, educating, and 3P influence), 25% influencing 1P product futures like a PM would do if they had the 3P knowledge you have from being on the front lines.

DevRel works in both directions: you speak for the company to developers, and for developers inside the company. How do you balance the two, and when have you pushed back on your own team for developers' sake?

Sometimes 1P product teams are not aware about the needs of 3P developers. What makes sense when working solely with internal tools and services may be hard to integrate with when using 3P tooling or infrastructure. Even something as simple as naming of functions in an API that will be called can cause misunderstandings or friction when launched if done without thought. Too often it's easy to ship internal complexity, and I've often found myself pushing back on shipping the org chart, instead of what makes most sense to 3P developers. Reducing complexity so more people have a chance of using something frictionlessly is a big part of my job as it is very easy to accidentally do that when you are only working in a 1P capacity as a traditional SWE. As DREs we must take a step back and see the forest not just climb the tree.

For example: How do we remove that "complex config object" that was required to instead be optional with some sensible defaults? This way advanced users can still have the choice to customize all the nerdy details, but newer folk can get started in 5 lines of code, instead of 20. Little things like that pay dividends over time with regards adoption by reducing friction of adoption.

Tell us about your community. Who's in it, how big is it now, and what helped it grow?

I started as the founding DRE in the Research and Machine Intelligence group (RMI) at Google for TensorFlow.js in 2019 after moving from my prior Google role as a Creative Engineer inventing the future for our top 100 customers using emerging technologies. At that time we had 1 million yearly downloads or so of the TensorFlow.js product and it was not growing - total flatline pretty much.

It was my job to build a community from zero to raise awareness of client side AI and how it can be complementary to cloud - either fully offloading to the edge or in hybrid implementations. To inspire developers I set up a bunch of initiatives for example (but not limited to):

1. Creating prototypes that recreated literal superpowers from sci-fi movies (teleportation, invisibility etc), or solved common problems people were facing (for example ordering the right size clothing during COVID from online stores). Many of these went viral and made folk wonder how I managed to pull these off in JavaScript of all languages! This sparked curiosity. I hold a patent for digital teleportation as a by product of that work! Alongside this I have given well over 150 talks in the past few years alone around these subjects at keynotes, hackathons, workshops, podcasts and more.
2. I also started a "Show and tell" series on YouTube to give our 3P developers a chance to speak about their wins when using AI in JS. This drove viewership, page rank for key terms, and long form views - kickstarting the beginnings of a community with something regular folk could rally behind.
3. Then came education - I partnered with EdX and others to create a full 16 hours course on TensorFlow.js and client side AI. We have had hundreds of thousands of students across our EdX and YouTube versions of the course now view the content.
4. Around 2022 I coined the term "Web AI" as we had more than 1 team working in the space, so wanted a single term and hashtag (#WebAI) folk could use to rally behind to represent any AI on the client side in JS to distinguish vs Cloud AI that was also taking off. Web AI is now the industry wide term for client side AI, and is even used beyond Google.
5. As such I then also started the annual Web AI Summit - a yearly gathering of the top minds from all companies and individuals in the space at our Google HQ. This has now been running for 5 years.

So what did all that work (and more) lead to? Well, fast forward to 2025 and at my last count we crossed 2.5 billion downloads yearly across Google's TensorFlow.js and Mediapipe web implementations and models. Incredible growth. 2500x organic growth in just a few years with a very lean team any given time for those two products.

Huge kudos to the amazing SWEs who have created some truly best in class production ready AI runtimes in JS - it is an absolute pleasure working alongside some of the brightest minds I've ever worked with.

Of course Web AI at Google has now grown beyond these 2 founding teams that I was part of, which is why the scope of my role has now also gotten wider too, covering new teams' work like LiteRT.js and LiteRT-LM.js for example.

How do you measure whether DevRel is working? What do you track, and what do you ignore?

There are many potential metrics to measure. What you choose may depend where you are on your journey as a team. You can choose from any one or more of the following as a few but non exhaustive list of examples:

• Share of voice - out of all the people talking about the area your product is in, what percentage mention your product?
• Product sentiment on popular social channels
• Views / comments / likes for videos / social posts etc.
• Website analytics - views, bounce rate, time spent, specific content reviews if your site supports feedback on articles etc.
• Raw downloads / usage metrics of the product including signups and daily / monthly active users etc.

There's a well-known saying that "developers are allergic to marketing." Do you agree? How do you reach developers without it feeling like marketing?

No one likes to be marketed to honestly. I've often been told my passion for what I do is infectious. I think genuinely believing in the thing you represent can go a long way to not resorting to just throwing marketing at people. I lead by example. I solve problems I personally have and show the world how I did it. Or I try to bring magic to people's lives that makes them the superstar at their office if they use it. The fact it uses my knowledge of a new product we have is convenient, but the passion of solving the problem in the first place is what excites me and others who choose to follow me is a byproduct of that passion. There is a huge difference between a SWE or DRE who is doing it for the money to pay the bills vs having a genuine passion for what they are representing. Throughout my career the ones in the latter category are the superstars that I strive to become one day.

How can people connect with you if they want to ask questions or learn more?

You have a few options:

• LinkedIn (preferred - hit the notification bell on my profile so the algo doesn't bias your feed with other people's AI posts)
• Web AI Newsletter (monthly)
• X / Twitter (less frequent postings)
• Github (let's get nerdy - code only)
• CodePen (nerdy with live demos to try)
• Personal Website (see what I am up to, though I probably need to update it - not enough time!)

Thanks for having me on Hackernoon - stay curious folk and keep innovating, these are some of the best years to make progress!