 Or you can continue charging your devices. That's fine, too. Welcome. I am happy y'all are here. My name is Anna. I'm going to be talking about how we, and that is many more people than just we, have scaled the community that's behind the DBT open source project from a few hundred folks to now over 30,000. And this is a slightly polished version. I am the director of community at DBT Labs. And I also run the data function because to us they're kind of closely linked. And a little about me and kind of why I'm up here. Communities are my universe. They're everything that makes up my life. I like to tell people the story that I met my husband at a Ruby meetup. So communities are very special to me. Most of my friends. I've met through some community or other. And I think it's just an incredible way to improve social mobility. Communities offer opportunities that you won't be able to get anywhere else. And so I tend to apply that lens to everything I do. And I'm really grateful to be able to apply that lens to a community as large as the one behind DBT. I've been a member of communities, studied communities and scaled communities for about 15 years now, I want to say. All the way from like open source to data and everything in between. I went to grad school because I wanted to learn how open source communities worked and help them work better. So if you're ever interested about that, I can talk to you in the hallway track. But today I'm responsible for one of the largest and most active communities in the data analytics space. And that's the DBT community. So what we're going to talk about today is I'm going to give you a little bit of a background about what DBT is because I think for most of the folks attending, this isn't a project you might have come across. But I promise you it's really big for the data analytics folks. I'm going to tell you a little bit about the growth trajectory that we were on so that you have some context about what scale means for us. And I'm going to give you a little bit of a talk about how I think about communities. I think they're three different kinds. And spoiler, they're not actually mutually exclusive. And then related to each one of those, we're going to talk about how we've scaled awareness of communities, knowledge sharing in the community, contributions, and even culture for 30,000 folks. So this is DBT. This is DBT core. It's the open source heart of the DBT world. And it's basically a DevOps framework for data analysts. So analytics code is still code, no matter what language you write it in, SQL is code. So what DBT does is it helps provide a framework for analysts to work like modern software engineers. So think Rails, but for data people, right? About 9,000 companies use the open source project in some form. There are hundreds of forks, hundreds of community contributions by now. The project is about six years old. It was, the first commit was March 2016. And we just released 1.0 last December. So we have a high bar for 1.0. And this is the growth of our community along this time. So the community has existed pretty much for as long as the open source project has because as soon as the open source project kind of landed out in the world, it transformed the way that folks on data teams work much in the same way that Rails did in 2008 when it first appeared, right? It really helped people develop more quickly and in a much more standardized way. And so DBT does the same thing. And people got really excited about that because it's a really, really new thing for folks in the analytics space. And so you can see that right around 2020 is... AV Guy told me not to turn my head. You can see that right around 2020 is when stuff started to really take off. And that's because we started to build a company around the project. So before it was just an open source project that was supported on a semi-official basis by a consulting company called Fish Town Analytics. And then we rebranded, we became DBT Labs, and we invested really heavily in developing the open source, the open core part of DBT. So we have an entire core team with an engineering manager, and we have a product manager who's responsible for this area. And so we have kind of a really interesting dynamic in terms of the development that we do and contributions. And our growth is still doubling. So we've doubled in the last year from more than doubled, from about 14,000 to about 30,000 now in terms of humans in the community, which is really cool. Looks like a literal hockey stick. So audience participation time. Any guesses what those little bumps are on the graph? I don't know if you can see them. Yes? Good guess, but no. One of those is, but it's also tied to a different event. Anything else? No? So we've actually been running a conference for the past two years. And it's at the end of the year. We announced our 1.0 release at the user conference, and the bump in community growth is a result of people gathering and talking to each other about this community. And every time we gather folks together, we see kind of like a step change increase in the rate of growth of the community, which is really cool. So before we get into like the meat of all of this, if there's only one thing that you take away from this talk, is really that you're never done building your community. It's a living, breathing thing. It's kind of like when you adopt a puppy. You kind of have to be with it throughout its entire life. So whether you have 50 people who are just really getting started using the thing that you've built, or if it's 5,000, you're always thinking about how to make their experience the best one. And so it's really not about you. Okay, so I lied, it's two things. You're never done, and it's not about you. And so you're not thinking about like how do I build a community at the scale that we're talking about. You are more tending a garden and you are encouraging and nudging things to work in a particular direction. You have very little control over the process at the scale that we're at. And I like to think about communities as aligned in three buckets because I always like to ask why. What is the problem you're trying to solve? What is the problem you're trying to solve with your community? And those three buckets, for me, are brand contribution and community practice. So when I say brand, I'm not talking about like company brand. I'm talking about identity, right? So the way that Obuntu is an identity, or in this case, I think folks in here would appreciate this, you know, the arch community has a very strong identity so much so that it's spawned a meme. People are really proud of the fact that they use Arch Linux, right? And so it's like, oh, hi, by the way, I use Arch Linux as a meme. And you literally don't need to know anything else about that community. And it's funny, but it's also a really great awareness tool. So that's brand. You've got contributions, which is kind of what people typically think about when they think about an open source community. It's like people contributing code, right? Maybe documentation, but, you know, depending on the types of humans and the type of problem you're solving with your open source project, contribution can mean a bunch of other different things. So for example, DBT solves a problem for data analysts. They're not usually folks who are writing Python every day in a production grade environment. I expect less contributions in the form of code, but we get a ton of documentation contributions because we make it really easy for folks to do that and to help us. And that's especially important because DBT depends, it sits on top of a warehouse layer and there's many different kinds of warehouses that DBT works with and we can't keep up with documenting all of those relationships. And so we depend on the community to document how things work a lot of the time. So, scaling your idea of what a contribution is. And then finally, a community of practice. And this is where you go into the space of forums, things like discourse, things like Slack, and a community of practice is really folks teaching each other how to do a thing. So if you take the example of Rails again that we've been talking about earlier, community of contributors would be folks who are collaborating on code and documentation and things like that. But the community of practice around Rails would be people teaching each other how to set up Rails for the first time. How to integrate it into their workflow, how to change the way that their teams work in order to adapt to this new framework. And so DBT has a similar model. And the thing that I've realized about communities is that it's really not any one of these things. It's kind of a portfolio. There's a proportion of each one of these things that's present in a community in different proportions. And so for us, it's more like 40% brand, 40% community of practice, and 20% community of contributors, mostly because we have an entire team that has a roadmap and contributes code and because we don't expect our users to have the technical background to be able to contribute in the way that some projects might. So roughly, to me, this maps to three different areas of leverage that you have as you're growing your community. So as your community grows beyond a few hundred or beyond tens or hundreds of people, the way that you think about awareness changes, and that's really related to brand identity, the way that you think about encouraging contributions changes and the way that you think about knowledge transfer and encouraging people to help each other, that changes a lot too. And so let's talk about awareness first. This is really a question of do people know who you are? Do people know what you represent? How are you different? If in a small community you're thinking about, like, I just want to get people to use this thing, right? When you're first getting started, you're mostly thinking about, like, hey, come try this thing for the first time. When you get to thousands of people, the types of things that... the different ways that you get the word out about your community, about the open-source project that you are supporting is going to be different. You can't go out and talk to thousands of thousands of people every month as a maintainer, as a founder. So what do you do? So I have a handy meme. There's going to be lots of memes in this presentation. You know, so the regular or maybe pea-sized brain version of this is just, you know, making your project work, right? That's the easy part. I say this is a non-engineer. I'm sure it's not actually that easy. And then, you know, it's about getting people to use the thing. That's like, you know, tens, hundreds scale. And then at the thousands scale, it's about getting people who are using the thing to tell other people to use the thing, right? And so if you have a community of a few hundred folks, it probably took you a lot of time to get to that point. You were probably spending most of your time reaching out and talking to folks. And so the next unlock for you is to scale yourself and get other people to talk about this thing for you. And how we do this, like there's many different ways to do this, but how we do this is we invest heavily in the people in the community. So for example, we coach people in how to write well. We coach people how to speak. We spend a lot of time helping folks refine talks and submissions to our conference to all sorts of other things. Why? It's really good for folks' careers, right? That's number one most important thing, like do things that help other people and then helping yourself. The second is that if there's really compelling writing or speaking that is by the community about their own work with DBT, that says so much more about the project and the community than if it was a bunch of advocates going out and like, here's a DBT demo, right? It carries much more weight. And there's a galaxy brain version of this. So if your motivation here is to get people to talk to other people about the thing, the galaxy brain version is people who aren't using the thing telling other people about the thing, right? And so this is when you get so good at telling the story of like what your project is, what niche you feel, what makes you special, that folks are starting to talk to one another about it, even if they're not users yet, is it possible? Heck yes, right? There are lots of examples out here on the floor. I don't use streaming data, but I hear folks who do use streaming data that materializes popular. That comes up a lot in the DBT community, for example. For folks here, I don't use Ubuntu or Linux Mint, but it's probably the best first Linux distro for someone to try desktop Linux, right? Like almost everyone will recommend Ubuntu as the first thing to try, or at least they did in my time, I don't know if that's still true now, but they don't necessarily have to be able to use it themselves. They just know that it's good for beginners, right? And that is awareness. That is like galaxy brain level awareness, right? And then the other thing is the way that we think about swag changes at the scale that we're at. So, you know, everyone makes stickers, you've got bottles galore, how many bottles and bags and stickers and t-shirts have you gotten today, right? It's kind of ridiculous. You have an entire closet of tech t-shirts. So, that's no longer fun and interesting, but the way that we think about swag is a little bit more of an identity statement. So, think about that distillation of the brand of your community, like what do you stand for, and design your swag around that. So, maybe the platform that you have is one centered around pride. Maybe it's the environment. So, I'll give you an example. For probably the women in the room, who here owns a pair of Rothes? Uh-huh, okay, okay. Okay, keep your hands up. So, of the folks who have a pair of Rothes, how many of you have talked to someone else you didn't know because of your pair of Rothes, or they were wearing them, or they were wearing it? Uh-huh, yeah, yeah, exactly. So, why is that? What's the big deal about Rothes? They are recycled plastic, yes. So, Rothes have a really compelling narrative. They're shoes, okay? For folks who are like, what the hell were we talking about? They're shoes, all right? They are really comfortable women's shoes. And this is, like, comfortable women's shoes are like pockets. That's already a selling point in and of itself, right? So, they're comfortable, number one. Number two, they're washable. And number three, they're good for the planet. And so, that's it, like, that's the narrative. And it is so compelling and powerful for folks that the brand just, like, spreads like wildfire. I think someone had, no? Yeah, we've got a moderator with a mic so that folks on the... Yeah, feel free to jump in. Like, we're a small crowd. Coming up the elevator, not two minutes before coming in here, we had a very lengthy discussion about pockets for women's clothing, yes. So, I'm still waiting for the brand that is going to build a platform around pockets. So, if you're looking for a business opportunity, there you go. But, like, that's what swag is to me at the level of, like, a really large community is, like, you're making a statement. And so, in this case, like, Rothy's isn't swag, it's the product. But the product itself is making a statement, right? It's making a statement about the environment. It's making a statement about, like, women's comfort and reusability and things like that. So, that's really cool. So, I encourage folks to think about that. The fact that she didn't use the word shoes at all... Uh-huh, yeah. Yeah, yeah. So, exactly. Really good point in the front here that I'll repeat is the fact that no one mentioned the word shoes in, like, the first several minutes of the conversation is just a testament to, like, how powerful that identity is. So, that's brand and awareness. Okay, let's talk about knowledge sharing. This is related to building a community of practice. And the reason it's second on my list is because for DBT, those are, like, the two big things, right? Brand and awareness and community of practice. So, a community of practice, just to remind us, is when folks are getting together in a community to teach each other how to do a thing. They are learning something new for the first time, or they are refining their skills. And so, in the case of the DBT community, what that looks like is we have folks who are data team leaders who get together and talk about how org structure changes when you adopt self-engineering best practices. Like, what does that mean for job titles? What does that mean for folks career progression? How do you evaluate folks? Like, all of those things. How do you advocate for these changes in your organization, right? How do you... What are best practices for working with data in this new space? Like, those are the kind of conversations that the community enables. And so, that is what knowledge sharing means to us. The problem is, how do you do this in a group of 30,000 people? Right? It's sort of like standing up in a room and yelling when everyone's gathered for a keynote at a conference like this one, right? It's a lot of people. So, this is where it starts to get really interesting. Who has heard of Dunbar's number here? Yeah, okay. At the risk of putting more steps on our moderators, Apple Watch maybe can have someone tell us what Dunbar's number is. It's basically like the amount of personal relationships that someone can maintain. And if new people come in, somebody else drops out. So, it's basically the average. It seems kind of high, actually. 150, yeah. Yeah, it's a lot. It's a lot of people. Just maintaining relationships like 10 is hard. Yeah, so if you think about it in the context of an organization or a company that you're a part of, 150 is when it starts to become harder to remember everyone's names and what they do. Even if you interact with people all the time, by the time you get to 300, you're like, I know we've met, but... And so, Dunbar's number gets really important. So, if Dunbar's number is 150 and you have 30,000 people in your community, what do you do, right? This is where we do something called micro-communities. So, we start thinking about different pockets of people who are much smaller, who have something in common, ideally within that number. So, for example, we have a community of DBT users in San Francisco, in San Diego, in Austin, in New York, in what have you. We have a community of folks who are data leaders and they have that thing in common with them. We have a community of folks who are working in a particular industry, that folks who are solving problems of the healthcare in finance with DBT, right? Like, in the public sector. And so, it's about kind of breaking things down into different segments and starting to think about what are the unique things that connect people beyond the fact that they're all a part of this community already. And a primary way we do that is when someone posts an introduction, say hi in the, like, community Slack, like, great. You said that you work for, you know, so-and-so company. Maybe it's in healthcare. There's an entire channel here. You said you're from the Bay Area. Cool, great, there's a meetup happening. And kind of helping people find those connections to someone within kind of this, like, smaller subset of the community is a really great way of bringing people in and, like, keeping them engaged. And it encourages people to share more freely because it's a lot easier to talk to a group of 150 people than it is to a group of 300, 30,000. Make sense? And then the other problem you start to run into is platforms. Some platforms just don't scale to the size of, like, 30,000 people. And so, I talk about this as minding the backscroll, and I'll give you a very specific example. So Slack tends to be the thing that lots of communities use, or, you know, Discord, what have you, like, some chat, IRC, some chat affordance that enables folks to get together, talk to each other in real time, answer questions, right, and get, like, immediate feedback when they're, like, stuck on something. Extremely valuable when you have a few hundred people. At 30,000 people, it's nuts. So this is what it looks like for us on a given day. These two posts are in the beginner channel. They are seven minutes apart. There have been about six that say morning already, and it's not even 9.30, right? And so imagine if you're the person who is helping other people in the community. You're really motivated. You're like, I want to help beginners get started. If you're not living in this channel 24-7, you're going to miss questions, and people are going to feel like they're just, like, shouting out into the void. So, like, sad face, right? It's, the backscroll problem is like a really significant one, and Slack no longer has the affordance of supporting that particular community use case at a certain scale. So what do you do instead? Here's what we're doing, and I can't say that this is the best way, but this is what we're trying right now. This is kind of like Reddit and Stack Overflow, but fewer trolls is the way that I would put it. So GitHub discussions is what we've landed on, and there's a few things that I love about this that Slack doesn't do. The first is it's easier to search things. People ask the same questions over and over again at a certain point. You just want to give, you know, you start sending out links. This way people find the most common thing themselves. You can also pretty easily help people navigate to, like, what is actually the thing that they're trying to do? Do you need help? Are you trying to figure out how to do something for the first time? And the really cool thing is we're going to be able to take this and be able to put it together with our documentation website, okay? And so then you have kind of this entire portal where all of your content lives. We can pull out the discussions that are answered, that are, like, gold standard, that are the most upvoted, we can curate, we can do all sorts of things, and it creates, like, a lot of that flexibility. So this has been a really big unlock for us and, like, a really big part of our strategy to keep up with the growing community. Yeah. And many, like, happy face instead of crying face. I hopefully will report back as we continue to implement this, but this is the solution that we've adopted so far. And it, so far it works really well. It's really easy for folks to navigate and has pretty good SEO, which is really important. Yeah. I just have a quick question. So as the community is growing and, like, all these questions are coming in, do you create, like, strategy more to get, like, your community members to answer the questions, or do you guys actually, like, hire more internal staff, like, over? The goal is for this to be a flywheel that the community supports itself. Like, that's the goal of knowledge sharing at the scale of 30,000 people. Like, you can keep up with all of the questions. Someone was telling me in, like, a related company, they have, like, 8,000 questions a day on Stack Overflow. That's insane. Only the community can answer that, right? So be on a certain scale. You really do need to lean on folks, and the thing that you focus on is making it as easy as possible for them to help you. And so that's what the next part of the talk is going to be. Like, how do you scale contributions? Yes. So are you still using Slack? We are. Yeah. So those micro communities still live on Slack. Yeah? Because Dumbbar's number. But for questions, for things that we think are longer-living, we're moving them to discussions. And it allows us to do cool things. Like, someone starts a discussion, and we don't really know, is it a question about getting started with the project? Is it a bug, or is it a feature? You kind of don't know until several comments in. Like, you tend to engage in a conversation with someone, and then you realize, like, oh, actually, this is like a bug. Or like, this is a gap in how we document the thing that we're doing, right? There's an assumption missing here. And so what we then do with that discussion is we transfer it to an issue in the right repo. And we link a pull request when it's been done. And everyone on that thread gets notified that, like, okay, cool, we now have like a blog post about this, or this is like part of the next release or something. And so that creates like a really nice, easy transparency loop without having to do a lot of additional overhead. So let's talk about scaling contributions. And this is us getting close to the end here already. So we just talked about how it's important to help people help you at scale. Like, you really can't... In a small community, maybe you have the opportunity to like handhold people when they're first getting started with contributions. You actually want to. You want to get to know the one person who's like, can I open a pull request against your project? The first few times that happens, you're like, oh my God, that's so cool. The hundredth time that happens, you're like, okay, I need resources. I need material. So of course you need contributor guidelines. You need good documentation. But there's a little bit more to it than that when you reach a certain scale. Like those are kind of like table stakes, right? So at this stage, when you are getting popular enough that you're kind of like batting contributions away, you want to start thinking about like, do you actually want contributions? That's not a given for every open source project. And the reason I say that is because you probably have a roadmap. You probably have an idea of what you're building over the course of like the next six to 12 months. So you do want contributions, but really specific kinds. And you probably don't want a throw away feature edition. You probably want to make sure that people are collaborating with you. So you're more likely to prioritize one repeat contributor over like 10 drive by PRs. It's much more valuable to you to like coach and mentor someone to be there with you, to work with you consistently on a release than it is to have like a bunch of people close bugs for you. Which isn't to say that the bug closing is not important, but like your priorities tend to change. And again, it depends on who is supporting your open source project, right? Do you have an engineering team behind that that is funded? Is it purely volunteers like those dynamics? Those dynamics different? I'd be interested to hear how some folks solve this problem. But for us, because we have an engineering team and we have a roadmap, we have a product manager, we want to be really clear with the kinds of contributions that we're looking for and the kinds of things that we think are really valuable for folks to spend time on. And so here's how we do that. Again, GitHub discussions. But this time it's on our core repo, not our documentation repo. You can see, and I don't know if this is big enough, but there's a few things going on here. We have, the top discussion here is an upcoming feature. So we're kind of signaling to the community, like this is what we're working on, this is how we plan to approach the problem, just like we would expect someone in the community to do before they open up a pull request to like, you know, jump in and talk about it. So we apply the same standard to ourselves. And then you can also see in this example, the number one most requested feature from the community is above the fold, like it's visible to everyone because it's like so highly upvoted. It's actually the last one on this list, column level lineage. It's a really hard problem to solve as it turns out. And so we get questions about it all the time, but we know we're not going to be able to get to it for a while. And it's not something that you can just hack in an afternoon. So we have a discussion about like, why is this a hard problem? And we make it visible. And we point folks to it as opposed to every once in a while you have an AMA or every once in a while you're in Slack and someone's like, when are you doing column level lineage? And we're like, here's the discussion. Right? And like if you want to stay up to date, subscribe to the discussion. If you want to contribute, if you want to work with us on making this a reality, let's talk. So that kind of signaling is super important. And when you give people affordances like this, when you make it easy to discover information, what you will find is that the community will start jumping in and addressing those questions for you. Right? So now anytime Pipeline comes up in the context of DBT, people are like, oh, there's a thread. Just go and look at it. Right? Anytime column level lineage comes up, not only DBT Labs folks, but the entire community is like, there's a thread. Like just go to this thread and everything is there. And it is really, really powerful. So the thing about getting people to help you is you need to make it really, really easy for them to do that. Right? Have things be really well organized, well curated, help people navigate stuff. So like really think about platforms and affordances. I can't say that GitHub discussions is the best thing for everyone. Like we've thought a lot about why this is the best thing for us. Almost everyone who works with DBT already has a GitHub account. Like you need version control in order to make use of the tool. So this is really easy for us to do. Like there's a very low barrier to entry compared to, say, Stack Overflow. You have to sign up for an account. Right? But that might not be true for your community. All right. And last but not least, how do you scale culture? Right? I mentioned for folks at the beginning, and if you missed it, I like to tell people that I met my significant other at a Ruby Meetup. And Ruby Meetups are kind of famous for their warm and welcoming culture, the Ruby community in general. But how do you scale that to like, again, tens of thousands of people? DBT as a community is also really famous for that. It's famous as a really welcoming place, as a really inclusive place, and that's really important because analytics is a field that has representation from so many different backgrounds and so many different kinds of folks' experiences and for a lot of folks, software engineering, best practices, things like Git, working in the command line, those are things they're encountering for the first time. It's really important that we create a safe environment. It's really important that we create an inclusive environment that we're talking about and making sure that things are, that folks feel welcome, seen, safe. And so when you're a small community, like, yes, you need a code of conduct and enforcement policy no matter how small or how large a community you have, yes, you need to remind folks about your rules all the time. In a small community, it's easy to remind folks about rules and be prescriptive, but in a large community, you can't be everywhere. You can't moderate everything all at once. And so it becomes really important to have the community step in and moderate for you, right? Just like it is with content. And it's equally important to focus on what people actually do. So I'll give you an example of what I mean by that. Again, this might be too small, but this is our introductions channel in Slack. And for folks who are a little closer to the front, I don't know if I can zoom in, do you observe anything about the way that people write their introductions? How would you write your own introduction knowing nothing else about this community? I'm going to try and zoom in. Yeah, exactly. Name title company. Yeah, there's like a formula here that's really easy to observe. It's like, hi, I'm so-and-so. I'm an insert title here, and I work at Bloch Company, and maybe I live in this area. And that's it. And everyone has kind of the same pattern. And you will see that when people reply, they will also use kind of a similar pattern to be like, hi, welcome. We're so glad you're here. And the reason that this works so well, we didn't tell people to do this, but the formula exists because people see other people do it. It's really easy to observe certain behaviors like that, but the same is true of behaviors that you don't want. And so if you are not that good at enforcing certain rules and certain behaviors, it can really quickly turn into a situation where you have bad examples that people are recreating because they see other people do it. So it's really important to keep in mind what people see other people do. It can be sometimes more visible than the rules that you have. No matter how many times you put the rules in front of people, it's really easy to lose your way. So that's why you have to scale moderation. You have to empower folks to tell you. You have to make your rules and expectations as easy as possible to follow so that other people in the community, just like they know where the Python thread is and just like they know where the column level lineage conversation is, they know that like, hey, we use threads here. Please don't double post. Please, we have a slack bot that says, don't say guys. Just little things like that are easy for folks to repeat and they help a ton in keeping this like a really easy to navigate and a safe and inclusive space. So that's actually it. That's all I got for you. But thank you for... Oh, thank you. Thanks for the great audience participation. I appreciate it. I'm around hallway track. Folks have questions. I know we're just about up at time. I don't know if we have time for one question. Do we? Okay. Oh, nice. Yes. Please. Thank you. This was really great. Let me just ask my question because we're short on time, but thank you for your presentation. Going back to the community of practice and brand and stuff, for I don't know a long time, but I'm just curious if you have any other thoughts or things on how you identify those? Do you see any band diagrams in them? Are they part of the whole... Is there something that they are inclusive of? All three of those. Yeah, it's a good question. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. Next question. There's definitely a band diagram. I mentioned at the beginning that for us it's like 40, 40, 20, or like 40, 20, 40 in terms of just like how much time people spend in those buckets. So it's probably all of those things, but the weight each one will have might be different depending on what you're trying to do. And so one of the really cool things about the DBT community is that the practice of what we call analytics engineering. Analytics engineering is the act of applying the software engineering best practice as the analytics workflows. It's synonymous and interchangeable with DBT the project. And that's really cool, but that's where branding and awareness becomes really important. And so what the DBT brand stands for is really closely aligned with what the community stands for. So we have to think about that really carefully. Great question. Thank you. Thanks. Thanks for coming. Thanks for hanging out.