What nobody tells engineers about becoming a CEO | Jay Kreps (Co-founder and CEO, Confluent)

For today's episode, I'm sitting down with Jay Kreps. He's the co-founder and CEO of Confluent, the data streaming platform built around Apache Kafka, the open source system he and his co-founders created while they were working as engineers at LinkedIn. In our conversation, Jay shares what it takes to go from software engineer to CEO.

I think the CEO job generally, you operate more in a kind of fog of partial understanding. Very quickly as the organization gets bigger, it's impossible to know everything about everything.

He traces Confluent's origins as an open source project and shares how they landed their first enterprise customers when the product was nowhere near done.

The software product that doesn't have nearly enough features, we've taken that out to very large enterprises that we have no business working with for more money than we feel at all comfortable with.

How a single blog post did more for Confluence adoption than years of engineering.

If we can't express why this is exciting, it's probably not going to be that successful of an open source project.

And why they bet everything on a cloud product than investors and half the company thought. Was a terrible idea.

We just kind of bludgeoned our way through. Like, none of it was pretty. Some of our biggest early customers quit on us.

Let's dive in. What's surprised you most? Like, you started the company as a software engineer.

Yeah.

And now you've had the full—

Yeah, I mean, lots of things have been— lots of things have been surprising. Probably initially the surprising thing was just how much of a jump in the deep end learning curve there is for going from this, you know, like the, I, the skill sets are almost exactly opposite, even though that's a, it's not uncommon, you know, for this kind of tech company, but it's still, you know, the set of things that you need to be good at are communication, your, the decisions you're making are very different. So certainly for engineering decisions, they're mostly knowable and there's mostly kind of right and wrong answers, but usually especially the early phase of the company, you're making a lot of kind of very big critical decisions with a lot of unknowable aspects, you know, but it'll certainly impact how the company turns out and you know that, but you don't know what the right answer is and you won't find out until later. So, you know, I think in a lot of those areas it's quite different than— I think the CEO job generally, you operate, you know, much more in kind of fog of partial understanding. I don't know that everybody understands that very quickly as the organization gets bigger, it's impossible to know everything about everything. And so you have to kind of be roughly directionally right. And people see this often in executives and it bothers them of like, oh, they don't understand that thing. And it's true, right? But in practice, you can't understand everything about everything. You have to understand a lot about the most important things and enough about some of the other things and try and make that judgment. The feel of doing that and how you do it, I think is, you know, probably also surprising if you come out of a, you know, you don't do that at all. There's no shooting from the hip.

In the first bucket, if you think about going from software engineer to founder and then over time founder to CEO, what's your clustering of the things you have to figure out at some point?

Well, it's a, it's a lot of things. I mean, I think CEOs need to know, you know, about 80% of what their executives know about their function, I think, over time. So really kind of learn that discipline, not enough to be good at it, but enough to be, to know what good is and know if it's going well. And so I think there's just a very long, there's a large learning curve because you end up having to understand a bunch of these disciplines. What does a head of marketing do and what are each of the subgroups of marketing do and how are we doing it and how does that apply in our business and What's the finance team for? And all those kind of things. So I think that—

What do you think? 80%, not 90, not 50, not 20?

Yeah. Yeah. I think it's just, yeah, I mean, ideally it should be 100%, but it's just not practically. If somebody's done that job for 10 years and you're kind of a dilettante who steps in every time there's a role to fill and then maybe manages it indirectly through them, 80% is going to aspirationally the best you'll be able to do.

For all of the different disciplines, as the business begins to scale, did you think about what is correct in the context of Confluent?

Yeah, I think that that's really critical. And I think each discipline, I always think of it as having some degree of kind of carryover, you know? So if you think about, say, a finance team, if you're kind of plugging from one SaaS company to another, how much is it basically the same thing, right? Everywhere. And how much of it is going to be unique to you? And I would say it's actually pretty high that it's the same across. So it's a very transferable discipline. And then, you know, I think when you get into aspects of software engineering, I think it's very transferable. Like engineering teams are relatively structurally similar. They'll have different concentrations and specialties, but it's not massively different. And then you get into something like product, it's quite different, right? I mean, there's obviously some transferable practices, but you actually need to make good decisions in that space about that thing. You know, I think each of these organizations has, you know, different, different genres. And so you need to know what, what genre of marketing team am I going to have? And that requires having some opinion about what the go-to-market is going to be like. And, you know, I think probably for early companies, that go-to-market construction is, is probably one of the areas where this goes the most wrong. Where you're effectively, you're trying, you're talking to people and you're trying to cut and paste what they've done into your organization, but without really thinking about the problem that you need to solve. And I think go-to-market people are often very execution-oriented. And so I would say they're often guilty of this where it's like, hey, this is the playbook I have done. I will do this playbook here. But ultimately, if you think about what is go-to-market doing, you know, it's trying to help the customer find you, figure out the value, make use of the product in some way. And that like particular journey is actually very unique for each company. And so you have to actually think, okay, what techniques are going to work well for us and which are not going to work well? You know, you see this a lot where aspirationally the founder would love to have kind of a very product-led motion, but in fact the product does not particularly lend itself to that. And you know, they're, they're, they're trying to will that into existence, but it's actually not You know, if you think about who's going to make a decision about using this thing and what they're going to go through, it's going to be very hard to do it that way. And so, you know, I think that's one, that's a common example of people trying to pick the mechanics independent of the problem that's being solved. And I think that's true to some extent in every discipline, but maybe go-to-market is the most common.

So did you find that you need to bring in go-to-market talent that was very pioneering and sort of curiosity-oriented, or did it mean that for far longer than you would ever imagine, you were intimately involved in all of these little—

Yeah, definitely, definitely my— I was pretty heavily involved in the go-to-market for—

Was that counterintuitive to start?

The way Confluent came about, there was an open source project that was out there and had some traction before the company came around. And since I was the CEO, as we were starting the company, it was a group of technical people. It was like, okay, we've got to go figure out how to get customers and sell this thing. And that was kind of on day one, an important problem to go solve. And so it was kind of natural that would be the case. The common example, you know, the common wisdom in this area, I think is exactly right, which is like, you know, the founders have to figure out how to sell the thing, maybe poorly, you know, but just kind of stumble through it. And in many ways, that early experience of, you know, selling our product was, I think, very valuable. Through the whole life cycle of the company. Because later on, much of what will happen in that journey has whole teams that do little subparts of it, but it's very hard for those teams to kind of think about that bigger picture. But just having gone through that process of like, hey, this is how people find out about us, this is why they decide to use us, this is what has to happen before they've got the value out of it, then you can kind of start to construct an organization that makes that go faster than that does it at scale. And so yeah, you know, in a sense I thought it was natural. That's always an area you're going to— and companies, you know, you always want more growth. You always, you know, you always want to move faster on that. So it's natural that that's an area you're going to put time into.

Maybe just so we have a little bit more scaffolding, you can give us the trailer version of the Confluence story going all the way back to when you were at LinkedIn, and then we'll use that as sort of a jumping off point.

Yeah, sure. I joined LinkedIn in 2007 and I think it was a pretty small company at that time. It was probably less than 100 people, but it had been around for a few years and it was an interesting time for software. I joined, you know, the area I had studied when I was in school and I was deeply interested in was machine learning, but it was kind of early in the use of machine learning in software companies. And I came, so I was looking for a role which would kind of apply this. Where I could kind of use these skills. And I thought LinkedIn would be a good place for it because there's very interesting data in these social networks about the world. And it just seemed like there'd be a lot of applications. So, you know, so that was kind of what got me excited and made me want to go there. It turned out in practice, it was pretty tricky to pull off that kind of machine learning-oriented product. I, I, you know, I worked on some of the data-driven functionality they had there around, you know, recommending people you would know, right? Or, coming up with the similar profiles, but end-to-end as an individual engineer, it was kind of hard to take something you knew and get the right products specified. You know, ultimately it was a relatively product-driven thing. And so kind of a, something happened and then a specification came out and then that was the thing the engineering team built. And so it was hard to kind of say, hey, you know, for these kind of relevance-oriented techniques, this is where the opportunity lies, at least for me as a software engineer early on. And so, I was, I was kind of frustrated by that. And then as a result, you know, I kind of realized like, hey, half the problem in any of these products is actually not the machine learning stuff. It's actually just the data, getting it, being able to work with it at scale, being able to apply it, being able to do that in the context of like a real running production system. And so I ended up spending most of my time on, you know, kind of data infrastructure. And that was early, you know, there, there's been a whole rise of cloud computing and open source and, you know, whole waves of data systems that are oriented at making this stuff easy. But this was kind of right at the very beginning of that. So you just didn't have most of it. There was a couple of open source databases, but nothing really built to operate at scale. And there was, there was a whole revolution happening around distributed systems and, and distributed computing that kind of Google was pioneering, but it was all locked up inside Google, right? You know, there was a period of time where there was a really significant need for scalable data technologies. There was no commercial offerings whatsoever that addressed that. And there was a rise of open-source technology, but none of it addressed that either. So there was just nothing, but everybody needed it. And you know, that kind of made it a really key problem for any of the technology companies of the day. And I felt that that was true for, you know, all the data technology that was out there, that there was an opportunity for any of the classical databases to have a kind of scalable version of it that would be important. And so I worked on that database for a while, but in the end it was, you know, it became not that unique. There was 20 other systems that were doing it and they all had different aspects of popularity. And then my scope inside of LinkedIn had grown and I, there was a couple different teams that I owned, including some of the analytics areas and some of the product areas. And so I was looking for, well, what, you know, what, what are the other problems that aren't solved? You know, if there's 100 of these key-value stores, what, you know, what's unique that nobody else is thinking about? And I felt like, hey, you know, it really is about the flow of data.

And so when you went and built the first version of the product, it was the customer was just LinkedIn. And what was the first version of the product?

Yeah, it was, I mean, it was just a very early, it was not radically different, you know, in terms of what it did from what the technology is now. It was not nearly as scalable or mature or didn't have all the features, but yeah, it was, it was kind of an early sketch of that, you know, that was built in part as kind of a side project. And then, you know, the goal for this was to replace a lot of these ad hoc pipelines that had been built up internally. Which turned out to be an extremely controversial and political project internally. Why? Well, you know, it's, uh, it's a funny thing about how these engineering organizations work. There's somebody who owns each of these things and their team's job is that thing. And so if you come in with something that's gonna replace a bunch of those, they're like, oh no, we don't want it. And you know, so some of the use cases I own, so we just rolled it out for that. Some of the use cases other people in the organization owned and we, spent 9 months talking about it.

And when you rolled it out for the stuff that you kind of could just rip and replace, did it click for you? This is hugely powerful.

You know, it was originally just me who worked on this and then we added pretty quickly some other really strong engineers, two of whom became my co-founders at Confluent, Jun and Neha. And yeah, you know, I think we got increasingly excited about it in the, you know, you could kind of, you know, you're onto a big problem when the number of use cases just keeps, you know, going up by like an order of magnitude that kind of pop out and where the problem you're solving seems really fundamental. And so, you know, kind of seeing that internally, we felt like it was a really big thing. You know, the goal was to really unlock a lot of the use of data, and I think it definitely did that internally. And so, and that kind of led up to the open source release and trying to take it out to other companies as well.

And so what was the— it was a very small group of software engineers working on this early version. What did it feel like? Was it like just you were early in your career working on cool technology? This is interesting. Yeah. What was like the energy of the team?

I think it was a, yeah, it was a high-energy group. It was very small. I think for most of the time we probably had 3 to 5 people. It was not some massive team. You know, I think, you know, we were very passionate about the thing we were doing. I think the open source part helped that once it, once it's a thing, then maybe the team believes in it more than they would just some internal technology layer. And I think it ramped up as the story of open sourcing, it was interesting. So we were very excited about this because we were already using it internally. We released it.

And it was not just your team's use cases. It now started to spread.

That's right. So it was broadly used internally. And so we we released it as open source. We assumed it would be immediately very popular.

And, but how did you decide that was the right time?

Just, it was far enough along. Yeah, it worked. We, you know, we were using it in production. Interestingly, it was kind of the opposite. So we, we'd had success with some of these other open source projects. You know, we, we released this thinking it was really the best thing that we'd done and just nobody had any idea what it was.

And it was very different than the first big open source release.

Yeah. So, so when we'd done the database before, it was very easy to explain what it was. It was a database.

Yeah.

People knew about databases. So this was like, hey, it's a database. It has less features than your other databases, but it's more scalable. So it was just very easy to explain what is it, where does it fit, what do you use it for? And then Kafka, this open source project, was very difficult to explain. You know, it was like, well, long explanation. It's about real-time data, it's for this. And you know, it actually took a while, you know, probably the first year it mostly sat on the shelf as an open source project, which we were quite disappointed about. And we then We really had to say, oh, okay.

But were you aggressively working on it internally?

Yeah. So internally, heavily used externally, by no means particularly popular.

Well, you said you felt surprised, but do you, did you feel like demotivated or did you feel like, I don't know why it's not catching on?

Yeah, somewhat, somewhat. You know, I, I think we were, you know, we had the courage of our convictions because I think we were using this internally and so we'd kind of seen it work. And so we put more energy into kind of getting it adopted, and eventually started to think about, okay, how could you get people very excited about this area? And so I ended up writing a very long blog post about it that really kind of caught on. And I think— Why? I think I put a lot of energy into it because I was like, hey, ultimately, if we can't express why this is exciting, then I think it's probably not going to be that successful of an open source project. And I think the blog post was kind of unusual in its form. It was like probably, I think it was like 25 pages long or something, weird pictures. And it was just, it was kind of entertaining, but also computer science-y. And then also talked about some of the applications of this kind of more real-time way of thinking about data. And so I think it was enough of a new way of thinking that people were, were intrigued. And I think that really helped the technology kind of catch on in Silicon Valley and eventually beyond.

But so before you put that out and after you put it out and it started to gain momentum, the product did not change. So it was really, your theory was it's a positioning and basic product marketing.

Yeah, I mean, the product of course continued to evolve.

Just get better and better.

You know, it continued to evolve, but it was effectively the same idea. So yeah, it was, you know, what was it that it took us probably several years to discover was basically product marketing, you know, in an open source context was, yeah, you gotta, tell people why it's interesting.

So maybe building on this just a little bit, if you had another software engineer who built a really interesting product and is trying to figure out how to do product marketing or explain it to a more technical audience, like what would you teach them or explain to them they should try to do?

It's interesting in this area that Confluent operates in, which is, you know, there's kind of very technical software products, it is often the case that when you see early companies that have quick success, I would say one of the defining things is often that the founders are very good at that kind of communication, you know, to a surprising degree. And so, yeah, what did I learn about doing that over the years? You know, first of all, just that it matters a lot and is hard, right? So like, you know, we would think about, you know, solving some computer science problem as being very hard, if you have a software engineering background, you don't think of product marketing as being hard, or maybe you think it's hard, but you don't know how to engage in a hard thing like that. You think, okay, maybe some people are good at that, some people are not good at that. But in fact, I feel like a lot of marketing, it just takes a lot of thinking. So the amount of time you're going to think about how to convey the thing is just much higher than you would expect. And the level of detail you're going to put into how you do that is just much higher than you would expect. And so That was one of the first takeaways. The second takeaway, this is all kind of like Marketing 101, but it's true, is marketing messages are ultimately kind of a pyramid, I think, where at the top of the pyramid there's some gestalt message. It's like, what's the title? What's the slogan of the blog post? But it's not enough to just have that. And people often think of marketing as just being that, as, oh, it's some slogan that we slap on it or it's some whatever, which is actually totally wrong. You need the rest of the pyramid. So what supports it is all the evidence, right? It has to be the people using it who are doing that thing, the truth of the long-form argument for what you're saying. The slogan kind of sits on top of that. And when you see things that don't work, it's usually because they're either missing the top of the pyramid. Like there's lots of examples, but they can't boil down to what it is, or it's the opposite. Like they have some slogan, but it is not supported in the broad set of facts that would be the rest of the pyramid. And so I always think about these things as just kind of construct that full pyramid.

Do you construct the top or the bottom first?

Bottom. I think the top has to come later because, well, not, I don't know about later, but it's a distilled version of what you think. So your first version of this will not be the pithy one-line statement, right? It takes a while to get to really understand how to boil it down in a way that actually you're never in a short statement going to convey a very deep truth except by reference to a larger set of things, right? So you have to kind of almost build the body of work before you can boil it down, but you kind of do both together, I guess.

What's the best example of this from all the years building Confluent?

One example for us was, you know, as we were preparing to go public, one thing you have to do is explain your company to investors. In a different class of investors than venture capitalists. Venture capitalists usually are a little more specialized in tech, will do a little bit more research, you know, so kind of public market investors just by nature, they— there's fewer public companies, right? And so they have to generally make their money across a broader set of things. And so they're going to be less specialized in your area. And especially as you're new and coming out, you got to really kind of boil it down. And so I do— I thought that was a good exercise for us. How did that exercise go? It was like, well, what, what do these people understand today? You know, what is the frame of reference that they have? How can we connect ourselves to that in a way that helps them understand the opportunity for the company, why it's a big deal, you know, why it's a strategic technology. And so we put a lot of effort into that. You know, what we came away with is like, okay, these people understand databases because there's been a lot of successful database companies. So if you want to explain what you do, don't do it from first principles. Just say, how are you different from a database? And similar, I guess. Yeah. Yeah. And so our approach to that was for the IPO was very much like, okay, databases, data at rest, but now all the parts of the company are connected. There's going to be an equally important problem of data in motion. And so, you know, the goal was to convey, hey, these two things are related. Everything that's at rest has to also be in motion. So the opportunity could be equally big. You know, it's caused by the parts of the company all having to talk to each other in software, which probably wasn't the case originally. And you know, that kind of implies a large TAM, you know, not in terms of detailed analysis, but just in terms of, you know, you're comparing to something big and it gives an anchor for what the technology is and where the company sits. We're not an operational tool or something like that. You know, and a remarkable amount of thought went into something that is kind of small, but it's actually very important if you're going to kind of come out to a new audience. And so I think audience by audience, you have to almost work through that. You know, the companies that are often the punchiest and best are very early companies where there's typically just one audience, which is like the user. And then over time you may have a whole set of, you know, if you're selling for more money, you'll have a whole constituency, user buyer. You'll have your internal employees, which are now a large enough group that you need to think about your investors. So yeah, and usually as companies, as time goes by, as a result of that, many things become more watered down because you're trying to say something to a bunch of people who have very different contexts. And you notice this, that companies kind of lose the edge in communication as they get bigger. And it's, it's almost inherent because you just have to talk to more people.

Winding the clock back, you have this magnum opus blog post And so then what happens after the next few months? Did it like instantly click hacker news kind of resonance?

Yeah, so the people were very excited about the blog post. That definitely helped the kind of spread of the technology. I, you know, I, we went and did talks as well in some of the tech companies and, you know, it really did start to catch on. You know, people were, I would say, passionately excited about the idea. It matched problems that they had that were top of mind. And yeah, that, that was kind of what led to starting to think about turning it into a company.

Was the usage of the open source product, did it look like an exponential after that?

Yeah, we, we, yeah, we had no real measurement there. We didn't have any kind of detailed tracking or anything like that, but certainly just in who we would hear from and the types of companies that were adopting it. Yeah, that, that looked like a pretty nice growth curve. It was never, you know, this type of technology is some work to adopt. So it was never just kind of rocket to the moon. And that's been true through the whole life of the company. It's been, the open source has kind of grown steadily, you know, kind of a line going up for that whole time period. But it wasn't like, you know, went from zero to infinity overnight.

What did it feel like as you were thinking about, do we want to start a company around this?

You know, I think actually my my co-founder brought it up, but I'd had kind of a very similar idea. And so I think to some extent we were kind of thinking in that way. And I think it came about sort of naturally in that, you know, we were hearing from companies that were well outside of tech all of a sudden. So, you know, media companies and banks and, you know, that, that kind of helped us understand, okay, what do they have the same problem? And it turned out, yeah, they have the same problem, but, you know, maybe bigger in some ways. And So we felt like, okay, this could be very, you know, this could be applicable broadly. And, you know, then it was just, hey, is there a form of company that would fit this? You know, effectively what we had was an open source project. Now, you know, there's more of a pattern for how this works, but at that time, I think companies around open source were seen as kind of not very successful. There had been—

and a lot of people had tried it at that point.

Yeah, there'd been Red Hat and that worked. And there, you know, there'd been some companies around Hadoop, that kind of struggled, you know, just was not seen as like a great paradigm.

Even in the early 2010s, developer tools in general, I think were a much more skeptical category, just broadly.

Yeah. So people were, yeah, not that excited about the whole space and that obviously made it more challenging for us coming in. We kind of understood, okay, this is not, not exactly a hot area, you know? And I would say even in the crowd we were in, probably enterprise generally was not necessarily the thing. You know, we had, we'd kind of come out of a social network and that had been the, you know, the big marquee companies of the day were definitely those, you know, it was Google and Facebook and so on. It wasn't, you know, it wasn't whatever the equivalent enterprise thing was. And this is 2014. So it was, you know, kind of right at the rise of a lot of the SaaS stuff, but that was, that had not kind of broken through at that point. So yeah, we were like, you know, this is a really good idea. This is a really good technological idea that doesn't have a really easy company form and is hard.

But you thought a lot about that.

Uh, we thought a lot about it. So we were like, well, what are we going to do? Maybe we package this up into some kind of vertical solution or something, but that didn't really make any sense. And then we're, you know, eventually we were like, look, we should just, you know, just take a product to market around this. Just do the obvious thing, like build this into a product and take it out to people. In 2014, that was just where it started to be clear that the, you know, the cloud was gonna be a big thing, right? But at that point, everybody believed it was just really AWS. Like there was not gonna be any other companies. So it was, you know, it was, it was a really interesting dilemma of how you would try and construct a company. 'Cause you have this cloud thing that's happening. That's maybe, I don't know what, 5, 7% of IT spend or something, some small percentage. It's really just Amazon. You know, it's unclear that anybody can live in that ecosystem around it. The kind of open source on-premise companies had not done that well. So that was the dilemma coming into it was like, okay, can you, and we're a category that doesn't exist and nobody has heard of. So can you get something going in that dynamic? And if so, how, you know, I think that, that was kind of the challenge. Now being software engineers, I think we dramatically overthought this. We spent probably 9 months thinking about how to do it. And the end—

was it mainly inside with you all talking amongst yourself, or were you getting out and understanding customers and understanding like what, what was the mix of the 9 months?

Yeah, we did go meet. Most of it was us theorizing, which was probably not that useful since in the end we just did the obvious thing. We did go meet with a bunch of the users of the technology and just be like, hey, you know, is this important to you? Would you, you know, what would a product, more of a productized version of it look like? Would you pay for that? And that, you know, that was pretty enthusiastic. The, you know, people were passionate about the technology. So of course they'll tell you yes, even though maybe they will or won't be customers later on. You know, I think that combined with the impact internally at LinkedIn kind of carried us through. So even though it was like, okay, not the most appealing area, not a really clear product path, we felt like, look, there's like fundamentally there's something very valuable here. We should just do it. And, you know, I actually think there's something to that. You know, I, when I've seen people who create companies in kind of a very top-down McKinsey way of thinking of like, okay, market analysis, like in some sense it actually works less well than just like marinating in some problem where you're convinced that there's like a really meaty chunk of value. And then even if you don't have the rest of it figured out, like you're kind of in the right spot. And, you know, I think to some extent, I think we, we understood that part of it. We were like, look, this, Data infrastructure, even though it's very uncool, is actually really valuable to companies now, and they're going to want this. And this problem that we're solving is a really valuable problem. So somehow we will be able to get some of that value, even though prior examples didn't go that well.

What was the first version of the product? How did you conceive of it? And it happened after you raised capital or before?

You know, it was a, it was an interesting kind of occurrence. So the, yeah, the idea was we were, okay, we're going to leave LinkedIn and go figure out the, details and put together a company and probably eventually go raise money. When we went to quit, LinkedIn was like, oh, okay, this is, first of all, we don't really want you to leave, but if you're going to leave, we do think this is really valuable. We would be interested in investing. And we were like, okay, off the balance sheet. Yeah. Yeah. Which they had not done in the past. You know, we were very unconfident in our ability to raise money. So we were like, okay, this sounds great. We should totally do that. And, but they were like, well, because We don't do any investing. We kind of need it to be a priced round where somebody else is helping set the price. It's not just us assessing our own thing. So you should go try and find some VC who will participate as well. Yeah. So we were like, okay, we should do this and we should do it before they change their mind because maybe they, you know, maybe this goes away if we let it sit too long. And so, you know, we went from kind of thinking of like, okay, we're gonna We're going to quit our jobs and we're going to cultivate, you know, figure out our product and build some early version and get some first customers to like, oh, okay, now we're going to go fundraise right now for a company that is not incorporated and doesn't have a name. That actually was probably the right thing to do.

Why was it the right thing to do?

First of all, I think it helps if there's interest. And for us, I think it helped that the company we were at was interested. I do think with a little bit of homework, we would've done a much we would've done a better job of putting that fundraise together. But in practice, I think a lot of VCs are used to some of the rough edges and can kind of see, they can kind of get past that if there's some traction and something happening in the world. And if there's interest, that always helps. So I think it was probably the right thing.

So then you raised the money with no product, no nothing other than the promise of what you were going to do.

That's right. Yeah. Basically we had a popular open source thing and some slides of what we would do. And it went from something where LinkedIn was going to be the kind of major investor to being you know, a smaller part of the round and it went from kind of a seed investment to a Series A through the course of that fundraising process. But yeah, it was, was ultimately successful. We benchmark invested and we were really happy to have them. You know, that was Eric Fisher, who was awesome part of the company from early on.

How close was the V1 of the product to kind of what you hashed out on the slides?

Yeah, it depends on what you call V1. You know, what we had pitched was actually very close to what we built. It's just that I said we were going to do it in a year. And I think in practice, the first thing we launched was much less than that. And to do everything on the slide took like 5 years.

And so what was the very first thing you put?

The kind of founding dilemma for us was, you know, we had at LinkedIn, we had really run this software internally as kind of a service. And so the, the early dilemma was like, hey, are we going to release a software product? You know, that's more applicable. People can use it in the cloud. They can use it in their data centers. Cloud is still a small fraction and unproven as a business model. Or are we going to do a cloud product where we feel like, hey, there's more value we can deliver? And of course, anybody you talk to is like, in a small early company, do not. The right answer is not both, it's just pick something. But that was actually not clear at all either, right? Because, you know, it's okay, we're this $0 billion data streaming market. Are you really going to slice it in half and be like, oh, we're, data streaming for the people who want it in this flavor. Uh, that didn't sound right either. Pretty early on, we were convinced we had to do both. Again, the starting with software was actually just pure expediency. It's easier to get a first version out and that would satisfy more of the market. And so we started with that. And then I felt a lot of angst about the cloud offering. And, you know, at that time, you know, as we launched, Amazon had a system that was actually built in I believe, imitation of Kafka called Kinesis. So it was incompatible, but kind of looked roughly like it. And that was popular and we were like, oh man, that's gonna take the opportunity. And if it doesn't, they'll build something around the open source, which they did. You know, so we felt a lot of angst of, okay, we've got to get this managed service done, but it's very hard cuz we're, you know, we're, there's a very small engineering team. We've just built this software product that doesn't have nearly enough features. We've taken that out to very large enterprises that we have no business working with successfully for more money than we feel at all comfortable with. And then we're like going to somehow pull resources away from that and build this managed service, which is a very big undertaking, and try and get that working. And, you know, we did start that pretty early in the life of the company. You know, I think, I don't know when we started working on, maybe we were a year and a half in something like that. And then it took, over a year, I think, to really get a first version of the cloud offering out there.

When you built and shipped the software and you started selling it, did it feel like we have real pull? People wanted it, people wanted to pay for it. Like, what was the feeling inside of the company?

It was good. I actually didn't know enough, you know, nothing. It, to me, I always felt like it didn't seem big enough. Like we didn't have enough customers, you know, the dollar amounts didn't seem big enough, but they were actually very good. For an early enterprise company. I just had no reference to what it ought to look like. And so yeah, very quickly we were getting lots of $100K+ deals coming in, but to me it didn't feel like a lot. It would be like, oh, we got 4 deals this quarter, but it was still, it was pretty good for like a company that was a few quarters into selling. So it, it, it moved pretty quickly. The angst was like, hey, we, we have this popular open source with a little bit of functionality around it. We have, which we haven't filled out, are we justifying the value that we're charging or does the bottom fall out because we just don't have enough kind of meat in the sandwich, right? And so that was very much the competing tension on the product side was, okay, we have this one product which has traction, people want it, we're landing big customers, but there's not, it's 10% of what it ought to be. And then, and in terms of the role, we wanted to increase that scope. And so we were kind of building things to do that. And then there's this whole other delivery mechanism, which is kind of a top-to-bottom rewrite, which really serves a different set of customers and people who are more cloud-native, et cetera, which we also have to—

and the people that started to pay you $100K or $200K or $300K, they could care less about the cloud offering. So they were pulling a different feature set out of you.

That's right. The early customers, you know, again, we were very market-driven. So, you know, we knew that like, okay, the kind of tech company that we'd come out of, mostly they would not buy a licensed software product. They would just use the open source, right? Or they might use a cloud service. You know, they would, they would use cloud services from Amazon. Would they use a cloud service from Confluent? We didn't know, but we thought that was the hope there. But where the early customers were was, you know, effectively large enterprises. You know, that comes with its own difficulties. You definitely need real kind of field team. The contractual stuff is a huge, list of items you have to do. So there was a big kind of overhead of that, but it was working, right? We basically had kind of large marquee enterprises, big banks, insurance companies, retailers who were—

In the first 12 to 24 months.

Yeah.

And did you start to bring in some traditional sales talent at that point or you did it all yourselves?

No. So I did the first set of early deals and then I started to hire individual reps that would do end-to-end sales or that would kind of begin a process and bring you in? Yeah, yeah, yeah, yeah. Basically the latter, you know, so I was still involved in meeting all the customers or one of my co-founders would be.

And did they come out of the domain?

Yeah. So I think we, you know, the early sales reps were experienced in the area we were in. I mean, not our little niche and the closest thing we could find. And they had worked in very early companies and we gave them a lot of equity.

And they were IC sellers.

100%. Or who had, you know, ICs who had also managed maybe small teams, but not— Oh yeah, right.

Not VP sales, whatever, CRO, whatever.

Yeah. And I think that's really a worthwhile investment of, I think you can kind of amplify the founder-led sales thing quite significantly with just a few people. But you need people who have been successful in early companies where they just don't have—

Not Oracle or whatever.

You know, there's no product marketing. There's no, there's all these other things you just don't have for them. but you have something, you have a deck that you've kind of scrapped together, but they just have to be okay with that and be able to fill in the blanks where there isn't scaffolding for them. And I think people who've been in early companies can do that, but the, the average sales rep coming out of a large company is going to be kind of like, WTF, this doesn't seem right.

There's actually a lot of lock-in with these products.

I think you could think of it as almost game theory, right? The selfishly for a provider, you would want as much control and leverage as possible. You would want, you know, as much differentiation as leverage as possible. Selfishly as if you're the software provider, right? If you're the buyer of the software, you want a complete commodity, right? Neither party is going to accept that. And you're kind of trying to find something that's the, and you want as much differentiation as possible because that's how you generate pricing power and market share. You know, fundamentally what, if you think of what is, you know, open source is maybe the purest commodity, right? And so, you know, if you're trying to sell a product which is purely open source, effectively the price of that product should collapse to the cost of providing it, which is based kind of at scale of zero, right? So, so there's no business in selling a pure open source software. You know, the business is going to come out of selling something which has some amount of differentiation and the more differentiation, then the more, you know, you could charge, but the customer has to, you know, accept that and want it. And so they're, you know, and they're gonna weigh those factors. And so if you look at how these businesses have evolved, yeah, they, you know, they have to really prove themselves and provide that value to customers. And customers have to feel okay. And indeed customers can move off of the, you know, any of these more open systems more easily than they could something purely proprietary. But it's not the case that the companies have no stickiness either. In fact, you know, if you just look at kind of revenue retention statistics, it was actually quite good. And so, you know, so, so if you think about it, the industry has kind of found a balance where you can build a successful company that captures some amount of value. It's not as complete capture as if you had full leverage, but it's also a better deal for the customers. I think it is the case that some of these early infrastructure offerings, you know, that it goes too far where the lock-in is so tight that the vendor can actually extract in some sense more than the value they create because moving off of it is such a nightmare at that point, which becomes a very negative thing for the customer, right? So yeah, I, I think it actually works out relatively well, but there on the product side, there's finding a balance of enough value and differentiation and enough openness. That's kind of the tricky bit.

So you had the software product that was selling well and meeting the demands of a number of enterprise customers in the first 12 to 24 months, and then you decided to build the managed service alongside it, even though it felt tricky because you had a small team being spread.

Totally. Yeah, totally, totally. So that, that, that was probably one of the more difficult things that we had to do early on.

How did you have the confidence to do that, particularly 'cause you'd never done any of this before?

There's always two lenses in a company. One is what can we do? And then the other is what do we have to do? And so what can we do? That's like an opinion from the team. What do we have to do is kind of imposed by the world. And so you kind of look at these things and you're like, okay, can we do two products at the same time? And it's like, I don't know, maybe we can. It's going to be very hard. Most people would say, don't do that. That's a bad idea, all else being equal. But if you look at what do we have to do, we absolutely have to do this. There's no question that a huge portion of the market is going to be in the public cloud and nobody in the public cloud is going to want to consume a licensed software product. So we have to have that part of the market. For me, at least, I felt, okay, it's very clear that that's like an existential thing. So we just have to do it and then we have to find a way that it can be done. And I think that's actually a very important takeaway. I've found that's often true that, you know, teams, because they spend all their time thinking about how to do something, they become very fixated on what can be done. And it's actually very important to step back and be like, hey, to be successful in this product area, what do we have to do? And then, you know, it's weird. Once you know you have to do it, then you find a way to do it. And you know, this phenomenon is seen elsewhere. Like the, you know, I think the famous, you know, whatever business book example is like the 4-minute mile or some marathon time or any of these sports things, which once You know, for a long time it's seen as unachievable. And then as soon as somebody does it and you know you have to do that to compete, then everybody does it. So in other words, the— it becomes possible once people know they have to do it. And so I think that's, I think that's an important view, but it was just very clear, we have to do this. It was just very difficult. Like we understood on the engineering side, okay, that's a very different delivery mechanism. You know, it'll be a lot of work to build. And we'd prepared for that. From early in the company. So we were kind of, we thought, set up to do it. It was in fact much harder than we thought. There's definitely a methodology for that, for any company that goes multi-product. We didn't know the methodology, so I think it was just blunt force was, you know, just continuing to focus on it until we did it. It was controversial internally. Probably half the company thought this was like the dumbest thing ever. It was still not the case that most of the market was in the public cloud. It was, the product wasn't really selling, you know, it was basically harder to sell and we made less money and the economics were worse. You know, some of the, you know, I, I think even some of the investors were kind of like, what do you guys have? Like on paper, like the best enterprise business ever, and you're putting all your energy on this other thing that kind of sucks. Like if you, if there was two standalone companies, we would definitely invest in this one and we would definitely not invest in that one. You know, we just kind of bludgeoned our way through, like none of it was pretty. Some of our biggest early customers quit on us because the product did not meet their needs in various ways, right? They either outscaled us, the limitations were too embarrassing. You know, the challenge for this kind of infrastructure is customers often kind of start small and then kind of, you just have to do whatever they need to do in there. So everything they could flexibly do in their environment, you have to have that capability, but kind of fully automated, and you have to be excellent at kind of at-scale operations. And yet the promise of these kind of fully managed cloud infrastructure offerings, that's kind of an easy thing to do for like application layer software, but hard for these big distributed data systems. But promise is, hey, it's just going to kind of run itself. So it's like a self-driving car, you know, but the feeling if you're in a self-driving car that crashes is not so good. You're like, yeah, if I'm holding the wheel, sure, maybe I get into a fender bender once in a while, but at least I know what's going on. And yeah, that early cloud product was very challenging.

But to build on the metaphor, it did feel like when you were working on it and you were making the promise à la self-driving, that everybody continued to be excited about the promise. It was that when they used the product, it was not delivering on the promise. And so it, you knew that the, you knew that if the promise was delivered on. There was a there there.

Yeah. I think in many of these areas that we've pushed through something hard, you know, I do think it starts with conviction of like, okay, this has to work, therefore we have to make it work. Like the fact that it's not working now is not relevant to what has to happen. And so, yeah. So, but, but nonetheless, it was a big struggle. I think inherently that a second product is always kind of irrelevant to people's main goals. And the, all the pressure of a business is to satisfy the customers that you have, the big prospects coming in the door, that, that kind of main flow of business becomes this like magnetic force. And so, yeah, we, you know, we really just had to force feed it in each area. So I think for the engineering team, we originally, it was like a small group that was working on the cloud offering and then we were like, no, okay, everybody only does the cloud thing and we will work on the software product in our spare time team by team, which is a very dangerous thing to do because that was where all the money was.

It didn't work to say we're basically just going to split the company and have two companies, two go-to-markets, two engineering teams.

Yeah, because many of the fundamental components were shared. So what would happen is, okay, the cloud team's trying to build this fully managed thing. They need the Kafka part to work for what they're doing. They go to the Kafka teams and look at all these, this customer needs this and this customer, and what do you want this for this science project? Yeah, totally, totally. Or a small amount of money. It was just, You know, where is the pressure? You know, the same on the sales and go-to-market side was just really breaking out every single goal for cloud and treating those numbers. There was just an extra zero or two at the end. Like that was the thing until it worked. And it did. We eventually ground through that kind of painful part. Interestingly, the product was growing quickly early on. It was just very lumpy and uncomfortable and off such a small number relative to the rest of the business that it just looked like zero.

Was the rest of the business in the tens of million— like what was the scale of it?

Yeah, it was over time. Yeah, we were probably in the tens. The early Confluent grew very fast off the software product. And I think we got to $100 million in revenue just very quickly after.

And so the software product is like at $100 million and this is—

Yeah, well it was, it was different points along the way, but yeah, we, we started it in, you know, we started working on it probably in our second year of selling in probably by our third year of selling. It was on the scoreboard, but just looked like an embarrassing failure. And then, but nonetheless, it was going up. It was just, it just didn't look like it was catching up. And then as we kind of rounded the corner on some of the product functionality indeed, it started.

For you, did it feel on the managed service that there was a crossing the chasm moment, line in the sand, or was it just a little bit less shitty every single day forever?

Basically. Yeah, it was, it was mostly the latter. You know, I, I always feel like the crossing the chasm thing is the, promise, you know, can you make this promise? And then the, the 100 things required to deliver the promise. That's the thing we were chipping away at.

But it never felt like on, on the Actu product that there was this massive phase shift and we got to the last brick slid in.

No, absolutely. So yeah, it definitely wasn't one feature that we did, but just you would see in kind of our results an inflection where it really started.

When you reflect on What about yourself has allowed you to be successful as a founder and CEO, specifically at the, also the first time you've done this? What about you as a human do you think were the input drivers to it? Or like, what's your working theory of it?

I think there's probably two things that were helpful for me. You know, there's, there's probably 15 things, 15 ways in which I'm unsuited to the job, but the two things that I think were helpful was You know, the first, just being curious and wanting to learn about all the parts of the business and how it worked, our customers, how they work. I do think that, you know, even people who come into a CEO job in an at-scale company coming out of a different discipline, I do think the CEO role is probably more multidisciplinary, you know, so, so you ultimately have to be very interested in learning about the market, learning about the customers, learning about the competitors, learning about each function. you know, in a way that's probably broader than many of the other executive roles. And, you know, even as a software engineer, I'd, I'd always just been curious about stuff. And software engineers probably generally are in learning mode more than many professions, even if it's not in that broad way. And so I, I think that was probably a good asset. And then I'm also just tenacious. I'm not necessarily an optimist. Like, I think it helps if you're an optimist. As you were saying, probably some of the best founders are just these inherently optimistic people. But, you know, if you don't have that, then I think it gets you there if you're just determined where you're like, well, okay, the probability is only 20%, but we're not going to give up until we've lost all hope. And then, you know, that, that turns out not to be as inspiring a message. So you may want to dress it up a bit, but yeah, I think just willingness to kind of keep working on things, you know, well past the point where it's a bit painful, you know, I think is important. And I, you know, I think that kind of whatever tenaciousness, pain tolerance, you know, I think that couples, I think that's actually probably the most important ingredient for the willingness to kind of go after the things that you have to do. So I do think especially in early companies, but probably in all companies, you know, there's these kind of big threats or bad news things or things that will kill the company. And the tendency is nobody wants to talk about that stuff. But I do think you have to just kind of lean into those things and get them figured out, right? Get them addressed, whatever it is. And I do think that's again, kind of back to the just tenacious part of it. And I, you know, I have come to believe that it's not enough on its own, but just not giving up on something, you know, for an extended period of time, it actually gets you pretty far. And I've found that in competitive situations, in other situations that if you just keep working on it. Like you'll keep improving and other people will kind of tap out at some point. And if you don't, then eventually you will kind of get there. And maybe it didn't look pretty at first, but it'll look pretty if it eventually works. And I think that thinking goes a long way. I don't know that it's a blanket rule because of course there is some point in time.

Are there things that you were doggedly pursuing in the context of Confluent and then you eventually did wave the white flag or whatever the expression would be?

Yeah, I mean, we mostly, we mostly carried through on things.

Would you say if that's the case, is it because you were correct, or that in the process of grinding through—

Yeah, it's probably both. I mean, I, I guess I would caveat this. So obviously you wanna be very flexible about some of the details of how you do something, right? That's the whole point is to change your mind on that. And then I think on the big things, do we need a cloud service? For us also, we've wanted, one of the more recent versions of this was we felt is very important for the company to do the processing of data, not just the flow. And we worked on this largely unsuccessfully for a number of years, right? And so it was just kind of products that didn't take off. In the last few years, that's really started to take off for us as part of the business. But to get there, we, we actually did give up on early versions of the product we'd done in that space. And so I guess, you know, I guess you'd have to be thoughtful about what was giving up versus not giving up. I think it was logically true that we had to have a cloud product. I think it's logically true that Confluent has to do the processing of data to like have strategic importance. So you kind of can't give up on that just because you haven't succeeded yet. Like you had, it has to work. And then the how you get there, you know, you're just going to keep trying, like strategy, people, whatever has to change, you're going to just keep trying until you can kind of make it move. And, um, you know, I, I think once, you know, in a very early company, you may not have that much runway to do that, but once you have at least something in the business working, then you usually, usually you have enough time to kind of keep working at the things that have to work. So I think just being very clear of like, hey, what, what is it that must be true for this thing to succeed or be at the next level? And then am I really confident that we're on that trajectory? And I feel like those two things often are missed, right? People are not clear on what really must be true, or they tell themselves kind of a happy story that the things that are already working are really the only things that matter. And then are we really on that trajectory? I think that's another one where people often, if you don't know how to fix something, then you often tell yourself it's good enough, right? But in fact, it's not. And that may be about the people doing it. It may be about the product approach you've taken. It may be about something else, but you kind of know, okay, this is not working the way it should. And I think when you don't know the answer of how it should be or how to fix it, I think it's very uncomfortable to say, okay, like, this is not happening. And then, but until you say that, you can't really figure out what to do about it.

When you're off on trajectory and you look at the root causes across the sort of different trajectories of the business, is it more often X or Y or it's evenly distributed? Meaning 80% of the time when you're off trajectory, it's the wrong person is in the seat. You fix the person at, you know, or is it just, it's 20% that it's 20% the product philosophy is wrong. Maybe 20%, it was just a year too early and the market wasn't there for it.

I think it's actually all of those things, a disproportionate percentage is people. But I do think also sometimes in organizations, people somehow become trapped in basically a failing mindset and methodology. And so like part of the people change is actually changing, is opening the aperture on what that part of the org is willing to try. And so, yeah, I think that debugging process is one of the hardest things I think in any company. You kind of have some top-level result and you're like, this is not what we want. And then ascribing the cause of what's not working well is actually shockingly difficult. I mean, you see it all the time. Typically it always comes back from sales, right? People are like, well, it's not, you know, sales are not good. So what's the problem? It's like, okay, the sales leader's bad, right? And it's like, well, it could be. And you know, that certainly could be, and it commonly is, but it could be every other thing in the chain of value leading up to that. You know, I think that's often one of the most maddening parts of these things.

Or across the years of the business, do you personally spend a lot of time on this diagnostic work?

Yeah, absolutely. So anything that's not working at a high level is inherently cross-functional. And you know, you'll see a weird phenomenon where people in each function are often don't have enough global context to totally diagnose it. They may, but it's often depending on their personality. Some people think mostly about their function. So like, you know, you'll see some people where if they're— something is not working and they're on the product team, they inherently think it's we don't have enough product features, right? And it's like, well, it could be, right? But it could also just be we have no idea how to sell the thing. But you are not thinking about that. You're thinking about the product functionality, right? Other people who are the opposite, where they tend to just kind of blame some other part of the organization out of defensiveness. So somehow I do think the CEO is in a good position, you know, if it's important and it's cross-functional, I do think you're in a good position to kind of put the puzzle pieces together. It doesn't mean you're doing that in isolation. The way the CEO does things is just go ask everybody like, hey, why doesn't this work? And then take all the answers and be like, okay, try and figure out which of these makes the most sense. And what do we— if that was the case, what would we do? But I do think often the CEO is in a good position to do that. Because it, you, you have to think very flexibly across about changes across different parts of the org.

One of the things I wanted to go back to as we kind of start to wrap up, you shared this idea of spending a lot of time figuring out what you must do, not what you can do. Is that instantiated across the company, across the whole history of the company in some way, or is it just an idea that you hit the drum on and mention all the time?

And yeah, probably more of the latter. We didn't turn it into like a value or management principle or something like that. But I do think it's kind of a common refrain of like, especially as a company gets bigger, it's very difficult. You know, a natural thing if you're one team that needs to do something that touches 5 teams is you go to the 5 teams and you're like, hey, this is what I need from you. And everybody says, oh, I can do it, or I can't do it, or if I could do it, I could do it in 12 months or whatever it is. You put all that together and you're like, okay, here's what's doable. We can do this project and it's going to take 2 years. And that's kind of the best answer that we've gotten out of all these people. So that's what it is. And I don't have any magic wand as a person in the company to change that. And so the lens that's very important for, you know, really that whole group of constituents is like, okay, how important is that thing? Is that good enough? Right? Maybe 2 years is fine. If it's not fine, then the fact that that was the best we could do is not relevant. Like we're not, we're not, we're going to be unsuccessful if that's what we do. And you know, it's weird how these things work. Everybody who has found this with headcount, with budget, with timelines, you know, if you kind of just go back and say, well, okay, you know, what would the 3-month version of it look like? Maybe that's totally impossible, but a significant portion of the time there is something you could do in 3 months. And what would that be? Is that a good starting point? What if we change this assumption? You know, it kind of makes people go back to the drawing board and question assumptions, but it doesn't naturally happen in a big organization. So yeah, I don't know a way of making it happen more organically, but, but I think it's a good practice.

To wrap up, when you look at the totality going from open source project, software managed service, at-scale enterprise software company, publicly traded company, what are a few of the things that you figured out that are globally correct for people creating startups that maybe aren't talked about enough? There are many things you mentioned that are correct in the context of the vessel that is Confluent, but I'm curious, like where do you have conviction that these few ideas are broadly correct and maybe underappreciated or underexplored in company building?

Yeah. You know, it's, it's hard to know what's underappreciated because so much, you know, like even compared to when we were starting 10 years ago, there's so much wisdom that's out there that is probably appreciated by somebody. I think as a company gets bigger, one of the things I've come to believe is really important is having, you know, that a small company kind of works almost like a fancy restaurant, like fine dining. Anything can be kind of customized or done right to get the outcome. And it works pretty well, but at small scale. In a big company, I think you become almost like, you naturally become more of a system. And so it's a little bit like Chipotle, like it's not going to be great, but it's not going to be terrible. And that's kind of the natural tendency and it's the most comfortable thing. You know, I do think trying to replicate pockets of excellence, even if it leads to inconsistency, I think that's actually, you know, really important. And to do it, you know, you almost need people to, you know, do things that are kind of outside of the norm of how business operates. So Now I found that to be very true in hiring where, you know, people who just act like they had, they, you know, they just have to fight for their life to go hire this team by themselves as if there was no recruiting support and they're just really devoting a ton of energy to it like that. Those people are just massively more successful. But if you're in most of the large tech companies, they actually have kind of some pipeline system that feeds you candidates and the whole system is actually set up to disincentivize that because they don't want to be dependent on people only having successful managers that they can find their own people. And so, you know, I do think there's many things that are very like that where you have to train the team to kind of go beyond.

Is that sort of centralization versus decentralization and pushing things to the edges, or that's not capturing the idea?

I think it's decentralization combined with like a sense of accountability. I think as a company gets bigger, how you can give people some unit that they own and have them feel like, okay, I have flexibility to go pursue these goals and I have goals. You know, I think that that ends up being underthought as companies grow, but it's really at the right time, right? Like for a company with 100 people, it's not an issue, right? Like the management team, as a company gets to be a few thousand, you have to have units that are like that, that are kind of working in that way. They can kind of move quickly, make decisions on their own, have a certain amount of autonomy, et cetera. And yet it's very natural to lose that as a company grows.

And you're saying that at 100 people, unconsciously, that's just the way that it works.

100%. Yeah.

And that as you scale—

Yeah. Yeah.

I think unconsciously you lead to centralization, standardization, process.

Yeah, that's exactly right. Like, you know, intuitively in a small company, the people who have a lot of freedom in decision-making, you know, are close enough to everything happening that you will just do the thing that makes sense. And, you know, as a company gets bigger, you often lose that. Common thing I tell people is, which sounds ridiculous, but it actually is just very useful, is to tell, I just tell them, neither I nor anybody on the management team wants you to do something stupid. So if you think you are doing something that is stupid, don't just do it, come talk to us. And you would think that's not needed. And yet it often is because people think, okay, we're supposed to do this thing, right? And so then they just go do it. And yet they actually know something that means that that's not a good idea. You know, I find every time those things escalate, something good happens. Either the management team learns something about the problem they didn't know, or the person working on the problem learns something about the global context that they didn't know but would need to know to get the right outcome. And in a smaller company, I feel like you have much less of that because the management is so close to what's happening everywhere. Right.

And you even as a CEO can hold everything in your hand.

Yeah. In a larger company, you have to execute some kind of strategy. So you're telling people, hey, this is what we want. Without understanding every implication of that. So you need, you know, you need really the, the whole company trying to optimize for the end outcome that you actually care about, not just do the thing. And I do think that requires kind of creating some units that have that type of thinking. And so that, that's been, you know, that's been important for us as the company has grown up, just trying to break units of product that carry a revenue target that can think of how are we marketing our area? How are we getting customers? They can't do everything because of course they're sitting in a system that handles some of the problems for them, but it gives them a certain level of accountability. And I think it just really helps them think through end to end what's working or not working. Why are customers using this or not using this? What's holding us back in growth? And then that becomes kind of the point that can easily escalate to the larger management team to unblock things in the rest of the system.

Do you spend a significant amount of your time working on making this happen in the company, or now it just kind of happens?

Yeah, I think it took us a couple years to, you know, inherently as you grow, you're just kind of always in this uncomfortable state where you're set up for something a few years ago and now you're doing something slightly different. And so, yeah, it was, it was, it took us a few years to go from, you know, kind of a fully centralized thing to having effectively little product areas that act like 45% of a company, right? You know, they've got the G&A stuff all done for them, but they have a revenue target and they have some dedicated marketing and they have, you know, a plan of how they're going to be successful and a plan of how they're going to grow and dedicated sales support and so on. And as you start to have more of that, you can, you know, make it more real that like, hey, you guys own this thing, figure it out. Don't wait for somebody to come to you with— don't just assume you're responsible for this narrow part. Like, oh, I've done the Product specs and I've done the engineering and so it's done the design and hopefully it all works, you know, really think through whether it's gonna work and solve all the problems across that are required.

Good place to end. Thank you for the conversation.

Yeah, my pleasure.

That was great.

Awesome.

Really interesting. Really enjoyed it.