 Welcome to the CEO 101. Thanks for joining GitLab. This meeting will be what you make of it by asking questions and chiming in. I said, I'm Amanda. Hi, Amanda. Great to meet you. So I spent last 12 years in a really corporate environment for a SaaS company, but still we had a lot of, I guess, red tape and traditional kind of corporate values. And I guess my question for you is one of the things I witnessed firsthand was how do you continue development, especially one of your values being boring solution when you have huge customers who are asking for customizations that may not, you know, align with a boring solution value. Yeah, great question. By the way, I love Juanajato. I went there for a friend's wedding and it's just such an amazing city. I was stunned. Like you drive under the city and like there's an intersection underneath the city. Like it just boggles the mind. Love the place you live. That's amazing. As we get bigger, there's some things that you will not be able to avoid doing. These are things, no good examples come to mind. Maybe let's talk about the things we should avoid doing. What do you see in big companies? For example, expenses. At a certain point, you get all kinds of complex rules around expenses, what you can expense, which you cannot expense, manager approves, etc. What we can also do is like say, hey, it's your own responsibility. And if you expend stuff that you shouldn't have spent, either you pay it back to the company or maybe we put you on a performance plan or something like that because apparently you lack good judgment. So what's really important is to not substitute good judgment with rules because you hire people because they can do their job. They're smart. They can make decisions that why we're hiring people. So don't prevent them from doing so because a few people are not exercising good judgment. What you do want to do is kind of indicate to people like this is this is about acceptable. This is about not acceptable. So maybe we have a list of things that you can expense to the company for your home office. Maybe we should include a few things that you can't expense so that people kind of know where in general the line is. But what you don't want is an approval process where you have to like ask approval before you expense it like that. That's ridiculous because that holds people back. We much rather spend a thousand bucks on something that we shouldn't have paid for it and then tell the person like that they're exercising bad judgments then then holding you back from buying something you need because it has to go to the purchasing department. There's lots of other big company stuff. Much very important to get lab.com right now is like keeping the get lab.com stable. You could do that by saying, look, we're just going to slow down how many new features we accept. And there's different ways of doing that. That would be very detrimental to the whole company if you joined my general after this morning velocity is the most important thing. So what you do is you both empower people to see the problems they cause. So we're going to have better monitoring in place and things we want to roll out features first to a subset of users. So the impact of any mistakes is reduced, like we have fewer people affected we solve them quicker, but also we're going to make a distinction per team. Your team is doing great and you're not making a lot of mistakes or you resolve them quickly. You get to deploy really quickly. If you cost a lot of outages on get lab.com before that eats in into your availability budget and you're going to become restricted like the team has to approve everything, etc. You only apply like the big company stuff to the teams that actually need it. So not. And that's that's kind of the theme like don't restrict everyone just because a few people are not doing well. And obviously I have no illusions that we'll be able to prevent everything but me and Barbie who's in this cobalt will try to fight it every step along the way. So starting with an open net and filtering as needed rather than being Uber constrictive in the beginning is kind of the way that you prefer. As Barbie says make it a the handbook is a guidebook like not a rulebook depend on people have a directly responsible individual that makes decisions that when a decision is a two way door something that's detailed on a leadership page. If you want to get them back out of don't don't force them to get approval five levels up. It's a one way door if it's hard for us to go back on the decision yeah you'll there'll be a bit more approvals but in general should keep it light and accept. I think except problems. So what what is needed is that you accept that some expenses will be unreasonable and you'll be unable to recover the money. The deployments to get lab.com will make our service go down but it will be limited in in in it will be able to recover quickly. One thing we're doing for example an engineering we accept that we only shift 70% of the features we plan to do. You could argue like we should ship 100% but what you get is that people say okay well I'm going to ship half the features then I know that I'm going to hit 100% easily. You got to accept these these things go wrong because the opposite of things going wrong is just not moving fast enough if you're running. You have a higher chance of falling down but as long as you can get up and keep running that's fine but obviously in a company in management level. You always look at. What's what what went wrong and you try to fix that but don't fix it by making it harder for everyone to. And to do their job next time because you're not seeing the hundred of things that went went right without any process so I'm very big on process I do a lot of commits to the handbook but very. We need to be very aware that we don't add a necessary process of processes can be avoided or process that isn't saving it's causing more harm than good. Yeah, I love what I love what Sid is saying Sid knows that I probably love what he is saying I think the important thing is we never get into a. Environment where we're always trying to manage for the lowest common denominator. Right we want to we want to be excellent. We don't want to manage for the lowest common denominator where we're a company we're not a family right I don't I don't you know I might. Rack my brain over my son not wanting to do his homework but you know here we should assume that we've hired great people and they're going to do their job and. And they're going to make the right choices and we don't we can address it but if we structure everything around you know the kid who doesn't want to do his homework then it's going to bring us all down. So I think we have to make sure that we don't fall into that trap which a lot of companies I think start to fall into and which I want to make sure that get love never does. Yeah, great and I think the best example of that is project managers. Soon as we get project managers, I'm out of here. Because a project manager is someone that doesn't actually do the work, but just kind of tells other people to do their work and then kind of check back back in on them. That's kind of a failure of those people to actually deliver and you see that at big companies people don't do that work and someone get assigned to make sure they do their work. We're not going to do that here as long as I'm around you're going to do I think you're going to do your work or we're going to find a job for you that's a better fit. But we're not going to have the people that not do their work like at overhead by having someone actually check their homework for them. And then have all the people that are doing their homework have someone check in on them and make them feel like less of an an empowered individual. And that's of course the worst part that your best performance will suffer the most. So do you feel that architects are similar to that because I know some companies have kind of cheap architects that any kind of design features and things have to be vetted through that person. What's what's your what's your view on that? Oh, thanks Barbie for that question because I highly opinionated. You get a lot of architecture astronauts who fall in love with their models and what they want is a clean architecture. And the reality is, it's messy. And there's there's not a clean. There's not a clean. There's not one solution that fits everything. But I fell in love with get lab the code base because most of the time when you open up an open source project, especially in that stage like a year old, you see that the original offer was kind of learning a new framework, like really, really into solid principles or really into microservices or really into something and they just apply that throughout the project and it could do it because it was their hobby projects that weren't any real deliverables. And you see in get lab that it wasn't like that. It was idiomatic rails, it was as boring as it could be and as effective as it could be and it allowed everyone to contribute. So that's what we want. So our architecture decisions are taken by the people that are doing the work. And we don't call Stan or Dimitri architects we call them fellows because they shape a lot of things themselves. But we should go to if we need an opinion about something architecture wise, they'll see it, but there's not some prescriptive architecture that someone wrote that is enforced across the company, because it will be written by someone that's only like writing this model and they'll fall in love with the model instead of falling in love with shipping and the work. So we should fall in love with results. And so far that's that served us really well. And I think I sometimes we have a lot of people would do like R&D I think we do a lot of D we don't do a lot of our we don't do a lot of research here, because we we we tend to focus on things that are already invented somewhere else we don't have to invent it we don't have to researches we just have to be this integrator of all these things that have already been done before. And when we have to do research, for example, our summit where we're doing stuff quite different from everyone else will do it iteratively and in small steps. I think the one time we had to do research was for GitLab Geo, and it was messy, and we should have taken build a few more prototypes so that we iterated a bit more before we got started there. We learned from that but in general we try to avoid it as as we try to avoid some big kind of architecture invented here. Architecture is invented elsewhere, for example, Rails is great because other people thought about it, it's great and we'll just conform to that. Hey, Sid, Sean Winters here, I'm a sales development rep. I know that I could probably speak for a few of us that are that are newer, but you know diving into GitLab and just being excited about the opportunity, something that really comes up quite often is just like working really really hard on it. And sometimes that spills over into not normal working hours and just would love to get your kind of feedback. I've talked to other people, but would love to kind of see what your words are on that. Yeah, so big risk of remote work is that it starts that there is no natural boundaries for it. So I recommend everyone to just have reasonable normal working hours. Turn off your Slack notifications, things like that. Yesterday at six o'clock I closed my laptop and I went to a restaurant and I didn't do much since this weekend I went to Tahoe and we walked around. My wife had to work, she's studying for a REACT, so she had to work. I ended up opening my laptop too, but I didn't have to work because it's weekend, I don't work weekends. It is very hard. I know a few people that are struggling right now and up to the point where we get HR involved and where we monitor them, like start them to stop working in the weekends. In the thank you, in the thanks channel, you're not allowed to thank people for working outside of office hours because we don't want to encourage it and we don't want it to become a thing. I think I've seen in other startups where people differentiated themselves by saying, hey, I work, I did this outside of office hours. I think what you see with these people, they bring themselves out and it all takes attacks. If you work a lot outside of regular hours, you're going to have a harder time focusing during hours. 40 hours a week is more than enough to get your work done. Don't get distracted, make the hours count. We try to do a great job here of not wasting your time with needless meetings. By allowing you, if you are in a needless meeting, to just do your work on, just mute yourself and go do your work. It's really important. We want people here for a long time and it's never worth risking people's health to achieve a goal. I think that, if you don't mind me adding something here, Sid, I think that we as leaders will try to be on top of this. I can tell you that as the leader of the People Outs team, I've never had Sid or someone else come to me and say, oh, there's a real big problem with Bob. He's not working enough hours. But I have had Sid kind of say, oh, we have to look out for Bob. I think he's working 24 hours. We have to pay attention to that. But I would also say that each one of us really has to set our own boundaries and set the expectations with ourselves and others. So I don't know if you're someone who works in the morning and then takes four hours off in the afternoon and then works late at night. And if I see you on early in the morning and late at night, that might concern me that you're working too much, but maybe you aren't. So it's really important to set your boundaries and hold that to them as best as you can because nobody else is in your home, is that your office is watching you. And so you have to really take as much accountability as for that as you can. But the other challenge, getting back to that earlier question around what changes as we grow and, you know, things that happen at big companies. One of the things that I've observed as I've been at many companies, and I suspect that this may be true for GitLab as well as we grow, is that as you grow, there's more information. And there's more meetings and there's more things that you don't have to be in all of them. But when you were smaller, you could. And as you grow, you almost inherit that fear of missing out and you, and there's too much information to really absorb it all. And there's too much to do it all. And it feels it feels kind of yucky because you feel like I used to be able to do it all. I know I can't. And so you have to let go of feeling like you can do it all because as the company grows, you have to understand, I have a position to play on this team. And I'm going to play that position really well. And it doesn't mean I'm going to cover the whole field. I can't cover the whole field anymore. The field's bigger now. So I have to rely on teammates. And so it's really important that we can kind of get to that point of accepting that we might not know everything anymore. We might not be involved in everything anymore, but we're playing our position really well. Thanks for that. If somehow this didn't go from the top to your leadership and your manager talks about the hours you're working instead of the results, that's not okay. And you can reach out to either the manager of your manager or to anyone at PeopleOps or to me directly. We're here about results and it should never be about the hours you're working. The only time we talk about hours is when we suspect you're working too much. Hi, Sid, Hugh, Hugh Christie here from the UK. Congratulations. I just wanted to say congratulations on building a fantastic company. I'm very excited to be on board. Apart from the product, one of the reasons I'm interested in the company was the values and the culture, the fact that everybody's friendly and inclusive. I understood that you've got an ambition to go to an IPO type situation. Do you think there's any risk? How do you think that might risk the values as we've got at the moment? Do you think there's going to be a risk to them? Yeah, thanks for the question. There's certainly a risk. First of all, like there's the things as you get bigger, there's problems and we talked about them in the beginning of the call. I think a few other things are at risk. Iteration is at risk. Iteration means sometimes things are less predictable and you sometimes change course based on what the previous iteration. There's a thing, for example, for our roadmap for what we're going to deliver, there might be revenue recognition implications. We check that out and it seems that as long as you say what the status of your roadmap is and you don't promise features to customers, etc. That that's okay. The biggest problem is transparency. So, for example, we've never published our financial results because we knew that if we were a public company, we would only be able to do that once a quarter. So we always want to be more transparent, not have to retreat. How we're going to solve that is, for example, by making everyone in the company an insider, so you'll all be restricted in how you can sell your GitLab stock. You'll be on a thing that you have to file beforehand, etc. That does mean that you can get full insight into everything at GitLab, so you'll be able to see all the sales dashboards, all the different revenue information, just like you're able to do now. And we'll get better dashboards, so it's going to be more interesting. Another thing we'll do is that we'll have a lot of disclosure channels. So we'll make sure that we can still talk about things and that people that investors are expecting us to use those channels, like using our issue tracker to say what features we'll build, things like that. So we'll try to get more transparent, but that's not a natural thing. Luckily, we found some investor relation help that company is aligned with us on this, so we're going to try to make it happen. We're going to be the most transparent public company in the world, and we're not going to wait until we IPO. As soon as we got audited financials, we'll start doing quarterly investor updates, which is ridiculous. No company in the world that's private is doing them. So that's going to be super interesting to see how that goes. And that will be like a practice run for us on setting the right expectations with investors. One of the hardest thing as a public company is to be predictable. Right now, we're not predictable. If you look at our quarter this time, this will be a public video, but we had to close a lot of deals on the last day of the quarter. That's not okay. We've got to get more predictable than that. So if you set any discounts, don't make them end on the last day of the quarter. Make them end the month before. So we can be predictable to the market because as a public company, predictability is more important, especially around revenue. Hi, sir. My name is Jacques Erasmus. I joined GitLab as a front-end developer. I want to find out where do you see GitLab in five to ten years from now? Thanks for that. Five years. So it'll be 2023. I can say what my hope is. My hope is that we'll be a public company for three years. Well, thousands of people working at GitLab will have become synonymous with a well-run engineering organization because GitLab encodes all the best practices of more than 100,000 organizations into a tool. It's the default way to develop and operate applications. The world will probably have moved to Kubernetes by then, so less relying on individual public clouds and more allowing you to run multi-cloud. And GitLab will be the standard way to do it. We'll have a company, our value as a company as to our stock price will be $10 billion. We'll still have our summits, but now they have a team of people on them, and it's feeling sometimes a bit like a village or a town takeover, and there'll be lots of other people there. We'll have Challenge Zoom to have even bigger calls. I think they can already handle like 2,000 people currently, so Zoom's pretty good. We'll still have our handbook. It will be many, many pages. Barbie will be wondering every day how to organize that content in a way that it's still consumable. Your onboarding checklist will have over 200 items in it, and hopefully will still be a friendly company that lives up to our values. Hi, Sid. My name is Sean Siecek. I'm joining in the security operations department here, and I just had a question more or less about the remote first culture, I guess, that's been built here. It sort of seems like it's getting more and more popular in the tech world thanks to GitLab and other companies that are sort of leading the way showing that it works while also sharing trials and tribulations. I was just kind of curious how that's portrayed on the other side of the house, like in the business or investor world. Is that something that they're fully on board with as well, or it takes them reassuring on your part, or the rest of the team to say, hey, this is the correct way to do things? Thanks, Sean. Yeah, for sure it's getting more popular. I was talking to some YC companies and they were like, yeah, yeah, we're all remote. It's becoming not quite the default yet, but it's becoming amazingly more popular. So with Barbie, we're going to tell the world a bit more about it and try to make sure that we're recognized as a company that's on the forefront of that. Investors don't like it at all. During raising our B round, we had one of the best investors in the world. He was super transparent about it. He's like, we're into pattern matching. We can make only a handful of investments every year. Yours look like a good one, but this remote thing is different. So it doesn't match our pattern. Now I'm not saying you'll be unsuccessful with it. Just saying it doesn't match our pattern. And we can, like they can just pick companies that exactly match their pattern. They see every deal in the valley and they haven't a great track record. And that's it. So it made a lot of sense. It didn't match their pattern. The investors that ended up investing in the B round, they also said like, wow, this is strange. Now, luckily they were very curious and they said, well, present to me how you're doing this. So I made a presentation about the old remote. And the point where it works during the presentation is when Abbie said, and Abbie was an associate or isn't associate there. He said, look, I know there, it seems, well, he didn't say anything. He said, I stayed up all night reading their handbook and it's amazing. I've never seen such a well run company. And that's when it pivoted and they were open to it. But they also said, look, our investment thesis is that, like, a fruit of the company's fail, a fruit get acquired and a fruit, and some maybe not even a fruit make it to IPO. In your case, you know, that gets like 80% gets acquired. 10% make it to IPO, 10% fail without an acquisition. In our case, the acquisition is going to be a horrible scenario because they're going to pay half. Because an acquire wants all the people at the company to move to their location. That's how an acquisition feels like. So because we're all remote, we're less attractive to acquire. And it's harder to make the numbers work for them. So they bet during our B round on IPO, which wasn't a sure thing. It's still not a sure thing, but then it was a long shot. So that was nice of them that they had that foresight and took that risk on us. And it's kind of a blessing in disguise. Maybe if we were a co-located company, we would have been an easier acquisition target and we would have been acquired by now. Sometimes becoming a big company is about not getting acquired along the way. Does not having to pay for buildings and stuff like that, how does that affect our overall value as a company? And I know that plays a role in it. Is it a big role? It's an enormous role. Great question, Sean. Our costs are way lower because of all remote. We don't have buildings. We don't have people spending two hours of their day computing. We don't have to, we don't pay for all kind of auxiliary stuff, like office management, food, et cetera. We get to hire the best people almost irrespective of where they are. I think that's a big benefit. So we get to hire better people. Like if you can only hire in a certain location, you're not going to get as good of a people if you can hire anywhere. Like people see your company and like, hey, that's interesting. And then they, they apply and those are, those, if you're, that's really great that we're able to hire those people. Also compensation is not the same everywhere. If it would have been based in San Francisco, these are the highest wages in the world. Everywhere else, the market rate is going to be lower. So that, that certainly helps. I also think it helps in other ways, I think, because we're remote only. We write things down. We're more efficient. People have better lives because they can be there for their loved ones. They can, they can travel more flexibly. So I think, I think, I feel like we're, we're a better company to work for. And that shouldn't be underestimated. And we, we're just very diligent with people's time. So they have more time to actually do things that, that get results. So I think that's a big benefit, but financially it absolutely helps. Otherwise we'd probably have half the half in the headcount that we have now. So instead of 250 people, we'd be, we'd be 175 people now. And do the, like the venture capitalists are investors today? What do they say about that as far as what you were just explaining? You're really capital efficient, but do you have to hire more R&D people, even more developers? We got over two people, 250, 220 people in like product development. So like our developers, funds and product people, it's really high. That's a high ratio. You'd expect that ratio at a startup that's much smaller. What we're doing with that is that we want to keep growing at the speed of a startup, nearly tripling every year. And because we're investing in there, we, we can continue that much longer, but it's, it's unnatural. It's, at this point, no, no one needed to get to IPO. We're, we're investing beyond that. That makes them a bit nervous, but also they're, they've seen that it worked and they're, they're willing, they're willing to hear us out. And last board meeting, they came in not wanting to approve the extra engineering hires we asked for. And they, they listened to us and we, we went back and forth and they, they voted in favor of it. So, so they're, they're open to it. So that's, we've got board members that learned from all kinds of mistakes in the past with all kinds of other companies and, but they're also willing to be open minded and to have a conversation. So that's a blessing. I said, on, on that one here again. Yeah. So that's, if there's a company that you, we could say is the model for the way that we want to go into this IPO. You know, what, what, what would it be? I don't think it's after one company, but there's lots of things to learn. I admire Amazon for the way they go after adjacent markets. I admire Datadoc, which is like a $4 billion company now for how they, they create a beautiful product that's super easy to use. I admire Elastic for how they're able to combine open source monetization in a beautiful way and have like a really wide reach in, in, in their use, the use of their product. I think there's lots of amazing companies to learn from. We're not modeling it after any particular company. There's, there's lots of inspiration. WordPress first company that had a remote first world culture is amazing. Envision 700 people remote twice our size. There's, there's just great examples everywhere. I had a question about culture. I'm Amelia. I am aware as we're, as I've been through the last few weeks, like what a rich and welcoming culture. Get lab has, and I think for me as a new hire, and I wrote this down so I don't get it wrong. What can we do to help foster and maintain a culture of inclusivity? It seems like I want to try to absorb what the culture is and, and be a really good contributing part of it going forward. And if you have tips of her, how best to do that. I'd love to hear. Thanks. That's really beautiful. Second time today, Amelia, that you're touching. We were talking this morning, we were in the breakout call and we were about where do you want to time travel to. Okay, with me telling what you said, Amelia. Yeah. She said, I want to travel to 50 years into the future. So I can be a better parent for my two year old now, because I know what the, what they will need in the future. I thought that was beautiful. Well, first of all, the important thing is that you want to, you want to have an inclusive culture. I think that's where it starts. I'm not sure Barbie's still in the call. She's a, she's a better expert at this than I am. I think what's really important is that we, we are accepting of, of all the differences that can be there. And that we try, try to be inclusive, whatever we do. And there's a, there's small things we can do, like trying to get rid of people starting a call off with, Hey guys. There's, there's bigger things we do like when you're vetting an applicant, try to leave your, try to not think like, Hey, is this a person I want to hang out and have a beer with or something like that. That does not apply. It's totally okay for you to be uncomfortable with a person's background or lifestyle or stuff like that. Look, look at whether they, whether they adhere, whether they can do the things that are the requirements for the job and try to keep the rest out of it. One thing where we're clearly lacking in diversity is in engineering. We have, we have a lot of men and few females. Talking publicly about how you experience your time at GitLab really helps. And you only have this impression now. So if you don't capture it now, it's going to be hard to talk about it three months down the road. And it can be as simple as having a video call with someone else, recording it and uploading it to our YouTube channel. And then from there on, other people can pick that up and make it into a blog post or something else. So tell, tell the people what it is like working here. And then hopefully we can attract a more diverse set of people even going forward. And I think inclusivity is also a lot about trying to not focus on the person, but on the work. Like keep, keep politics and religion out of the workplace. That's, it's actually kind of a struggle. There's, there's in some San Francisco companies, there, there's almost a politic seep into the workplace. And then we see that tendency here too. And I really, we rely on everyone to make sure that, that that's not, that's how I'm going to be there. The case here. And yeah, when you see something, say something. So either, either stop the behavior right when you see it, even if it's small or reported so that the company can take action if you're uncomfortable with that. But yeah, I really appreciate you bringing it up in this, in this call diversity is one of our top six values and, and thanks for your, thanks for wanting to contribute. I just want to comment on something you said. That it's okay to be uncomfortable. If you're screening somebody that you're not looking to see that it's going to be a, the right fit for you to be friends or hang out with. In my last six months of interviewing, I think I ran across about five different companies who legitimately mentioned that they were looking for a good cultural fit and that it was really important to their team that everybody got along and they actually ask behavioral questions to understand how I would react in social situations. And you know, it never really occurred to me until this very moment how damaging that is to try and make a little army of the exact same type of people. And how that really reflects on the product you're putting out. Right. It's, it's very, very tunnel vision. Right. Oh, you muted yourself Amanda. Sorry. It's, I was just saying it's really cool to see that here. Yeah. Thanks. Thanks so much. Yeah. Culture fit is bullshit. And I think it's, it's literally in our values. So we have some bullshit in our values. But it's not like some companies use the airport test. Is this a person I want to hang out with at an airport? And no, don't just don't, don't do that. It's not about whether you see yourself together with that person in social life. It's about whether they can contribute to it. And you should, you shouldn't hire people who are. Are toxic who, who like. Don't. They have to contribute, but in all kinds of different ways. We have some people are introverts. Some people are extroverts. Some people are super friendly. Some people frown all the time, like me, like it's. And that should, that should be okay. And that should go for a lot of dimensions. And that's why values and requirements are so important. We, we test, like if you make a hire, you test them according to our values and according to the job requirements. That's it. You don't bring, you don't bring, don't want to have a beer with this person into it. It's, it's, it's, we're not, we're not, we're going to have a summit. Luckily we're not all drinking beer. There's some people who never drink alcohol. There's some people who prefer other beverages. And that's, that's how it should be. So thanks, thanks for chiming in. I guess one tiny follow up, just because you mentioned it, you mentioned that some people are introverts and some people are extroverts. Just from personal experience, like speaking on the all hands call in front of like 300 people, it can be a little intimidating. Do you have, advice or tips for people who might be on the more introverted side of the spectrum for, for joining into discussions? Well, first of all, you're, I'm not, I'm not sure how you classify yourself and you don't have to say, but you're doing a good job of it. I think what you see sometimes in reality shows, I watch the profit a lot. And it's, it's about a show with entrepreneurs that have, need a company turn around. And Marcus Lamones comes in and helps them with that. And he, the people forget the camera after a while. You just see them do things that you should, you should never do. And especially not when you're on national television. And they just forget after a while that it's there. So that's one of the hopes that if you're longer here, you kind of forget about the recording light. You do remember that this is a workplace setting. So you have to behave appropriately for workplace. If it's appropriate for workplace, we're cool with it being on the internet. So hopefully that helps that you forget about it. I don't know any other tricks. I hope that people see like what's surprising about transparency and having, having these big audiences, et cetera, is that there's fewer problems than I ever imagined. I thought there'd be more things that would go wrong. And it's, it's mostly not happening. So I hope people recognize that it's, it's not scary. And that's, and that everything, that as long as it's appropriate for the workplace, that everything goes and that people appreciate your contribution. Our mission is everyone can contribute. It doesn't always mean that everyone will do as you suggest. It doesn't always mean people will agree with you, but it does mean that they appreciate it when you speak up. I said here again. So what just interested in what percentage of the revenue at the moment is you, it comes from the U.S. as opposed to the rest of the world. And how do you see that changing over the next couple of years, if at all? Yep. This is a public call. So I'll, I'll not go totally granular. You have access to Salesforce. So you could look for yourself a bit too if you're, you want to dive into the details. But in general, U.S. is more than half. It's about two thirds Europe about a quarter and the rest of the world what's left. That's not a lot. That's not the, it's almost the inverse of the usage of GetLab. GetLab is super big in Europe. I think it's probably even bigger in Asia Pacific. And it's the smallest in the U.S. So there's a big difference between usage and monetization. And I think it's a few things. I think U.S. companies tend to be more in the forefront of the adoption of technology like DevOps. Most important factor is probably that U.S. companies are more comfortable paying for software. They're more likely to weigh like the advantages of the, the added features and support against the cost. And then concluding that it's a great deal. And it's a great deal for the, for companies in Europe too, they somehow seem to not make that calculation in the same way. It puzzles me a bit. I think we got huge potential there. I think also, so I think we're going to grow a lot in Europe. Also going to grow a lot in APEC, South Korea, Japan. There's enormous potential. And maybe, maybe we can find a big partner in China to crack that market as well. The encouraging thing is the usage is there. So most of the time it takes patience and hard work, but once you get the usage at some point, you'll be able to monetize. But it's taking a lot longer for those markets to grow than I anticipated. And there's a lot, the encouraging thing is there's a lot more growth in the U.S. than we ever thought. And that still seems to be going on and on and on. So that's, that's the good, good, good news. Thanks. I think we're going to ask a question now that everyone. Well, If no one else has got a question, I've got another one about open source and, you know, commercial. How do you see any, how do you, how do you, are you going to balance those, those two. Two components, I suppose, in the next couple of years. Thanks. I think we've, we've done a great job of balancing them. And we just want to keep doing kind of the same thing. We've been doing going forward. We have our stewardship promises. And basically what we look at is like, is this a feature more aimed at like individual contributors than it's more likely to be open source? Or is it more used by the management? And then it's more likely to be a paid feature, but there's a lot of common sense and also just listening to the rest of the community. We'll never close source features that have been open source before. And where we make mistakes in closing, introducing a feature as close source, well, we'll open source it afterwards. And I think the most important thing is we keep listening to, to the wishes of the community and that's served as well. For example, for Debbie, and we switched to a developer certificate of origin, instead of having people assign their copyright to us. And that's been a very positive change and we'll keep doing that going forward. And I'm very proud that at this size, we still have the confidence of the wider community and we're going to work really hard to keep that. Oh, that was the last question. Thanks so much for contributing to the 101. And welcome to GitLab. If you have any questions or any complaints, I'm responsible. So feel free to DM me at any time. All right, thanks. Thanks.