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

Isaac Takushi, team lead for Ecosystem Quality at HubSpot, joins Nick, Dennis, and AJ to discuss developer relations and ecosystem quality. They explore how technical problem-solving intersects with environmental science and share insights about building and maintaining developer communities.
When that becomes a thing, if I. I can't, you know, not. Not in episode 10.
I mean, 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 Return of Agent gets everything.
I was gonna say. No, I was gonna say the last two weeks were fine. All of a sudden you get AJ back and then technical difficulty starts bringing 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 real.
At least you didn't butcher his name. So don't. You're not doing too bad.
Yeah, yeah, I know. No, I definitely. I watched while I was not here and definitely laughed and. Yeah, you know, I took notes. Don't worry, I'll send you some.
I don't.
I don't read well, so it's. 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, 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 D hug about building a more accessible web experience in 2025 that is now up on the developer's 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. We're going to talk all about the elevate theme basically for that one, which is going to be pretty cool. I think we need to do more of that. And then SJ is actually taking over. It's. March is a month where I think we celebrate the women of the world. And we're. We're. The developer hug is being taken over by SJ and team, and she's gonna do a special thing there. I have no details about it, but I know it's happening. And 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. So we got one with Replit. Isaac knows them well, followed by one with Postman. And I'm working on getting cursor in after that. So I'm trying to hit them all.
That's huge. Thank you. That's fantastic. And speaking of the element theme, kind of a spoiler, we're going to try to get no pressure on the team, but we're going to 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 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, drag and drop sections. So you should check that out. That's something really, really fantastic when those were in the marketplace used to review the email templates and you know, 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@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 humble brag 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 definitely something that you should look into and take advantage of because it's something that HubSpot does for developers.
So Nick, just once again, stopping you right there because my golly gee whiz, you certainly up 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 wing that. That was pretty, you know, I remember because I remember the inbound marketing one was one I wanted to take and then improving website performance was one. I didn't take it at HubSpot, but I, 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. It's cool.
What you don't see is off to the right is the mirror that he.
Practices in or the lighting that I.
Have set up for. Eventually, you know, that's fine.
I'm.
I'm working little by little, gradually something off screen. I'm working on it, gradually let on my little. But 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. 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. Jonna, 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 kind of meets our general guidelines and standards. And that's all in service of the customer and making sure that you're putting your best foot forward for your creations. And we love partnering with you. We love being in the Devrel family, kind of playing off of the strengths of the dev advocates as well as the solution architects. SJ obviously in the community as well. And we just kind of try to create a tapestry of programs and 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 really is. It's just one of those things where.
It just really is you kissing up.
No, 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. Screaming out there.
Well, it all happens because of the work that we do and, like, the, you know, kind of kinship and partnership that we have. 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. And I'll admit that I was a little skeptical at first, but I see even in the first couple episodes, like, what 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.
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.
That's a good way of looking at.
It most conversations, because I don't want it to go bad.
That's a safe but. 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 slash developer sphere? Like, how did you first get an interest in it? How did you first become aware of its existence?
Yeah, I. 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 eight 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'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 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, 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 a. 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, 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, like, both a company that's well regarded but early in its kind of development. And I thought it was. It was kind of a startup phase. I was going to be in for a couple years and then go off and do my own thing. I was waiting for inspiration to strike for like a new environmental technology, carbon capture or something like that. And 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. Three of our team members are former Portsmouth support folks, where we started in the trenches, as we call it. 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 like 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 ice.
But you made it 10 minutes and 13 minutes into.
Right. I tried, I tried to hold it off as much as possible but 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 like HubSpot positions, especially support and like inbound sales as we call it, are looking for a certain type of character and you're not going to bring the SaaS skills you're not going to 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, you know, what a CRM was before joining. We were often most of us in our, in our first job like first customer facing role in a, like a 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 the like 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 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 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. A different way of learning than 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 had seen it. So, like, were there certain languages and 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 like a little bit of dabbling into Swift. So the earliest foray that I had was honestly in like my later like part of the senior year in college where I was in this kind of startup. It was both a like, 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 like 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, of the school year rather than semesters. And I wanted to do a. Had this idea of doing in 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 like 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 kind of motivating myself. So there was this idea of. It was called Duelist, which was like a play on the to do list, but it's due list as in Emma, like Dungeons and Dragons or some kind of RPG where you're like dueling this big project and you're like trying to knock down the HP through the like organization and prioritization of tasks and trying to keep that on task and gamifying that. No, like that. That was a concept but no experience like 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 like I had to graduate and start to like 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 like 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 extended 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 kind of developed into okay, I really like this technical troubleshooting. I seem to be decently good at it. Started developing the apisaq Persona, which is my internal handle to this day, and joined Developer Support, which was at the time a new team. 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 two support. So I was fielding questions about how JavaScript functions. We're 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 you are. And I just want to like another plug for the support team because 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 was working with HubSpot. Generally speaking, like me personally prior to being 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 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, 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, like a Dungeons and Dragons wherein 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. So even early on like your technical problem solving skills were already like even in their infancy were still probably leaps and bounds about 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 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, okay, 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.
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 my comment?
Well, we're all problem solvers and especially 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. 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. 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, you're building, whether you're doing it with the code or with programs or with people. Little hand, hand wavy there. But that's, that's my connection. I really enjoy the putting together of like, you know, Nick, you bring a unique set of skills to the team that cannot be replaced by anyone else. And 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, you know, 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 is 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, it's beautiful. Tennis. I'm going to need you to clip that first part of that where we talk about how good I am. Okay. That way we can run that as a sound clip whenever.
Sure, sure.
I want to feel good about myself. That was a good thing.
Times Square ad right there.
You're very, you're very strategic in the way you think. Because I remember during peer week we were chit chatting and you had mentioned playing poker and like chess and stuff like that. Because of, of the strategy portion of it, I remember you saying like, you were really involved in like, like you, you enjoyed those types of challenges that are like strategy based and it, it definitely shows. Like, I know you and I have 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.
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? Are you looking at 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 kind of phase, I did realize that I really enjoy working with technical people, kind of 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 that's just renamed and broadened in its scope. But the way I think about it now as a people manager is optimizing for the the folks who I have a vested interest in outside of. Just like 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, we draw a lot of inspiration from you. And like we, I want Devrel more broadly to be the most like 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 sport just out of necessity, yes, you should know what that new beta API is that you're answering questions about, but you won't know necessarily what, 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 do you make that? How are you making that transition?
I'm still having to tell my remind myself each day, like 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 daughters 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. 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, 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.
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 that, like, for example, like newsletters, things 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 is, 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 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. And 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 more, much less frequently. So start with the principle and then work back in abstraction or less abstraction to more specific details. And 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, it's the perfect way to do it and the proof is in the pudding. It, it is working because you know, we are doing like some of the things we're working on, some of the things we're doing with that approach is mildly successful. No, very successful. It's, it's very good. I wanted to, I, I, 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 you know, like how to kind of recent events and things of that nature. What were. Have you been to any like conferences or anything like that recently? And mainly because I want to get dirt on Dennis. Have you been to any conferences recently or anything that's kind of like really kind of sparked your interest or that you've experienced that has 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 will spark a whole other part of the conversation, I'm sure. But it's not a, it's not intentional but ecosystem, quality, EQ or equality. 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 good cop, bad cop to the dev advocates. Good cop. It's like 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, certain things. And that's all in the effort of making value for everyone.
I have curiosities. How do you, how do you decide this guardrails? And what do you. I mean, at what point are you right and the customer's, you know, wrong and something like that, you know, I want my freedom. Dagnabbit.
We should always be reevaluating our. We should always be reevaluating our guardrails. It's true. But again, that comes down to the like, initial principles, which I think don't change as often. And the way that those principles are enforced or enacted can, can change dramatically. But I think generally speaking, they're, 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 kind of 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, 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. And 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, 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, no, 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, 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 mean to be a blocker anymore for people. So, yeah, there's. It's, it's not, not that it's frustrating, but 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 seven 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, my education back into the, into the picture here. I, I will often describe our programs and 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, like, 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 like 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 like 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, you know, environment. 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. 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.
And my philosophy on this, and we've talked about this because we. 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. 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 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.
It's awesome. I knew Dennis, that was. That was a good ranger. Ranger Dennis. That was. That's where it came from.
I knew it.
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, I think someone had mentioned something about being a double edged sword, but 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 like, like, for example, like with at least on the asset side. Right. In the app too. But like, you don't want to tell people how to code. Right. You're, you're more trying to like set these guardrails where you just, you don't want to seem like you're like forcing them to do something that, especially when there's questions about like, well, why can't I do it the other way? And why, why, why can't, like, for example, I just, for, for whatever reason, the language switcher and themes keeps coming up in my head because there wasn't, 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 there, 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, you know, which is not the kind of message that you want to really send.
Right. Which is, and I don't think we have any kind of 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. And I know that might even be toeing the line for some philosophies. Right. But we're not saying like, you must exactly use this, this class structure or something like that.
Well, let me, let me ask you this. What is, 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, 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 while 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. The primary thing since optional scopes has been introduced. 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 kind of accommodate your, your own pricing, packaging or your go to market.
Sorry aj I cut you off there.
No, no, I was going to say that that was an awesome answer because I was going to have a follow up of like, well, why? Why? Only what you need. But you, you nailed it when you said like 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 going to give access and just open up all 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, like all sorts of stuff. There's issues that arise from that. So that's.
It's not that we don't trust our developers. Right. It's just that we want to pare it down to what is the customer actually granting access to. Because they, they expect that, honestly, they do expect that of you and the apps that are very thoughtful apps and developers who are very thoughtful about their design. I think to 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, 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 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, as you're speaking. I'm getting my message. Message, message, message. I mean, I get them already just from the dumb stuff I say. But like you, you're making it, your 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, we're on this journey with you and we're trying to, yes, protect HubSpot to a degree, but also just like make it so that the, the things that customers are expecting on our marketplace are of a certain level. They're up, certain values are upheld and we can help you get there. And ideally, like, 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 techy, shall we? Just to kind of 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 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 the extreme example. But what are some of the things that you do 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, but I have a lot of. A lot of smaller hobbies, and a lot of them are outdoors. So do a lot of hiking. Anything outdoors that's active, basically. Cycling, kayaking, scuba diving. Not so much a rock climber. I have done rock climbing. That's not amazing. 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, 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. The wind and the sun has always been a passion of mine, and that's why I pursued environmental science. I still enjoy it. Do 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. So it really grounds me and resets me for more cerebral pursuits at work.
You also do music too, right? There's a sort of musical aspect to it because I'm trying to remember. I was trying to tie in, because I remember you. And I wanted to bring this up because I remember you showed us a picture once where you had a. And 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, yeah, I know I'm spilling some secrets here, but. And we're gonna bring that up right now. No, I'm just kidding.
If you have it, bring it up. Yeah.
Exist. You don't have a picture. It.
But no, that was that, like. Because you. You said you were in. I believe it was 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. Did music and 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. Did it have that same kind of unwinding effect where you like, you know, music and like 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. I was an alto sax player too.
Yeah.
Oh, my God.
Kindred spirits.
We.
It's a creative act and it kind of flexes, like certainly a different part of your brain. But also, like, how can you create something new within certain parameters? To go back to that, like, there are, you know, 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. And actually very similar to like dueling saxophones or dueling pianos or something in jazz where this call and response, you know, often wanting to echo patterns that you've seen from the other dancer in the battle and. Yeah, just two sides of a similar, like, kind of creative coin.
Nick, do we have budget to do a Isaac documentary? Like, can we go out there, just film something? I think it's kind of necessary.
Yeah. I mean, yeah, 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. And I want to ask too, am I hearing that there's going to be a dev rel jazz band? Is that what I'm hearing? Because AJ is learning to play guitar. So I am.
I'm not very good at it at.
The moment, but there could be. Yeah, that's.
I mean, imagine a devrel, like, meetup or 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 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 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. 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. I'll make pasta, and it'll be like, oh, three 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 going to. 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, like, operate. And it can be something as seemingly like left brain or right brain as, like, 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. My brain always goes more creative. I'm like. Like, EJ with the measure. I'm like the Swedish Chef, 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, 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, to follow things more precisely. And it's just I have such a hard time doing it, you know, which isn't something you should admit in front of your manager. I have a hard time following.
Don't worry about it.
Don't, don't clip that one. Just. But, 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 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 yeah.
And to answer Janice 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. 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 like developer advocacy, right? Is like, how do you encapsulate that or encode that in a way that can be consumed by other. 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. And that is, that's just communication.
Isaac, well played, man. Just brought it back in.
It's amazing and it's 100% and it's all about like what you learn, right? Because those people, it's like bartenders, like really experienced bartender can pour announce 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. Whatever there's going to be. Whenever I have to document theme reviews, it's going to be a pinch of everything. You just gotta look at this and do a little A pinch of hovel here.
Just eyeball it. It'll be fine.
I don't know if you. You make rice. All right, So I grew up obviously in. So my mother's Thai and we made rice every meal. And there's a. Not just Thai folks, but like a lot of East Asian 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. Finger method, which is like mind blowing to other. Especially I would like to see who have not grown up, like, eating rice.
I need to see this because I have messed up a lot of rice in my day.
Me too.
I'm just like, well, it's like that.
Awesome.
Even in the same brain, certain applications will be needing that measure, that universal measure, and others will just be heuristic.
Oh, that's awesome. I know we're getting close to coming up on time, but one of the questions I did want to get in before we kind of wrapped everything up was what are some of the. Because I. 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. 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 for me. It doesn't have to be for 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. I could have shut your higher down. Right.
Yeah.
That goes back to my, like, I'm. 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 no, best advice. Like, I wrote down Two things that I. That came to mind for this like, questionnaire and I'll. I think I'll go with one of them. I mentioned a lot of us started in the Portsmouth support. 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 kind of 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 going to 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 going to make mistakes. You're going to tell the customer the wrong thing. You're going to 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. 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.
Fantastic. It's, I mean it for it 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, but. 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, 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, I was gonna say what's, what's the average size of an elephant?
I just, yeah, like, that's a very.
Isn't that the 800 pound gorilla? Okay, 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, I'm all right admitting that.
That's me.
That's fine.
I think, I think he made a great point though, Isaac. And like, I think, 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. 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 failed, who cares? 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 John before I made the 800 pound elephant. Elephant thing. She was on safari. She could have totally set me straight on that one. I just thought about that now when she posted that. Yeah. Can we go back and edit that in post?
No, no, I think that's the point. You just learned, you just progressed, nick.
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, we just will 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 clear for the. For posterity, it's an African bush elephant. Averages maybe 6,000 to 13, 000 pounds. 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. It's.
It's fine.
It's all right.
But no, I. Isaac, I want to thank you because this was fantastic. 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 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 it 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. You know, just. I mean, coming from the. Just coming from the. Again, Dennis, roll the eyes. Real estate, it's. There's technical problems to solve, but, you know, there's people that you'll. You'll talk to that you just. You don't get that same kind of, you know, man, it's almost like a. 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. 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.
You're safe, buddy. Don't.
The checks.
Well, I appreciate you saying that, Nick, if I can offer some.
I'm not saying it.
You know, we were, we were amusing in like a one on one, not too long, where tech is very accessible to people of all different walks of life. We heard it last week with Jonna, certainly 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. I mean, maybe to 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 Dennis put out in the HubSpot ecosystem. 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. We'll end this and I'll leave everyone with the words of the immortal Beyonce. When asked about AI if you like it, then you should have put some guardrails on it.










