She Built the Feature Every Customer Said No To

" Almost point out I think it was either a C plus or a C minus and I just decided like you know what like whatever I'm just going to keep doing it and we just figure this out. Let's start off for people who don't know what RD is. What is it? Arty is a platform that allows you to stream data in real time in near real time like sub minute.

Uh that's what Arty does. What do people get wrong about what you're building? " And you built the history table feature when literally every customer said they didn't want it and 6 months later 40% turned it on. The strongest features or ideas is when both of those are true.

Like your customers say something and you're like, "That makes so much sense. I'm so excited to build it. I could already see like 10 other customers that would want this. And so we did it anyway.

We launched it. No one needs it as expected. But then like you said, like six months later, we did a check and we're like, wait, 40% of our customers turn it on and are Hi Jacqueline, welcome to the Agents at Work podcast. Thank you for coming on and thanks for having me.

So where are we right now? Uh we are at the like garden patio area of the Transame building. Um it's a place that uh me and my co-founder husband like walk our dogs a lot. We like redwoods hiking in the East Bay and so uh this just like reminds us of the hikes that we do.

Yeah, this is a very nice spot. And so let's start off for people who don't know what Arty is. What is it? So RD uh is a platform that allows you to stream data in real time.

So hey we have Postgress databases, databases and we want to stream that data uh into a snowflake data bricks iceberg um in near real time like subminute uh that's what does and what what do people get wrong about what you're building? I think what people get wrong and what I actually got wrong about what we're building is like, oh, you're you're moving data from like A to B and okay, I get that you're moving it really really fast, but that doesn't seem that hard. And so that that was the thing that kind of tripped me up too. I'm like, why is this like really a hard problem to solve?

And then you go, you know, you talk to uh companies that have done this. " And you often get these we have like 10, 20 engineers working on this. It's been four years. It took two years to go into production.

And then then you're like, why? And then you dig deeper and you're like, wow, this is like a real time streaming streaming systems are just like unforgiving. They're very powerful, but just really really hard to get right. Yeah.

I mean, you tell people real time data isn't really a thing yet and they don't believe you. Is that right? Yes. " Yeah.

Like we do hourly batches uh or we like wait overnight like today we can our executive team can look at the numbers from yesterday and that's just very normal uh has actually you know people used to look at reports on a weekly basis and uh but yeah like to everyone that's not close to this problem it's like what do you mean why do I have to wait like what is that about and why is this important for for other founders like building in the case. Yeah. So if we actually look back at the trend of like data replication, it's pretty interesting. So um number one, okay, why does data need to move?

You have these like transactional production systems like your Postgress database. They're uh really good at be doing what they do which is fast transactional rights. And then you but you want to do like analytics. You want to analyze that data.

You want to build customerf facing analytical platforms. You want to do fraud detection or hey our AI agents need to understand like have context from all the data that we have so it can interact with internal ops people or like our customers but you can't put that on the transactional system. You have to put it somewhere else. And so okay so now that those systems are sitting somewhere else how do you get that data there?

And uh why it's important is like well imagine you're a fintech you're a bank and you're running your your fraud models sit on data bricks your ML engineers run these uh you know run these uh fraud models well if the data takes an hour to get to data bricks it's it's you know the meanantime to detection or meanantime to resolution for these uh fraudulent transactions or entities the longer the gap, the more risk to the system. Uh or even if you think about like uh an AI agent that does like customer support, uh you you try to book a ticket like airline ticket to somewhere. You're like, "Hey, I don't see the transaction go through yet. " You raise you talk to the AI agent and the AI agent has no let's say if it's even running on like a 10-minute latency.

The AI agent has no idea. He's like, "Oh, don't worry. there's no transaction yet. Let me create one for you.

But turns out the other one was just delayed and now you have two tickets. And so it's like without the right data in the right place, like if you if if data is late, it's it's at this point it's simply just wrong. Okay. Thank you.

That makes a lot more sense. And so a month ago, you built an internal agent called Hermes. Hermes. Yes.

Hermes. what is it and how has it changed how people work dayto-day? Yeah, so it it's been a massive shift in how we think about like work. Um, so what we built is and Hermes is uh is you know a harness that was created by uh news research.

It's very very sim it's kind of the same as openclaw. Um, and uh, the first one that we build is a like a R&D like an engineering agent. And how it kind of changed what we can do is um, if if Hermes is the one that executes on a bunch of stuff and it's not great right now. We're still improving it.

You have to build the harness, write the right skills, and have the loops that will make it like self um uh not self-reover but like get improve better like on on a daily basis. But um if if Hermes can do the execution of like small and medium tasks then what do our engineers do? And so what we realized is like wow now the jobs of engineers is to one you either improve Hermes by building a better harness writing better skills and all that stuff or the second thing is like your job is to just have good understanding. So there's a very large project we're building and you have to understand like what are we bu building how do we want to build it uh understand the full picture how it interacts with other systems and then we're going to like break it down into small and medium chunks I say small and medium because that's all Hermes can take right now this will change as Hermes gets better but it's about like chunking so based off of your understanding you're able to chunk properly and then hand the pieces off for peries to actually execute.

So, no one no one should be like actually like coding anything anymore. And and this has like really increased like productivity because if you think about it, you can like chunk one project, send a few to Hermes, monitor it, but then you have another project and you can you can just run multiple projects at the same time and you're just the manager of like these tasks that are being executed. Um so we've seen I think it's been almost two months now but within the first two three weeks we saw like 2x productivity improvement um and Hermes was you know doing it is not even that impressive compared to like like you know um you know what Gary Tat is doing with his his agent but within the first three weeks we got to a point where it was pushing like 1500 um PRs a And what was Gary Tan doing with his agent? I think he he's just been building this for a little bit longer.

And there are loops. There are agents that are um monitoring what other agents are doing and then like creating like self-improving loop. So So these agents are, you know, pushing PRs and improving the system completely on on their own even when he's sleeping. So we still have like a human in the loop for um the actual like approving the PR.

So it's it's not like fully autonomous. Um but uh so there's still one step at the end where we're very very much involved. And you also rate Hermes coding a five out of 10. Yes.

And say it's already changed everybody's job. So like how do you decide what to hand to an agent that's a five out of 10? So I think so five out of 10 uh is I think within the first week we were rating it like two or three out of 10. Okay.

What when we talk about the ratings it's like how close is it to what we could hand off to like like a senior engineer um or a person that could just take this autonomously. So maybe at a three out of 10 it's like okay everything everything needs to be chunked into like kind of like quite small pieces with a five out of 10 some medium size uh workloads or projects can be can be given to it and so as it gets bigger like you you can actually like chunk less or like prompt less um or like adjust less as as they execute on certain tasks. And what's cool is that with the engineering Hermes agent, we're now building like different profiles. There's one for uh bisops, there's one for uh sales, there's one there's going to be one for marketing.

That one doesn't exist yet. But with each one, it's it's it acts like another member of the team. So the bisops one will understand how our billing system works. will understand how our um outbound system works.

And so when you talk to it and when you improve like it it knows it has the context within bisops and everything that bisops does. Uh and that will also like our our bisops person like she is coding new workflows with her needs like every single day. And you built the history table feature when literally every customer said they didn't want it and six months later 40% turned it on. Walk me through that.

Yes. So this was interesting because the classic you know like and this is very much still true. It's hey what do you what do you build? Like you listen to your customers.

Go talk to your customers. Do they want it? Would they use it? And that's how you determine like what you should build.

Um and we kind of the history table one was very much not customer driven. Um it actually came from uh you know my co-founder was reading a a textbook um about like data warehousing systems and and whatnot and through that he was like this is you know having history tables which if what it is is like so what does what it did before history tables was just one mode one to one six right like whatever the the tables look like in your database uh we will replicate it one to one so it looks exactly the same in your destination. You add a column, the column will be added. You you do updates to rows, those rows will be updated.

Um and history tables was like well it's called an SED type two table. I I think people will want it instead of a onetoone view. It's if you update a row 10 times, you'll get all 10 uh rows in your destination with the time stamp and the type of operation. And so the idea was like, hey, if you want to train data, train train um, you know, models off of historical data, if you want to like do de debugging um or if you want to build like a historical view of like, hey, user did this when and have a log of it or do auditing.

Very, very useful. And so we just had a feeling that it was useful and we we wrote a one pager. We actually tried to do the thing where we're like, let's talk to our customers. Um, and we we sent it to all our customers.

And this is like this must have been like two three years ago when we did this. Sent it literally kind of like crickets and then we're like nudging our champions. We're like, "Hey guys, can you take a look? " Um, I can't think of a use case where we turn it on.

Like just wasn't interesting. And so we kind of sat there and we're like what do we do? Like we just we just really want to build this. Um and I think because we just had the conviction that it would be useful.

And I think the second thing that was actually very helpful is like we wanted to use it. Uh we wanted to use it because we wanted to build also an audit trail of like like you know and when you go into our pipelines you want to know hey something changed which person on my team came in and what did they change that would be covered by like a history table that we would need. So we knew we wanted it uh we we had a strong gut feeling that like it would be useful. Um, and I think the genesis of the company was also like, hey, we felt the pain of building streaming pipelines and we're just going to build the thing that we want.

I think that also kind of like helped us have the conviction that we should build this. And so we did it anyway and we launched it. Uh, no one used it as expected. Uh but then like you said like six months later we did a check and we're like wait 40% of our customers turn it on and are using it.

Uh and we're like okay like that that was great but I would say like that is like what like most of the time we're just following what customers want us to build. Okay. And is that how you tell a real convinc conviction apart from just being attached to your own idea like you wanting to use it yourself and you Yeah, that is uh you Yeah, like that that is something that like helps because it's like a genuine like you know and and going back to when we were at YC it was like can we find one company that would want to like use this and pay for this? Yeah.

And if you can find one, it's like you kind of have to convin you can probably find 10 and if you can find 10, you can probably find a hundred. Um, so we're like, well, we're we're one and we're like a real company and this is a legit use case. It's going to be in our product. Like, yeah, the YC gospel is talk to your customers.

You just described overriding them. Yes. And so, when do you trust your gut over what customers tell you? Uh, and okay, this is interesting because um I think the strongest features or ideas is when both of those are true.

Like your customers say something and you're like, "That makes so much sense. I'm so excited to build it. " Um, and I think I that is true for actually like most of the features that we built. Like both of those have to be true for for us to go ahead and build it because one example is like we'll have customers ask and we actually say no a lot.

Um, and because like our this is not our our gut is sort of like hey this is this is our medium to long-term road map. This is what we think we want to build and uh where we want to go as a company. Let's let's call that our gut basically. And then um and then there's customers that ask for things and some of the things are like or hey something that we want to build a year out maybe we just do it now because people are asking for it or it's like hey it's kind of adjacent but it's still like it kind of pushes us towards the same direction.

Great like we should do that. That's when it matches really well. Sometimes customers will will ask and in those cases it's actually like so so so important for you to say no because every step you take that's orthogonal just takes you longer to do like what where you want to go. And so I think there's a balance.

I think what um and and actually I think the YC advice is also super interesting because it's they're very much talking about like the very beginnings. Even now when I go back to talk to our our YC group partner, they're giving advice that it's like completely like like a 180 from what they told us when we were first starting the company. And um and it's not that it's wrong. It's like hey, you're at a different stage now.

So yes, the advice is like completely different. So your belief is that anyone can do anything they set their mind to. Most constraints aren't real. Where did that belief get tested in your own jump from finance to running a data infra company?

Cuz you were doing finance yet. Yes. It actually even started like before that. Okay.

So, I do believe that anyone can just do whatever they set their minds to and like all all constraints are sort of like just like um your your own like you just don't want to do it and that's why you haven't done it. Um yeah, and I think that I do think that that's true and there's like things that happened uh throughout my life that continue to reinforce that why I feel that. And so like when I went to first year in college, I decided I didn't really know what I wanted to do. And so I decided like I wanted to be a math major.

Um and I like almost flunked out of the first math class that I had. Um and it was just really hard. It also I discovered later it was like a weer course. Um wait, what does that mean?

Uh it's like it's meant to be so hard that it kind of discourages you from progressing. Oh, weer course. Okay. Okay.

Okay. And so it was actually designed to be that way, but also it was just really hard and I wasn't very good at it. " Like I literally like almost point I think it was either a C++ or a C minus. It was terrible.

And and before that I was like like a straight A student. And so like I don't I don't know if I can do this. And I just decided like, you know what, like whatever, I'm just going to keep doing it and we just figure this out. I'm going to do better.

Um, and I continued on and I ended up like just just loving it. Like by my junior and senior year, it took a while, but by my junior and senior year, I really really enjoyed uh the course. I understood how to learn like math properly and got into my rhythm. And then from there, I decided, hey, I'm going to go to finance.

Uh and everyone else that was like in my starting class was like they did a they did not an MBA but they were in a in a business in business school they had done some like financial modeling before they they like just the stuff wasn't like very new to them and for me it was like okay I had been doing like proofs for four years now I'm going to do finance uh it was all new but uh I was like okay well whatever I can do this um so did did that and then I then I was like I'm going to go from the sell side to the buy side uh which is when I jumped to the hedge fund. Um and that was a ch that was literally drinking from a fire hose. It was a completely different way of thinking and so uh and it was like a really demanding environment like you didn't really get that many chances. Um and so uh so it did that uh was wasn't for very long.

It was just like three or four years. um but was was fairly successful and then um then I think it it just gave me the conviction to be like data infrastructure okay like I was kind of one of those people that was surprised that like real-time data wasn't a thing and whatnot um and I decided to uh just go for it anyway. Wow, that is amazing. And so it's really awesome that you stuck through it because I remember when I was I think in second year I took this business class at Laurier um where your co-founder um he studied at Laurier which is really cool and it was very very hard and it was also a we like a wait what's the weer the weer course so I did see a lot of people they would drop out like drop that class because it was so so tough.

I was one of the people who left that class because it was so hard for me and I'm also really bad at math and I just couldn't do it. So kudos to you for sticking through. Like what part of math that was very challenging for you to grasp? I think it was just the um was kind of the you know it's really hard for me to remember at this point but it was probably something around the it was a different type of math.

it wasn't so much um it wasn't so much structure or uh the professors are sort of like hey this is the material I'm gonna teach you there's a lecture and then you're off on your own so there wasn't so many like checkpoints or things to to know that you're you're you're on the right path and then by the time you get to the final you're kind of like cramming but you you don't really it's like a different kind of math there's some proofs in it but it's it's it's not quite there and you just need to learn differently and I just didn't know how to learn it. And the way that I was learning it from high school didn't translate and so it was more so like it wasn't I I always knew it wasn't like can I learn it. It was more like can I figure out the right way to learn it. Okay, that's awesome.

Jacquine, what happened? Okay, so obviously we changed locations. Yeah. Um we got kicked out.

We did. I mean, the first time I filmed there, it was really good. No one said anything, but second time, yeah, we got it. It's good.

We uh pivoted. So, we pivoted. Yeah. Great.

This is a really good location. So, let's continue where we left off of. So, what did the finance lens give you and where did it mislead you? What did it give me?

" like nothing could have prepared me for any of uh like part of the journey in the in the very beginning. But um what I realize now like in hindsight there are some things that I've gotten feedback from from my team that I realize has come from my finance background. And one of them is like really embodying the um like strong opinions but loosely held concept. And so I'll talk about like how it applies to finance and and then how it applies to arty.

But um actually I'll do I'll do the flip side. So, what I've the feedback I've gotten is like, wow, like you um like you're able to like make decisions in a very calm way quite quickly, but then you'll just like change your mind like all the time when you have like new information that comes in. And it seems like when you say it out loud, it sounds like logical, but I think emotionally it's like not what everybody does. But how it came from my time in at the hedge fund that I was working at is you have to like you get information like incomplete information an earnings drops and you get some numbers and and you're like wow you have to make a decision within like five minutes 5 10 minutes you have to put in a trade and the trades can be like singledigit millions or like double digit millions uh of like value and so but then an hour later or two hours later as you do more research as you get more information you might decide like wow that was the wrong choice and you have to completely flip your position and I think because I did that for like almost four years that's something that I'm like quite comfortable in or I like learn to get like really comfortable in um and so I guess I still like very much embody that at Arty like I'll make a decision and then like a week later if I'm like you know what that was a bad decision.

I'm going to like revert it and do something else. And I like don't feel bad about it. It's not something that I have to hesitate to be like, what are what are other people going to think? Like, do I need to like, oh no, what if like like they think I'm like changing my mind?

For me, it's just like, well, I got new information. Like, I'm just going to like act on that new information. Wow, that's awesome. Let's go into founding with your spouse.

Mhm. So, your co-founder and CTO, Robin, is your husband. Yes, you said founders hide this. Why are you happy to talk about it?

So, uh it's actually a just a personal decision um that I I just think makes my life easier. So, for an example, like I know, you know, there are investors there are some investors out there like that don't want to invest in in couples because maybe they had a bad experience in the past and so they're like scarred from it. Um or and I think that I think that is a big reason why a lot of people that I know are like actually hiding it and and not talking about it. Um for me it just seemed like that was going to be hard.

And what I mean by that is like, okay, let's say I hide it. And then we get investors that are like, I don't want to invest in couples. And they don't know we're a couple. And um and then like a year down the line, uh if things get tough and they find out, it's like you're just constantly having to like hide this or it's like two employees, right?

It's like, hey, we're not going to tell you. and then you join the company, you find out and then you have to so so for me it's very much about that's too hard. So I'm just not going to do that. So when we were investing it's like hey the first thing I tell people when I meet them is like hey how I know my co-founder he's my husband.

When people join RD I always make sure they know upfront that like hey I founded this with my husband. Um, and I think it just makes my life a lot more a lot easier. And it's also why like we're very like transparent and open to all of our team members as well. Um, like everyone gets our investor updates.

Like everyone knows how much revenue we have, how much cash we have, how much burn, how much money we're burning, and they just get all the information because I think it just candidly like makes the conversations easier. they have all the context and um and yeah, so it's kind of selfishly just makes things easier. And so on your website, I saw the about page where it was like almost this this timeline. So it's in 2016, that's when Robin had the idea to start.

And then in 2023, that's when he teamed up with you. So tell me more about that story from your perspective. Yeah. Yeah.

So 2016 was sort of like he was at the startup where they were dealing with like mass amounts like billions and billions of events uh on a monthly basis. And so even at a very small startup like in that experience he learned to deal with like distributed systems and building like like solving large scale data problems. That was the beginning of like some of the learnings that go into our product today. And then that startup got bought by Zenesk.

And then at Zenesk uh they I mean they have like uh you know if for people that don't know they're like a service uh platform customer support platform they have like billions of tickets that go through their system like every single day and so um CDC and event- driven architecture is big at Zenes and that plays a big role in what our product looks like today. Then we went to open door and at open door it was uh he started working more with warehouses like snowflake and it was like hey we got to get data into snowflake as fast as possible to uh you know increase operational efficiency better fidelity on data reduce days on market for the homes that we buy and sell as as a company. Um and at that that's when he was like building these like data replication systems and realized wow like it takes eight engineers six quarters to really productionize and have a robust system like this in place. This is really painful and like we needed this at Zundus.

We're seeing that we need this at Open Door. I wonder do all companies need this and if they do are they all going through this really painful process or can we just for them it's like can I productionize this everything that I've built into a product so the next company that needs this they can deploy in like 15 20 minutes they don't need to think about like failure recovery monitoring alerting systems and how to make sure that no rows are dropped or no events are read out of order I already know how to fix all these problems I put it into a product. No one needs to think about it. Oh.

And that was the genesis when he told me about the idea and we kind of jumped in. Wow. And then so did you study ground rules before you started kind of working together or did you figure figure out the boundaries of like the hard way? I think we tried and I think this is like maybe very um it depends on who your co-founder is and what the relationship is like.

So I think this is very much like your personal like characteristics and your personality. For us, we try to set ground rules. Things like, hey, from 5 to 6, we're going to go on a walk and we're not going to talk about art or hey, why don't we implement a day on the weekend where there's no work and we we don't talk about work and there's separation or like date nights or stuff like that. Nothing really stuck.

And um nothing really stuck because like every time we'd be like I know we're not supposed one of us would be I know we're not supposed to TALK ABOUT IT. CAN we talk about it? And we'd both be down. And so I think what we learned for us what works is like there's no separation and it's fine.

Like this is our whole lives. Like if you constrict what we both want to talk about like it's not like it's making us any happier. Yeah. Um, so there is no separation.

We're It's pretty much already all day. Um, but that seems to like we're happy with that. Nice. And you own the customer, Robin owns the technology.

Did that split happen by design or just by who is better at it? Um, in the beginning it was very natural. Like our conversation for who owns what what was literally like 20 seconds. Uh it was like well I can't build the product you can.

So you go build the product. Let me figure out what are all the other I mean in the very within in the first few months it was literally like there was we had no customers. There's no entity. It was just the two of us with an idea.

So for me it was like okay it's very important for you to build this make sure it works. make sure it's robust and then in the meantime, let me figure out what are the things that like needs to be done that are not building the product. And so it took me like went and did that and like okay sales we should sell. So I need to learn to sell.

So I bought some books and like I read them and I'm like okay so I'm going to I'm going to do sales. Um I think now it's a little uh a bit more blurred because I think I own like I own the customers very much pre-sales actually even during the PC and post sales Robin's very involved with customer Robin our engineering team very involved with customers and I still come uh I still check in with them and meet them and like understand how it's going afterwards but it's very much like mix now that we do have customers, but the split was very clear in the beginning. You either build it or you sell it and I can't build it, so I'll sell it. That's so cool.

And yeah, congrats for you like really like I mean like learning all about reading all the books and really making sure like you're you're ready for it. So was there a moment where being married made a hard business call harder? I wouldn't say so. No.

Um, and I don't know if it has to do with like I I I wonder if it would be different if we weren't married, but it's being married has never made it a decision harder or easy. Actually, I I think it's made it easier because I think there's a level of like, okay, we really care about each other. Yeah. And so there's never a moment where we're um really like attacking each other to drive an initiative forward.

Like that really never happens. And so it makes things easier because that layer is gone. And then we also have a lot of trust in each other. So we know that whatever decision we make, we're really trying to understand like can we make the company better?

Um, and I think because of that, I think because our personal lives are so mixed and our values and motivations are so combined, it's always it's it's never like there's me and you and the company. It's just the company and like what are we doing to to improve it in some way. Oh, love that. You said after four years you found real strengths in um in just being together and like owning this business together or like this startup.

What's the one most people would never guess? Strength. The one strength most people would never get. Um, I think this one's like very obvious to me, but uh I get questions on this a lot.

Um, which actually goes back to my previous point, but people are always curious about like how do you work together? like wouldn't you argue all the time because your personal lives and your work life is mixed and actually because it's mixed um we're very aligned and so there are a lot of things that you would think are like problems or issues that you would have to talk through actually just doesn't exist and I think I can say this because there was a period of time when Robin was working for a very small startup it was a five person startup. This was pre-zenesk and I wasn't part of it. Um I was in finance doing my own thing and I think because our lives weren't completely combined uh I didn't know what he was working on.

I didn't know how important it was. I didn't know like stress levels and stuff like that. And so when our personal lives got disrupted uh because of a work thing, I didn't understand. And that would actually cause like friction.

I would be like, "Hey, we said we would do this. " And I couldn't grasp what was happening. I think now like those conversations literally do not need to exist. Um something happens like you let's say we have an outage and we're supposed to like travel somewhere or go to dinner or like meet up with friends or or whatever it is.

It doesn't even have to be a conver. " It's not even It's just It's totally fine. And that actually makes it easier because there there are a lot of conversations you don't need to have. That's amazing.

And so for anyone watching this who's also thinking about like, you know, working on something with like their significant other, what would you say? What would you warn them about? And what would you say? What would you say to encourage them or think about?

I would say it's easier than you think than people would think because the hardest part about co-founder relationships and um what I've heard also is like a lot of startups they fail because either the co-founders give up or there's a co-founder breakup and there's a lot of times you know now that I've I've I have friends who like their founding team has has broken up there's a lot of like underlying like trust that like gets broken as part of that process. us. And I think as a as you know, whether you're like brother and sister or siblings or you're married, there's just like a such a strong foundation layer of trust that actually like pulls you forward um that sustains you way more than you would think and it makes a lot of things easier. And so it's actually easier than you think it would be.

But then that being said, it's not like it doesn't require work. Like we have uh a founding coach, a founder coach that we both see and we do joint sessions together and like you have to work like communication still needs to change. Like communication at home is different from communication at work. You just have to learn these things and like learn how each other works and you just have to still put in work.

But I would say that's also true and even more true if you're not siblings or married or something like that. You have to put in a lot of work. Yeah, that's true. And how would comm communication differ from like work and maybe at work would you you don't all be because another thing is like you're making sure you're you know deliberate about maybe not like presenting a unified front so people they can push back on either of you.

Yeah. And that was something that we um we knew to be very important in the early days. Yeah. " Yeah.

Or having problems working with Robin. Who are they going to go to? They need somebody to go to, but there's nobody else because it's just us two. And so we made um I think, you know, in our one-on- ones, we make a we make an effort to say like, "Hey, I know we're we're co-founders.

who are married. But like here's and I tell all our all our employees this like this one-on-one is like not recorded. Uh everything stays where it is. The idea is if you have issues working with Robin or me, we probably have experienced the same.

And so it's like setting the expectation of like what is this one-on-one for? How can you like leverage me as a resource? and this is how I intend to help you. Obviously, there's a level of like rapport and trust that needs to build before they're comfortable doing that.

But, you know, like I think if you put some intentionality behind it, it works really well because I've had people that come to me and say, "Hey, these are some issues that I've had. " And I'll be like, "Hey, I actually had this issue a year ago and this is my approach. um or like I tried this one thing, it didn't work. I ultimately ended up trying this other thing.

This approach works really well. Maybe you should try it on Robin. And um and like I'm like really glad that my team is able to come to me and like talk about that stuff. Um and I think like how you respond is also important.

It's like, hey, I'm I'm like in on your side in your shoes now. This is how I would approach it. It's not like I'm going to go around and like have a three-way discussion. That's amazing.

Well, thank you for sharing. This is very helpful for anyone listening about this. So, moving back to the product. So, Netflix, Door Dash, Instacart, they all built real-time streaming in-house.

Yeah. So, the obvious question is if the giants cracked it, why does a company like yours still need to exist? Yeah, that's a really good question. And I think um that's actually the genesis of like a lot of a lot of products out there like um Kofkco was invented in LinkedIn then they open sourced it and then they uh the founders came out and started conflict.

Wait what is that actually? Uh Kafka it's it's um it's a message queue uh a streaming system that actually like already uses Kafka under the hood as one of our systems. Um but uh but yeah it was it was invented in LinkedIn first they used it extensively and then they're like this could be a product and so I think there's like two ways fundamentally to start a company one is you've experienced something yourself and you found a solution that solves that personal like painoint which is how was started and then there's the other one where it's like hey I really want to be a founder I'm going to interview talk to a lot of um potential customers customers or users and understand the painoint really well and then create a product out of that. Um but I would say like why does this still need to exist?

It is because that these companies like Netflix, Door Dash, Instacart, um it works really well and it's so powerful but yet like most companies don't have that. And is it because most companies don't want that or is the barrier to entry just really really high because these systems are just so complicated and so hard and take such a long time. Yeah. And so we're like well why don't we take the best like you know some our back fill method came from this Netflix paper that they uh published called uh Netflix DB log and so it's like taking components of like what what have these people solved and what has Robin personally solved before take that and productize it so that um you know a all these like 99% of companies that don't have these systems, they don't need to learn how to build it.

They just they can just get the outcome from it, which is fast, reliable, consistent data, and then they can build all these downstream use cases and unlock use cases that they just couldn't build before. Um, but if we if no one built this thing, then it the power of these systems would only stay with the Netflix, Door, Dash, and Instacarts of the world. That makes a lot more sense. Thank you.

And you've got this metaphor you use to explain what RD sells, the wedding cake. I want everyone to hear it. Walk us through it. Yes.

Yes. So, okay. And this goes back to like why is why why is real-time streaming so hard or the the end to end outcome? Why is moving data from A to B so hard?

Um, and the metaphor is like, okay, let's say someone wants a wedding cake. And the wedding cake is that fully um productionized useful streaming system. what exists in the world today are a lot of like tools, like low-level tooling. Um, so it's it's like, hey, I want a wedding cake.

Here's there's like different kinds of flour, different kinds of sugar, there's vanilla extract, um, and whatever. Maybe there's salt in there somewhere. Um, and then it's like, you have all the ingredients, you have all the tools, now go build it. And now depending on the company, depending on who's built, baking the cake, do you have a baker on your team or is everyone just figuring out as it goes?

Do you have uh like Yeah. pastry chef? Do you have a chef? Do you have um I don't know, people that really know how to make icing.

If you don't have those people, maybe it'll take you longer. Uh if you do, maybe it'll take you faster. and then the quality of what comes out can be very very different or sometimes it just fails. It just doesn't bake.

It just doesn't work. Um and then and so for for what the metaphor is like for us it's like let's not pe give people the ingredients. Why don't we just give them the whole cake and they can just eat it? And so that's what RD is.

It's like let's forget about like Kafka, forget about like uh topics, forget about like h how do how do we make sure no rows are ever dropped? How do we get data out from these production systems in a very um you know in a reliable way that doesn't put load on their system? How do we make things fast? Our customers don't even think about that.

It's more just connect us and then you're done. You just have the cake. Awesome. And then so your bisops reports the CTO not you.

Why? Yes. So this is something I've changed my mind on and okay let's talk about so bisops used to report to me but things were very manual and we weren't um we weren't like actually automating or optimizing a lot of things. And what we realized was that like my brain and Robin's brain just simply works differently.

And I think from a techn and I've talked to other CEOs and CTO's about this and it's I've se I've seen this pattern where the CEO is like these manual things are fine because they're getting it done and then there's uh the the technical person and they're like wow this drives me nuts. The fact that this is done manually or the fact that this is not optimized completely drives that person nuts. Does not drive me nuts. So I'm like great, why don't we put bisops under Robert because he will just get pissed off about so many of these things and then we can identify what to optimize and what to automate.

Um, and part of the reason is like it's not that like I don't want to optimize things, but because I don't know what can be done or what is possible to automate and auto uh optimize some things, it's not hitting me. So we'll just move bisoft under Robin. So that we expose so many things that we can improve. But once we improve those things after a few months, we're like, okay, this doesn't actually make sense anymore.

Like this is much more um optimized now. Now, now that level of thinking is like we can do it now because now we know. So we don't need Robin anymore. Um, but I actually do need bisops to be like reporting to me because there's a lot of operational things that um actually is helping sales and marketing.

Okay. And so like great, now I'm gonna take it back. Okay. Um, and like I think to the outside this can feel very like wow, you're like moving like direct reports to report to like different like managers like is that thrashy?

Like I don't know. It just didn't feel like that. It just made a lot of sense and it just it's just what what was needed at at the time. So you wrote a working with Jacqueline doc for every new hire.

I read it too. It was so interesting. I read all of it. Talk a little bit more about that.

Yeah. Yeah. So um a couple of things. One was I noticed that with every new hire joining um I would just like repeat myself on how to work like different at different points in time I would repeat myself on like this is how I think about things.

This is how you should make decisions. This is when you do need to come to me. Uh these are my pet peeves and stuff like that. And so I noticed I was repeating myself.

Um, and so I knew I I I needed some sort of like dock so that it so that new people, not that I don't need to I I still need to repeat myself, but it's more like you get everything up front. Nothing's a surprise. You don't have to like figure it out on week two or week three. You just get it on day one.

Um, which I've, you know, now that I've done it, have gotten such positive feedback. It's like, oh, like this is so clear because I know how you think. I know what's okay or not okay. and I don't need a guess makes them move a lot faster.

Um the second thing is it was inspired by um this book called Scaling People by Claire Hughes John Johnson which is the XCOO of Stripe and it's something that she does for all her direct reports and I'm like this is such a good idea. Um, and I I actually think that everyone should probably have their version of that cuz it's not just like founders to give to their direct reports. As a direct report, you can actually write a doc like this. Give it to your founder or give it to your manager.

I can even write something. Okay. Yeah. I think everyone should have a working with me doc and it just makes it so much easier for like communication and stuff like that.

No, it is very underrated. Definitely more people should be doing it. And so in the hiring doc, it something shows up about like the score takes care of itself, not just your reading list. And so who is Bill Walsh for anyone who doesn't know?

Because this is something he like said. And what did he change about how you run Arty? Yeah. Yeah.

So I think it's helped me a lot. I actually have this like his quote and a couple of his quotes like stuck to my like um back mirror. Yeah. And um so the score takes off care of itself is literally the title of the book.

Okay. And Bill Walsh was um a coach for the 49ers and he became the coach of the 49ers when they were like the worst team ever. They just consistently lost for many many years. within I think it was like a year or two of him taking over the team uh they won the Super Bowl and then they continue to win the Super Bowl many years after even after he left and so he has like learnings from him coaching the 49ers and now he like he wrote a book and it's very relevant to like business leaders as well and the idea is like just focus on the inputs and everything that you control don't focus on the outputs if you do the right thing and you do it really really Well, the score, the results will take care of itself.

And so, one of the things that he like one example that he does is like even the janitors that worked for the team, they had to like dress well. They had to be cleaned up. Every player that goes to a game, they have to wear a suit and tie because it makes them feel better going in. um there's just like a standard of performance that is very much on the inputs like do everything well and don't look at the score and I've kind of taken that to heart and it's a reminder for myself every day because I think a lot of founders are like they get they get um and this was me too like at some point you raise money you have investors and you're like oh my gosh the revenue this month this quarter Um and and you you start focusing on the wrong things and you're like should we do this to make this number go up?

Um and instead it's like let's forget about all that. Actually I don't even look at the revenue numbers. Um unless I have to write an investor update. It's like not what's important anymore and it took a while to to completely forget about that.

But I truly don't look at it anymore. And it's more about like you know in the sales process at least like this is just an example. Are we asking the right discovery questions? How do we improve each step?

Um, this customer asks like ask a question like are our docs not clear? Like just really focusing on the inputs and making sure everyone is like hey dayto-day are we doing what we're doing well and are we working on the right things? If it is, we will do well. It will take care of itself.

Let's not talk about those things. Just talk about are we doing quality work and doing the right work. Great way to end it. Thank you so much, Jacqueline.