0:00Hi, everyone. Thanks for joining us. My name is Zoe. I'm on the growth team at MotherDuck. For anyone new to MotherDuck, we provide infrastructure for answers for both engineers and operators. So we're starting a new series where we're actually going to be sitting down with folks that are building inside of the company at MotherDuck
0:20to talk about how they query data and what that looks like and how it impacts their roles. So we thought that there would be no one better to start with than our chief of staff, Kaitlyn. We're excited to be here with you all today to talk about how she is operating within MotherDuck while using data that we have for her and how to query, visualize it and use it as a context layer.
0:42So, hi, Kaitlyn. You want to do a quick intro? Hello. Hello, everyone. I'm super, super excited to be here. Like Zoe said, I'm chief of staff here at MotherDuck, which means a lot of different things, and we'll definitely get into it. But I think this is going to be a fun session. We can get hands on with some of the stuff that I know the operators are thinking about every day.
1:03And we're living in a world where you've got tools to be able to action this stuff in just like ways that you have never been before. So I'm excited. Awesome. So just for today's agenda, we will actually roll through two different specific flows that Kaitlyn uses on a daily basis at MotherDuck. But before we get started, how did you become a chief of staff and what does that mean to you?
1:27Oh, there's a version of the story that I tell when I'm trying to make it seem like this really beautiful, clean through line. And then there's a version of the story that's that's the real version. I think the real version is I I don't know. I've kind of just like followed my curiosity, a bunch of different places. And it's it's landed me here. I straight out of school tried to found an ag tech company of all things.
1:51Didn't work out, but got the startup bug completely and then actually moved into venture capital after that, where I got to invest in early stage startups. And really the skill that I built there was being able to look at things that sort of a ten thousand foot view and say, hey, you know, where are the big pockets of opportunity to generate more enterprise value?
2:12What could we be doing differently? And I got approached by Tristan Handy at dbt after five or six years in venture capital. And he said, hey, why don't you come be a chief of staff and sort of apply that knowledge to actually helping us act on those opportunities? And so that landed me my first chief of staff job at dbt Labs.
2:32And I totally got the bug to do this at an even earlier stage. And so joined MotherDuck when we were a little less than 100 people and have been here ever since. OK, cool. How do you think about making decisions at MotherDuck?
2:49Like what keeps you up at night if if you were to explain what your role is so that we can use that contextually for what we're moving into next? Like, how would you summarize what that looks like? Totally. And I think I hope a lot of the operators on the line, too, will resonate with this.
3:05But another word for chief of staff roles and a lot of these sort of operator roles are people who handle, quote, strategy and operations, which sounds like a super nebulous thing, but someone described it really well. And they once said strategy is just decisions. That's all strategy is a decision to do something. Operations are executing on that decision.
3:29So what that means in practice here is the chief of staff role is really about making sure that we are having conversations about some of the most important decisions to be made as a company, whether that is how we structure the team or what is on the road map, how different parts of the company work together most effectively
3:49and then trying to build infrastructure to help execute on those decisions and monitor whether or not they're working, which is a lot of what we'll get into today. You know, that is obviously a very data driven endeavor or in a perfect world. It should be right. You know, I think you can get everyone into a room for the decisions side of that. You know, hey, we have X, Y, Z problem at the company. Let's all get together.
4:10Let's talk about what we're going to do. But then you need to be able to actually track how that's going. And people do that through things like company goal setting frameworks. A lot of people use OKRs, for example. We've sort of made our own homegrown goals framework here. And I would bet a lot of the operators on the on the phone have their own sort of goal setting frameworks that they do.
4:31And then there's ways to sort of monitor progress against those goals through things like weekly business reviews, monthly business reviews, board meetings and things like that. And all of that sort of falls under the chief of staff purview. So I like to think of it as strategy and operations, strategies, decisions, operations is executing on those decisions.
4:50And it's your job as an operator to own that intent. OK, thank you. And then just a question. I know obviously we're going on two different areas. So Kaitlyn's actually going to start by walking us through how she thinks about token spend, which I know is like a hot topic for a lot of people.
5:11I'm not sure how many finance leaders we have on the call, but hopefully that resonates for some people joining us. As we scale really quickly and our team grows, I know that's something Kaitlyn tracks very quickly on a daily basis. And then after we move through our token spend, we're going to run through how Kaitlyn actually runs our weekly business review
5:31and the metrics that are most important to us to track on a weekly basis. So, Kaitlyn, do you want to hop into the token spend to start? Yeah, 100 percent. Just a high level overview to get started. So I would say tracking token spend is like the number one thing that I talk to different operators about.
5:55And that ranges so much in title. I talk about it to a lot of chiefs of staff. I talk about it to a lot of like engineering and product ops leaders. Finance people are obviously thinking about it. And unfortunately, if you're working with one of the frontier labs,
6:13they go to pretty decent lengths to make sure that you can't like it's kind of hard to find data about how this stuff is being used. And so with MotherDuck and a feature that we have called Flights, which is a data pipeline tool, I've been able to basically aggregate a lot of that data together into one spot, pull it on some sort of a regular basis and get us a view of of our token spend.
6:36So I will go ahead and share my screen. This this is our usage dashboard. We've we've put dummy data on it. So this is all fake data. But this is like truly what the visualizations look like every day. And I would imagine that most people, this is like the shape of their graph.
6:58Like everyone is starting to use AI more and more. It's going up every single month. And really the headline question here that I think about when I'm talking to our CEO or to our engineering leader is, how high does this number need to get before we really want to start thinking about whether or not there's a different way to be working with these models? You know, the path that a lot of people go down is you start with the Frontier Labs.
7:22It gets to a certain expense point and then you sort of switch to maybe more open weight models or or things like that. So with MotherDuck and again, I am not a technical person. I have never written a line of code or even a line of SQL by hand in my life. I was able to pull this all together pretty quickly.
7:43So through the dashboards that you can find in your Claude admin or your OpenAI admin portal, you're able to see a lot of data sort of at the individual user level, how much people are spending each month on any given tool. You can look at it across different tools.
8:05You can also get a sense of API keys and how much money is being spent on those. But unless you're in the enterprise plan for some of these things like this data is not presented to you in a really clean way. Like there is no, you know, API that you can hit for all of this. You can download a CSV file for some of it, but for other things, you would just have to scrape the data that you're seeing on the screen.
8:29And so the big unlock here with MotherDuck flights, and I encourage everyone to to go download a MotherDuck account and and try this out, is I was actually able to make effectively a vibe coded data pipeline that will download the CSV reports that I have every single week. It does it on a schedule Mondays at 9 a. m. , as well as like scrape the actual screen for data,
8:52structure that into a format that can be put into my data warehouse, which is MotherDuck, and then aggregate that all together into this nice dashboard. So some of this stuff is things where you would have to either pay for the enterprise plan or even go a little bit deeper into sort of like finagling these APIs to be able to get it.
9:13But relatively quickly, I mean, this this took me less than two hours to make. Like it really wasn't that much. And you can get down to pretty granular cuts here. You know, you can see, OK, which which of my models are really driving most of my spend. What are the surface areas that people are spending most time on? Like, OK, Claude Code obviously drives a lot of this.
9:36But like, oh, you know, co-work has been going up quite a bit over time. And so maybe we should we should watch that. So it's a really, really powerful tool. I think the biggest thing that I think about from a decision making standpoint here is, again, like I said, at this point,
9:58let's if we look at this annualized spend here, one hundred ninety seven K a year that let's let's call it about the cost of one headcount. I think it would be pretty safe to say at our company and most companies out there that spending like A. I. has made us as productive as adding one more person to the team. I think that's a no brainer.
10:18But eventually that number is going to get up to half a million bucks to a million bucks, maybe even two million dollars. And you start to get to a point where you say, OK, like, are we actually getting a level of value out of this? How do we need to optimize this? And there's just some really powerful things that you can do with this data. So I love this. This has been a thing that I look at every single month.
10:40I talk about it with our engineering leaders. Sometimes if I see a user whose usage spikes a ton, I will reach out to them and say, hey, how have you been using this tool? What are you finding that's interesting? You can also make skills in Claude to help them analyze their spend so they can. You can just send it to them and it'll analyze their Claude usage for the last week or last month and say, you know,
11:04here's how you've been using tokens and maybe here's five or six things that you can do differently to try to optimize that. So it ends up being this like really powerful tool to just double click on our spend and make sure it's all going to the right spot. So that's that's the usage tracker. Before we move on, we actually had a few questions in the chat about this.
11:27How do you think about the ROI on token spend? Oh, boy. The ROI on token spend is really tough. Again, I. I think in the early days. I would think about it truly as like an equivalent to headcount.
11:48When the number is small enough, you can pretty easily rationalize that, hey, this is probably as good as as adding one more person to the team. As time goes on, I think really, I mean, the there there are tools out there that can help you really get down to this, like on a really granular level.
12:12Here are some changes that you can make on an ongoing basis. But I do think you have to start truly looking at it at an individual level and empowering your team to be able to spend this as effectively as possible. I think the reason why thinking about ROI on token spend is so hard is because every person uses this in a really different way.
12:32How our people leader uses AI is completely different than how one of our engineering managers uses AI. And even within engineers themselves, they're all using it in very different ways. And so I have tried to think about token optimization, honestly, less in the macro picture of things.
12:51And I think about it more from a how do I make sure each individual person is doing this as effectively as possible for their job in the same way that it's been really hard to teach people sort of broad based skills over how to use AI? I don't know if anyone else has had this experience, but. I've like attended like one or two trainings on how to use AI.
13:13We've thought about bringing trainings in house and like the reality is the best way to learn with these tools is by just getting hands on with them. And so I think about token optimization in the same way. I think it's hard to apply broad strokes principles to are we spending this effectively? I think you have to really get down to the individual level, empower the individuals.
13:32And if your company is a little bit bigger, think about this being part of a manager's job is they are not just managing a set of people. They're managing a set of agents and AI tools, and it's their job to make sure that those things and people are working effectively and getting the most out of them that they can. So it's a tricky question, but that's really the only way that I think I've been able to rationalize it is at a high level.
13:52Think about it as is this adding more people and am I as effective as adding those many people? And then on a micro level, think about it as just empowering the individual to do the best that they can. I think that makes sense. And obviously, since agents are changing the way we work on kind of a weekly basis,
14:12it's almost like we would constantly be behind if we were just doing trainings instead of just living in the moment. Oh, it'll be 100 percent. There's another question in the chat. I'm not sure if you want to cover this now or when we roll through the WBR, but it's about queuing pipelines and how you think about trust levels. Do you want to chat through that with this one or let's have a look?
14:36We we can hit it here. And some of the the principles, I think, apply to the WBR pipeline. But it's a really good question. So I think this flight in particular is unique or this this dive, which is what we call these dashboards and MotherDuck is unique because it is taking what I would call unstructured data.
14:59Right. Like effectively, this thing is scraping screenshots. And so to be able to trust that it's doing that well on an ongoing basis can can be really tough. The way that I have found most effective for me, again, as a non-technical person who's less familiar with things like evals and stuff like that is in the initial process of building this.
15:23Definitely go through spot checks. Right. Like as all this data gets aggregated, you can actually go back and have Claude or OpenAI or whatever you use tell you where it got something. You can go back and check it. And then as you are doing that, you will probably notice it will tell you things about how it has chosen to process this data, how it has chosen to make sense of it.
15:47And you can actually tweak your instructions in the flight prompt to make sure that you address those. And so pretty much my process every single time that I build a flight or build some sort of a data pipeline is let it pull the data, have it go back, explain to me how it did it after after it's done it.
16:05Got check some of the data, tweak its instructions and put those back into the instructions for the actual flight. So it's a little bit of a messy process. Again, as a non-technical person, there's probably more that I could do with evals and things like that out there. But for now, I think that that gets in 90 percent of the way there.
16:28I think, too, it's. An important thing that I tell chiefs of staff and anyone who is responsible for reporting out to the company on a regular basis on how the company is doing
16:44or looking at a large set of data is it's really important to be in those numbers all the time in order to get an instinct on how they're going. So if really the only time that you look at how your company is doing as a whole is quarterly at the board meetings, you're not going to have a really good instinct over whether or not some data point is right or wrong.
17:05And the reality is in this new world, like we do have less visibility into what these models are doing. And so we need to be able to rely on our own instincts. And so I encourage people to, like, say that if there is a dashboard that you have made, like you need to be looking at it minimum once every two weeks, like you need to be that familiar with the data. You need to be constantly poking holes in it and asking questions.
17:29At the end of the day, like your human instinct is going to matter a lot here. And so just keep finding ways to hone that human instinct. Thanks, Kaitlyn. I know that we are right at the time that we probably want to hop into the weekly business review just for reference.
17:48I know everyone calls these like different things, but for everyone that's joining for reference, our weekly business review is a meeting that actually happens today, every Thursday that Kaitlyn runs where we run through cross-functional concerns. It's a place to zoom out or zoom in on areas that are going well or that we want to flag across engineering to product,
18:12to how we think about people using mother to compute all the way through to our own revenue and marketing metrics. So, Kaitlyn, if you're down, I think it'd be great to jump into that. And just for reference, an area that we haven't talked about a ton is guides. She'll get into it, but that's a context layer that we run on top of all of this.
18:34Yeah. Yeah, I think guides is honestly really the star of the show here. So this is our weekly business review dashboard or dive, as we call them in MotherDuck. This is really meant to be the canonical source of truth for our company on how the business is doing. So this is all dummy data. It's it's not real data.
18:57But I think if you're a operator, it may be like a small early stage startup, like a lot of these things are going to look familiar to you. I'll briefly go through sort of the main things that we're hitting here just to show the level of granularity that we can get into. But you sort of start with, hey, these are our overall top line numbers on how we're doing.
19:17This is, you know, based on our target for the quarter, how we're pacing towards that in any given week, how much of our revenue is coming from old customers versus new customers. You can go into changes by week and and what's driving it. A big part of what I do with these WDRs is, you know, I'll look at this data at the beginning of the week, try to spot any anomalies that are out there.
19:41This is a prime example and say, OK, the last week was a really big week for us, both on how much expansion revenue we got and on contraction revenue. The fun thing that I love about dives is there's an AI chat feature that you can have in it, too. And you can go in here and ask questions like what drove my. expansion last week.
20:04This is dummy data, so unfortunately, it will not give a good answer if I ask a question, but you could really use this to dig into everything. So I think most of the operators out there, like a lot of this stuff will look familiar, whether or not you are doing this across your entire company, like this weekly business review dive is doing,
20:24or even just for your individual domain. So whether you're a finance lead or a customer success lead or something like that, this idea of having a dashboard where we look at the most important metrics in our business and you sort of want everyone to agree on it is like a pretty common thing that people want to do.
20:49And this is where I think it's really important to talk about guides. I think that Ian McComber at RAMP said this really well, in a world where it is really easy to make dashboards, which is very much the world that we're in now, again, I'm a non-technical person and I was able to make this completely on my own without writing a single line of code.
21:12The rare thing to get to in a company is consensus. So how do you know that everyone, when they say, how much AWR, which for us is annualized weekly revenue that we had the week of September 20th, how do you make sure that everyone who asks that question gets this exact answer right here? It's a really hard thing to do.
21:35And the best way that we found to do it at MotherDuck, which has worked extremely well, is through something called guides. So guides are really nothing more than just like large markdown files that define sort of your key business metrics, how you want to pull them and how you calculate different things. For you as an operator, this is sort of the power of the moment that we're in,
21:59you are gonna be the one who is closest to these definitions. You know why they matter, you know the nuances of, okay, well, when I think about what an MQL is, it's actually, it's this thing, it's not this thing, and you gotta always be careful to not forget about this thing over here. And so what I was able to do in sort of one of my first things that I did here at MotherDuck was sit down and say,
22:23okay, what are our canonical business metrics? What are the things that are the most important things for evaluating the health of our business and how do we really concretely define those? It's an exercise that I encourage every single operator to go through when you first step into a role. Sometimes there's a lot of stuff already there and you find that people agree on most things.
22:47And sometimes there's gaps and you can be a big part of helping to fill those. A good example for us is where a usage-based revenue business, the concept of churn and when a customer has truly churned versus just contracted is a difficult concept to think about and not everyone agreed on it. But what you don't want is for someone to go asking Claude, hey, tell me what customers churned
23:11and for three different people to get three different answers on that. So using guides, I was able to basically pick, I would say about 25-ish metrics that we care about across the business and codify what those were in guides. These sit directly on top of MotherDuck. They are super close to the data. So every time that someone is building a dashboard
23:34on top of MotherDuck using dives or every time that someone is just asking a question in Claude about their data, they call guides. Guides are able to be referenced in the answer and it makes sure that everyone is getting the same answer and using the exact same calculation every time. So it's a super, super powerful tool and honestly like a completely necessary thing that you need to do when you're going and building something like this.
23:59Otherwise, what's gonna happen and this was happening before we joined, you're gonna have, you're gonna sit in a meeting, you're gonna say, hey, our total AWR last week was 4. 8. Your CEO, your head of sales, your head of whoever is gonna be sitting on the side and say, actually it was 4. 7 and then you're gonna spend the whole meeting like arguing over what that number is. So I really would encourage everyone
24:22to go about building something like guides where you define all these things. It's absolutely necessary in this age where more and more people are gonna be self-serving on top of your data. Well, and Kaitlyn, just to add to that too, for reference, like for anyone that's not super familiar with MotherDuck, like we are powered by our own warehouse when you're looking at Kaitlyn's data app here or dive,
24:44but our warehouse is connected to everything from like our ad spend vendors to Ramp to any other platform that we're using that's being ingested into the business and therefore it's all living there and that does get to be that source of truth that's feeding the guides. Just for reference, I didn't know that as an operator like a year ago, so. Yeah.
25:10No, it's really powerful having this stuff this close to the data. I think there's a lot of ways to think about like semantic definitions and like a lot of the times those things can be like really, people, especially data engineers, I think wanna codify them in like semantic models or dbt models or something like that,
25:34which I think our thesis here at MotherDuck and what has proven to be true is that now these days, these models are really, really good at just deciphering natural language. So to just have one big markdown file where all of this lives, it's both human readable so that I can just make sense of it. I can look at it and be like, I understand exactly what this is saying. The models can interpret it really well.
25:57It's turned out to be a super effective tool for us, so. Yeah, that's that. We have a few questions in the chat. Is there someone is asking if you have an example of what a guide looks like? If that's hard to pull up now, we could definitely have someone on our team follow up
26:21with examples of guides afterwards. It might be, I'm trying to, let's follow up afterwards. I haven't logged into GitHub for the day. It's, watch me go through my octal login. But just to like talk about it at a high level,
26:45like it really does look and read just like one big document. And what this started out for me was a like huge Google Doc. And I wrote down sort of the business definitions in there. You also too, I mean, these models are pretty good these days. If you have an existing data warehouse where all your data lives, you can go in and point it at your data warehouse
27:09and basically ask it to build you a set of metrics definitions based off of these things, based off of what it sees. And then you can go in and say, okay, here's how it's interpreting the data in my data warehouse. Let me correct it. Let me add more detail here. And so in terms of what the guide actually looks like itself, it's one really big doc. It goes through a bunch of different definitions
27:32and it ranges sort of from in some moments, there's a like really specific note about how the SQL should be interpreted. A lot of times, again, the models themselves sort of make those interpretations. And sometimes it's just more of a high level. Hey, when you think about net dollar retention, here's the like math equation for how to calculate it. So, yeah. I'm gonna roll through a few more of the questions
27:55I see in the chat as well. So someone asked when you use a guide versus defining something in the semantic layer, and then they followed up by asking if we use dbt in our stack. Yeah, so it's a super good question. So we do use dbt in our stack.
28:17I think the idea of modeling data in a structured way is still very useful in this moment. There is sort of a philosophical debate going on right now over how structured semantics need to be, which is kind of what I was alluding to earlier. For us, we have chosen to use dbt primarily as a transformation tool.
28:41So if something comes in in like a really raw format, and we need to clean it up a little bit, like we do still use dbt as part of that stack. But we don't have like a hardcore semantic model. We used to have a BI vendor six or nine months ago that did have some semantic modeling capabilities in it, and we had built some stuff out in there. But we pretty quickly said, hey, I think in this new AI era,
29:06more of a open-ended markdown, lightweight style approach like guides pretty much like served all the purposes. So for us, we've chosen to go the more lightweight route. And we actually did have a moment where we had like pretty strict, like semantic modeling on one side and guides on the other. And they worked like pretty similarly. And let me tell you, the guides are a heck of a lot less work
29:31to be able to get to than strict semantic modeling. So it's a philosophical question that I think everyone has to choose for themselves. I do think the way that these models are headed, I think you're going to need less and less doing strict like hand modeling semantics on your own. So, yeah.
29:54The next question is, how have you solved the gap between data in a warehouse and this guide? How is the process with business people and technical? If any. Zoe, how are you interpreting that question? I'm assuming that this would really just be like the change management piece
30:17of like how to educate different types of like internal groups if the person that asked this question wants to add more context, let me know. But otherwise that's how I'm interpreting it. Yeah. Change management is a really big part of this process. I don't want to like skip over the fact that it is a pretty difficult thing. So let's go back to the churn thing, for example.
30:44You know, churn when I got here was not well-defined and different people had different perspectives on it. I think it's your job as the person who is closest to the data or who is tasked with building this view to come with an opinion, but you do then have to sort of play the whipping the votes, the whipping the votes approach of saying,
31:09hey, I'm going to get everyone on board with this particular definition. And so identifying the two or three key stakeholders that really matter, like for churn, you know, our CEO is that this is a big thing for them, our head of finance, and for us, it was our customer success leader. Those were the three people who I knew like, I need to get you all on the same page about what churn means. Once we're on the same page, we can codify it in one place. And I think too, the reality with change management is those three people really care
31:33about what that definition is. A lot of other people are just sort of happy to go with whatever you choose. And so what's nice about guides is once that is baked into your BI slash analytics, agentic analytics workflow, everyone sort of then gets the definition
31:58like osmosis into them over time. So on the change management side, you definitely do have to go, you do have to play a large change management role in the beginning, focus on two or three big stakeholders. After it's codified in guides, it'll then flow through to everyone else's workflow. And people tend to pick it up pretty easily from there. Guides also being human readable helps with that a lot. People can actually go in and say,
32:22how do I define churn as a business? And they can look at it there. From the technical perspective, occasionally there's additional like modeling that you have to do to go back and change something, right? You might wanna change the name of a table or a column or a set of columns on how you do things. We do have some data folks on hand that help out with that when it's needed, but I would say it's needed far less than it used to be.
32:46So our data folks have had to do less as a result. I think a really powerful demonstration of this was once we had shipped dives internally, we made a decision to move off our dedicated BI tool. So we had a separate BI tool that we paid for and we moved off of it. I managed that process end to end as someone again, who has never written the dbt model in their life.
33:08And I posted this on LinkedIn when we finally made the jump. I was checking in with our two data engineers before we officially like turned the light off on the BI tool. And I said, hey, is everything good to go? Are you feeling good? And these people both said like, I'm feeling great. I've done pretty much no work as a result of this. So you can do more and more as a non-technical person these days, which is great.
33:32Yeah, this is making me just want to stay on this call with you for like two days about all of the different dives that we run as a business. I see we have two more questions in the chat or three for now. And then we have kind of like a wrap up question and can hold space for more Q&A. But someone asked if it's more expensive to rely on a guide versus just within the data model.
34:00I'm assuming this is from a token spend perspective. The logic of the question holds, yes, when you are calling, if a data model is embedded in SQL and it can just be part of the like SQL function when you're calling it, yeah, it's gonna be cheaper than money that you spend on tokens, having a LLM interpret a guide. And then go back and try to apply that to how it's pulling SQL.
34:25So that I follow the logic of the question from a query basis. I think the thing that the question is missing is the cost of maintaining that data model long-term, especially when things are changing quite quickly. I do think over time too, you can take something in a guide
34:48and codify it in the data model. Like I said, when you look at our guide, there's a mix of sort of specificity that goes into it. And sometimes it is like, hey, anytime you are gonna calculate XYZ thing, use the SQL query and do not change it. And that can be pretty straightforward. And you can even go so far as to say, okay, on some sort of regular basis, I'm gonna codify these into my data model.
35:12So you can take this iterative approach, but that's sort of how I would frame the question is logic definitely holds that. Yes, like calling an LLM versus calling something like having this codified in SQL is going to be more expensive on a query by query basis. But I think any data person will also tell you
35:35that maintaining a data model is tough over a long period of time. And it can be hard to keep pace with the business. And so I would think about that cost as well. Okay, thank you. And then there's what I would consider a spicy interesting question in chat, which is what is your opinion on whether this business logic, so guides lives in the data warehouse versus in a BI tool
35:58or just totally separate of both? Ooh, I do have an opinion on this. I will caveat it all with, I work at a company that's a data warehouse company and builds data warehouses at the end of the day, but I've also worked at dbt, which puts this in a totally different camp. The story that has really changed my mind on this
36:19was I was chatting with a friend who works at LangChain, which is a fairly like AI forward company. They build tools to help people build agents. And I asked him, he works on the data team. And I said, hey, what keeps you up at night right now? And he's like, look, we've done all of this modeling,
36:42all this work in a separate semantic layer. And I have people writing all agents all day and they're all just going directly to the data warehouse. I can't get them to pass through this other place, whether that is in your BI tool, whether that's in a separate semantic layer or anything else. And so in a world that is really self-service, which again, like we are getting to where people are going to have to build,
37:06people are building all this stuff themselves. And it's hard to get them to follow like strict rules on how to do it. I think that your metrics definitions need to live as close to the data as possible. And so for us guides like lives in the data warehouse, you cannot miss it, even if you are querying the data warehouse directly. So that is my personal opinion on where this needs to live.
37:29I think people have differing opinions, but again, having seen this from a couple different angles, I think that is the best way to make sure that all the work that you put into like codifying these metrics lives on and is used every single time, no matter what, so that you minimize hallucinations and everything else. Well, and also just for anyone on this call
37:52that is not super familiar with hallucinations or SQL, just to call out that like, I think that this has actually been a more technical chat than I expected us to have, which is really exciting. So like the technical operators that are like following MotherDuck, thank you for joining us. Just for reference though, you can just connect via like CLI and start running tests.
38:16I don't think I'm quite as technical as Kaitlyn, but all of our growth marketing decisions, including about spend are made through the MotherDuck product, just by connecting to like our warehouse, which is connected to ad platforms and our signups and all that kind of stuff. I know that we're almost at time, Kaitlyn. I wanted to ask you a closing question before we open it up for Q&A.
38:39I know we were slacking, what, last week about the blog posts that Notion put out. Like essentially making everyone a data scientist. I'm curious, like as you, based off of your experience at dbt and now at MotherDuck, like what do you think that will look like six months from now that people aren't really like talking about as much currently?
39:04Oh, six months is such an interesting timeframe. Like it's, you know, 10 years, two years is like easier to answer than six months from now. So if anyone hasn't read the post, Notion is the latest tech company to sort of make a self-service data agent for their entire team. So instead of pinging your favorite analyst on the data team,
39:28hey, what was my revenue last year? You can just ask, I don't remember what they named their bot basically, but you can ask this data scout, I think was what they called it. And I think, I mean, what we're seeing is that this is pretty much the ideal that every single like company,
39:53at least that we talked to like wants to get to. But it's really scary. Like we were even just talking about. this morning? I think the workflow side of this, like generating dashboards and getting to answers is largely a solved problem at this point. People launched a Claude launch called dashboards recently. You know, we have dives, a lot of different people have some
40:16sort of way to actually build these data visualizations. And the biggest challenge that people are facing now is trust in the data that they have, and that people are actually querying the same thing and getting the right answers. And so, I think six months from now, we will
40:38watch more and more people feel comfortable adopting tools on the front end side of this problem. And I think you'll have a lot of people saying, I'm going to use Claude dashboards, I'm going to use, you know, whatever. But you're going to have a lot, a lot more people
40:57saying, now I have this big unsolved problem, which is the trust side of things. This is where guides come into play. This is where all this stuff, like, you're going to have to start doing work that sort of feels like back end work, which is a little scary. But again, I think a big part of the theme here today is that that work is able to be done
41:19by non-technical people more so than it's ever been. And so, I'm excited for the world six months from now. I think we'll all face, like, a very new set of problems. But it's something that we're already thinking about here at MotherDuck every single day. And I think there's, like, a real path forward. I love that you're answering this so calmly while you're clearly getting here. As I'm walking, I'm sorry.
41:44If anyone has any additional questions as we wrap, feel free to throw them in the chat now. We're happy to wait, like, a minute or two to see if anything else pops up question wise. In the meantime, we just linked the you can just go to motherduck.com slash get started if you're interested. We have a free trial where it's, like, super easy to connect
42:08your data to whichever sources that you're interested in testing with. So, you can build your own guide or dives for a week. The other thing that I would call out is that we're actually running our own data and AI conference three weeks from today, actually. It's in San Francisco. We have people that are leading data, AI, ops and engineering speaking from companies
42:32from, like, Stripe and Mercury to Clay and Perplexity. If you don't already have a ticket, we added our code here just for a discount. We have pretty limited availability for our workshops right now, but we have one day of talks, one day of building. It looks like we don't have any other questions in the chat for now, so we're going to hop
42:56but thank you so much, Kaitlyn, for the brain dump. This is a series that we're going to continue in about a month. We're actually going to do this with one of our product leads about how she builds with agents. And again, you're welcome to try MotherDuck grouping our team if you have additional questions. Thanks, y'all. That was lots of fun. Thanks. Bye.
