Ep. 10 - 800 Pound Elephant with Isaac Takushi | Devs:After Dark

When that becomes a thing, if I— I can't, you know, not, not in episode 10. I mean, come on.

We just won't add you to our nature programming.

Yeah, okay.

I'd be the worst David Attenborough in the world. A lot of user error going on here. I don't know, I'm just saying it's Good start, D.

Good start.

Doing my part.

I don't know about you guys, but I guess I just can't leave again because apparently—

The return of AJ.

It's everything. I was gonna say—

no, I was gonna say the last 2 weeks were fine. All of a sudden you get, uh, AJ back and then technical difficulties start springing up all over the place.

Yeah, and I do just want to say to, to Carter— Carter, I am a real person. I know I haven't physically met you yet. I'm working on it. I'm working on it.

He's a real person.

At least you didn't butcher his name, so don't— you're not doing too bad.

Yeah, I know. I definitely watched while I was not here and definitely laughed. I took notes, don't worry, I'll send you some.

I don't read well, so it's okay. But nevertheless, we are in double digits. This is exciting. We are on episode 10 of Developers After Dark. I am your host, Nick, as usual. With me is, well, not as usual, but AJ is back. Dennis is on the technical difficulties and we have a very special guest and friend of the show. But before we get into it, let me pay a couple of bills real quickly and just mention that if you didn't catch the DeHug about building a more accessible web experience in 2025, that is now up on the Developers YouTube channel. You should definitely check that out. Dennis, do we have another one coming up soon?

Yes. So the hug, we have technical SEO and performance coming up, followed by a CMS React. Uh, we're going to talk all about the Elevate theme basically for that one, which is going to be pretty cool. Uh, I think we need to do more of that. And then, um, SJ is actually taking over. It's, um, March is, um, a month where I think we celebrate the women of the world. And, uh, we're— the developer hug is being taken over by SJ and team. And, uh, she's gonna do a special thing there. I have no details about it, but I know it's happening. Then beyond that, oh my God, I'm starting to schedule things out. I'm going to be focusing a lot on AI in web development. We got one with Replit, Isaac knows them well, followed by one with Postman, and I'm working on getting Cursor in after that. I'm trying to hit them all.

That's huge. Thank you. That's fantastic. Speaking of the Element theme, a spoiler, we're going to try to get no pressure on the team, But we're gonna try to get some people in on the show as well to kind of talk about the creation of that theme as well. That should be— we're working on that because I think that would be pretty beneficial for everybody to kind of get an inside scoop about the whole creation of that. So, um, speaking of the YouTube channel, if you're around and want to take a look at Brooke, just dropped her first video in February about creating custom emails with the drag and drop sections. So you should check that out. That's something really, really fantastic. When those were in the marketplace, I used to review the email templates and You know, it's, it's come a long way since then, so there's a lot of really cool things to check out. So if you have a minute, go over to the HubSpot Developers YouTube channel and check some of that out. There's a lot going on, so don't feel confused, don't feel overwhelmed. Just go to the developers changelog at developers.hubspot.com/changelog. You'll be able to see some of the new stuff coming out, some of the new things happening, and you'll be able to keep yourself up to speed. And one final thing for those listening, Your coworkers are laughing at you because you're bad at coding. Do you want to fix that? Well, you can. That's the Academy for HubSpot. And as Dennis and AJ laugh at me for my bad code, you can always go to academy.hubspot.com. You can learn anything from inbound marketing to improving your website performance. And there are courses on there with certifications as well, and you get to humblebrag those anywhere that anyone will read. any of your posts. So that's always awesome as well. I myself have done some of the SEO ones, so it's, uh, definitely something that you should look into and take advantage of because it's something that HubSpot does for developers.

So— Oh, Nick, no, just once again stopping you right there because my golly gee whiz, you've certainly upped the game.

Yeah, you're sounding like a real podcast host here.

Was that a commercial? Did you just get paid for that?

I just, I just winged that. That was pretty, you know, I remember because I remember the inbound marketing one was one I wanted to take and Improving website performance was one. I didn't take it at HubSpot, but I watched that one because I'd done something similar somewhere else. But yeah, I— this is kind of— this is how my brain works. So I mean, it's okay, you get to bask in the greatness. It's all right, I won't charge you. It's cool.

What you don't see is off to the right is the mirror that he practices in.

Yeah, or the lighting that I have set up for eventually, you know, it's fine. I'm working little by little, gradually.

It's up and off screen.

I'm working on it gradually, little by little. But, uh, with that all said, what we'll do next is— there are no corrections because we're great at everything we do, so there's no really corrections. Uh, and any notes from the management, we don't really have to worry about that because we technically have the team lead for the Ecosystem Quality team, which I am on, with us as a guest today. So without further ado, I will let him introduce himself and tell us who he is and what he does.

Thank you for having me, Nick. I'm thrilled and honored to be here for the 10th— double digits for Developers After Dark. I can't believe we're here. My name is Isaac Takushi. I am the team lead for the ecosystem quality team here at HubSpot. So Jana, you heard from last week. Nick is here. You may have worked with us in either the template marketplace or the app marketplace. We often will be working with you to make sure that your app template, whatever solution that you're publishing, meets our general guidelines and standards. That's all in service of the customer and making sure that you're putting your best foot forward for your creations. We love partnering with you. We love being in the DevRel family, playing off of the strengths of the Dev Advocates as well as the Solution Architects, SJ obviously in the community as well. We just try to create a tapestry of programs, for you to make sure that your impact is great.

Absolutely, 100%. And it's, I gotta say, it's probably one of the most exciting kind of roles that you can have just within like DevRel in general, like ecosystem quality and all of these things. And actually how they tie together too, right, with the dev advocates and then the community and events, all of these things, they kind of, it's crazy how they just kind of seamlessly like weave together. And then they create these type of systems and these things to like help benefit. It's just, I, I can't say enough. And it's not, you know, it's not, it's not me just kissing up, but it, it really is. It's just one of those things where—

It just really is you kissing up.

No, it, it really is like the way things come together. A fantastic— I don't know, you just really can't ask for things to work in conjunction together any better than they do.

It's almost like a butterfly effect. I don't know. I don't know.

Just putting that out there.

Well, it all happens because of, of the work that we do and like that, you know, kind of kinship and, and partnership that we have. Um, I know your first episode, I think, dropped right before you, you kind of shared it with the team more broadly and say, hey, we're starting this new thing. Um, and I'll admit that I was a little skeptical at first, but I see even in the first couple episodes, like, what the, the promise and possibility of this can be. And I think this This podcast is part of that tapestry and pulling together the voices, the programs and things, and creating kind of an interface for our community.

So I'm glad somebody thinks this is going somewhere.

No. Yeah, it's hard attaching Dennis's name to anything. There is the skepticism.

It's true. High risk, high reward, my friend. High risk, high reward.

It's a good way of looking at it.

I don't think I mentioned Dennis in most conversations because I don't want it to go bad.

Like, it's just, you know, that's a safe bet.

Well, Okay.

All joking aside, every superhero has an origin story. So, Isaac, why don't you tell us, how did you first kind of get into the— we'll call it the technology/developer sphere? Like, how did you first get an interest in it? How did you first become aware of its existence?

Yeah. I certainly fell into tech. So it's not a secret for many of you, but my whole career has actually been at HubSpot. I've been here for 8 years and change, started right out of college in customer support. And the reason that I started in customer support is interesting as well. I studied environmental science, technically environmental studies, but I say environmental science because that, that's the more common term. Environmental studies is the interdisciplinary application of science and policy and all these things. But I knew that I wanted to do eventually something with kind of environmental startups or regulation or something like that. And the way I saw it kind of leaving college was there are a couple of paths. You could go NGO, you could go business, or you could go you could go governmental agency, kind of, or academia for that matter. And so in my final years of college, I was getting involved in kind of the startup incubator at my college, thinking about how startups, not exclusively tech ones, get going with an idea, you know, get funding. And I was really interested in kind of applying some of my passion and knowledge around environmental sustainability to business because I see business as both one of the major machines in our world that is both detracting from sustainability and also a really powerful mechanism to drive that at scale. So I thought, okay, naively, I'm going to learn business from the inside. I was thinking back to Jana saying something in the last podcast, which is she studied business and she said, I'm going to do business deals. In after college. And I just laugh at that now and think, you know, like, what is business exactly? I thought HubSpot was a startup at that time. And the reason I heard about it was it ranked highly on best places to work in Boston. I thought I wanted to be in Boston. The college I went to is in New Hampshire. And I thought, okay, want to be relatively close by, like move to the city. and learn from both a company that's well regarded but early in its development. And I thought it was kind of a startup phase I was going to be in for a couple of years and then go off and do my own thing. I was waiting for inspiration to strike for a new environmental technology, carbon capture or something like that. So I ended up in support because I had a friend who was a year ahead of me and kind of referred me in. He's since left HubSpot, but was placed in the New Hampshire office, the Portsmouth office, which is RIP, no longer, no longer part of the HubSpot ecosystem, but met some of the people who have really shaped my journey, including some of our own team members. 3 of our team members are former Portsmouth support folks, where we started in the trenches, as we call it. And so I started with HubSpot in tech. I had no experience in college, but I quickly learned that I had a mind for technical problem solving. I really enjoyed thinking through problems and thinking through systems and applying some of what my understanding was of natural systems to technological systems, which I'm sure will be a theme. of today's talk. But I really fell into it as, hey, I just want to work. I want a job. I want to work for a company that's decent and get a start in business. And I quickly learned that I have an interest in technology as well.

Did the customer service aspect of it kind of start to garner the whole— because I mean, a lot of times at HubSpot we talk about having empathy and obtaining empathy. Did the customer service aspect for you kind of help bolster that? Because I know for me, I didn't start in customer service even when I worked in real estate. Dennis, roll the eyes.

But, uh, you made it, uh, 10 minutes in 13 minutes.

Right.

I tried, I tried to hold it off as much as possible. But, um, it— there was— it wasn't until— and it wasn't customer service from that respect, but it wasn't until I started interacting with the actual users of like the, the real estate website or the CRM and things of that nature where I really started to understand people versus being an ID, you know, and then actually starting to understand. And then as time went on too, like, you know, you either if you're renting or if you're looking for like a place to live, then you start to understand, oh, what I'm doing affects that process that now I'm going through. So did you get that kind of from the customer service access of HubSpot? Did you get that?

Certainly. I think that, and I think this is probably the case today too, that a lot of the entry-level HubSpot positions, especially support and inbound sales as we call it, are looking for a certain type of character. You're not gonna bring the SaaS skills. You're not gonna bring, in those cases, likely coding ability and real technical background. But if you are the type of person who likes to help people, Who is empathetic and a good listener and likes to solve problems and try to get to the bottom of something, is curious. These are the types of things that HubSpot certainly draws a lot of folks in from. And I was with like-minded people in— none of us knew what a CRM was before joining. We were often, most of us in our first job, first customer-facing role in an adult kind of company. I've had jobs elsewhere, but this was my first career job. But with that foundation, building technical acumen by drinking from the fire hose, as we say. So, just forced to get on a call or a chat. We didn't have chat back then. We had just email, web tickets, or phone calls. And a little later we added chat. Getting forced into a situation where you're this empathetic, like mostly millennial, you know, kind of still afraid of talking to people on the phone and forced to ask questions of someone who has been running their business for a while or is much more experienced in marketing or sales than you will ever be and trying to work through to the root of the problem. was a really good way to flex that empathy, but also kind of learn about the technology from the inside. So in that way, I think I've had a very different road to learning about software than others who grew up tinkering with— I'm hearing people coding their Commodore 64, whatever it is. And I did not have that. journey. I was looking through natural sciences.

That's—

that was always my passion. And realizing in an environment like HubSpot, you can apply a lot of that same thinking to technical problems is where I've come from. And learning it from the inside with like trying to ask questions of someone who understands this technology way better than you to try to get to the root of what the issue is, is it— is a different way of learning than like tinkering and building. It's kind of tearing it down and seeing how it works from the inside, but both legitimate ways.

No, 110%. Yeah. What now? Was there any— because you did mention, I remember you had written down and mentioned that there's a little bit of programming that you've done right there. So it's— there's— there are some aspects of it that you have touched on here and there. What were some of the things that even if it wasn't something like— because there's— I'll be honest, like there's— I mean, there's plenty of things to choose from, but like There's certain things where it's like, I may not have actually programmed it, but either have the knowledge of it because I've witnessed it in action or just had to look over it. Or so what are some of the languages that you've kind of worked in or worked on that have really kind of helped? You know, it's kind of helped like reinforce some of the stuff that you're trying to like, because you're trying to solve for something. Because like, I'll be honest, like when I first got here, right, I was trying to solve for quality with themes and modules, not 100% knowing at the time, like from day one, like how everything— like I wasn't an expert in Hubble at all. Like I was aware of Hubble. I'd seen it. So like, were there certain languages or certain things that you've either attempted or come across that have helped you where you've looked at it and said, okay, I'm starting to understand this and this is helping me with some of the other things that I've seen?

Yeah, I'll say that most of my experience has been at HubSpot, and I'll talk about that a little bit. But I know in that kind of pre-questionnaire, I mentioned a little bit of dabbling into Swift. So the earliest foray that I had was honestly in my later part of the senior year in college, where I was in this kind of startup. It was both a kind of club, but also a residential community. So we had this whole floor that we were living on together, and we're talking about We had these programs that were run. There was a space that we could go to and hold meetings. And there's a pitch competition that's every— we call it like term, but it's a quarter basically of the school year rather than semesters. And I wanted to do a— had this idea of doing a gamified productivity app for At the time, I was actually diagnosed with ADHD. I don't know if that's actually true, but at the time, I was really into learning about that and thinking about ways that I could make myself more productive and help others at the same time. Again, no coding experience, but had this idea of, okay, gamifying tasks to keep yourself organized is something that I struggle with and could be an interesting way of, of kind of motivating myself. So it was this idea of, um, it was called Duelist, which was like a play on the to-do list, but it's Duelist as in, like, uh, Dungeons and Dragons or some kind of RPG where you're like dueling this big project and you're like trying to knock down this, the HP through the organization and prioritization of tasks and trying to keep that on task and gamifying that. No, that was the concept, but no experience coding at all. So I started learning just on Treehouse a little bit of Swift and honestly didn't get very far by the time I had to graduate and start to look for a job. But that was the very earliest foray into thinking about technical problems. And very quickly in support, you have to learn JavaScript, a little bit of Hubble, Early on, I kind of gravitated toward an ads specialization. So learning how JavaScript was communicating with Google Ads, and it was primarily Google Ads at that time, which was a pretty undeveloped part of the HubSpot product. And so seeing how more sophisticated users could extend the— we weren't really calling it the platform at the time, but extend the way that HubSpot was communicating with these integrations, how you integrate that signal to the Google Ads event in your form submission upon load, and then a little bit of how you incorporate that into the CMS or COS as it was called then. So learned it as necessity, but then developed into, okay, I really kind of like this technical troubleshooting. I seem to be decently good at it. Started developing the APIsec persona, which is my internal handle to this day, and joined developer support, which was at the time a new team where we— if you've been on the community for a while, you may have seen many of my older posts. I have not contributed in years. Dennis took that crown certainly. But developer support was a formal team and we hope to bring it back. But we were staffing the community forums as well as the Slack to a lesser extent and also serving as what we call product experts internally, which is tier 2 support. So I was fielding questions about how JavaScript functions were not were not triggering or how people could do basic calls to the API. And so again, I've learned some of the HubSpot technology and some of those technologies from the inside. Even without, I still wouldn't consider myself a developer, but—

Oh, I think you, you are. And I just wanna like another plug for the support team, 'cause I feel like that is where you can come in as a developer prior to this, like you did, Nick, and just have like a Very set perspective, but the support team, man, like that's top of funnel, right? That's like everything HubSpot does all at once, all the time. So you get to see the perspectives of every aspect of the product, which I think is a huge game changer in how you think about coding or just working with HubSpot, generally speaking. Like me personally, prior to being at HubSpot, you know, I did a lot of just website development and didn't think about the CRM aspect of it at all and how these things tie together. What am I doing? Why am I doing this? All that good stuff. I'm just building a pretty page, right? And someone else is dealing with all the other stuff. I wasn't thinking about how to really optimize it for the other stuff and how to make it just more accessible for that.

I gotta say too, kudos with the technical problem solving, uh, Isaac, because it, it really does show. And then even your example with the, the gamification or the gaming, you know, aspect of And the reason why I want to bring that up real quick again is because like my son actually for his math does that particular kind of aspect. It is kind of like a Dungeons and Dragons where in like in order to move to the next thing and knock down hit points and stuff, you have to answer math questions and yeah, it's task-oriented.

Mm-hmm.

So even early on, like your technical problem-solving skills were already like, even in their infancy, were still probably leaps and bounds above because that's literally what the standard kind of is right now. And you thinking about that long before. So kudos on that, because that is something where, uh, it's, it's something you can try to learn, right? It's something you can practice. But, you know, there are people— and this is also a tribute to you as well— it's like there are people that you speak to where you can just tell they get it, that their mindset is that, right? There's people that try. I mean, I'm not perfect at it, but people try. But there are people that you can speak to where you can say OK, this is somebody that is not— it's not just goal-oriented, but it's task-solving. That is, it's in the conversation. You just know that's where we're going with this, where people like me can ramble and talk and go on tangents. And sometimes it gets lost, but I get there. But yeah, it's just one of those things.

Do you, though?

Do you? Google Maps. Google Maps.

By the way, everything you say that compliments him, I feel like you're just trying to save your job at this point. You know, like, I can't take that lens off.

That's okay.

That's fair. Because when Chris was on—

It is performance season.

Can I submit this video as the thing and not even get a review? Just be like, here's the video, see all the nice things I'm saying? Is it that kind of deal?

Well, we're all problem solvers, and especially like in this kind of broader ecosystem that we generally operate in, it's like with a technical bend. I will be the first to admit that I'm pretty impatient when it comes to the heads-down technical problem solving in the code. I like to think strategically about a problem, how to break it down into manageable chunks.

Mm-hmm.

And I have realized over time that is one of my skills. I can see farther ahead than a lot of people, or I like to think. And I like to draw upon the strengths of others to try to get it done in a team-oriented fashion. And that was the case for that app idea, as well as some of the other clubs I was involved in before joining HubSpot. But thinking about problems and breaking them down into solutions is you're building, whether you're doing it with the code or with programs, or with people. Little hand wavy there, but that's my connection. I really enjoy the putting together of like, Nick, you bring a unique set of skills to the team that cannot be replaced by anyone else. In concert with everyone else like John and others, we are able to achieve some really remarkable things which are not dissimilar from if you go down to an individual app or the services that make it up. what they do and what they're optimized for and how they work in concert together. And what I see as one of my roles is best at, like, seeing what the strengths of each of these people or systems is and putting them together in a weird and creative new way that solves a problem.

No, that's beautiful. Dennis, I'm going to need you to clip that first part of that where we talk about how good I am. Okay? Yeah. That way we can run that as a sound clip whenever.

Sure, sure.

I want to feel Good about myself.

That was a good Times Square ad right there.

You're very, you're very strategic in the way you think. Because I remember during Pure Week, we were chit-chatting and you had mentioned playing poker and like chess and stuff like that because of the strategy portion of it. I remember you saying like you were really involved in like, like you enjoyed those types of challenges that are like strategy-based. And it definitely shows. Like, I know you and I've had strategy conversations before about stuff. So yeah, no, it's, it's definitely a skill that you have for sure.

Thank you. Yeah, I hope to guide the— continue guiding the ecosystem quality team with that in mind. And I'm sure we'll get into some of that too.

Have you— has your mindset shifted in terms of, is it like less technical, more people, or is that just the same thing? You know what I'm saying? Like, are you looking at it a different way now, or are you growing to look at it a different way?

Yeah, I certainly have. I've had a couple of different careers at HubSpot, as I mentioned. So After that developer support phase, I did realize that I really enjoy working with technical people, helping people get unblocked, and was one of the original members of the then certification team, which has since transformed into ecosystem quality. It's the same team, it's just renamed and broadened in its scope. But the way I think about it now as a people manager is, optimizing for the folks who I have a vested interest in. Outside of just the work that we do, I want to lead the most fulfilled, happy team at HubSpot. And I want, truly, I say that pretty frequently, and not to knock the developer advocates, but we draw a lot of inspiration from you. And I want DevRel more broadly to be the most highly effective and happy and well-balanced team. At HubSpot too. So it's not a competition. We just should all lift each other up. But yes, I do think about technical problems at a higher level now and have to look farther ahead than like, okay, the very reactive mindset that you have to be in when you're in support, just out of necessity.

Mm-hmm.

Yes, you should know what that new beta API is that you're answering questions about, but You won't know necessarily what thing is going wrong until someone reports it to you, and then you're going to be reactive in how you solve and react, escalate that accordingly, try to put solutions in place for it.

I asked the same thing to Chris, by the way. How do you make that transition? Because that's a tough one to stop getting out of the reactive phase of things. How did you make that? How are you making that transition?

I'm still having to remind myself each day, It's probably better to delegate than to jump in myself and come up with a hypothesis and then say, this is the way we're going to do this for the team. I've been asking more of the team to say, okay, Nick, you're the subject matter expert in this. What's your recommendation? And then help kind of shop that with the team. So it has certainly been a struggle, but I always base it in kind of the empathetic foundation that I mentioned a lot of host otters have, and realizing that you bring certain things to the table that you're really good at. I have recognized what those are, which is bringing different voices and helping coordinate and orchestrate them, and seeing hopefully multiple steps ahead and seeing generally the direction that we want to go and not having to be concerned with me making the call on every single step to get there. But the general direction.

It's a hard, it's a hard habit to break to try to like not be hands-on on everything, right? Because like, you know, I coming from like a place previously that was a smaller team, it was like you were the delegation. Sure, there were certain things you could delegate, but like usually you'd be the person to jump into it. And especially if you, not even just if you're in that situation, but if you also have the mindset where you want to problem solve and you want to get in there and you want to get your hands dirty and do it, it's a very, It's a very hard thing to separate out, you know.

Mm-hmm.

And the question I— the next question I wanted to ask you is, with all of that, right, so not only are you technical problem solving, but you're trying to delegate amongst, I would say, um, uh, an atmosphere where there are multiple, multiple, not just programming languages, but conceptual items, whether it's what as broad as like, hey, AI quality, what do you think? Like, okay, can we be a little bit more specific? Like, you know, it's, you know, to that, to like down to the very, okay, theme, language switcher, this particular, like, what are some of the ways that you kind of, um, or I should put it this way, what are some of the things that you do to try to keep up with the surrounding elements? Like the, like, for example, like newsletters, things like that. Like, what are some of the things you do to kind of keep— On top of some of that? It's because it's ever-changing, obviously.

Yeah. I will say that I've been consuming a lot more of the traditional technical articles and stuff since midpoint last year with the explosion in AI. ChatGPT was obviously before that, but especially since HubSpot is going in that direction, I knew I had to keep up to date with this very rapidly changing space. Honestly, before that, and this kind of broadly encompasses my philosophy, especially on quality, is try to boil it down to the simplest principles, especially when it comes to the impact on the customer. I tell the team all the time that this is— yes, we are in developer relations. We do want to enable all of the community to build better. Ultimately though, our focus on ecosystem quality is ensuring that the things that are built are safe, are productive, are valuable to the customers. If we focus on that as our North Star, we're going to better enable developers to get there and do it in a way that is not hopefully overly onerous, is not constantly changing. If our principles of, for example, least privilege in applications is that is the principle for customers. What does that mean in an operational way for how HubSpot Auth works or how the APIs are interacted with? And then we kind of start to settle on some of the details. So I always start with the principle of the value that we're trying to create or something that we're trying to do for the customer. What is valuable to them? And then how do we work back and what does that mean in technical terms rather than starting with the Technical things are changing every single day, but generally the principles are going to change much less frequently. Start with the principle and then work back in abstraction or less abstraction to more specific details. How do we put programs around that to make it a balance between what the value that we're trying to protect for customers and how do we enable developers? Next slide.

No, it's the perfect way to do it. And the proof is in the pudding. It is working because, you know, we are doing like some of the things we're working on and some of the things we're doing with that approach is mildly successful. No, very successful. It's very good. I wanted to ask you just about, because I know that Dennis was also at this same event, but as Does it— in the same theme of like keeping up with things and, uh, you know, like how to kind of recent events and things of that nature, um, what were our— have you been to any like conferences or anything like that recently? And mainly because I want to get dirt on Dennis.

Sure.

Um, have you been to any conferences recently or anything that's kind of like really kind of sparked your interest or that you've, uh, experienced that has, uh, kind of helped bolster that kind of problem solving?

Yeah, so we both attended the Replit HubSpot Code Jam in San Francisco in early December. I know that's been talked about a couple times, and that was— I haven't been attending as many events recently in last couple years, but I hope that changes this year. I certainly will be attending Inbound, and I see this as a way not only for myself, but also for the team to kind of reemerge on the HubSpot developer community scene as thought leaders in quality. We have for a couple of years been pretty behind the scenes and that has been intentional. I've been the senior member on the team and I take this, this will spark a whole other part of the conversation, I'm sure, but it's not a— It's not an accident, it's not intentional, but ecosystem quality, EQ, or equality, like, it kind of underscores what my philosophy is, which is we within DevRel, our unique role is to ensure that customer value and enable developers. But sometimes that can be more of an enforcement motion. It can be more of a, like, good cop, bad cop to the dev advocates, good cop. It's like, we're okay being the bad guys. I'm okay with being the bad guy. In terms of at least putting guardrails around what can be done to ultimately protect the customer. And again, that is not in a punitive way, but it's more to— there should be guardrails around certain things, and that's all in the effort of making value for everyone. I have a curiosity.

How do you decide these guardrails? And what do you— I mean, at what point are you right and the customer's wrong and something like that? I want my freedom, dagnabbit.

We should always be reevaluating our guardrails. It's true. But again, that comes down to the initial principles, which I think don't change as often. And the way that those principles are enforced or enacted can change dramatically. But I think generally speaking, they're not going to change super often. In a world of AI, I think that A lot of the questions are up for debate again. So we're trying to find our footing there as well. But back to the equality piece, our role is to make it a level playing field across the entire ecosystem and making the output as consistent and predictable as possible for the customers. And sometimes that does take the form of like, hey, you got to take that out, or hey, you should really add this back in. And that indeed, that informs how I interview and how I really think about the way that we represent ourselves in ecosystem quality to the community. And it has been intentional that we haven't been super public in past years because we've been finding our footing, scaling our programs and trying to play that neutral role. Whereas some other teams in DevRel can spend more time with certain partners and certain developers than others. We want to make sure that at least we're bringing up the rear and making sure that everyone is bringing the same amount of predictable value and coming along with the trends. Whereas the Dev Advocates, I think, are leading the charge in what can be done.

For my first year here, I was really going to change my Slack handle to Dr. No because every theme I was just rejecting. Like, and for good reason, you know what I mean? It was like, and the theme providers understood that. But at the end of the day, it was like, I just felt like all I was saying was like, nope, nope, nope, sorry, nope. And it was just like, I felt bad for a moment. And then like, you know, just getting here after, after a while with that same kind of mentality where it's like, you're not trying to be the bad cop, but you are trying to enforce a kind of consistent quality, you know, where it either may not have existed or it was still starting to come together. And even when it does, like you said, even when it does come together, Yeah. there's always going to be iterations on that. There's always going to be, hey, we— this doesn't need to be a restriction anymore. You know, we've, you know, we've either come up with something or, you know, we've, you know, changed something on our end where that doesn't need to be a blocker anymore for people. So, um, yeah, there's— it's, um, I don't know, it's not, not that it's frustrating, but it, it does force you to be sharp, right? It does force you to not just fall into compliancy where you're like, well, these are the rules now, so for the next 7 years just watch the spreadsheet and just keep following this, you know what I mean? It's like you have to not fall into that or you become very— it becomes very stale and very obvious, you know, even to the provider and to anybody else that's, you know, looking at it.

Yeah, and also my education back into the, into the picture here, I, I will often describe our programs in ecosystem quality as, and it makes it easier that we're actually using kind of natural science terms. Ecosystem, I'm very familiar with them through my formal education, but what is being created is not necessarily like a natural part of the world, right? Like, humans are creating new things, and so they have real impacts on— I'll bounce between like the tech environment, right? And then like the broader ecosystem implications. But The introduction of a new permission or an API can, for lack of a better term, cause a lot of new development and growth, and that can have implications on other parts of the ecosystem and what is competitive in the marketplace. And we want to allow that envelope to be pushed, but also mitigate any potential risks with that, especially We at HubSpot push stuff all the time that could have had a second look sometimes and causes breaking changes, and that is painful. So some amount of friction is necessary. And in an ecosystem context, there are very few natural systems in the world anymore that are not significantly impacted by human activity, whether that's everything from ocean acidification to just greenhouse gases basically affect everything in terrestrial environments in some way. And so I like to think of our team as somewhat independent regulators that try to mitigate some of the inputs to those systems that could cause shocks and cause inordinate impact to, in our case, customers and other developers. We try to soften the blow of some— in ecosystem parlance, it's disruptions. Hurricane comes through, it knocks down thousands of trees. That's a disruption. It has a real impact on the ecosystem and how the processes are going forward. How can we mitigate that kind of stuff and, for example, maintain an ecosystem that is healthy and is allowing everyone to grow and flourish While protecting from a tree falling on someone who's walking on a path. So I apply a lot of the thinking from ecosystem management to parks management to how we think of our ecosystem as a dynamic living environment with many different organisms and groups and interests. And how do we minimally impact that in a negative way? Well, In maintaining like the health of that ecosystem.

You consider it to be neutral or do you feel like you're fixing the game when you do that? Like, like for example, bringing back to environment, um, some trees need a fire to allow seeds to actually, you know, germinate and work or cold stratification with certain flowers. Those are necessary. You know, like those disasters are, that's part of the environment. And you are saying you think we should be able to, you know, kind of do a puppet, a little, you know, puppeteer.

I see where you're going. Yeah. And my philosophy on this, and we've talked about this because we both have this like kind of interest, is allowing those within certain parameters. Right. So sequoias and other redwood species do need the fire to come through. That's a natural part of that ecosystem that was suppressed for decades based on US forest policy. And so that was an unnatural burden on that ecosystem. What we're trying to do is keep it pretty natural while mitigating those very specific point risks where the forest fire coming through is a danger to the small village that's within that national park.

Yeah.

While allowing the rest of the ecosystem processes to play out as they normally do, which is why we try not to get too in the weeds of individual reviews and things like that, because we see that as a broader ecosystem pattern. Whereas if we can make sure that a certain type of beetle is not infecting all of the trees because that came from overseas, that's what we want to make sure. Okay.

That makes sense.

That's awesome.

I knew Dennis, that was, that was a good— the Ranger, Ranger Dennis. That was, that's where it came from.

I knew it.

Isaac and I are, you know, kindred spirits in this regard.

I love it. No, that's fantastic because I— yeah, it's one of those things where it's— yeah, it's— I don't know, I think someone had mentioned something about being a double-edged sword, but yeah, it's true. It really is true because you don't want to overstep and kind of tell people Yeah, thank you, Scott. You don't want to tell people how to— for example, at least on the asset side, right in the app too, but you don't want to tell people how to code. You're more trying to set these guardrails where you don't want to seem like you're forcing them to do something that— especially when there's questions about, well, why can't I do it the other way? For example, for whatever reason, the language switcher and themes keeps coming up in my head because there was a time where we were trying to enforce a certain way to do it for a quality check, but then realizing, well, there's multiple ways you can implement this. So to force people to do it a certain way is kind of like now you're kind of— you're not, you're not just putting guardrails up. Now you're forcing a particular action or a particular coding method that isn't the only way to do it. And who's to say that that's better than the other way where it's— it looks more like, well, this is just the way we want it, so just do it. Which is not the message that you want to really send.

I don't think we have any standards like that in our programs. We're not saying exactly this is how you must refresh your auth tokens. We're saying that the general principle is you should refresh auth tokens before they expire and not relying on an auth code. I know that might even be toeing the line for some philosophies. We're not saying like you must exactly use this class structure or something like that.

Well, let me ask you this. What do you think is the biggest guardrail that a lot of people miss the mark on right away? That, you know, like we have a lot of certifications and we have the guardrails, but there's always like that one that people are like, oh, you know, they like skip over that line when reading or something like that. And it's like, what would you call out as the the biggest thing that people are just missing when it comes to certification, the trend that they're missing? Like, hey, it's usually always this, so be on the lookout for this.

Yeah, it's definitely the unused required scopes. I get early on you're going to want to select as many permissions as you can so that you're not blocked in your development. But as you're readying for that listing or for that certification, make sure that you're operationalizing that principle of least privilege and making sure that your application has everything that it needs and nothing that it doesn't. Because that is probably the single theme that we see across the most apps that we review. That's for the interest of the customer because they shouldn't have to grant you more permissions than you actually need. There is something to be said about, well, we're actively developing that feature, And we want to enable that as a HubSpot platform better. We've had some pretty blunt tools in the past on how we've had to do that, and you've seen some of that in our programs. We hope that gets a lot easier with versioning and projects and things like that.

You still see scopes issues, like the primary thing, like since optional scopes has been introduced, like is that still as big of a deal?

It's still very common, but we have more tools in our in our belt to say that type of use case, you can now use conditionally required scopes. You have multiple variations of install URLs that you can accommodate your own pricing packaging or your go-to-market.

Sorry, AJ, I cut you off there.

No, I was going to say that was an awesome answer because I was going to have a follow-up of, well, why only what you need? But you nailed it when you said customers shouldn't be giving access to more than you need to play with or more than you need to do your interactions. It's a security thing when it comes down to it at the end of the day, right? You're gonna give access and just open up all that. Like we wouldn't just let an app access everything in a portal if all they're doing is talking to contacts. That's, you know, data leaks.

Yeah.

Like all sorts of stuff.

There's issues that arise from that. So that's, that's—

It's not that we don't trust our developers, right? It's just that we wanna pare it down to what is the customer actually granting access to? 'Cause they, they expect that honestly, they do expect that of you. Yeah. And the apps that are very thoughtful, apps and developers who are very thoughtful about their design, um, I think do statistically do better.

It's like a terms and conditions, like how many people just click the button not realizing what it is that they're actually allowing access to. Whereas at least in our flow, like we specifically spell out like you're allowing them to connect to all of these things. So.

I mean, devil's advocate, I, if you add scopes to your app, the person has to reinstall it, which is kind of a pain in my opinion. But, you know, I don't want to get in trouble with anyone.

Yeah, and again, that's another thing that we, we need to make better for our, our developers and for our platform.

Agreed. Legal department is pinging me right now, Dennis. Yeah, I'm getting like message, message, message, message. I mean, I get them already just from the dumb stuff I say, but like, you, you're making it— that tally's going up.

So yeah, and again, it's not, it's not meant to be punitive. It's meant to be like Hey, we're on this journey with you and we're trying to, yes, protect HubSpot to a degree, but also just make it so that the things that customers are expecting on our marketplace are of a certain level, certain values are upheld and we can help you get there. Ideally, that's incorporated into your flow when you do your second app and third app. We want to see you grow.

Absolutely. Let me, let me take it and wind it down a little bit and let's go a little bit less techie, shall we? Just to kind of, uh, um, what are some of the things? And because I mean, again, like technical problem solving, it's like your mind is in it, right? You are, you are honed in, you are zoomed in and you are laser focused and it's a lot, right? It's tech heavy. Obviously no one can argue that, but Like anybody in that situation, right, there are things that you, you kind of have to do. And I always use the caveat, you cannot get away from tech 100%, right? There are very few things unless you're whittling wood on your porch out somewhere in the middle of nowhere with no cell service or Wi-Fi.

Maybe, right?

That's, that's the, the extreme example. But, um, what are some of the things that you do, um, as far away removed from tech That you kind of do to sort of kind of unwind and kind of decompress.

Yeah, that's not far from the truth. I don't, I don't whittle, um, but I have a lot of, a lot of smaller hobbies, and a lot of them are, um, outdoors. So, um, do a lot of hiking, anything outdoors that's active, basically cycling, kayaking, scuba diving. Um, uh, not so much a rock climber. I, I have done rock climbing. That's not I know that's a major category for a lot of techie people, and I think it's very interesting that it is. My theory is that it is a technical— it is the most technical of physical pursuits. It is extremely like you need to plan your route and like—

Right.

There's a—

there's the most optimal way to get up that wall, and I think that is attractive to a lot of like engineers and techie people. So that's also culturally like, you know, California and West Coast kind of Rock climbing is really big. But getting out into a space where I can hear the birds, you know, just feel the wind and the sun has always been a passion of mine. And that's why I pursued environmental science. I still enjoy it. I'm doing a lot of photography. And if I don't have a week where I'm hiking for several hours, like it kind of throws off my entire week. Um, so, uh, it really grounds me and resets me for, um, more cerebral pursuits at work.

You also do, um, music too, right? There's a, uh, sort of a musical aspect to it because I'm trying to remember. I was trying to tie in because I remember you said— and I wanted to bring this up because I remember you showed us a picture once where you had And this is this is this is going to lead to a question, I promise. But you showed us a picture where you also had a mohawk at a certain point.

Yeah. Whoa, whoa, whoa.

Yeah, yeah, yeah. I'm I know I'm spilling some secrets here, but um and we're gonna bring that up right now. No, I'm just kidding.

If you have it, bring it up.

Yeah.

No, it doesn't exist.

You don't have a picture.

But no, there was that like because you you said you were in um I believe it was uh jazz bands and but was it was Did music play as big of a role as kind of like outdoor? Because like, you know, like it's nice too that you're able to like, you know, with, with bird watching, with hiking, and with photography, you kind of— there's kind of like that mesh together, right, where they can kind of flow. Um, did music in that have that same type of like— I don't want to say calming effect because maybe it's for some people, maybe it isn't calm. Like rock climbing might be a little stressful. But did it have that same kind of unwinding effect where you like music and the musical arts?

Yes.

So, right. I didn't actually note this very much, but I've done for a big portion of my life from middle school to high school into college was, that was one of my main things. It was skiing. I ski raced and I did band and specifically jazz band. So a lot of improvisation. Playing alto saxophone, alto and tenor, but primarily alto.

I was an alto sax player too. Oh my God, kindred spirits.

We, um, it's a, it's a creative act and, um, it, it kind of flexes like a certainly a different part of your brain, but also like how can you create, um, something new within certain parameters to go back to that. Like there are, you know, that you want to stay in key, you want to use the like blues, you know, you're going to be using certain certain notes, and there's plenty of variety within that. There's a world of variety within that, even within some, some generous guardrails. And that also translated to dance. So that photo that you're referring to was me as part of a hip-hop group in college. So I picked up b-boying or breakdancing in college. And that is similarly an improvisational art form where—

Mm-hmm.

actually very similar to like dueling saxophones or, uh, dueling pianos or something in jazz, where this call and response, um, you're often wanting to echo patterns that you've seen from the other dancer, uh, in the battle. And, uh, yeah, just 2 sides of a similar like kind of creative, uh, coin.

Nick, do we have budget to do an Isaac documentary? Like, can we go out there and just film something? I, I think it's kind of necessary.

Yeah, I mean, yeah, we, we can take away from some of my hair and makeup budget. I mean, I think there should be something there where we can do— there's plenty in that. Um, and I want to ask too, am I hearing that there's going to be a DevRel jazz band? Is that what I'm hearing? Because AJ is learning to play guitar.

I—

so I am.

I'm not very good at it at the moment, but there could be some—

yeah, that's—

I mean, imagine a DevRel like meetup or a thing where it's like It's a concert. I mean, how—

we've talked about like for like developer meetups, like we should just bring guitars and stuff because there's so many people in the community that like have bands and play music and do all of that. Like it's, it's honestly astonishing. Like when you think about it, like I, I think it's in the same vein as you said, like rock climbing is very technical. I know a lot of engineers and stuff that are— that play guitar. Like a lot of like heavy tech people also play play musical instruments and stuff like that, because I think, again, it's a technical thing. It's something that you really, like, zero in on. Like, I like baking. Like, that, that just happens to be, like, one of my hobbies where it's technical in nature. Like, I measure water when I make macaroni and cheese. Like, I'm a very technical— like, I follow the guidelines. My wife laughs at me all the time, but, like, I do. Like, I'll make pasta and I'll be like, oh, 3 cups of water. And she's like, why are you measuring water for pasta? I'm like, because it's—

I do the same thing. Yeah, I do the same thing.

It's just, it's a technical thing. So like for me, baking is that, like, it's, it's something that I can be technical about and wrap myself around and like do all those things. So it's, it's, it's definitely, yeah, the technical skills or like the technical hobbies are things that I think engineers and stuff flock more to. Yeah.

I mean, a lot of the folks that we talk to are just gonna, whatever it is, whether it's birding, I've certainly like, that's my, one of my more recent really crazy hobbies. You can't stop certain people and their brains from deconstructing a problem or a pursuit into its component parts and trying to optimize the things within that. That's just how a lot of us operate. And it can be something as seemingly right brain as improvisational jazz, but you can still apply those same concepts to that as you can to coding.

I think Isaac's the Ron Swanson of developer relations.

That's awesome. Oh my God. Also, my brain always goes more creative. I'm like, like, boom, like, easy with you with the measuring. I'm like the Swedish Chef in this, and I'm just like, things are flying around. Like, I don't measure stuff right. Like, I don't—

yeah, it's, it's—

there's something to be said about the creative versus the more technical Like, do you ever see those, like, you know, like you can get a wallpaper for your desktop, the left brain, the right brain, you know, like there's— yeah, I, I try so hard sometimes to, to be more like, um, to follow things more precisely. And it's just, I have such a hard time doing it, uh, you know, which isn't something you should admit in front of your manager. I have a hard time following the directions.

Um, adding it to the review, adding it to— I just clipped that, so don't worry about it.

Don't worry.

Don't clip that one, uh, just— but, uh, but no, it's— yeah, there's just— there's, there's something about that type of discipline, I think was the word I was looking for, uh, to, to really kind of hone in and try to— yeah, it's, it's hard for some people to do. It truly is.

But, um, yeah. And to answer Janice's question, yeah, no, that— it, it drives me absolutely crazy that like there's some people that just are like, oh, a handful of this, do that. And I'm like, how?

Like, yeah.

A handful is different by every person.

So true.

Because like our grandmother used to like would make cookies and like I remember through our family like we were trying to get the recipe and literally they had her like doing it and they would stop her and measure whatever she was doing to be like, no, you don't understand. You can't just do like handful of flour, handful. Like I need measurements. Sure. I need to know.

So yeah. Well, it was fitting her mental model and like it made perfect sense to her and she just knew. what the amount of whatever it was. But to communicate that, and this comes into developer advocacy, is how do you encapsulate that or encode that in a way that can be consumed by other people who don't speak exactly the same language, don't have exactly the same weights and measures as you do in your mind? That's just communication.

Isaac, well played, man. Just brought it back in.

That's amazing.

It's 100%, and it's all about what you learn. Because those people, it's like bartenders, really experienced bartenders, can pour an ounce without having to measure. They just know because they've done it for so long. That same applies in like the coding world where somebody may come and say, hey, I have this issue. Oh, you just do this. How did you know? Because I've done it so many times that it's like second nature at that point.

I know now too, when I work with John, I'm going to start quantifying things with a pinch of every time we have to do whatever there's going to be. Whenever I have to document theme reviews, it's going to be a pinch of everything. You just got to look at this and do a little Pinch of hovel here.

Just eyeball it, it'll be fine.

I don't know if you, you make, uh, rice. All right, so I grew up obviously in, uh, so my mother's Thai and we made rice every meal. Um, and there's a— not just Thai folks, but like a lot of East Asian, um, uh, parents probably teach this, where it's like a certain point on your finger, your index finger, is where the water should rise above the rice. That you are measuring. So I actually do not— I take back what I said before. I don't measure everything. I measure it for pasta because I'm not as accurate with like— also, I don't think it matters as much like how much you put in the pot. But for rice, you need the exact amount of water. And I still use like this finger method, which is like mind-blowing to other, especially Westerners who have not grown up like eating rice. I would like to see that.

I need to see this because I, I have messed up a lot of rice in my day.

Me too.

I'm just like, well, it's like, it's like that. There you go.

Cool.

Awesome.

Even in the same brain, like, certain applications will be needing that measure, that universal measure, and others will just be heuristic.

Oh, that's awesome. Um, I know we're getting close to coming up on time, but one of the questions I did want to get in before we, uh, kind of wrapped everything up was What are some of the— because I love this because it doesn't even have to be like, it doesn't have to be technical. It can be from a different vertical. It could just be life advice that then you translate into your career. But what is some of the best advice a mentor has given you? It doesn't necessarily have to be about the industry, but like I said, there are some life mentorship quotes, you know, that can be applied to it. But what are some of like some of the ones that you've been given? As far as advice, that's just kind of really—

It doesn't have to be from me. It doesn't have to be from me. You can use other references.

I was hoping it was me. I mean, we try to work in Dennis's mentorship every time.

I'm amazed that we haven't even talked about how I could have shut your hire down, right, Dennis?

True.

Yeah.

Kidding.

That goes back to my, like, I pride myself as very fair-minded and I want to give everyone a fair shot. you came in with like glowing references from my then manager, which obviously sways your like internal narrative. But, um, no, uh, best advice, like I, I wrote down 2 things that I, that came to mind for this like questionnaire, and I'll, I think I'll go with one of them. Um, I mentioned a lot of us started in the Portsmouth support, uh, in the Portsmouth office in support, and one of our senior support specialists who recently, like not too recently left HubSpot named Ed Justin, always said it's just marketing software. And I gravitate toward this for a couple of reasons. On its surface, it doesn't seem like that great of advice, right? It's like, well, you're not gonna take your job seriously. No, that's not what I take from it. It gave me permission to Approach everything with like that air of humility and like curiosity and knowing that there are people looking out for you who like, like, look, at the end of the day, you're gonna make mistakes. You're gonna tell the customer the wrong thing. You're gonna be in uncomfortable situations where you don't know the answer, but it's not life or death here and you will learn throughout it.

Yes.

And that is the same type of mindset that I think a lot of your other guests have talked about where I just started tinkering and I started building simpler to more complex systems and programs and applications and things. And that was the trial and error that they needed to grow in their technical acumen. For me, again, I didn't start with that. So it was more trial by fire within these conversations with business leaders who, they've been running their business for 20 years and they're looking at you like you're an idiot. But having the permission to fail there and iterate on that is what I needed in my early career and has led me to where I am. So just a simple, relatively specific statement, like, don't worry, it's not heart surgery, it's just marketing software, gave me the permission to grow into levels of expertise that I didn't previously think I could have.

No, that's fantastic. I mean, for the longest time, like, I always thought the best mentorship advice I was given was, what's wrong with you? But then I just realized it was just people questioning me all the time of what was really wrong with me. I thought that was mentorship advice. But no, no, it makes sense though. It really does. It's like, you know, people get not overworked, but you get it. There's like a— like when I first started here, there's a nervousness to like, this is like, it's Do you know what I mean? It's like when you're, when you're like a little kid and you see a tall, tall building for the first time, right? It's that overwhelming kind of like, whoa, this is massive. Like, this is, you know, HubSpot is big. You can't— there's no denying it. Like, whether you're talking about employee size or you're talking about just, just the depth in which it affects everyday people, you know, or just our providers and our partners. So there's, there's kind of that, that weight, even though, like, it may not all impact you in whatever job you're doing in HubSpot, that overall weight is kind of like that 800-pound elephant in the room. Do you know what I mean? It's like, yeah, sure, I, I'm reviewing this thing and I, you know, and I may not know. It's just, yeah.

That's what I'm saying. What's, what's the average size of an elephant?

Yeah, like, that's a very, um, isn't that the—

the 800-pound gorilla? Sorry, that's an admonishment. That's an admonishment for next time.

All right, that's fair.

I do not know the weight of the animal kingdom.

That's— I'm all right admitting that.

That's fine.

I think you made a great point though, Isaac. And like, I think it's good advice for anybody who's a manager is like, it's okay to let your people know that it's okay to fail. Because like you said, Nick, like people have this nervousness when they go into a position and they want to be the best. They want to You know, kill it 10 out of 10 time every time. And it's just not realistic. Like getting people to say that, like, you should never fail. You're never going to make progress unless you fail at some point. Like, you're never going to learn. So I think letting people know, especially managers, like, hey, it's okay to tell your employees, like, if you fail, you fail. Who cares?

Yeah.

Let's, let's learn from it. Let's move. Let's pivot. Because all that's going to happen is if an employee fails and you don't recognize that, hey, it was a failure, but it's okay, they're going to just stew in that and that's going to affect the next project, the next performance, the next whatever they do. So allowing people to fail and just supporting them when they fail is just going to make their career trajectory and path much easier for them and they're going to produce better in the end.

Tell my daughter that, please, if you don't mind.

Tell my kids that.

Like, I should have checked in with Jana before I made the 800-pound elephant. elephant thing. She was on Safari. She could have totally, uh, set me straight on that one. I just thought about that now when she posted that. Yeah. Well, can we go back and edit that in post?

No, no, I think that's the point. You just learned. You just progressed, Nick.

Yeah, I'll say 8,000 right now, and then you can just cut this part and then move it back over and then just do some magic, and then we'll be good, right?

Remember, Nick, it's okay to fail. If you don't know anything about animals and their weights, it's okay.

Yeah.

How am I ever going to be the lead of HubSpot Plus When that becomes a thing, if I, I can't, you know, not, not in episode 10. I mean, come on.

We just won't add you to our nature programming.

Yeah.

Okay.

I'd be the worst David Attenborough in the world.

For the record, just so we're, just so we're clear for the, for posterity, it's, uh, an African bush elephant averages maybe 6,000 to 13,000 pounds. As a— Yeah.

So you're big.

Little bit. 800-pound elephant is a very small elephant. It's a baby elephant.

Baby.

Well, that's what I was, I was thinking.

Yeah. Yeah, of course.

I'm looking out for the kids.

Looking out for the kids. That's—

it's fine.

It's all right.

But no, I, I was like, I want to thank you because, um, this was fantastic. Um, the, the stories and the journey, to me, that's what makes this whole thing amazing, right? And that's why I hope more and more people tune in to listen, because not just because they're different amongst everybody, but there is commonality, right? It may not be the exact same path, but there is There are higher-level kind of things that go on that people can relate to just instantly, right? The same feelings, the same, like, again, like we say drinking from the fire hose, like, that's not just a HubSpot thing, that's other places, right? It may manifest itself in different ways or in different, you know, verticals or job titles, but it is a thing. And I think your mindset and your problem-solving skills and the way that you approach it With like a technical, um, kind of like— it's almost like a technical focus that is— for some people, it's just, it's hard to do. They do it, they may do it okay, they may do it well, but there— it takes a certain type of kind of focus. It takes a certain type of understanding and empathy and things like that to really not just do it, but then be able to for it to be obvious for everyone, like to see it and be like, yeah, no, I know that that's obviously what he does because look at this, right? That's not— you don't get that all the time with people, uh, you know, just— I mean, coming from the— just coming from the— again, Dennis, roll the eyes— uh, real estate, it's— there's technical problems to solve, but, you know, there's people that you, you'll talk to that you just— you don't get that same kind of— you know what I mean? It's almost like a, um, Like, oh, I'll follow that into battle. No problem. Yeah, that makes perfect where you're kind of like, all right. Yeah, no, I know that's what they said, but we'll see.

You know what I mean?

You don't get like, I can honestly say, Isaac, you're one of those people where I can listen.

Oh my God.

No, I'm just saying you're never getting fired.

You're safe, buddy.

Don't. The checks in the bank.

I appreciate you saying that, Nick. If I can offer some final thoughts.

I'm not saying it.

Final thoughts.

That's fine. You know, we were amusing in like a one-on-one not too long ago where tech is very accessible to people of all different walks of life. We heard it last week with Jana. It certainly is in my case as well. You don't have to have started with coding tech, but you can enter it and flourish in it because it can bring together so many of these different skills that people innately have and have been able to apply to other other pursuits or leave tech and apply to other pursuits as well. And I think it's uniquely, um, I mean, maybe to a, a super uninitiated person, maybe it does not feel accessible, but I think it is. And it is accessible, especially with the great content that folks like AJ and, and, um, Dennis put out in the HubSpot ecosystem. Um, but we uniquely bring together people of different backgrounds, of different perspectives, and that allows us to make Better build better things, build better systems, build better teams, build better products. So I love it. Awesome.

Awesome.

Well, thank you again for coming. And of course, thank you to Dennis and AJ for making all of this possible. Without their help, this does— this doesn't really work. It really doesn't. You got it. So with that, I'll leave you— or we'll end this and I'll leave everyone with the words of the immortal Beyoncé, when asked about AI, if you like it, then you should have put some guardrails on it.

Oh.