The biggest lessons from building Hubspot, from co-founder harmony to engineering the culture — Dharmesh Shah

 Well, thank you so much for joining us. I can't wait to dive in here.

 I thought, uh, an interesting place to, start our conversation is to talk about your co-founder relationship with Brian and sort of what I've noticed that at afar, it seems like an outrageously productive relationship over an exceptionally long period of time. even when you have quite productive, uh, founder relationships, you often don't see them, go on for 15 years.

And so I thought it might be interesting to have you talk a little bit about when you look back on what made it work and what made it so, uh, productive, what sort of the root cause? What, what made it work?

 yeah. you're right. It has been a long enduring, Um, productive relationship. And I think that we'll start with the, kind of the obvious things which people don't talk about, but apply one is when you're picking a co-founder or trying to choose who you're going to partner up with, on this kind of long startup journey, you need to actually like the person, and you need to have some degree of mutual admiration and respect.

And I think that gets missed sometimes when founders are trying to kind of assess each other, they'll assess the idea. They'll maybe have a beer together. and that's all well and good, but you have to kind of really ask yourself, I enjoy spending time with this person because you will be spending a lot of time with this person, in many cases more with that individual or a group of individuals than anyone in your life, including your significant other.

And so, you know, just do you enjoy spending time? That's a fundamental thing. and the other thing that I think is interesting in terms of figuring that out, I don't think people allow themselves. enough Time to get to know their, potential co-founders. Um, and Brian's my co-founder Ryan Allegan.

He and I were very, uh, I'll say methodical about making this determination. So, uh, we met in grad school, uh, which I think a lot of founding relationships start there, but the reason that academic environment is useful, um, when used correctly is it gives you a relatively lightweight non-intrusive way to kind of really get to know a person, at least in a, even though it is a somewhat, uh, hypothetical setting.

Um, but what we did is that we said, okay, well, we might start a company together someday. Uh, we knew I still had another year left before I graduated, but we said, okay, well, every class that we're having together, which was a lot of them, um, any class that has a project, we're going to intentionally put ourselves on the same team.

And sometimes it was just a team of the two of us. Um, and we took it a step further. We said, well, every project that's kind of required of us, we're going to. Make that project tied back to this startup that we called HubSpot, the HubSpot wasn't a company at the time, it was a idea for a company. Um, and then that idea shifted.

But the idea here is to try and, uh, I'll use the word simulate for lack of a better term. It's like, what would it be like being around this person for 4, 6, 8 hours at a time? What would it be like having a project that you're working On together that's going to be measured and that you have to deliver that actually does matter.

Um, what would it be like and how do they change as circumstances change? Um, and it's a very compressed one or two year environment that you get this opportunity, but we maximize that opportunity and, and that's, um, I think that's what contributed to it. We sort of knew each other really well. And in our personal relationships, we often will, you know, date for a long time before we make a very long, um, ideally, you know, lifelong commitment, um, in, in, in co-founder land.

I don't think people are as deliberate about, um, spending time with their potential co-founders and, and getting to know them. That would be it it's like, make sure you like them, uh, make sure you have yeah. Mutual admiration or respect. And then on a tactical level, make sure you have kind of different skills or divergent skills, uh, but common values.

And this is going to sound a little bit cliched because it is, but this kind of different skill sets is important. And that's an easy one that says, okay, well you both, both shouldn't have the same set of skills, the same background. You can't be clones of the same people. Um, it's often tempting to do that with co-founders because those are the kinds of people you gravitate to.

And you know, when you hang out with, um, in our case, you know, Brian grew up in, in sales and marketing. I grew up in product and engineering. And so we had very kind of different backgrounds, um, and in different skillsets. But then we also had a kind of common set of values, which is super useful. Um, as you're scaling, you know, one of them being around transparency, one of them being around this.

Obsession with the customer and solving actual problems. Um, so it's all those things kind of help. You have to know your founder like them and hopefully be different enough that you can bring different things to the table.

 On that point about common values. Did you explicitly surface them in that year or two before you started the company and they kind of express themselves organically it's a good question. So a couple of them, like this notion around transparency was there from time T equals zero. And it was not because we sat down and said, oh, here's our list of values. Transparency is one of them. It was more, a matter of convenience, which is, Hey, uh, we sat down and we had to make a decision when we started the company.

 It's like, okay, well we have this information. We just hired our first time. And we have to decide what we're going to share with this person. Now we could have gone one of two ways, right? Just a I'm an engineer. So I kind of look at the boundary conditions. One could have been that we're not going to share any information with anybody.

It's just the two of us. And that's just how we'll run the company. And, um, you know, it can be argued whether it's actually possible to run a company that way, but we'll call it the minimum amount of information, uh, to all possible people. The other end of the extreme was to share all possible information with all possible people.

Um, and the way we kind of looked at it, the, the latter was a much more efficient way to go about it, which was, we didn't have to make the choice. We didn't think the first one was going to work in terms of being closed. We wouldn't be able to delegate. We wouldn't be able to scale. Um, and so we kind of tested.

It's like, okay, well, how would life look if we said we're going to make everything available to all people, unless it's illegal, um, or

it's not our information to share. And so That core value just came out of just a practical, how do we want to run the company? What does this feel like? And then that translated over time and to. Kind of an articulated, here are a set of values and transparency has been one of them since time, time equals zero for HubSpot.

 That you too could have been a successful co-founder pairing working on most types of companies or was this specific company in HubSpot, a unique expression of kind of the way in which you two, um, could be successful.

 So in theory, uh, Brian and I both believe that we could have been parachuted into any kind of similar tech company. That's our, both of our background, um, and would have had a reasonable shot at success will still be the idea itself. And the other connectional factors were, were common.

 So the answer is yes, I believe it that, uh, we could have been at a different company. It didn't have to be this one on a practical matter. I have kind of a semi evidence of this. What do we started HubSpot my kind of motivation. So just taking a step back, you know, I had done a couple of startups before, uh, sold them and I said, I'm going back to grad school and to kind of find myself and figure out what's next.

I had promised my wife, I would not do any more startups. That was the agreement. Uh, she and I have been together since, before I did my first startup. Right. And I'm like, no, I'm not. That's, you know, I live the, the kind of proverbial, canonical startup life with all the startup hours and all the sacrifices people, um, talk about.

And so I said, I'm not gonna do a startup. And here I am in grad school. And then, you know, just a few months in, you know, Brian, I had met and we had this kind of a set of common passions around, you know, startups and tech and small business. Um, and so we first made the decision. This is why this kind of deliberate kind of feeling each other out and getting to know each other, um, through an academic setting and these various projects, but we didn't really know what the idea for the company was going to be.

Right. So. In a way you can think of it. Like Brian, I first came together as co-founders and then jointly came up with, okay, well, we've decided that we really like each other enough and that this is kind of worth pursuing. We have broad sense of what we wanted to do, but the idea that's now HubSpot didn't really manifest until after we made the decision that the two of us were going to start a company together. 

 I'm interested when you think about your. Kind of compatibility and your worldviews, how did you approach if you did this and maybe it was completely unintentional the, the path of growing together over a long period of time. Um, and I, I think in some ways, as you were sort of mentioning, it's, it's similar to a lot of relationships and, and potentially marriages, and we all hear about marriages where people are super aligned when they get married, but in 10 years they're different people.

And I think, you know, you had a company that went from zero to one to 10, to one of the most meaningful, um, SAS companies in the last 20 years. And so just an insane amount of change and insane amount of scale. And yet it seems like you were able to productively grow together. And I'm curious, sort of any reflections on that.

 Yeah, I think a few things contributed. One of the things that.

brought us together in the first place is that, um, and, and it's not overly surprising since we were both in grad school when we met, but we have this, um, real passion for learning. Um, we're kind of learning machines and then it's, uh, and, and the nice thing about as you know, the company scaled is that, um, there was just, and this was our first time doing something, you know, anything approaching the scale of what HubSpot became.

And so, you know, every, every month, every quarter, every year there were new things to learn things that neither one of us knew, or in some cases. Um, it was an area that, you know, Brian had more experience in, or I had more experience than the other one kinda came along. Right. So, um, we kind of both learn from each other and then both learn together about things that neither one of us knew much about.

Um, and so that's been helpful. I think that, um, kind of have a sh having a shared purpose and it's not such like a highfalutin kind of mission, which we did have, uh, but we had this kind of shared goal of trying to get better. Um, and, uh, you know, to this day we will send each other emails at one or 2:00 AM.

We'll send each other book recommendations. We know what's on each other's reading lists. Uh, we'll uh, discuss, you know, talks we've watched or things we've learned. And we, um, and then this carried it. Wasn't just a, the co-founding team. All the early employees, we had this very kind of academic oriented.

Uh, culture. So we really believed in debate. We really believed in, um, you know, the easy issues were kinda easy to knock out. It's the ones that were where we couldn't decide on, um, where it, you know, debate was actually very healthy and it was very respectful, but it was a very academic debate. And we could pick anyone off the management team at the time and say, okay, well, we've got this issue, uh, argue whichever side, like in, uh, they may not necessarily agree with that particular side, but just like debate, um, debate school, you learn to do that.

And so that process of just learning together of kind of pushing on each other, um, even when we disagreed, which did happen, but not all that often, uh, I think that helped kind of keep the relationship productive, keep it fun. Um, because we both enjoyed learning and then, uh, growth itself is kind of funny.

It was, uh, you know, if the company had gone really, really poorly, I think we would still have survived. It probably wouldn't have been quite as much fun, but, um, yeah, that's, that's it it's just learning together is, is a useful, a useful. 

 can you share a story that kind of brings that to life over the past handful of years?

 Yeah. So it's, you know, the longest running debate in HubSpot history, um, was in the early years?

and it was a deciding on our target market and we had it, uh, kind of reduced down to two things. One, there was a third one that we all had read. Wasn't going to be the target market, which was these kind of developer it folks at the time we said, okay, we're going to focus either on professional marketers, because we had a marketing suite of applications that was our first, uh, kind of set of products out of the gate. so we could, uh, focus on professional marketers or we could focus on kind of business owners and entrepreneurs. Those were the two, um, two target markets and we had names for those personas. So we called the marketing persona. We called her marketing Mary, and we call the, uh, kind of the business owner, owner Ollie.

So maybe he owned a small accounting firm or something like that, as an example. And. There were trade-offs on both sides, right? There were many more owner Ali's out there than there were no marketing marries because there's lots of, kind of startups and small businesses, but marketing, Mary understood the product better.

She had a more kind of burning need because it's like, oh, I'm trying to do marketing the old, stuff's not working. Let me look at HubSpot. Um, and so that one was one we, um, could and did literally debate for like years before we made a decision. Um, and then this was that, that, that long running debate was turned into a, one of the most popular Harvard business school cases, which has taught to every HBS grad that graduates now as part of the core curriculum, uh, in the marketing class there.

Um, but, and the way we kind of ultimately resolved it, like step one was we had to decide to decide, because previously we had kind of walked into rooms like, okay, we're not going to leave this room until we have a decision. And we like spend seven hours talking about it, uh, order food in and, and we kind of leave.

And that night. We'd be pinging you back each other. It's like, I know we made this particular call, but you know, what about this? And what about that? Um, but we finally did make the decision. Okay. Like sitting on the fence is, is just not a great way to do this. Um, and we made, made a decision and, uh, and, and moved on, but that's yeah, that's one example we had, we have those kind of long running debates.

Uh, we're much better about it now in terms of getting to a decision faster and we're much, much better about not, um, kind of second guessing ourselves. And once the, we use the phrase kind of sailing the ship, once we've failed a sale, they ship on a decision. We don't call it back to back to Harbor.

 so you're touching on a few maybe rituals or practices that you and Brian sort of shared over the years. I'm curious. Maybe you could expand a little on that in terms of the things that you did on a weekly, monthly, quarterly, annual basis that provided fantastic dividends for the.

 Yeah. The, the biggest one where know we are both, um, make people night owls. Um, so that kind of helped. I'm not sure the.

relationship would have worked as well. Probably we would have still made it work. Um, so that was, that was one thing. So we'd have these kinds of late night conversations and they were, when I say conversations, we almost never talked on the phone.

Um, cause neither one of us are our phone people. Um, and that's one of my quirks is actually do like almost zero, like one-to-one calls. I never answer my phone. I have made. Three four calls a year. Um, it's a little bit of weird, but anyway, so all of our conversations were asynchronous and this is in the kind of pre slack days.

Um, so it was all over email. And so we would have these kind of, and we were never apologetic about long emails. It's because that's sort of how we thought about things. So someone might kick off a particular locale. What do we think about this particular kind of market director or this new competitor that's come along?

You know, and it could be at the 50,000 foot level, uh, talking about kind of long-term strategy and it could be down in the weeds about a particular feature within a particular product. Um, but what was very productive is the fact that, uh, it was an asynchronous. So tactically that just works better rather than trying to schedule time.

Although it's a lower bandwidth conversation, um, you know, it takes longer, but the upside to it and we go back, um, through the kind of animals. Got HubSpot history all the time. Like we'll go back to old emails that, um, especially as new folks join, because there were things that kinda, we had uncovered in earlier conversations that Brian and I have had.

Uh, and the nice thing about that particular kind of tactic of using email as a kind of recurrent, um, collaboration mechanism is that we can then take snippets, um, or even entire email threads and pull a new person in. It's like, okay, well, Brian had been back and forth on this thing around, uh, some sort of product strategy thing, and let's bring in, you know, X or Y from the team, um, kind of catch them up or B get their take.

And it's a nice, smooth way to make that process happen. So that's worked out really well for us in terms of having that open collaboration kind of, and kind of putting our brains on speakerphone in a way by virtue of kind of writing down our thoughts in an email. So that's the one thing that jumps to mind, but then just books.

We read a lot. We both have always enjoyed reading prior to prior to HubSpot. And so, and I think this came a little bit because, um, we were such recent grad students. One of the values you get of having a co-founders and by the way, so we were both at MIT Sloan, um, and this was both a good thing. And a bad thing is that the next six hires that we had, or six out of seven hires in the early team were all MBA.

Students all went to MIT Sloan within like a three year, four year time horizon. We weren't all there together. And there are lots of downsides to that in terms of that was too much too homogeneous a team. If I had to do it all over again, I wouldn't do it that way. But one upside to that model is that we have.

Uh, a higher order vocabulary, having taken the same classes with the same professors learned the same business cases, read the same books, um, as part of the curriculum. Uh, so we could talk about, you know, something in like a sentence that would carry this kind of richness and all this kind of context with it simply because like, we had just done that case.

It's like, oh, this is like the capital of one case where, you know, we're, we've got an arbitrage opportunity so we can provide, you know, they're, they'd provide like the most efficient interest rates to make things fair for consumers. We could do that over here. And just by saying, it's the capital of one case kind of carried all that kind of richness of context with it.

And that that was useful. And so we took that idea of like, oh, it was very useful to have taken the same classes and read the same business cases and things into books. I was like, okay, if we read the same books, we can kind of point back and reference either entire books or sections of books or quotes from books and say, okay, well, this sorta applies to us.

What do we think? Um, and we've carried that not just between the two of us now, the management team at home. Uh, does that on a very regular basis, we don't do a like required reading, but we do highly recommended readings. That's like a, if you really want to be kind of part of the Richard conversation, it's going to be helpful for you to have read X, Y, Z book.

 one of the other things that I think you all have developed over the years is, is an approach to your own annual review. Um, and I was interested in maybe if you could talk a little bit about what does that practice look like and what are the pieces

 Yeah. The hard thing about annual reviews, uh, for, for founders and, you know, people higher up in the organization is that like you, you don't have a boss per se, I guess you could get your board. If you have a board to write a review for you that that has its own set of challenges with it. So what we did, uh, and have been doing, uh, between Brian and I is that we write each other's reviews.

Um, and we spend a lot of time on it, uh, because one of the other values we share is we both really, really believe, uh, And crave feedback, uh, when we like to iterate. So we'd like to kind of know how things are going. We love, um, love feedback. And so it's hard to get that feedback. Um, you know, when you're, when you're a CEO, you're a, co-founder just, um, from an org structure perspective.

So what we decided to do is that we would do each other's reviews on an annual basis. Uh, but it wouldn't just be, oh, here are my thoughts on Brian or Brian's thoughts on me, that person, whoever was doing the review was then responsible for talking to 15, 20 people in the team of their choosing, who they thought might give kind of most, um, color and context to how things were going.

Um, and then it was a of review writer's responsibility to kind of synthesize all the feedback, heard, add their own things in there, and then write this 10, 15 page review that we shared with each other on an annual basis. And then, uh, and then it would be a response to the review, uh, in written form that says, okay, well, I heard what was said.

Um, here are things tactically that I'm going to try and do over the course of the next year, um, to try and kind of improve those things. And there'll be, and, uh, this is a somewhat funny, funny thing is that, um, so when I write Brian's review, since I'm a product engineering guy, I write as a, as a kind of a product report and it's like a bug report almost.

It's like, oh, here are all the kind of bugs, uh, that people have reported back, right. About, uh, you know, the way you lead or the way you manage or the way you are. And, uh, just like if it were, um, uh, a kind of a product feedback thing, you know, some of those things Brian will come back with and rightfully so, he's like, well, that works as designed.

That's, um, I'm unlikely to change that. I do the same thing in the, in the reverse. It's not, not picking on him, but, um, and then we, and so we would version it. It's like, okay, here's Brian 4.0, and here are the issues. These are things people love about Brian 4.0, this new feature that you added over the course of the last year or two years, it has been received very well, but this. W we think as a bug, um, multiple people have cited the same bug. I think it's kind of holding, uh, holding you back and holding the company back. And, uh, one of the many things I love about Brian and he's, he is exceptionally good at receiving, uh, receiving that feedback. But, uh, but so the short story is, um, we spend the time, we understand how important it is.

Um, and there's some things that are just really hard to completely delegate to like a head of HR or, you know, someone else. And this is a practice that has worked well for us. And it also serves to kind of keep us closer and we can, uh, because we've been kind of friends and have worked with each other for so long, we sorta know, uh, where that feedback is coming from.

 when you're, when you're collecting the feedback from other folks in the organization, what are you asking them? What have you found gets you kind of the most crystallized insights or the, the most accurate bug reports from, from other folks in the organism?

 Yeah, it's funny. So in the same way I described it to you, I, uh, this is how I describe it to the people that I'm getting feedback from. Um, especially folks that are newer to the organization, which is, you know, I'm writing a, and I'll joke about it. Like, you know, I'm a product engineering person, so I'm writing a kind of product review of, of Brian and, um, and you know, what do you think is working?

What are the features of Brian that you kind of really enjoy that it's like, you're glad they're there. What are the things that are annoyances that, you know, if you'd like to fix, but they're not really keeping you from kind of doing your work. And, uh, and they're not critical, you know, we can kind of rank the severity of them, but I try and leave it.

Open-ended um, what I'm trying to do is not say, okay, well, I want to collect feedback from this particular person around how Brian interacts with the, the engineering team. Uh, even if I'm interviewing an engineer, um, I think. That kind of pigeonholes it a little bit too much. You shouldn't kind of request certain types of feedback from certain roles, because a lot of times we think we know what the interaction between, um, you know, Brian and let's say person X would be because of the role of the organization.

And it turns out, you know, some times people have much more useful feedback that might be outside of their immediate role or their immediate set of interactions. Right? Sometimes the feedback is not because of direct interactions they've had with Brian, but it might be around, they've heard Brian speak at public events or they ran into him, um, at a conference or whatever it might be.

Uh, so I try to leave it as open-ended, as I possibly can. Uh, it makes it a little bit harder to synthesize because it comes back in a relatively unstructured way. Um, that's part of the fun of it. And then you kind of look for patterns that says, okay, well this was unaided feedback like that. I didn't try to lead the witness in any way.

Um, you know, what came back here, people here are the things that kind of jumped to people's minds and they tend to kind of self-select in terms of things that are most impactful versus trying to answer your question. Uh, so I try not to be too specific. 

 When you think back to all the bug reports that you've received over the past 15 years, are there specific bugs that have led to the most significant growth for you personally?

 Uh, yes. And in both ways. So I'll, I'll give you one of each one is a reported bug. Um, and the bug was, we don't see enough of Dharmesh, uh, when he's in the office. It's awesome because we feel like we collaborate. We feel like we're connected. Um, and we really enjoy, and this is pre pandemic. Um, and I got that feedback for at least a couple of years, uh, and we'll keep popping its head up every now and then.

And my response to it has been that sort of works as designed. And so I understand the value of that kind of in-person meeting. But, um, the cost of that particular, uh, fixing that particular bug is exceptionally high for me emotionally. And as a result of which is exp exceptionally high for HubSpot, because that kind of one or two hours of in-person time on a one-on-one meeting or I'll do it.

Uh, but it's going to kind of ruin the rest of my day. Maybe the, maybe my week, because I am a, I have a lot of quirks, but one of them is around, um, I'm a super introvert like it's, and, and it's not that I don't like people. Um, it's just that I don't like being around them a lot, um, in, in, in person. So I'm great, you know, over long email exchanges, uh, I can, you know, hop on the slacks every now and then if I need to, but just that, um, it just takes a lot of energy out of me.

So that was one that was like, okay, I understand that this is what you want. But, uh, my apologies, I, I don't think I'm going to, I'm going to deliberately decide not to fix that particular one. Um, one that I did fix, which is around like Dharmesh, you know, you're kind of out there. We really don't know what you're working on or what you do or what you care about or like it's.

Um, and that was that because I was kind of hiding anything. It's just because I wasn't sure anyone really cared. I didn't want to distract the team with whatever random thoughts were kind of going through my head. Um, and so now what I did to fix that particular bug and still kind of aligned with my original, you know, like my alone time introvertedness is I started a series of Wiki posts, and then I write on the internal, um, it's basically an internal blog.

That's called Dharmesh as ponderings. And I'll talk about, um, things that I can't actually talk about publicly because it's, and, but the nice, good newsletters inside the company, um, doesn't leave the company and that's been a great way for me to be transparent. Um, and then people can opt in if they want to read that blog post on what I think about web three or what I think about whatever it happens to be on my mind at the time where I like, you know, made a particular decision I made, um, they can kind of get inside my head if they choose to.

 when you think about your own personal growth and evolution, when you get bug reports that you decide are worthy of you acting on. Do you immediately go to some system level change or practice in, in sort of like the example that you just gave us around, um, more internal comms to, to keep people abreast of what you're thinking about or what you're doing, or are there other ways that you actually go about implementing feedback?

And I'm always curious about this because I think in general, even if folks are good at receiving feedback, most people don't actually make a profound change and they just, you know, if they're not detail oriented, they kind of keep going on, not detail oriented and kind of implementing feedback is, is maybe trickier than one would imagine.

 Yeah, I think this is, uh, you know, we have some kind of base level features. What I call the HubSpot operating system, which is our culture and how things work at HubSpot. Um, and one of them is around, you know, we believe in autonomy, um, which is super important. So people have lots of discretion and control and lots of companies do that.

But we think the flip side of, um, autonomy is accountability, which is, um, you have to kind of hold yourself and your peers and your leadership kind of accountable for the things that they commit to doing, um, and accountable to our values. So kind of my motivation for doing that kind of series of Wiki posts around transparency.

It's like, okay, well, you know, transparency, wasn't hard. It's like, okay, well that's our culture. So I don't think anyone's gonna be bothered by the fact that I'm putting my kind of thoughts out there. Um, but in, in terms of the review responses, one of the things that Brian and I have done is, um, when we decide we're going to make some base level changes or like we're going to respond to, um, you know, uh, feedback from the review, we will share that, um, with all the employees, right.

We'll say, okay, well, here's what I heard back from my latest review from. Here are the bugs that are, you know, you might call them bugs, but I say they work as designed. Um, I'm not gonna address them and, and here are the things I am willing to fix. Um, and often I'll try to put a timeline around it if I can, if it makes sense, but most it's assumed that that'll be in the kind of following calendar year.

Uh, but it's, that's what I think, make sure that the change that should be happening is happening is that it's okay for someone not to make the change and they can kind of make their case for why they're not going to change a certain thing, but they actually have to kind of reveal that they made that decision.

Right. You can't just ignore things. Um, and so, and we do this, not just at the individual, you know, Brian and I kind of review level. we do a, a net promoter score survey for all of our employees. Uh, we do that poorly and have been doing it for over a decade now. And. That's basically like a bug report, um, for, for the company right there, just like you would have, um, a customer satisfaction survey or a net promoter score for your, for your product.

Uh, we do the same thing and we think of culture as a product and people submit their feedback and we will, we, as a, as a management team will say, and we publish it. Uh, the, the responses themselves are anonymous, but the actual entirety of that survey result is, is published both in quantification format of the classified form and say, here are the things we heard back, and here are things that absolutely, uh, many of you felt this way.

It's a big issue. It's a hard one to fix. And so here's the plan we're putting in place to, um, to make those changes. And then similar to how we do it on the one-on-one feedback. We'll say these are things, a handful of, you mentioned we understand where you're coming from. Uh, but we just don't think we're going to be able to make that particular change.

At least not. Now, we're not saying not ever, uh, but we're not going to be able to get to it. Um, you know, anytime, anytime soon, let's talk about it again. If it's still continues to be an issue. time. 

 before we switch over We didn't touch on your own role as a co-founder in the business and, and maybe how it changed over the last 15 years, or maybe in what ways?

Dharmesh Shah is the co-founder and CTO of Hubspot. He explores the 15-year journey building the company — from his partnership with co-founder Brian Halligan, choosing to never have direct reports, and treating company culture as a product. 

The biggest lessons from building Hubspot with co-founder Dharmesh Shah

CTO Dharmesh Shah explores the 15-year journey of Hubspot — from his partnership with co-founder Brian Halligan, choosing to never have direct reports, and treating company culture as a product.