 Welcome to the functional group update general. I'm your host, Sid. And today we're gonna talk about these things. And if I say strange words to refer to customers, it is because of our organizational code names. I wanna have a try at making this call fit for public consumption. However, if you wanna ask something that is not fit for the general public, please do not hesitate because the last thing I want is people not asking certain questions. Some of the good stuff that happened. We made our revenue goal for January. Q1 is looking good. We're more likely than not to exceed our goal. However, it is dependent on some large deals. So that's the thing with large deals. They can happen, they cannot happen. It can have a big difference. Tone, yes, Chad is still confidential. And look, Tone, if you wanna ask a question that is confidential, go ahead, just do it, and then we'll just not publish this call. So don't worry too much about it. Just want to, I wanna make sure that we, as a company, can publish even more materials. And if we work with code names, we can do that. So that's why I want to get everyone used to that. And thanks Yop for linking to the code names in the chat. Another great thing, the pipeline for Q2 is looking good. We have a few more millions to go, but the team, especially the SDR team, is producing really well. We added two million in a week of incremental of additional pipeline. So that's going very well. So we're gonna meet two times pipeline coverage. And that's the minimum for Q3. We're gonna look at three times pipeline coverage, but still it's an improvement. And we're hiring at a rapid pace. Now, hiring is not a goal in itself. Like we hire people because we need them, but when we need people, and we decided we'd need a lot of extra people, it's great that we're able to get them. And I'm just seeing really, really qualified candidates the whole time. And I'm impressed by the quality of people. We can attract them, wanna especially call out like the SDR team, we needed a lot of extra SDRs and the people that are joining us are just really, really good. So thanks to the SDRs that joined us, but also thanks for the team for reaching out to people and finding them. Cortland says, I'm feeling like buying a car. Yeah, the code names are all based on car models. And it is so when you see a car model, you realize that it's a code name. At least that's the idea. So that you're like, oh, what is this strange car? Oh yeah, cars are code names. Some concerns, the move of GitLab.com to Impressa is being delayed from March to April. So that's not fun. But I think the team is doing good job considering the circumstances. We're not actively sourcing for old vacancies that need it. We're hiring 100 new people in a quarter. That is just a very, very rapid pace. And it is a big stretch for the recruiting team to do that. So they're working as fast and as hard as they can, but it's just a whole lot of vacancies to fill. In the future, hopefully we hire slightly slower and we have an even more efficient process than we can have active sourcing on all the vacancies that need it. And another concern is that Fable, one of our largest customers might churn. These churning happens from time to time. It's not fun and me and Hayden, we had a call for example yesterday, we're doing everything we can to prevent that and we'll see many times if you fight for it or if you work for it, great things happen. And Scott mentions in the chat, like we welcome all referrals. Yeah, it's not just the recruiting team that does the recruiting and the sourcing, it is everyone, especially the hiring managers, but everyone, if you have a great referral or if you know someone who's great, please, please do help. Someone mentioned that I might be a bit overzealous with code names. So, and then you kind of give away the code name. So that's a lesson for me. Philips, there's what's the trend for the coming months regarding recruiting? I think that, so Q1, we're adding 100 people, then the whole rest of the year, we're adding another 100 people. So it's slowing, you could see it as slowing down by a factor of three. Now in Q4, it's gonna be a bit harder to hire anyway and we might have some kind of leftover things from leftover vacancies from Q1 that we didn't manage to fill and have to fill in the rest of the year and we might change how many people we hire if we adjust that upward. So don't count on it slowing down by a factor of three but a factor of two should be, is something I do expect. So James makes a good point we might have to kind of revolve code names at some point. And James, I must say many of these code names, I don't think that the customers that we mentioned like mind that much, it just, we have to be a bit on the careful side but it's, I know that some of the customers even tweeted that they use us. So it's not the end of the world. Gabriel says that we should probably use more obvious car names that make sense or highlight the words. So that's a good idea. I can make them bold when I use them. Scott has a metric. We're doing about 20 hires per month. Yeah, Marcus reminding the sales team. I'm happy to join on customer prospects calls. I love that. I love being in touch with customers. So like whenever you put me in touch with a customer you're doing me a favor. Victor, a rotating code names. Yes, good idea. One-time pad, less of a good idea. But I do think there's something to be said for rotating a code name every once in a while, especially if it comes obvious after the fact. Paul Schieber asks what skill sets are we hiring? Paul, I think it would be good to look on our jobs page about getland.com slash jobs. So you can see the different vacancies we have. Mark Punsek has UBK based code names. Well, Mark, speak up if you can explain how that works. Clements. I was hoping Victor's rotating keys. If you want to really secure, you have to press the UBK every time you want a new code name. Yes, we're going to have public private code names. Very sure. It's going to be one-way hash code names. We'll just put the hash in there. Clemente asks what inspired the code names idea because the problem is sometimes we want to talk in an issue about like this organization needs something and it's really hard. Now we solve that a bit by just linking to Salesforce, which works exceptionally well, but selling presentations like this, like having a Salesforce link in there feels a bit weird. So that's why we had the code names idea. And it also feels a bit cool, I must admit. It's using a code name not already hint. Yes, it kind of is. And Philippe, it doesn't have to be perfect, this whole code name stuff. And Scott mentions that everything on our job page is something that is a priority and we're hiring for. And Mario, thanks for adding the URL here. Cool. Some plans really early. We're starting on time this time with the OKRs for the second quarter. So really early OKRs that haven't even been this, that basically come from me and not from the executive team are on the OKR page. Another plan is to get BizObs running. Today is the plan, but I wanted it down to this week, but with Brian Flood and the rest of the teams made some good progress there and we're figuring out what we wanna do, what we don't wanna do. And I look forward to kind of the first graphs in our data warehouse this week. Hiring a CRO this quarter, interviewing we have three great candidates that we're now doing extended interviews with. I'm really excited about external repositories in 10.6. This used to be called CI only, but we thought we focus on kind of what we support and as a support, we add support for having your repository outside of GitLab. So I think that's a great naming suggestion. I think it was Williams. And I'm very excited about this because this means that we open up GitLab to a whole new world. I think it's gonna help a lot on SaaS especially where people can now like, they don't have to move from GitHub straightaway, but they can use like the best CI and CD system in the world. So I think it's a big thing. We're gonna do our best marketing it and I'm really excited about it. Yop corrects me. It's the eGroup, not the team. Thank you, Yop. Still getting used to that myself. Fabio links to the external repositories issue, Fabio, but thanks for linking. And then the partnership launch in Q2. I'm also excited about that. I think it's a great partnership. I think we're betting on the public cloud that is gaining ground, gaining traction and that is very much aligned to what we are doing. Now, some top of mind things and I am running out of time. So I'll just let you read those, but I'd love to talk about them. It's gonna be according to questions because I'm out of time. Can you specify what changed on the team structure table? So the team structure table, the fact that we have one is basically what changed. So let me see if I can click through to this. So we kind of now have a word for every layer in the company and then it's something I've never seen before, but now that we made it, I think it's a very useful thing. You kind of have a management group and a reporting group. So the management group is that layer and everything up. So for example, if you're a manager, your layer and everything above us, it's called the management group. And then the reporting group is that layer and everybody below. And I'm sorry about this above and below nomenclature. I tried to kind of switch around the order but most people think of an org chart top down, kind of like a pyramid. So it ended up being this. And Scott, you're a muted. So unless you wanna speak up, consider muting yourself. So the reporting group is that layer and everyone below. So on a manager, that would be the team. So a team we refer to kind of the smallest possible, it's just a combination of individual contributors and their manager. And then on a director level, you'd call it the department. And on a VP or C level, you'd call it a function in the company. Robert, do we really need to tell people to scroll a page? Yeah, I don't like it. I would rather have our org chart under aboutgitlab.com slash team slash chart, for example. Now, the whole team doesn't work anymore in that URL too, but I'd rather have it on a separate page and then keep this page for describing the structure and I have the chart for the chart itself. And that way we can just refer to another page. I think that's better than scrolling, but I didn't have the time to move this thing. So if anybody else can, please help. Brittany, does that answer your question? Yes, the only question I had was, I know that the nomenclature changed where we had band and crew versus using team. Did that adjust as well with this iteration? Yeah, so the band thing, Martin said it didn't work. He tried it for three weeks and it didn't work. So I think that's the strong data. He actually tried it and it didn't work. Okay, great. So we should change that. And he said the team was the best term for that. So I'm like, okay, let's roll with that. Let's have team for the manager and reports, but then we needed other terms for the whole rest. The crew thing is still a thing. It's not based on success, but that is still a thing. So if we assemble a group of people to temporarily work on an issue, we can refer to that as a crew, because we don't wanna use the word team for that because that might be confusing. Cool, thank you. Thanks for asking. Abby says crew seems strange. Yes, it's strange, but I love for an alternative. This is the best I could come up with. So I'm open to suggestions. So Sid, what are some of your thoughts on consistency of demos? Thanks for asking, John. I think right now what I'm seeing, I'm seeing our solutions engineers give good demos. So yay, that's great. That's awesome. However, I don't see changes to our official demo page. So it seems that people are just doing kind of one-off demos. They kind of learn the product and then they give a demo. And a reason might be like the idea to production is a really long demo, but I much rather have a couple of demos on this page and then be able to discuss upfront, like what demo are you gonna give? Like, is it gonna be the demo that involves the prototype and framework that we made? And after that look at, I think like whatever we do, I think it's good to kind of have a name to refer to it and do it the same way. So that's not happening. So I'd really love for the solution engineers to start making contributions on this page. I checked this page out. I think the number five contribution is like five months ago from Mark. That can be the case. We're giving demos every day. So we should be improving and we should be contributing to it and we should have a way to do a demo. It shouldn't be something that we just give over from person to person. It should be something documented because if it's documented, it's easier to learn from each other. Oh, the other person gives it this way. I tried this other way. I think it's better. Let's change it and let's have everyone do it that way. And we're gonna get there eventually because product marketing is gonna kind of organize these things and we're hiring for a product marketing manager. It is a technical specialist that can help with this. But in the meantime, I'd love for solution engineers to contribute to this page and describe the different demos that they're giving. It's fine if we have like five flavors of demos. I just think it should be something that we document instead of something that everyone has to figure out by themselves. What do you think, John? I think you're right. I know the essays are talking a lot about creating like plug-and-play demos because a lot of the demos are structured around the pain points that were discovered during an earlier discovery call. So we try and craft the demos to show how we solve their pain points. So I think that's why you might be seeing a greater variety of demos. They are typically based around the I2P demo. Yeah, I think it makes sense that we have different demos. I just think we should kind of document them better. And yeah, William, you made an issue to create a stock demo. We have a stock demo. It's on this page. So let's figure out what we need to add to this page instead of creating a new page that has our stock demo. Like just describe the different variants. Don't start from a vacuum and then have a problem of having to integrate it with this demo. Just make this one better and make different versions of this. And naming the demos is like the hardest thing. So I think, for example, on this page, and I apparently stopped sharing my screen at some point. I'm not sure why that was. But on this page, it should have the idea to production demo and then there's a CI CD deep dive, but there should also be a CI CD overview demo. And it could say, like, hey, this is do the same thing as the I2P demo, but start at test and end at production. Like that's totally valid. And then we have a way to refer to the demo because now if I have a call with a customer and I know they need a certain demo, I cannot ask a solution engineer, give that demo. Because there's no word for it. If there are no other questions or suggestions, thanks everyone for joining. Have a great day and maybe see you at the team call.