Jay Kreps - Episode Transcript

Brett: 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.

Jay: 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.

Brett: 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.

Jay: 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.

Brett: How a single blog post did more for Confluent's adoption than years of engineering.

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

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

Jay: We just kind of bludgeoned our way through. None of it was pretty. Some of our biggest early customers quit on us.

Brett: Let's dive in. What's surprised most? Like you started the company as a software engineer and now, you've had the full ...

Jay: Yeah, I mean, 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 CEO, the skillsets are almost exactly opposite, even though that's ... it's not uncommon for this kind of tech company, but it's still the set of things that you need to be good at or communication. The decisions you're making are very different. 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 a company, you're making a lot of very big critical decisions with a lot of unknowable aspects, 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 I think in a lot of those areas, it's quite different. And then, I think the CEO job generally, you operate much more in a 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. And the feel of doing that and how you do it, I think is probably also surprising. If you come out of it, you don't do that at all. There's no shooting from the hip.

Brett: 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?

Jay: Well, it's a lot of things. I mean, I think CEOs need to 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 know what good is and know if it's going well. And so I think 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. I think that-

Brett: Why do you think 80%? Not 90, not 50, not 20.

Jay: 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 kind of aspirationally the best you'll be able to do.

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

Jay: 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. 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, 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, I think when you get into aspects of software engineering, I think it's very transferable. 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 is 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. I think each of these organizations has different genres. So you need to know 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 I think probably for early company, that go to market construction is probably one of the areas where this goes the most wrong, where you're effectively ... 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, it's trying to help the customer find you, figure out the value, make use of the product in some way. And that 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 see this a lot where aspirationally the founder would love to have a very product-led motion, but in fact, the product does not particularly lend itself to that. And they're trying to will that into existence, but it's actually not ... 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, I think 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.

Brett: 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-

Jay: I was pretty heavily involved in the go-to market for-

Brett: Was that counterintuitive to start?

Jay: The way Confluent came in 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 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 wisdom in this area, I think is exactly right, which is the founders have to figure out how to sell the thing, maybe poorly. But just kind of stumble through it. And in many ways, that early experience of 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 sub parts of it, but it was very hard for those teams to 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, in a sense, I thought it was natural. That's always an area you're going to ... And companies, you always want more growth, you always want to move faster on that. So it's natural that that's an area you're going to put time into.

Brett: Maybe just so we have a little bit more scaffolding, you can give us the trailer version of the Confluent 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.

Jay: Yeah, sure. I joined LinkedIn in 2007, and I think it was a pretty small company at that time. It was probably less than a hundred people, but it had been around for a few years. And it was an interesting time for software. I joined ... The area I had studied when I was in school and that 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 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 worked on some of the data driven functionality they had there, around recommending people you would know 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. Ultimately, it was a relatively product driven thing. And so kind of 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, 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 kind of frustrated by that. And then as a result, 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 kind of data infrastructure and that was early ... There's been a whole rise of cloud computing and open source and whole waves of data systems that ended up 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 a whole revolution happening around distributed systems and distributed computing that's kind of Google was pioneering, but it was all locked up inside Google. 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 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 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 ... 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 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 are the other problems that aren't solved? If there's 100 of these key value stores, what's unique that nobody else is thinking about? And I felt like, hey, it really is about the flow of data.

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

Jay: It was not radically different in terms of what it did from what the technology is. Now it was not nearly as scalable or mature, didn't have all the features, but it was kind of an early sketch of that. That was built in part as kind of a side project. And then 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.

Brett: Why?

Jay: Well, 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 epic. And so, if you come in with something that's going to replace a bunch of those, they're like, "Oh no, we don't want it." And 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 nine months talking about that.

Brett: 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?

Jay: 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, I think we got increasingly excited about it. You know you're onto a big problem when the number of use cases just keeps 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 kind of seeing that internally, we felt like it was a really big thing. The goal was to really unlock a lot of the use of data and I think it definitely did that internally. And that kind of led up to the open source release and trying to take it out to other companies as well.

Brett: 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 earlier in your career working on cool technology, this is interesting. What was the energy of the team?

Jay: I think it was ... Yeah, it was a high energy group. It was very small. I think for most of the time we probably had three to five people. It was not some massive team. I think ... we were very passionate about the thing we were doing. I think the open source part helped that. 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're already using it internally. We released it-

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

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

Brett: But how did you decide that was the right time?

Jay: Just it was far enough [inaudible 00:15:27] yeah, it worked, we were using it in production. Interestingly, it was kind of the opposite. So we had success with some of these other open source projects. We released this thinking it was really the best thing that we'd done and just nobody had any idea what it was.

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

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

Brett: Yeah.

Jay: 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, it was very difficult to explain. It was like, well ... long explanation, it's about real time data, it's for this. And it actually took a while, probably the first year it mostly sat on the shelf as an open source project, which we were quite disappointed about. We really had to think, okay-

Brett: Were you aggressively working on it internally?

Jay: Yeah. Yeah. Yeah. So internally heavily used, externally by no means particularly popular, and-

Brett: Did you feel ... You said you felt surprised, but did you feel like demotivated or did you feel like, I don't know why it's not catching long?

Jay: Yeah, somewhat ... I think 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-

Brett: Why?

Jay: 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 weird pictures and it was kind of entertaining, but also computer sciencey 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 intrigued and I think that really helped the technology kind of catch on in Silicon Valley and eventually beyond.

Brett: 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-

Jay: The products of course continued to evolve.

Brett: Just get better and better.

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

Brett: 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, what would you teach them or explain to them they should try to do?

Jay: It's interesting in this area that Confluent operates in, which is 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, to a surprising degree. And so yeah, what did I learn about doing that over the years? First of all, just that it matters a lot and it's hard. So we would think about 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 ... they're 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, 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. There's lots of examples, but they can't boil down what it is or it's the opposite. 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-

Brett: If you construct the top or the bottom first.

Jay: Bottom, I think the top has to come later because ... Well, 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 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. So you have to kind of almost build the body of work before you can boil it down, but you kind of do it both together, I guess.

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

Jay: One example for us was, as we were preparing to go public, one thing you have to do is explain your company to investors.

Brett: Yeah.

Jay: And 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. So come public market investors, just by nature, 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 thought that was a good exercise for us. How did that exercise go? It was like, well, what do these people understand today? 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, why it's a strategic technology. And so we put a lot of effort into that. 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?

Brett: It's similar, I guess.

Jay: Yeah. Yeah. And so our approach to that was ... for the IPO was very much like, okay, database is 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 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. 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 that kind of implies a large TAM, not in terms of detailed analysis, but just in terms of 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. 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 come out to a new audience. And so, I think audience by audience, you have to almost work through that. 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 ... If you're selling for more money, you'll have a whole constituency-

Brett: Right, you're a buyer.

Jay: You'll have your internal employees, which are now a large enough group that you need to think about. You have investors. 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 almost inherent because you just have to talk to more people.

Brett: Winding the clock back, you have this Magnum Opus blog post.

Jay: Yeah.

Brett: And so then what happens after the next few months? Did it like instantly click hacker new-

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

Brett: Was the usage of the open source product, did it look like an exponential after that or like just-

Jay: Yeah, we had no real measurement. 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, that looked like a pretty nice growth curve. It was never ... 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, kind of aligned going up for that whole time period, but it wasn't like it went from zero to infinity overnight.

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

Jay: I think actually 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, we were hearing from companies that were well outside of tech all of a sudden. So media companies and banks, and that kind of helped us understand that okay, what ... do they have the same problem? And it turned out, yeah, they have the same problem, but maybe bigger in some ways. And so we felt like, okay, this could be applicable broadly. And then it was just, "Hey, is there a form of company that would fit this?" Effectively, what we had was an open source project. Now, 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.

Brett: And a lot of people had tried it at that point.

Jay: Yeah. There'd been Red Hat and that worked and there'd been some companies around Hadoop that kind of struggled. It just was not seen as a great paradigm.

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

Jay: Yeah. So people were 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 exactly a hot area. And I would say even in the crowd, we were in probably enterprise generally was not necessarily the thing. We'd kind of come out of a social network and that had been the big marquee companies of the day were definitely those ... yeah, it was Google and Facebook and so on. It wasn't whatever the equivalent enterprise thing it was. And this is 2014, kind of right at the rise of a lot of the SaaS stuff, but that had not kind of broken through at that point. And so yeah, we were like, "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."

Brett: So you thought a lot about that.

Jay: 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 eventually we were like, "Look, we should just take a product to market around this. Just do the obvious thing, build this into a product and take it out to people." In 2014, that was just where it started to be clear that the cloud was going to be a big thing. But at that point, everybody believed it was just really AWS. There was not going to be any other companies. So it was a really interesting dilemma of how you would try and construct a company because you have this cloud thing that's happening that's maybe, I don't know what, five, 7% of IT spend or something, some small percentage. It's really just Amazon. It's unclear that anybody can live in that ecosystem around it. The kind of open source on premise companies have 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? I think that was kind of the challenge. Now, being software engineers, I think we dramatically overthought this. We spent probably nine months thinking about how to do it-

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

Jay: 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, is this important to you? What would more of a productized version of it look like? Would you pay for that?" And that was pretty enthusiastic that people were passionate about the technology. So of course, they all tell you yes, even though maybe they will or won't be customers later on. I think that combined with the impact internally at LinkedIn 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 ... fundamentally there's something very valuable here. We should just do it. And I actually think there's something to that. 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 marinating in some problem where you're convinced that there's a really meaty chunk of value. And then even if you don't have the rest of it figured out, you're kind of in the right spot. And I think to some extent, I think 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.

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

Jay: It was an interesting kind of occurrence. Yeah, the idea was, 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-

Brett: Of the balance sheet.

Jay: Yeah. Yeah. Which they had not done in the past. We were very unconfident in our ability to raise money. So we were like, "Okay, this sounds great. We should totally do that." 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. And so you should go try and find some VC who will participate as well." So we were like, "Okay, we should do this and we should do it before they change their mind because maybe this goes away if we let it sit too long." And so we went from kind of thinking of like, "Okay, we're going to quit our jobs and we're going to cultivate, figure out our product and build some early version and get some first customers to like, 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. And that initial fundraise-

Brett: Why was it the right thing to do?

Jay: 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 have 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 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.

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

Jay: That's right. Yeah. Basically we had a popular open source thing, handed 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 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 ultimately successful. We benchmark invested and we're really happy to have them. That was Eric Fisher who was awesome part of the company from early on.

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

Jay: Yeah, it depends on what you call V1. 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 five years.

Brett: And so, what was the very first thing you put?

Jay: Yeah. Well, the kind of founding dilemma for us was, we had ... at LinkedIn, we had really run this software internally as kind of a service. And so the early dilemma was like, "Hey, are we going to release a software product?" 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, is just pick something. But that was actually not clear at all either because it's, okay, we're this zero billion dollar 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." 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 at that time, 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 going to take the opportunity. And if it doesn't, they'll build something around the open source," which they did. So we felt a lot of angst of, okay, we've got to get this managed service done, but it's very hard because 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 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 we did start that pretty early in the life of the company. I think, I don't know when we started working on it, 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, but-

Brett: When you built and shipped the software and you started selling it, did it feel like there's a there? We have real pull, people wanted it, people wanted to pay for it. What was the feeling inside of the company?

Jay: So it was good. I actually didn't know enough ... to me, I always felt like it didn't seem big enough. We didn't have enough customers. 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 plus deals coming in, but to me it didn't feel like a lot. It would be like, "Oh, we got four deals this quarter." But it was still, it was pretty good for the company that was a few quarters into selling. So it moved pretty quickly. The angst was like, "Hey, we have this popular open source with a little bit of functionality around it, which we haven't filled out." And so 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 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, of people who are more cloud native, et cetera, which we also have to-

Brett: And the people that started to pay you 100 or 200 or 300K, they could care less about the cloud offering. So they were pulling a different features out of you.

Jay: The early customers ... Again, we were very market driven. So 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. 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 effectively large enterprises. And that comes with its own difficulties. You definitely need real kind of field team, contractual stuff. It's a huge list of items you have to do. So there was a big kind of overhead of that, but it was working. We basically had kind of large marquee enterprises, big banks, insurance companies, retailers who were customers-

Brett: In the first 12 to 24 months?

Jay: Yeah. Yeah.

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

Jay: No. So I did the first set of early deals and then, I started to hire individual reps and we got-

Brett: That would do end-to-end sales or that would kind of begin a process and bring you-

Jay: Yeah. Basically the latter. So I was still involved in meeting all the customers or one of my co-founders would be, but they were-

Brett: And did they come out of the domain?

Jay: Yes. Yeah. So I think 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.

Brett: And they were IC sellers.

Jay: Yes, 100%, or ICs who had also managed maybe small teams but not-

Brett: VP sales, whatever, CRO, whatever.

Jay: 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-

Brett: Not Oracle or whatever.

Jay: Yeah. There's no product marketing, 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 average sales rep coming out of a large company is going to be kind of like WTF.

Brett: This doesn't seem right. There's actually a lot of lock-in with these products.

Jay: I think you could think of it as almost game theory, right? Selfishly for a provider, you would want as much control and leverage as ... you would want 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-

Brett: And you want as much differentiation as possible because that's how you generate pricing power and market share?

Jay: So fundamentally, if you think of what is ... Open source is maybe the purest commodity, right? And so, 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. So there's no business in selling a pure open source software. The business is going to come out of selling something which has some amount of differentiation and the more differentiation, then the more you could charge. But the customer has to accept that and want it, and they're going to weigh those factors. And so if you look at how these businesses have evolved, 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 any of these more open systems more, easily than they could something purely proprietor, but it's not the case that the companies have no stickiness either. In fact, if you just look at kind of revenue retention statistics, it's actually quite good. And 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, 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. And so yeah, I think it actually works out relatively well, but on the product side, there's finding a balance of enough value and differentiation and enough openness. That's kind of the tricky bit.

Brett: 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.

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

Brett: How did you have the confidence to do that? Particularly because you'd never done any of this before.

Jay: 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? It's 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? 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 found that's often true that 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, it's weird, once you know you have to do it, then you find a way to do it. And this phenomenon is seen elsewhere. I think the famous whatever, business book example is like the four-minute mile or some marathon time or any of these sports things, which once ... 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. And so, in other words, it becomes possible once people know they have to do it. And so I think that's an important view, but it was just very clear we have to do this. It was just very difficult. We understood on the engineering side, okay, that's a very different delivery mechanism. It'll be a lot of work to build. And we'd prepared for that from early in the company. So 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 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. The product wasn't really selling. It was basically harder to sell and we made less money and the economics were worse. I think even some of the investors were kind of like, "What do you guys have like the, on paper, like the best enterprise business ever, and you're putting all your energy on this other thing that kind of sucks." If there was two standalone companies, we would definitely invest in this one and we would definitely not invest in that one. We just kind of bludgeoned our way through. None of it was pretty. Some of our biggest early customers quit on us.

Brett: Because the product did not meet their needs?

Jay: In various ways, right? They either outscaled us, the limitations were too embarrassing. 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 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 money or software, but hard for these big distributed data systems. But the promise is, "Hey, it's just going to kind of run itself." So it's like a self-driving car. 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.

Brett: But to build on the metaphor, it did feel like when you were working on it and you were making the promise, ala 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 you knew that if the promise was delivered on, there was a-

Jay: Yeah. I think in many of these areas that we've pushed through something hard, I do think it starts with conviction of like, okay, this has to work, therefore we have to make it work. The fact that it's not working now is not relevant to what has to happen. 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 all the pressure of a business is to satisfy the customers that you have, the big prospects coming in the door. That kind of main flow of business becomes this magnetic force. And so yeah, we really just had to force-feed it in each area. So I think for the engineering team ... 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.

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

Jay: Yeah, because many of the fundamental components were shared. So what would happen is, okay, the cloud team is trying to build this fully managed thing. They need the Kafka part to work for what they're doing. They go to the Kafka team and say, look at all these, this customer needs this and this customer ... and what do you want this for this-

Brett: Science project?

Jay: Yeah, totally, totally, or a small amount of money. It was just, where is the pressure? And then 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. 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 and it just looked like zero.

Brett: Was the rest of the business in the tens of millions? What was the scale of it?

Jay: 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-

Brett: And so the software product is like at 100 million and this is-

Jay: Yeah, well, it was different points along the way, but yeah, 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, but nonetheless, it was going up. 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 and you decide.

Brett: 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?

Jay: Yeah, it was mostly the latter. I always feel like the crossing the chasm thing is the promise. Can you make this promise and then, the hundred things required to deliver the promise, that's the thing we were chipping away at.

Brett: But it never felt like on the act two product that there was this massive phase shift and we got to the last brick slitting or-

Jay: 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.

Brett: 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 what's your working theory of it?

Jay: I think there's probably two things that were helpful for me. 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 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 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. 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 in a way that's probably broader than many of the other executive roles. And even as a software engineer, 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 think that was probably a good asset. And then I'm also just tenacious. I'm not necessarily an optimist. I think it helps if you're an optimist. I think that, as you were saying, probably some of the best founders are just these inherently optimistic people, but if you don't have that, then I think it gets you there if you're just determined where you're like, "Well, okay, then the probability is only 20%, but we're not going to give up until we've lost all hope." And that turns out not to be as inspiring a message, so you may want to dress it up a bit, but I think just willingness to kind of keep working on things well past the point where it's a bit painful, I think is important. And I think that kind of whatever, tenaciousness, pain tolerance, 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, 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, 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 have come to believe that it's not enough on its own, but just not giving up on something for an extended period of time. It actually gets you pretty far. And I found that in competitive situations, in other situations, and if you just keep working on it, 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.

Brett: 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?

Jay: Yeah. I mean, we mostly carried through on things that-

Brett: Would you say if that's the case, is it because you were correct or that in the process of grinding through, it kind of got you to-

Jay: Yeah, it's probably both. I guess I would caveat this. So obviously you want to be very flexible about some of the details of how you do something, right? 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 it was 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 actually did give up on early versions of the product we'd done in that space. And so, 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 product. I think it's logically true that Confluent has to do the processing of data to have strategic importance. So you kind of can't give up on that just because you haven't succeeded yet. It has to work. And then, how you get there, you're just going to keep trying strategy, people, whatever has to change, you're going to just keep trying until you can kind of make it move. And I think once ... 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 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 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 thing 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, this is not happening." But until you say that, you can't really figure out what to do about it.

Brett: 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, 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?

Jay: 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 results. 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. And you see it all the time. Typically, it always comes back from sales, right? People are like, "Well, sales are not good, so what's the problem?" It's like, "Okay, sales leader is bad." And it's like, "Well, it could be." And that certainly could be, and commonly is, but it could be every other thing in the chain of value leading up to that. I think that's often one of the most maddening-

Brett: Across the years of the business, do you personally spend a lot of time on this diagnostic work?

Jay: Yeah.

Brett: Yourself?

Jay: Yeah, absolutely. Anything that's not working at a high level is inherently cross-functional. And you'll see a weird phenomenon where people in each function 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 you'll see some people where if something is not working and they're on the product team, they inherently think it's, "We don't have enough product features." And it's like, well, it could be, but it could also just be, we have no idea how to sell the thing. But you're not thinking about that. You're thinking about the product functionality. Other people who are the opposite where they tend to just kind of blame some other part of the organization out of defensiveness, but it's-

Brett: Yeah, sales blames product is like a configuration-

Jay: Yeah, totally. So somehow I do think the CEO is in a good position. 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 does this work?" And then take all the answers and be like, "Okay, try and figure out which of these makes the most sense. And if that was the case, what would we do?" But I do think often the CEO's in a good position to do that because you have to think very flexibly about changes across different parts of the org.

Brett: 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-

Jay: Yeah, probably more of the latter. We didn't turn it into a value or management principle or something like that, but I do think it's kind of a common refrain of ... especially as a company gets bigger, it's very difficult. A natural thing, if you're one team that needs to do something that touches five teams is you go to the five 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 two 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 really that whole group of constituents is like, okay, how important is that thing? Is that good enough? Maybe two years is fine. If it's not fine, then the fact that that was the best we could do is not relevant. We're going to be unsuccessful if that's what we do. It's weird how these things work. Everybody who has found this with headcount, with budget, with timelines, if you kind of just go back and say, "Well, okay, what would the three-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 three months and what would that be? Is that a good starting point? What if we change this assumption? 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 I think it's a good practice.

Brett: 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've 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, where do you have conviction that these few ideas are broadly correct and maybe underappreciated or under-explored in company building?

Jay: Yeah. It's hard to know what's underappreciated because so much ... Even compared to when we were starting 10 years ago, there's so much wisdom that's out there, that's 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 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. 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. I do think trying to replicate pockets of excellence, even if it leads to inconsistency, I think that's actually really important. And to do it, you almost need people to do things that are kind of outside of the norm of how business operates. So I found that to be very true in hiring, where people who just act like they just have to fight for their life to go hire this team by themselves as if there was no recruiting support and are just really devoting a ton of energy to it. 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, can it. 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 if they can find their own people. And so, I do think there's many things that are very like that where you have to train the team to kind of go beyond.

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

Jay: 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." I think that that ends up being underthought as companies grow, but it's really at the right time. For a company with a hundred people, it's not an issue. The place you need that is maybe 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 the company grows.

Brett: And you're saying that at a hundred people unconsciously, that's just the way that it works.

Jay: 100%. Yeah.

Brett: And that as you scale-

Jay: Yeah. Yeah. I think it-

Brett: Unconsciously, you lead a centralization, standardization, process.

Jay: Yeah. Yeah, that's exactly right. Intuitively, in a small company, the people who have a lot of freedom and decision making are close enough to everything happening that you will just do the thing that makes sense. And as a company gets bigger, you often lose that. A common thing I tell people is ... which sounds ridiculous, but it actually is just very useful, 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." And so then they just go do it and yet, they actually know something that means that that's not a good idea. I find every time those things escalate, something good happens. Either the management team learned something about the problem they didn't know, or the person working on the problem learned 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.

Brett: And you even as a CEO can hold everything on your hand.

Jay: 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 really 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'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.

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

Jay: Yeah, I think it took us a couple of years to ... 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 took us a few years to go from kind of a fully centralized thing to having effectively little product areas that acts like 45% of a company. 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 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 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 though. I've done the product specs and I've done the engineering and I've done the design and hopefully it all works. Really think through whether it's going to work and solve all the problems across that are required.

Brett: Good place to end. Thank you for the conversation.

Jay: Yeah, my pleasure.

Brett: That was great.

Jay: Awesome.

Brett: Really interesting. Really enjoyed it.