 I was going to ask, how did you and Dimitri meet? I didn't see that in the brief history. I just saw that you guys ended up teaming up, but how did you guys initially come in contact? Yeah, thanks, Mike. So I saw GitLab on Hacker News when it was a year old. I thought, wow, this is amazing. I'll start GitLab.com because no one was doing something like that. I did a show Hacker News with that. And I sent an email off to Dimitri like, hey, thanks for making GitLab. I'm using it. I'm going to start GitLab.com, and I'm not inclined. You're not going to get any renumeration for this. I'm not going to pee you anything, but thanks anyway. He sent an email back, no, no, that's fine. You don't have to pay me anything. It's open source and great that you're making it more popular. So I thought that was a good attitude. And that's an attitude that we always try to remember when, for example, Perforced bundles GitLab with their product and never, never be. It's OK. It's open source. No one owes us anything. And then a year later, Dimitri tweeted out of the blue, I want to work on GitLab full time just to the whole world, even though he was employed. And I saw that. I'm like, well, we should probably make that happen. I got some really large enterprises running GitLab that approached me where I could add new features to it. So you can probably, I can pee you and then you can add the new features. That's how we got started with GitLab Enterprise Edition. Were you working at a company at the time, Sid? Or were you, what were you doing? It says Ruby Programmer. Yeah, I was a Ruby on Rails developer at a company called DigiDentity. They make the single sign-on system for the Dutch government. So mentorship played a role in your growth and success since coming on to GitLab? Of course, there's great bosses in my career. I think one of the more memorable ones was one when I was super depressed. I had one of my worst bosses. I was a proctor and gamble. After that, I got one of my best bosses. His name is R2 Boss. And I greatly admire him for lots of attributes that I'm not very good at, like patients. For GitLab, the biggest thing was joining Y Combinator and kind of getting a roadmap of like, okay, if you want to go for the top prize, this is how you do it. And it's actually a possibility. And right now, I still have a lot of people that kind of help us. The board comes to mind, the board members. There's some advisors. But I also have a CEO coach called John Ham. And that's the person I rely on the most for kind of coaching and mentoring. Speaking back about the Y Combinator experience, why did we participate in the 2015 batch? And what was the most valuable thing that either you or GitLab learned or took away from that experience? Yeah, thanks, great question. We saw that companies were gonna consolidate. They were gonna either consolidate on an Atlassian stack or GitHub stack on GitLab. And we know that if we weren't fast enough, if we weren't out there with salespeople, with marketing, then it wouldn't be GitLab. And GitLab would kind of go away as a project. The beginning of an industry, you have 1,000 flowers bloom, you have all these car manufacturers, and then it consolidates. And we wanted to make sure if one consolidated on GitLab and not another one. So we knew to do that. We had to go faster. We knew that Y Combinator was the best place to do it. And we learned lots of things, but I think the most important thing was iteration and the speed that comes with that. Y Combinator, they said, what's your growth goal? And we've read the literature and it's required to do 10% per week. So we said 10% and they know that we didn't really think about it. So they just doubled our, they said, no, you're gonna do 20% a week. And we walked out of that meeting like 20% per week. And we had to be back in like two weeks. That means 40% growth in two weeks. Like, that's impossible. So we kind of give it a half ass, that's right. And then we came back two weeks later and everyone else in the room had done a stellar job. They worked really hard and they kind of took shortcuts, but they got it done. And we looked at each other and we're like, oh my goodness, everyone is so much better. I remember vividly after me was the founder of that campus job. And she was amazing, she knew all her numbers. So I got my turn citing what we did and the numbers and what we achieved. And then afterwards it was her and it kind of looked at me and they pointed at her like, this is how you do it. And we felt, oh shit, we have to do a much better job. And we started chipping and we just thought, okay, how can we improve downloads 40% like, we don't know like, okay, well at least we can make it easier to download and we can probably user test it a bit and we can write an interesting blog post and et cetera. And you just get going. One guy stayed behind in the Netherlands, Jakob Fosmar. And he was like, what's happening to these people there? Like, is it like pressuring you too much or what's happening? And everyone was back to him like, no, no, this is the new normal, this is how things are done here. And that's kind of the spirit we have to keep. Like they say there, the only companies that fail is kind of the companies that stop shipping. So that's from me, you'll always see an emphasis, okay, what's the smallest possible thing and can you do it like tomorrow or next week? Get it done, get it out there and then build on that. If you lose that, you lose speed. And the startup, the difference between a startup and a regular company is the startup is based on growth and growth comes from speed and speed comes from small iterations quickly done, fast decision-making. So I actually had a question related to that, unrelated to the history. One thing I've noticed, so I've been here for almost four weeks now. One thing I've noticed working remote is compared to my previous job where I was in an office with people, I feel like I had a better sense of how quickly I was moving or my pace. And so I think my question is around, I feel like I'm iterating and I'm trying to push things out, but I have like no sense of is this, I guess it could always be faster, but is it going too slow? Is it on average for my peers? It's like I have no sense of how to maybe compare myself or to benchmark like how quickly I'm delivering. So that's kind of where my question is at. Yep, Taylor, face sort of question. I think your situation is not typical. For everyone else, Taylor is a data scientist on the BizOps project, and that's new project. So it's really hard to kind of get out what the goals are week by week. But the problem is certainly there. I think we can do a better job setting expectations for everyone in the project. I think in the beginning, we were kind of stumbling along, figuring out what the project really was and what we wanted to do. I think now that that's cleared up. I know for this week, we're all looking forward to implementing the analytics tool that we're thinking about. So that would be the goal for this week. And we kind of, there's kind of a goal for Brian every from meeting to meeting. Let's make sure we also have a goal for you. That's on me. So thanks for asking. Can you talk more about the culture of remote employees and your thinking behind that of, was that the strategy from the start when you started GitLab or did it kind of morph into that? Yeah, thanks, Tony. It wasn't the study from the start. It's not a very boring solution. It's actually interesting. So it doesn't really fit with our values. The thing is, it was just, Dimitri was in the Ukraine. I was in the Netherlands. So we did it like that. And then the first employee was Marlon. He lived in, he moved to Amsterdam, I think pretty early. And he could come by and work from my place. We had two desks next to each other, but he kind of stopped bothering at a certain point. I was like, am I gonna tell him to come in? And I don't mind either. So it worked like that. And then after we left my combinator, we know that a lot of organizations have engineering remote, but not sales and marketing. So we said, okay, so sales and marketing are gonna be on site. So we hired this place where I'm in now. We put in nine desks and people stopped showing up for work. So Hayden, Kay, our regional director, like he was welcome. Like he knew that there was an office. He came the first two days and then one day he didn't show up. We're a remote company because we didn't have a rule that you had to show up at the office. And I strongly believe that one of our values is results. So not input. So I don't care whether you show up off the office or not, I can't let you get done what we achieved and hopefully a bit more. So that it follows from that, just not caring about the input. And I also felt a bit like if people need to show up at the office to keep up to date, like I probably doing something wrong, like I should probably write a bit more down, record a bit more, et cetera. I had a kind of follow up question about results there. One thing I kind of find hard to decipher is the concept of a company caring only about your results and how that can kind of, how that can relate to people being potentially overworked as out of fear that they're not producing the right results. So like not giving people clarity on what having good results means or producing enough work means. So particularly for like new engineering, as a new engineer of the team, I kind of, it's pretty hard to benchmark what I think looks like, what success looks like for me. Whereas at least if I was at a company working closely with my peers, it was kind of pretty easy for me to get a good indication that I was contributing well, being so disconnected that it's quite difficult. And I worry that that kind of leads potentially some people to be overworked and how we can kind of mitigate that. Yeah, great question. So first of all, it's real, like the chance of burnout is bigger, I think, if you're remote. Also because there's no natural barrier between work life and personal life, because it's like, it tends to be the same space, the flexibility in time. So it's very easy to kind of start working in the evening and things like that. So it's a problem. There's no one right answer. It's something we care about, like the top talk at our last summit was Martin talking about burnout. Martin just got the only conditional bonus in the history of the company, like you did a great job, Martin, but watch out, watch yourself. Burnout was the topic of conversation at our last executive meeting on Monday, that's yesterday. So it's certainly, we're all at risk for this, and remote makes it harder. There's a couple of sections about burnout in our handbook, I advise you to beat them. The other question was around kind of benchmarking yourself with your peers. This is where your manager comes in. So your manager should be able to to help you there. So it's a totally legitimate question to go to your manager and say, look, how am I doing? How am I doing compared to other people? What do you think of my results? What do you think of my output? That's why we gave everyone a single manager and we make sure that the manager doesn't have too many reports. I think maybe Taylor and the BizOps project is kind of an exception where it's, Taylor doesn't have, well, it's a bit more messy there than in the rest of the company. The rest of the company, it's pretty functionally oriented. Your manager should understand what you do. You should be able to go there and it's, don't be afraid to ask that question. I think I've managed people, I love it when people ask that question. It shows great attitude. And then if you're curious about what other people get done, look, don't forget it's GitLab. So you can just go to their profile and GitLab and watch their activity feed and get an idea for how many comments they do, how many merge requests they do, et cetera. But that's really more, okay, judging output is really more your manager's job. It should be that you can focus on your work and you don't have to look left and right, watch what the other team members are doing. I said, what has been GitLab's biggest mistake and what have you learned from it? Thanks, Suri. There was one thing where we kind of focused on something else. So I started GitLab with GitLab.com and I think this is gonna be awesome. And when I did the show Hacker News for that, someone said, there's already Bitbucket. They also have free private repos. And I just lost the biggest edge that I thought we had. So it took a year to realize that the demand was not for the SaaS service, the demand was really for the self-hosted service. So after a year, we kind of started focusing on that and that's been a big help. Now the biggest problem that we still suffer from is also that we kind of pivoted back too late or I won't call it a pivot, but we focused back too late on GitLab.com. I think only now, next quarter, GitLab.com is gonna be ready for mission critical tasks. And in hindsight, I would have rather have that a year or two years ago, but it's kind of sometimes you overcorrect a bit. But that was a big change, figuring out where the market was. And I see the same thing with a lot of startups that they focus on SaaS and then they figure out that all the big companies are still self-hosted and they need to and they need to address that. Thanks for that, Sid. So I have a question particularly about design. So one of the challenges that we see in the industry sometimes is that technical startups that work with code related products have a challenge dealing with design. And I've just come in and I see a very healthy relationship between development and design. I'm a front-ended developer myself. How was that relationship started? What started design at GitLab and how has it come to be what it is now? That's a great question. I think also we got lucky, also with the people we hire, et cetera. And I also think that the collaboration is our first value and people live that. Like it's due to people being open to criticism and to feedback, but also having the strength to say, okay, we don't need consensus in the end, I do this. So first of all, everyone gets or everybody, but a lot of people in GitLab get the importance of design. We had really bad design like two years back. People couldn't stop complaining about our navigation and it was horrible. So we have a lot of pain. So we're really proud that right now, I think if you compare us to the competition, we have better user experience than anybody else, despite like having a higher velocity of new features and despite having a broader scope for a single product. So I think that's an amazing achievement. And I also think that our UX and front-end teams stick to like boring solutions and I'm very proud. Like you see people, other companies get off the rails there, they try to do something too interesting and it kind of holds everyone back. And hopefully it's also because it's interesting. You have enough new features that you don't have to be bored and it's just hard to keep up with the fire hose that is on already. And one thing I think we do well and that's kind of in general in the company. We have this, most companies have, if you have decision-making, you can do, most companies speak between two options. Either it's very hierarchical, top down or it's bottoms up. Top down, you miss kind of the good ideas. If it's bottom up and we all need consensus, that doesn't really work. So what you get is people will start doing things in secret. So they don't wanna get bogged down by consensus so they have secret projects so other people can stop them. So both things don't really work. We choose I think the best of two worlds by splitting it, making, having, acknowledging that it's two different things. First is like data gathering. They're the bottoms up really work. Everyone can comment, everyone can contribute, everyone can have an opinion. Then the decision-making process, what do we really do? It's just whoever does the work or their boss decides. Super easy, no need to build consensus. You might wanna leave a comment that you heard someone but you don't have to convince them. So you do the work, you call the shots. And I think by combining it like that, I think the collaboration, the cross-functional collaboration just gets easier in the company. In the end, if it's a front-end thing, the front-end decides. And I think that gives a lot of security to open up for all the inevitable suggestions. Okay, but as you go by iterating, don't you uncounter already some people trying to iterate on the already discussed feature to try to put a previous solution that was rejected or something like that? I'm not sure I completely answered the question, so feel free to follow up all of it, but I'm not afraid to kind of open up. It's okay to kind of try to open up an old conversation. So our process is disagree and commit, or I'm not sure, it's disagree and something. I think it's disagree and commit. So if we make a decision, everyone goes with that. Like you can't like not half do something because you don't agree with the decision, but it's always okay, almost at the same time, to still be like, okay, but I really think we should do it different. And I gather some more data, and can you reconsider this? Some of the best decisions we've done, including like adding GitLab CI to GitLab the application, is because people just can bugging people about it. And that is fine, as long as at the same time, while you're bugging people to change the decision, you comply with the decision that was made. So you do the work, you maintain two separate applications, but then Camille came to Dimitri and said, look, I really think we should integrate it. And Dimitri kept saying, no, that's a weird idea, like separate tools for separate tasks, like small tools that you compose. And then Dimitri agreed, and then Dimitri went to me and he said, no, no, no, that's a bad idea. And then Dimitri kept going. So it's okay to keep droning on about something. It's probably, if it keeps bothering you, it's probably something there. Does that answer your question? Yeah, exactly. Hello, Sid. I was wondering, I'm joining the US design team. So can you talk something about the monthly release schedule and the idea behind that? Do you think that a slightly longer schedule would help in shipping more features or would be able to help in a longer design mission to establish the product? Thank you, Sid. That's a great question. So it got established just because Dimitri released the first version on the 22nd. The next month, he did the 22nd and he thought, oh, let's keep this up. As long as the company existed, so even during Y Combinator, for example, you can talk to Valeri, he said, look, why can't we do a two-month cycle? Like, we'll have more time. We spend so much time right now, we just do release process. That would all be effective working time if we had a longer cycle. And there's a lot of people that do longer cycles. I think both like Chrome and Ember are on six-week schedules. So those make sense. If you look at Github, we ship in a month what our competition ships in about a year. So it's hard to argue with that. Like, we get a lot of things done. And the iteration is one of those secrets. Like, because you have so little time, you bite, you see the whole thing, but you have to bite off this super frustrating, super small thing that doesn't quite do what it should do. And that is extremely frustrating. It's like every applicant says, oh, I love iteration. I always think, oh, and I say, you don't know what you're signing up for. Like, this is iteration done properly. It's super painful. I hate it. I hate it myself. Like with the BizOps project, we had to reduce scope. And I was like, almost ready to say, like, oh, we can at least say that we're gonna do this in the future. And I said, iteration, like, keep it simple. And you can always expand from that. And that's extremely painful. So I get the want for a longer cycle, but biting off those small bits makes sure that we can oversee them. And we still, like I would be open to making a longer release cycle when we ship exactly everything that we planned at the beginning of a release process. Right now, we don't. So if anything, we should keep it, make it shorter and go to every two weeks or every two weeks. I'll probably have Feliri and you being mad at me when I proposed that. So this is about the, this is the consensus we got to, like the 20 seconds seems to work well. So we'll keep that, but it's, if you wanna go faster, take smaller steps and take them a lot faster. So that's why we're not lengthening the release cycle. I think we'll bite off more, we'll have a harder time swallowing it, we'll have more things that don't ship in the release that we planned. Do you have the same mentality and attitude towards things that aren't featured? So either refactoring for performance or like test coverage or something like that. Yeah. What do you think about organizational design? Handbook updates. Like, oh, I updated 16 pages in the handbook. And like, oh no, what did you do? Like keep it small. I have a great new idea for this. Okay, what's the first step? How do we, how do we get there? So it applies cross-functionally. Okay, we've got a great new marketing idea. Well, do we build a whole campaign about it or are we first gonna do a test event? We're gonna do a mailing about our ultimate promotion. I said, okay, well, can we just email the first 10% of people and see what their feedback is and what questions they have and then improve the mailing for the rest? Seems super obvious, but if iteration is not, you really have to think about, oh, how do I iterate before you do stuff like that? I said, I have a little bit of a fun question. What would you say is the meaning behind and the story of the logo, the GitLab logo? So we had an old logo. If you've seen it, it's kind of a frowning fox. We're completely angry. We kind of said like, as soon as we got more than 50% of the market, we'll make the fox smile. So it's a smiling fox. Yes, the current one, I think the fox smiles, although there's no mouth there, but it's a smiling fox. The thing was that the old logo gave people nightmares. So two people independently reported that they had bad dreams about the logo because you kind of see it the whole day that you're working with GitLab and it haunted them in their dreams. Thanks, Andre, for posting a link to the old logo. So we were like, okay, this is not good. And we kind of wanted to ask the person that contributed the old logo for his blessing. His name is Ricardo Mars. And what happened is that at the high point of our company up to that time, at my Combinator demo day, Ricardo Mars, the guy who contributed our logo was in attendance as an investor. So he came up to us and Dmitri asked like, sorry, but like your logo gives people nightmares. Is it okay if we change it? He's like, okay, of course. He says, I know just the person. This person is specialized in fox logos. We're like, what? You have logo designers that are specialized in fox logos, but apparently that's a thing. And I think that the person did a wonderful job, although obviously this is a Tanuki, not a fox, but... But why the fox or the Tanuki? Why the meaning behind it? Because Ricardo Mars made something that both looked like a raccoon and a fox. So we decided it was a Tanuki. And the other part of the story is that Tanukis or raccoon dogs, they collaborate. They're not individually strong, but they are strong because they collaborate. So GitLab is not strong because we're the best company in the world, although we are. But we have a superpower and that's collaborating with 1,900 people on this. And that's our superpower. Speaking of other companies, how often do you talk with maybe other CEOs or exec teams of remote only companies like Zapier or Elastic? And like, do you get information from them or comparing interest notes? Yeah. So Matt Mullerweck, the CEO of Automatic, Makers of WordPress is on our board. I had lunch with him last week. So we compare notes and there's some interesting idea about coaching that we might implement. I talked to the person at Buffer. I talked to the people at Zapier. We talked with the people at Hacker One, trying to give them some hints on remote work. So yeah, we do talk with those not on a regular basis, but we do compare notes. And we try to kind of, if they have good ideas that we can implement, we certainly try to do that. So I think we're a bit further ahead than most companies in making this work. So reflecting on remote culture, do you think this is something that's infinitely scalable? Like, I think it works great now, but thinking about a time after we IPO someday and the company is 2,000 people, do you think that a remote setup working will work regardless of the company's size? I think it actually works better at scale. So I think if you're seven people, probably remote is harder because you can all be in a room together and there's a certain vibe to that. I think as a company grows, you start having, at first you had a room, now you have a floor and you have multiple floors, you have multiple buildings. Like that whole benefit of being in the same room that greatly dilutes with us, the benefit of having documented processes and things like that, it accumulates. Our values are better specified than any other company. Our communication structure is better specified than any other company. A real-time org chart, I've not seen that in any other company. Those things that kind of were a burden maybe at a company of 10 people, they start accumulating, they get better at your scale. Well, the benefits of being on site start degrading at your scale because there's only so many people you can walk into in the hallway. So I think it actually gets better. So I think every large company is a remote company anyway. They just didn't acknowledge it and they didn't optimize for it. Also welcomes our questions about our values. We already talked about some, but questions are very welcome. Also about team structure and about how we work. Yeah, I have a question regarding titles because I saw in some teams, people are called engineer, while in others are called developer and I'm wondering what makes the difference. I think it's inconsistency. I don't think there's a big difference. It's actually not true. I think in some places, Michael specifically on his ops, he says he cannot be called an engineer because it's like against Canadian regulations and so he has to be called a developer. But that also, yeah, charted in some countries, engineers are charted and he's not. I think developer is better because it's specific more specific, so it relays more information. What's the value that you see most people or many people struggling with? Thanks, Zoe. Great question. Iteration. Iteration is by far the hardest. I think all the other things, people kind of have a feel for it. With iteration, people underestimate the magnitude. Like people underestimate how small of a change is already beneficial. You can see it like new hires, like they have these work-in-progress merger requests. And then first of all, it shouldn't be marked more of work-in-progress because if you merge it, like stuff gets bad, like there's no downside to merging it. So it shouldn't be marked like that. And then the second thing is they work too long on it. Like it's already beneficial. They should merge it and start a new one. No need to kind of drag it out over multiple days. And that's not just in engineering, like that's also merger requests to the handbook and other things. It's just really painful to do the minimal, the minimal next step, because you want to, everyone here wants to do a great job and they envision the future and then they have a vision how, this is where we should go to. And they are a natural instinct is to kind of pack up the stuff to go to on this long hike towards the top there. And then that's not what we expect you to do. We expect you to just grab only a water bottle, walk out for a few minutes and then set up camp there and then work on something else before you continue. And just get a lot done. And then we think it's always really easy to plan for the field that's immediately in front of you and really hard to plan for like this track up a mountain where you don't have a map. So the way to get there is many small sprints. The analogy doesn't totally work, but iteration is the hardest thing. And I struggle with that. I think the executive team struggles with that. I think it's super counterintuitive and very painful. And also I sound a bit like a downer here. It's also amazingly effective. Like look at what we're able to accomplish every month. So it works really well. Can I ask that you follow up on that work in progress merge request point that you made there in some way like top down to engineering managers? Cause I agree with your point. Like it's hugely beneficial to just be merging code the second it works. And you get a whole bunch of extra benefits on top of this in terms of how comfortable people become with just making small improvements because they're quicker to get merged. People refactor code quicker because it doesn't have a week long review cycle. But the only kind of thing I want you to follow up on is that I don't think that's what's being communicated from engineering management or in the review process. The whip merge requesting may be even encouraged in the engineering handbook as well as certainly I think that's basically how most of the engineering teams are working. So it'd be interesting to kind of follow up on that discussion and see where the differences lie. Yeah, that's interesting. I don't have an opinion on this. I can see the whip merge request for engineering because there's a definition of done and things like that. You want to avoid merging stuff with our documentation. You want to avoid doing a review and then everything you bring up that person says, oh, well, I thought of that. It's going to be edit. So I think with engineering, it's a lot about kind of keeping the scope small and kind of the release cycle helps with that. Like you can do that more than a couple of weeks of work. Now it might be that it's beneficial to make it even smaller. And I encourage you to kind of bring that up with your manager and be vocal about that. I more mean the merge request kind of to the handbook, like that it's not code. It's not going to break anything. It's an improvement. Like just get it over with. So that was my example. But it might be that in engineering, we're able to do smaller things too. Feel free to advocate for that. I had a question on the structure. So when I was looking at it, I saw that it looks like, I think it, is it Joe as the VP of product? Correct. And then there was a, there was Mark who had another section as head of product. How come those are broken out separately? Yep. We got two great product people and I'm a bit of a product CEO. So it's something I care about. It's something that like evolves really rapidly. If you see that we went from just source control like two, three years ago to the whole DevOps lifecycle now, I want to make sure I stay in touch there. And we got two people that are kind of competent on the equal level. So they both, both report directly to me. Nice. Thank you. I think so. That question, Christy. First time someone asked about that. So well done. It's a good question. Go ahead. Go ahead. Luca first. Okay. Yeah. Hi. I have a question. I've heard kind of talks and stuff about how, where we're going to be within the next couple of years. But where do you see GitLab being in like five years from now? Like six, seven years from now. What are your kind of long-term goals for the company? Where do you see us being then? Yeah. So five years from now, that will be 2023. So we would have IPO'd three years before that. We would be the default solution for like developing software. So developing and operating software. We wouldn't only have the most market share self-hosted, but also in SaaS. We'd be a couple of thousand people as an organization. We'd have more than 5,000 contributors. We start making inroads beyond just software. So the other part of our mission, everyone can contribute, not just to software, but to everything. We already have a substantial business in data science where people use a core of GitLab to be able to contribute to it. And we're branching out on in other markets, like design, like bookmaking, things like that, maybe even movie editing. At that point, we start seeing the move from GitHub to GitLab for open source projects. So the open source projects want the benefit of a single application for all their development and operations needs. Yeah, those are the things that come to mind. Was that the direction you wanted to take it in? Yeah, I think so. That's a good answer. Thank you. A question that's tacked on to that. In terms of the amount of people that work for, like the amount of employees, I think there's a goal to hire, I think it's 1,000 employees by 2020, right? Is that what I've heard? I don't think that's a goal. I think we want to do our work with as few people as we can. But yeah, that was going to be my question. Is there a limit on the amount of people that you see the company needing or wanting? You know what I mean? I don't see a limit. How do we start up? We want to grow as fast as we can and we'll hire the people according to how many are needed to execute on that. Okay, cool. Thank you. Thanks for the question, Tony. Yeah, thanks. So my being customer facing in my role and working with directors and higher-up executives in the enterprise level, we talk a lot about functionality and our differentiators and how we're going to change the market. So as we continue to add functionality, what are the goals with regards to ensuring success and having a long-term partnership with our customers and making sure that they're not just having success in the short term but being with us for a long time? Yeah, I think we want that and we want a long-term partnership and make them successful over the long run. I think the partnership, as we evolve, it should be less about GitLab and it should be more about them achieving their goals. So instead of, hey, we're going to make you successful in using GitLab, it should be, no, we're going to make you a really well-run engineering organization. We're going to make you your DevOps lifecycle three times faster and really partner with companies on that and help them achieve that. And that takes a lot of, the first step is quarterly business reviews with them, etc. But we want to make sure that when people think about a well-run engineering organization, they think, OK, GitLab can help there, not just with the software, but also the software should be a distillation of all the best practices and we should be able to help transforming those organizations. Thank you. So just a follow-up to that. So right now it's really important for us to continue to grow our market share and get those new logos or those new customers. So with regards to what do you see as, we talk a lot about functionality and features. I know there's a lot of talks right now about pricing, but it's definitely about value, right? Being able to do from idea to production, the value of going with a GitLab solution obviously is out there. So what do you see as the biggest obstacle or what gets you frustrated about the sales team and that you want to see them start promoting a little bit more? In other words, Sid, for me, can you help me do some selling? What do you want to see me do a better job of for you? Yeah. Well, I'm not frustrated with the sales team. I think they're doing an excellent job. But I think the challenge we have as a company, there's two challenges. First is awareness, not everybody knows about it yet, and it's slowly getting addressed. And then the second challenge is people thinking of us as version control instead of a single application for the complete DevOps lifecycle. And one address both things. And I think the sales people, they come in when apparently there's some awareness. So they have a big role in sketching that vision and how they can understanding and articulating how we can help people being better run, how we can make organizations better, how we can enable a faster DevOps lifecycle and then give specific examples there. So, OK, how can you do that? Because every vendor that comes by here has some version of that story. How can, what can I do with GitLab that I can do in other things? And articulating that, I think, is really powerful. Thank you. Cool. Thanks so much for the questions. This was really fun for me. You made it happen. And welcome to GitLab. So glad you joined. If there's anything wrong, it's my fault. So feel free to direct message me on Slack or paste something in the CEO channel. Have a great time. Bye. Thanks, Sid. Bye-bye. Thanks, Sid. Thanks, Sid. Bye, everyone. Thank you. Bye.