← Return to Index Archived July 6, 2026
The Lead — Jul 6
SUPRA INSIDER · MARC BASELGA, BEN EREZ

#117: How Gusto is turning every employee into an AI builder through hackathons | Alex Meyers (Principal Product Manager @ Gusto)

A Gusto product leader traces how one company’s AI adoption moved from informal demos to quarterly hackathons, shared tooling and an expectation that everyone, not just engineers, learns to build. The conversation argues that sustained time, paired practice and connected data matter more than slogans if companies want AI fluency to change how work gets done.

1h 01m / July 6, 2026 /aiproducttechnology / Transcript sourced from openai
All episodes from Supra Insider →·Podcast website →·Listen on Apple Podcasts →

Overview

This episode is about how Gusto moved from light, scattered AI use to making AI part of day-to-day work across the company. Alex walks through the shift from one person quietly using Claude and Perplexity to a broader system with shared tools, connected data, recurring hackathons, and even PMs shipping pull requests.

The core argument is simple: AI adoption does not happen because leadership says it should. It happens when people get access, time, support, and a clear way to practice inside the company’s real workflows.

Key Takeaways

Alex says the turning point at Gusto was not a memo or a tool purchase. It was repeated show-and-tell, a working prototype for compliant copy generation, and a pitch to leadership that focused on enablement rather than one-off wins. His point was that a cool demo matters less than making it possible for many people to build their own.

A big lesson from the rollout was that access alone is not enough. The company needed connected systems so AI tools could pull from the places where work actually happens: code, data, internal docs, and product context. Once those links were in place, AI became more useful for real tasks instead of isolated experiments.

The other major insight was about time. Alex argues that short bursts do not work well for this kind of learning. The hackathons gave people long blocks to build, get stuck, pair with others, and keep going without context switching. He says the largest jumps in self-reported confidence happened around these events, with PM confidence moving from 11 percent before hackathons to 83 percent after them.

There is also a strong case here for pairing and shared learning. Alex makes the point that many employees do not have spare evenings to tinker. A company-wide ritual makes learning social, practical, and less dependent on who happens to have free time.

On the PM side, Gusto has pushed further than many teams. Alex says about 76 percent of PMs have merged a PR. That does not mean everyone is taking on heavy engineering work. It starts with small changes, while engineering review standards stay in place. The goal is more technical fluency, better judgment, and less backlog drag on simple tasks.

Practical Steps

If you want this kind of adoption in your own team, the playbook from Alex looks pretty clear:

  • Start with visible examples. Show real work improved by AI, not abstract claims.
  • Give people company-approved access to the main tools and connect those tools to internal systems, docs, and data.
  • Create recurring build time. Alex’s view is that 24-48 hours of focused work beats scattered one-hour sessions.
  • Make learning collaborative. Pair experienced users with less confident ones.
  • Save what you learn. Gusto keeps materials and examples from each hackathon in a shared repository so new employees can ramp faster.
  • Start PM coding work with low-risk tasks like copy or UI tweaks, then expand carefully.
  • Keep review standards high. AI-generated code still needs the same discipline as any other code.
  • Use hackathons to build things that matter, not throwaway demos. At Gusto, some outputs turned into shipped customer features.
  • Look for repeatable loops, not just one-time wins. Alex is especially interested in workflows that automate reporting, monitoring, and pattern detection.

Notable Quotes

  • "You can't just say, please be AI native, and it happens. You have to create that structure and that resource for folks to actually be able to do it." - Alex

  • "The biggest jumps that we have in AI proficiency amongst the PM org is directly around the times of hackathons." - Alex

  • "Pre AI, so much of product was spent organizing things and people. And now with AI, where you can automate a lot of that, you can focus all that time towards customer and strategy." - Alex

You can’t just say, please be AI native, and it happens; you have to create that structure and that resource for folks to actually be able to do it. — From the episode

Full Transcript

Source: openai 1h 01m runtime

We are live. Alex, welcome. What's going on? Nice to see you guys. I've known you a long time, Mark, but I don't get to chat with you on the interwebs that much, so this is fun. Yeah, and some quick context. Alex is one of my best friends. We met in college almost 13 years ago. He's a killer PM and he's also been a founder, so he has a really cool background. And yeah, he joined Gust about two years ago and it's been really cool to hear his journey with the company and also just tracking how the company has been adopting AI tools. And I just got to hear a lot from Alex, but I feel like there's not enough out there of the amazing work that you guys are doing. And so I just wanted to take this opportunity and just share a little bit of how that journey has been since you joined and where you guys are now. And not just the PM team, but also the company as a whole. And it's cool because I feel you've been pretty much in the epicenter of that revolution in the company. So yeah, maybe let's start there. Walk us through that journey over the last two years. Yeah, before walking through that journey, way to make me feel really old saying I've known you 13 years. Thank you, Mark. But, you know, I joined Gusto about two years ago and when I was interviewing, I was getting really deep with these AI tools. I was using Claude for a lot of interview prep before anyone had heard of it. I was using Perplexity to research companies and come in with like very pinpointed questions. And so when I started at Gusto, naturally I was like, I cannot go back to the old way of doing things. So this was summer 2024, where a lot of people were still handwriting PRDs or just like writing queries by hand to like get data. And the company was like not quite in the whole AI native force that it's in now. And so I was a little bit quiet about it. But as I was doing my work, this started to propagate and come up. And by the way, like maybe like paint a picture, like what you saw when you arrived at the company, like was there, did they have any Claude subscriptions that people could use? Like, did they have like, you know, Copilot like for GitHub? Like, like, and what was the, like, if you remember, what was like the lay of the land? So when we got there, we did not have many subscriptions. And now we're full in, right? Everyone's using Claude code, a little bit cursor. We have an internal MCP that connects all of our different data sources, like everyone has has that AI pill. But it was definitely like a journey to get there over the last two years. And when you say everyone, are you talking about like everyone in the PM team or everyone at the company? The whole company. So the whole PM and R&D org is like all in. But the expectation at Gusto is that every gusty is leveraging AI to do their work better. And it's been an incredible transformation. You see much higher output per employee. You have like genuinely new insights that you just couldn't get before because AI can synthesize data so much better and pull together resources so much better than one human can. And so what that's led to is like a much better experience for our customer because we are able to do more for the customer in less time. Cool. So, so Alex, if, if you guys had so much progress in two years from where you came in to now, let's now go back to maybe like the beginning of that, that part of the story. I'd just love to know from your perspective, both as an individual and maybe what you've observed in the org, like, what were the key kind of, you know, milestones from the beginning? Like what, what was your experience like kind of witnessing and maybe influencing that, that journey? Totally. So when I got to Gusto, I had been using these AI tools a lot to help me research and prepare for interviews. And I was starting to use it to actually do my product work. So writing PRDs faster, doing competitive analysis, etc. And at that point in time, it was not heavy usage of AI tools. But then the CPO at the time saw some of the stuff I was using and asked me to start showing the PMs. And all of a sudden, everything just started to like move way faster in terms of that AI adoption. So we then got a chat GPT enterprise account. We started having speakers come in like Claire Vo, who was walking through chat PRD and how she uses AI to do her product work. And as we were doing this more, I started this monthly sync across the PMs called like PM AI tinkering. But we just got together and jammed on like, how are you using AI tools to serve the customer better and get your work done faster. And that just started this whole snowball effect. And something that I observed while I was ramping at the company and using these tools more was I was spending my days and nights playing with these tools because I just love them. But not everyone had that time and space to go and play with them. And that it was super key that our leadership creates space and support for everyone at the company to be able to have dedicated time to learn and play with tools. And so what that's ultimately led to is we created this concept of PM AI hackathons that's now propagated around the company. So like the data team does AI hackathons, the finance team, the design team, everyone. And in each of these hackathons, we've had a theme. And through that we go through and create materials for the PM org on like, the first one was basically just use tools to do your job faster or build a prototype. The second one was build a prototype end to end with our design partners. The third one was ship a PR. And the fourth one that we're doing in a month is going to be building your own LLM wiki. What we found through the process was the PMs having that dedicated time and having resources for them to learn how to use tools in the context of gusto has really exponentially increased their understanding, their throughput and their comfort, their comfortability with using AI and being better at their jobs. And I'm curious, maybe so I go back to that moment where, like, the CPO maybe was like, hey, this guy is kind of doing things and other people are not doing. And there might be something here. And how, like, how did that happen? And then like, what were like the next steps for was he like, hey, like, kind of figure out a plan for other people to work like you were you meeting with with him? Like, did he give you like, full power to be like, hey, like design, whatever you want? Do you think that that you think is going to lead to other people using it? Like, how did that go down? So at first, there's a lot more show and tell, like we would have PM all syncs, or just like group meetings, where I would start to showcase some of the things that I was doing with Claude or with perplexity at the time. But the real the real pivot moment, and this was unfortunately, after he had left, was actually, I was doing a demonstration for our C-suite team of a product that I prototyped internally with cursor that was focused on helping our internal stakeholders write gusto compliant copy faster. Because we have very high standards for what's legally compliant, what's on brand, and what's the voice of the customer. And we wanted to be able to produce this copy faster for a lot of our different surface areas like email or internal platforms. And so I just sat and prototyped it, I was like, this should exist, I know the technology is there. And when I presented it to the C-suite, I was, you know, one of the key messages was this prototypes cool, but what's a lot more powerful is actually enabling anyone at the company to do it. And so that's when the aha moment happened, which was, you can't just say, please be AI native, and it happens, you have to like create that structure and that resource for folks to actually be able to do it. And my whole pitch as a part of demonstrating this prototype was create that dedicated time and space. And so, you know, the evolution basically came from like demos and partnering with folks and just meeting to like, actually having like a, you know, an org where you can like, provide events that's just like, we're going to pause and really focus on using these tools well, and have a lot of education. We brought in folks from other companies, like some of our vendors. So we've had folks from Repl.it and Cursor come in and show how to use these tools most effectively. As a PM, we've had folks from Anthropic come in and demo Cloud Code. And we've had a tiger team at the company that sits and blends our knowledge of these tools, and our knowledge of gusto, and bring that together so that there's like clear action plans for PMs to actually execute from. How long do you think it took from like, when you had that meeting with leadership and they're like, this demo is awesome, Alex, like, let's get everyone to be able to, you know, write copy within these guidelines and like compliant and our brand tone, etc. Like, but that's that we have no idea how to do that. How long did it go from like that moment to, you know, everyone has access to like the data they need and the AI tools natively to like do their job with like the connective layers. Like was that how long of a journey was that? So I did that demo about a year ago. And we did our first AI hackathon three months later. And so through that demo, I got buy in from the product leadership that let's do PM AI hackathons. And so through that first one, I helped assemble a tiger team of like folks that I knew were excited about AI and like willing to lend their time to this effort. And we went and put together like, what's the format going to be? And so that first hackathon was, it was a little bit open ended, where it's like, you could use internal tools, you could use building tools. But what we knew was like, if on hackathon day, people showed up, and they were spending the whole time getting their environment set up or getting access to tools, they weren't actually going to build and learn. And the secret sauce here, the big insight is like having dedicated long times, long blocks of time to actually build. And so the whole point here was like, don't just do like one hour a day, like every day of the week, you actually need someone to have like 2448 hours of that deep thinking building space, because that's where you get that continued progressive learning and it builds upon itself. Whereas if you're doing like an hour a day, or like a couple hours a week, you have these gaps. And then you have this context switching that makes it a lot harder to really get these learnings and insights. So to come back to your specific question, though, from that first demo, the first AI hackathon was three months later. And then this year, the company has been focusing a lot more on enabling folks to use cloud code to connect to all these different systems, and invest a lot more in skills. So that way, you're not having to constantly repeat yourself and do the same task over and over again, but rather have skills for each part of the software development lifecycle. So that you know, things you don't have expertise on, you can pair with cloud on it. It makes sense. Yeah, I'm curious. So it seems like the big unlock or like one of the biggest unlock was like connectivity. So like, allowing everyone to have access to in whatever tool they're using, either a cursor or cloud code to the tools where they actually work happens or the tools where the data lives. So you can kind of like, all of a sudden kind of get that magic. And then the other one was more on like, actually advocating for dedicated and prolonged build time. And to make sure that you actually can get to that aha moment, because like, if you do one hour at a time, you're just kind of getting like these like, glimpses. It's almost like it actually, when you were explaining that, like, I know you're big into silent meditations. It's like, it's probably the reason why, you know, you don't start with like a 10 day, a three day retreat. Because that's too short, you don't get to the aha moment, you start with like a 10 day retreat, right? And you can only do a three day retreat after you've done the 10 day. So that was kind of like where that hackathon idea was kind of bringing me back to. Yeah, no, that's a good point. I actually hadn't connected the dots there. To be totally honest, starting with a 10 day retreat is wild, but it was very enlightening and probably a separate conversation, if you will. But I think the big learning I had was as I was playing with these, yeah, in these short periods of time that you just like don't get enough there. And I think you hit it right on the head of like, the two big levers for the company have been creating more shared access to these tools and the connected data layers, but then creating that space, time and resources for folks to like really adopt these. And kind of the the mental model I had was like, you know, you can feed a man a fish and he can eat for a day, or you can teach a man a fish and he'll eat for a lifetime. And so the whole methodology of creating space and creating resources around this is really that teach a man a fish concept. So instead of just handing someone this prompt and chat to the team, like good luck, it's like actually pairing with them and walking them through that journey of like how to leverage this tool to write a PRD faster or how to query data. And then the next time they need to do it, they're not bothering you for a prompt or asking for your expertise. They've learned, they've built that muscle and then they can build upon it and grow their skills and leveraging these tools to do work faster. I'm curious, like, I think, I mean, it makes total sense. And I think that it sounds like the hackathons have kind of been a very important ritual for the organization to kind of lean in, see what's possible. Like you said, build, create that uninterrupted, those uninterrupted blocks of time to go deep and really explore. So my question is, do you think that the hackathons will continue to have this kind of like disproportionate impact on the org moving forward? Or do you think that they're almost like a little starter log for a fire and kind of like once you do maybe two or three hackathons, everyone kind of gets, you know, basically people get the message, they know it's possible. And at that point, it's kind of like everyone's off to the races and they know how to fish. Or do you think instead, the way you're read on the organization is like these will continue to happen and basically they're a forcing function to always like check out the latest stuff. So it's not about working with like AI in general, but it's more like maybe the next big wave is going to be using agents and maybe like everyone's using AI now, but maybe not a lot of people are using agents to like automate certain parts of their jobs. So maybe like that's whatever the next flavor is of the latest wave of innovation is the thing for the hackathon. And you guys want to just keep doing hackathons as far out into the future as you could think about it? Yeah, that's a great question. I think the goal is that this is a ritual that you keep doing. So the first hackathon was like proof of concept, let's see if it works. And we have a commitment, at least for this fiscal year to be doing them quarterly. But think how much things change in like two to three months, right? So nine months ago, right, people are still talking about prompting their agents. Now, we're talking about loops, right? And how you're not even prompting the agent, it's just kind of like knows where to continue, and you're just building loops for it, right? So to say that you do a hackathon once or twice, and then you're done, I think, misses the heart of it, which is, this is moving so quickly, it's impossible to keep up, like even the folks that are in the industry are overwhelmed with like, how to stay on top of like the latest trends, the latest technology, etc. You need that dedicated play time. And so right now, at Gusto, we've always done like company-wide hackathons, but that was like once or twice a year. And so this quarterly methodology right now, that helps you to stay up with the trends, right? Because every two to three months, Anthropic or OpenAI release a model that just blows your mind. And it changes how you approach everything. So for example, when I was using Cloud Code a year ago, it was really good for like, some basic coding work, right? It was about comparable to cursor. And then now it can control my browser, right? So I actually like had to put together a presentation the other day, and I needed to get certain clips of customer calls as a representation of it. And the interface in which I was interacting with, I couldn't click download on the audio clip. So I was like, how am I going to show this to my execs? I sat with Cloud Code and opened up a playwright browser to go and actually download that clip for me through the network tab, right? And so that wasn't doable a year ago. And so if you do hackathons, and then just stop doing them, you're not going to keep up with like, how the agents and how the models are improving. And you'll keep doing things like yesterday, as opposed to where the puck is going. Do you think that's a fundamental kind of like reality of just being in a full-time role at a company? Because like, the thing I'm thinking of as you're talking is like, why are hackathons necessary? And why don't companies just start giving or empowering the employees to carve out more ongoing time for themselves, like whenever they feel like they need it or something, you know? Like, sounds like... I'm just curious to get your take on that. Like, why does it have to be a top-down kind of like... I'm not saying it's top-down, like it's forced on people, but like, why does it have to be this like, organized company event versus something that everyone can just do when they want to do, like to tinker? Yeah, it's a good question. You know, having the dedicated time worldwide is also super important, not just for like calendar blocking, but also because pairing is so important. So if I go and do it on my own, that's great. But the value in sitting and pairing with other PMs, especially like folks that don't know it as well, pairing with someone who does know it better, that's again, that teaching a man how to fish aspect again. So if you sit by yourself and you're not feeling confident and don't know where to go, you hit a dead end. But if you're pairing with someone who can help unblock you and help kind of push your mind towards the new way of working, that helps both of you keep evolving. Yeah, I think that makes a lot of sense. And I think there's some people that are more lucky that maybe like, enjoy this and have free time to do that type of work. But I think other people is like, you know, they have a shit ton of things going on, maybe a couple of kids, they feel behind on their job. And it's like, hey, it almost feels like counterproductive to spend this time or it doesn't feel obvious. It's almost like why a lot of people struggle to prioritize strategy work, because it's like, there's no immediate like short term return. Obviously, it's very good for long term. But like, I think our mind is very good at convincing. I say like, is this urgent and important? And then, you know, for all the things that are important, but not urgent, we're just gonna just put it on the side, because you know, we don't have to get out. And I think, unfortunately, that's kind of how a lot of human brains work. Yeah, no, I mean, like, what I'm what's coming to mind is like, I remember, I think it was like in college, maybe where I remember some professors kind of being out for sometimes, like maybe once a semester, once, twice a year or something like that to like, do continued education, where like, they go to some seminar. And I remember also an investment when I was in brief stint in investment banking, like sometimes people that have certain licenses have to go and like stay on top of the latest, you know, rules and regulations and whatever. And it's kind of like sounding like, because I knew, I know, fundamentally, like those seminars are not making them almost like immediately better at their job, but they're helping them kind of like stay up to date, you know, with like the latest, like, for example, if you're a surgeon, and there's a new medical procedure that comes out that you want to learn how to do, you got to go learn how to do it. And then, you know, you'll be able to do those surgeries. And if you but you would not if you didn't get certified on them, I guess. And I guess what I'm getting to is like, I'm wondering how this all shakes out in the long term, if like, you know, all these upskilling from a technology perspective, are just like part of the basic expectation and like, where the dust is going to settle is like, there is no dedicated time for this stuff. It's like everyone's just expected. Like you almost like hire people who are just innately able to make the time to like learn the things they need to learn versus needing the dedicated space for it. Like, you know, it would be crazy if I took a day off of work, you know, three, four years ago to like figure out how to use the latest version of some other Google Sheets or something, you know, like, it's just like, you're just gonna use the latest versions of things and figure out how to use it. But now, the latest versions are so disruptive, I guess, to what's possible that it feels like we like just need to take it take someone off the line of off the line of doing their job to go figure out how to use this thing and then come back to doing the job. And I just wonder if that's sustainable. Yeah, I mean, I don't think I don't think it's like a new concept, right? Like I think people have gone to conferences or like seminars, like or like even like Bill Gates, I like his famous like Think Week and or like people taking vacation like a lot of people like successful people take like time off to like just like and I think part of it is like building distance from the work but also part of it is like using that time to like reskill yourself. I think that the big difference right now is like the consequences of not doing that and staying behind are much higher than they were before. Like I think you can just like really notice a delta between the people that are using the latest model or that are like using cloud code or they're using agentic workloads with the people that are still like freaking writing PRDs. are still like freaking writing PRDs still like manually, right? Yeah, but is anyone doing that? Is anyone, like, is anyone like writing PRDs manually at the moment? Are we like past that? But yeah, that was an exaggeration, but I think there's people that are writing PRDs with like chat GPT, but it's not connected to their context or data warehouse or I just think like, or even like design system. So I think like there's like a huge or even like they're gone or like, that's like maybe like the new kind of distinction. And I think there's just like a huge difference in those two states. Yeah. And to like add to this, right? So since we started doing the hackathons, like I hear you that like dedicated time sounds a little weird and maybe not sustainable, but like the biggest jumps that we have in AI proficiency amongst the AI work is directly around the times of hackathons. So self-reported metrics. I believe that. I have zero doubt that that's true. It's just so fascinating to me that that's what's needed. Yeah, go ahead. Yeah. Well, like the self-reported metrics, like before the hackathons, PMs felt, you know, 11% of PMs felt like confident using these AI tools. And since doing the hackathons, self-reported 83% feel like highly confident in using these tools. And the biggest jump is always pre post hackathon service. But I don't think this is unique to tech, right? So like growing up, my dad was a doctor and he would sometimes take time off to go to a conference to like, you know, refresh his skills or learn the newest pieces of parts of the practice. Right. And then he would come back to his patients and deliver higher quality care. And I know a lot of businesses maybe aren't having that dedicated time, but many businesses offer budget for taking a course like up level, right? Or they'll pay for a conference for you to go to. And I think, you know, I'm not going to tell everyone how to run their business, but I think in this age where the technology is moving so fast, it's advantageous to create that support for your employees to keep up because the dividends just pay for itself. Yeah, no, I mean, that makes total sense to me. And the other thing I was just thinking about as you're talking is it's, it's interesting how, because to me, what you're talking about is like, it is part of the job now. It's not like extracurricular. It's like this, this feels kind of like table stakes. And yet, I think the way, and you're definitely, you guys are definitely not the only company where I'm hearing this. It's like very common still, but like the idea is like, there's, I have to, I have to, I have to like pause the job to do this other stuff so that I can resume the job. And I think that that part is, I think the part that I'm kind of, I'm kind of wondering how that's going to shake out. Like the idea that figuring out how to use this stuff is not something that's baked into like the workday, you know, like I'm, I'm still thinking through how that happens. Well, think about, are you familiar with like Alex Hermosi? He has this quote of like working in the business versus working on the business. This is just working on the business, right? And like rethinking how you are doing the job. And sure, like take 10, 20% of your time building a business, like work on the business, right? And then like that work in the business goes exponentially faster and it's in a much healthier state. I mean, that makes, that makes sense. Like, and I love, I love that example actually. And Mark, I guess when I think, when I think about the way we work, I feel like maybe I'm just used to like a little shorter cycles because we're just a two person team. Like we don't have a larger org around us. We can, we have, we have access to all the tools we want to use. So for us, maybe it's like we, every two weeks it's almost like we step back and work on the business and then we go into like a two week period maybe where we work in the businesses. Yeah. Or ongoing even. Sometimes it feels weekly that we make that altitude shift. Also, like I think we were in a very unique position where we don't have any like internal pressure or any external people that are telling us, hey, here's what we expect from you. So I think we, we're kind of like already designing a way of like, Hey, we're high agency and we can think about what we want to do. And I think that's not the reality of most companies. But I mean, when you were saying that, Ben, I was like thinking, like, how is that different from like performance reviews, right? Like they happen every six months. Like you're doing, everyone is doing it at the same time. Like in an ideal world, like you would be giving and getting feedback all the time because like, you know, like you want your team to be better. You want yourself to be better. But like, again, it's like, I mean, I personally don't believe, I mean, that's, we could spend time on that. I knew you were going to say that. I know you were going to say that. Yeah. I think, I think, I think structured performance reviews disincentivize ongoing feedback. And I think they actually make the daily dysfunction worse. So I, but yeah, but, but, but, but the reason they do it is for convenience. I mean, the reason companies do that is for convenience, because it's just easier. Just tell everyone, do like, some people want to get promoted. Some people need to get raises. Some people needs refreshers. Like there's all this stuff that has to happen. So it's like, why don't we just like create a cadence that allows us to like make these decisions instead of on an ad hoc, ongoing basis. We do it. I think, I think there's like a lot of different ways you could cut that. Right. And like, you know, different companies do performance differently, right? Netflix has a flavor, Gusto has a flavor. But you know, not speaking too much to whether quarterly or not quarterly feedback is helpful. I think having the dedicated time to sit and reflect is like very important. Not everyone can afford to just sit and reflect every day and then incorporate that. Right. So that's what we do with the hackathons. That's probably what many companies do with performance reviews. But I hear you. It's like, it's definitely a new mental model to sit and think about like breaking this out as isolated from the work. But honestly, like the way we've been building the hackathons is like, it's not throwaway. Right. When we did our second hackathon, which was building a prototype, people were prototyping stuff that they were going to ship to customers. And like outcomes of that were like actual product releases. That wasn't going to happen in just the day to day work. They just did not have the time and space. But through that dedicated time of practice and reflection, now this really awesome customer feature is going to come from it. So that's actually a really important point that you just brought up. So like every altitude of the org chart basically participates in the in the hackathon? Yes. Because at this point, we still have like different levels and different levels of management. Like everyone is expected to be a builder. And so what's come from that, it's been a ramp to this, but like my skip level boss, for example, has built an entire dashboard that shows everyone's every team's KPIs and their roadmap items. So he just like has kind of a Jarvis like end to end view of like what's going on in the org. And it's really, really cool. And then my boss has built a bunch of prototypes that have influenced kind of how some of our teams are working, has also created his own LLM wiki that auto updates what our team is doing in the performance metrics. So that way, when we have to report out, we can just point to markdown files. And this is all come from having dedicated hackathons on time. So no one's asking the PM, so like, give me a status update on what you're my, by the way, my last full time job just for reference was like two and a half years ago. But at least until that point, people are still asking for like updates, you know, on like what your team's working on, what's the roadmap looking like? Are you saying you guys have basically created a self serve tool for executives and members of the org to just get the answer to that question on any team that they're interested in? We are marching towards that. That's actually the focus of our next hackathon. It's like very dedicated on like LLM wiki and basically optimizing how you do reporting and knowledge management across your team for that makes it accessible. I've been like doing different flavors of this ever since I started using these tools. But you know, even in my day to day, I got to ship product, right? And then my secondary job is shipping quarterly hackathons. And so I haven't had as much time to build out as much of a robust, you know, LM wiki style setup that I want for my team. And so we have a dedicated work week coming up where we're all just focused on like learning and building. And we have another hackathon coming up. And my goal for these two time periods is actually to build out my team's LM wiki and the loops for auto reporting on how the product is performing and auto generating the status updates so that I can focus a lot more time talking to customers working with my team, applying taste to the product direction rather than the monotony work of like rewriting what's going on in my head into like this status update or that status update or having to like rewrite a query. I just want that to happen so I can really focus on the customer experience. And so everyone's building their own flavors of that to ladder up into it. And we're starting to formalize that more. And it's really exciting because, you know, PMs just like have so many great ideas and have such a good pulse of the customer. And pre AI, so much of product was spent organizing things and people. And now with AI, where you can automate a lot of that, you can focus all that time towards customer and strategy. And that's beautiful and very exciting. I'm in and I do want to get at some point to like the I think it's like spicy topic within the product sphere, which is like whether PMs should be merging PRs. And I know like you are dabbling in that space, so I want to make sure we get there. But one final question kind of in this space before we start getting there is. So given that hackathons are such an important part to like kind of keep that like to increase that activation energy and get people using these tools, how have you changed about the way you onboard new employees, given that maybe you might be like three months from to the moment that they have their own hackathon experience, right? So like, how do you like make sure in those three months they're not like completely behind and lost and kind of like, you know, being cavemen compared to these people that are like in the future, the seasoned gusties? If you're enjoying this conversation, please check out the links in the show notes to support the podcast. Mark and I do this out of love, but to keep it going, we also need your support. Thanks. And now back to the episode. That's a great question. So every hackathon that we do, we record the learnings of all the different PMs and all the materials. We have a centralized repository of all this so that as someone who's onboarding, you can go reference how the organization has evolved and learned. And obviously, like you plug cloud code into it and it can summarize and go deeper into certain areas. And then, you know, the beautiful thing that the hackathons are happening every three months, and there's always a different theme. Sure, you haven't done the previous ones, but you're starting at like a similar level as everyone else for the next hackathon. Obviously, there's not endless themes. We'll have like repeat ones with like shipping a PR or repeat ones like optimizing your internal workflows better. But at the same time, because this is a recurring event and ceremony, just because you haven't done previous ones doesn't mean that the next one is going to be too difficult for you to do. We really spend a lot of time making sure that we have materials and education that span the different levels of fluency. So folks that are very new to it versus folks that are very technical or very in the weeds. Nice. Actually, I wanted to ask a quick follow up before Mark, before we change direction, which is, so obviously, like your onboarding period is their first chapter as like a full time employee. But like, I'd be remiss not to ask about the chapter right before that, which is the interview chapter. I'm guessing that the people that are getting hired now are going through some kind of like, I guess Mark used the term caveman, but you're making sure I'm guessing you're not hiring people that are completely AI naive, I guess maybe is the term. I would use the term less AI fluid. But in terms of the hiring process, are you asking how we are assessing that? I guess I'm just asking for your read as someone who's been at the company, you said a couple years, two years? Yeah, two years. If you've noticed any changes in just like the amount, the level of AI, the baseline level of AI fluency, let's say that just new members of the team come with. Just observations. Totally. So my observations, like when I started relative to now is like people come in way more fluent than like when I started, but also like that is an indicator of how the industry has evolved and how the technology has evolved. And in terms of like how we're talking to candidates, like it's a core part of how we interview. I can't speak to the specifics, but you know, we want to make sure that folks are able to deliver the best experience possible to our customers. And we know that like leveraging AI to its fullest is a core premise of that. And so it's just blended into the interview process and a way that we are thinking about how folks operate at the company. Got it. So yeah, you're mostly, so when someone joins the company, the parts that might be new or the parts that might have a steep learning curve to them are just like the exact flavor of AI adoption at your company or like the way that data flows or like the cultural rituals around it. But there's like a baseline of expectation that everyone knows like the basic concepts of like how to use AI to get stuff done. Yes, yes, exactly. And I think, you know, a lot of the principles that we have applied at Gusto and that we use like are not unique to Gusto, right? Like having MCPs is not unique, right? It's like a global standard. Being able to like have context in your code base is like not unique, right? It's just like Gusto's implementation of it. And, you know, Gusto has done a really good job of making sure that like that's all covered now. And so yeah, making sure folks are like understanding the concepts, have some experience with it, can speak to past experiences that they've done and how they would do it better with AI now is like very important for us getting the best candidates at the company. Makes a lot of sense. And let's talk a little bit about the PRs, PMs submitting, you know, submitting PRs and merging them. And because I think, you know, last time we talked, I think you said like something like crazy, like about 80% of PMs have merged PRs. It's about 76% of the PM work has merged a PR. And it's now, you know, a part of how we think about the product work, not necessarily like some crazy feature, right? But just developing that understanding of the code base and that engineering empathy is now like a core part of the role. Got it. Yeah. Yeah. And I think that's like such an interesting topic because like, as I was saying, I think there's like different school of thought. Some people are like, hey, like some companies are like, oh, absolutely. Like PM should be emerging PRs for features. And, you know, but I think the one consistent thing is like the review gate should be consistent with what was before. Like we should still be very like disciplined and like read it. But then some other people are like, no, like that shouldn't be like some people are saying like not all PMs should be submitting PRs because then if you submit like a PR that's like, you know, terrible code, then you're wasting like precious hours of like an engineering engineer who's like, you know, just should be doing other higher leverage stuff. So maybe those PMs should only be using the PRs for like copy changes or like quick UI changes. I'm curious, like where does Gustaf fall into that like philosophy and like what have you learned in that journey of getting more and more PMs to merge PRs? Definitely. So it's been an evolution and folks are learning. So we have everyone start small, right? A lot of folks come in having not written a lot of code before. And so for you to go do a database migration does not make a lot of sense. But like small copy changes or like changing colors or like small UX changes, like those are definitely within scope. And so that's where a lot of the education we've done for the hackathons has come from, right? We created the vibe code checklist, right, of like, you know, do these things don't do these things. So for example, it's touching a crazy number of files, you probably didn't do something correctly, like let's walk that back. But all the engineering review processes are still as tight as they ever have been. And so, you know, we do put some ownership and onus on the PMs and their respective engineers like talk and make sure that the PMs are following best practices and not using engineers time on some of the wrong items. So engineers are still very focused on like, bigger, higher leverage projects that are, you know, a lot more sophisticated. But I think now, when there used to be a ticket that would just sit in your backlog of like a copy change, so it goes stale, the PM can go do it. And it's like a minimal code change. It's like a minimal review. It's like very simple. And that helps the engineers to focus on these higher leverage projects. And so that's been really incredible. I think as PMs get more technically fluent, I have seen many take more sophisticated projects. We actually just did a case study with Cursor where one of our PMs builds a feature end to end with Cursor. And so they had an engineer kind of steering and giving some input from their team. But that was, again, the teaching man had a fish concept of, instead of just writing requirements and shipping it to the engineer to go build, the PM was basically able to go use Cursor to like navigate the code base, understand what's going on, have a proof of concept, check in with the engineer, get some feedback and have that loop back and forth. And then she ended up shipping that feature to production. And that was super powerful because, you know, six months ago, she could not have done that, right? Even three months ago, that would have been a stretch. And it was through kind of having these guardrails in place, having that support and education. And a lot of what the company's doing with creating skills for different parts of the software development lifecycle helps to codify that. So, for example, some of my engineers worked on a skill for implementing experiments and feature flags, right? So now as a PM that doesn't know how to write code, I don't really need to know or have to have done that before. I can execute the skill and it gives step-by-steps like if this go this direction, if that go that direction and make sure that it's configured correctly. So that way, once the data scientists and engineers are reviewing it, it's following most of our best practices and they're catching anything that slipped through the cracks. Yeah, I mean, that's super interesting. What was coming to mind for me is like, as you started, you kind of hinted that building loops is kind of like something that's you think maybe the next frontier, the next direction. So my question for you, maybe just personally, how you think about it, if you if let's say there's a task that you're going to bang out today or tomorrow, and maybe it seems like an isolated incident of something, you know, it's like a specific fix or a specific copy update or whatever. Do you have you found yourself pausing to ask yourself whether you should treat like the symptom to solve that one thing versus build like explore almost like increasing the scope to figure out what's what's almost like the loop that would run or what's like the guardrail or what's the end-to-end test that we could implement that prevents something like that from happening again or what's a, you know, like, I'm just curious how you personally You know, like, I'm just curious how you personally have been finding your brain, you know, navigating those, the scoping of these things to like a one-time task versus like, I should build the system or app that prevents this thing from happening again. Yeah, I mean, some of this is data driven, some of it's instinct, right? So like, in my current work, some of the loops I'm starting to build is like one like proactively checking slack for like messages around a product feature I'm building or products that other teams are building that I like have a stake in and need updates on. And I want to like proactively like have knowledge on that and update the team. But I also want to be building loops that are reporting out on data dog on, you know, amplitude, etc, every day, and starting to synthesize that data so that an agent who is looking at it can be like, okay, here's a pattern we're seeing and then file a ticket on it. And then what ends up happening is my team and I, and this also, this has been like me thinking about it a long time, but then also listening to like, Forrest Churney and Peter Steinberger talk about it, then what we end up doing is focusing a lot more on like taste and like prioritization. So what should we do next? Like, where should we start to steer the loop and the agent to like keep building and talking to customers so that we can get that information that's not inherently obvious from a dashboard that an agent can detect. But even then, like you start building that ritual of talking to customers constantly and having transcripts of an agent reviewing those transcripts can start to detect patterns and have another loop of feedback into this should be a feature or this should be a fix and then prototyping that, partnering it, shipping it, right? And, sorry, maybe a stupid question here, but what is the,