 And it's only been about three weeks since our last functional group update. So we'll go through this pretty quickly and hopefully leave lots of time for questions. Here on the accomplishments slide, I wanna be very clear here that Canada has officially been removed. We are done with the work we need to do to safely hire in Canada. Australia is very close. So we can start looking at candidates, we can start sourcing, but there's still some contractual stuff we need to get into place before it's official. We're going to continue to try to expand or limit the do not hire country list. And these were the two first countries that we made progress with. We'll continue to try to make progress. Vacancies have been added to the team page, but we want feedback. So that's why we also linked to the feedback issue here. We're trying to do things differently to show how much hiring we're doing, to show that all of those future hires are positions here at GitLab that are important to us and future teammates that we wish to have. So if maybe it also incentivizes us if we see a little too many new vacancies on the team page, then we can all help and use our networks to help replace new vacancy with a name or at least initials once they get hired. The also take a look at the new transfer policy, not a whole lot of new updates here. Just wanted to make sure that everybody understands that here at GitLab, when we work at GitLab, our previous colleagues, our previous managers are references to us for a new job. We really wanna support growth and development. We want people to be able to move around if that increases their engagement at GitLab and their contributions to GitLab. But we also wanna make sure that it's clear that there needs to be transition plans put into place so that it doesn't just work the business too much as well as being able to know that your manager may have feedback for you for that new role and for you new manager. Doesn't mean that a manager can block a transfer. It just means that they are part of informing the decision. And I brought up the chat box and I'm gonna move it to the side, sorry about that. So I also am, as you can see here, doing open office hours starting next week. I wanted to start that this week but wasn't able to get it started this week. The idea of this is I'm gonna leave my Zoom open for an hour from 10 to 11 on Thursdays and the link is my standard Zoom link. And if you want to join me and just pop in and say hi or have a question or it can be very casual. If you see other people are in there, depending on the nature of the discussion, we can all talk together or we can have you call back in once that discussion's over. If there is a very confidential discussion that you wanna have with me though, however, I would still go ahead and schedule a meeting with me. But this is just a way for me to try to be more open and more accessible to the Git labbers that we have here. If we were in a traditional office space, you'd be able to walk by my desk. And if I was sitting there, you'd be able to reach me. This is kind of me trying to experiment with that. May or not work, but if I'm sitting there with no one joining me for those hours, that's okay. Cause I'll still get a lot of work done, but would love to see you. Will the office hour be on the team calendar? Thanks for creating that. Excellent choice, Clamont. Team calendar. I'm gonna confess my lack of awareness here. And if you wanna speak up, feel free to unmute. Are you talking about the availability calendar? What specific team calendar? I think Clamont's asking about the meeting calendar, where for instance, the FGUs are and any team meetings are. Okay. I think that's the availability calendar. Yeah, that's the availability calendar. And I'm not quite sure if that's the great use for it. So we'll talk about that. If we continue to use it in that way, sure I can add it to that. If we decide to have a different option there, then I'm not quite sure. But great question, especially when I don't have the answer, you know it's a good one. So going on to plans. We are re-looking at titles at GitLab. You can click on that issue to see what we're doing there. We're basically trying to, it doesn't change a whole lot, but we're trying to phase out junior and intermediate as being terms that we will not continue using and insert the terms of numbers like some companies do. Every company does this different. Titles are not used consistently anywhere. They're not a good way to gauge a level of a candidate to be honest with you, if you're hired from an outside company, because every company does it differently. We're doing it a little more consistently to Google with this new mechanism. However, it's not exactly the same. We can continue to iterate off this and it won't be necessarily that every team needs all the same job levels. For example, I will probably use recruiter two, three and senior, but I likely won't use staff recruiter. So different teams might have different levels they use, but that you can get more details on the issue. And if you've already had the chance to read the issue then you can open up to questions at the end as well. The comp calculator continue iterations. Brittany continues to do work on the comp calculator and you can get some insight and visibility into the iterations on that there. Performance review feedback cycle is coming up. You're gonna start hearing me change the way I talk about quote performance reviews because I don't wanna talk about them as performance reviews. I wanna talk about them as feedback. I think that review carries a lot of baggage from other places we've worked and other companies we've worked at. And I really want this to be about investing in each other and providing feedback to each other and less about judging each other and giving each other a rating. So I will start talking about it more as performance feedback. One thing that we're doing at the company and this was actually a recommendation from Sid is the GitLab 101s are really great and it's wonderful that Sid gives his time to our new teammates by holding those 101s. The other functional groups, the other leaders are going to start doing this as well. So you can look forward to start seeing GitLab 101s for people ops and we're getting motion to schedule those every six weeks. These are for the invite list will be the same invite list that Sid uses for his GitLab 101s. And of course we're doing lots of hirings. We still want lots of referrals. We've implemented a job of the week for once a week and Scott's and the recruiting team will announce what the job of the week is. That's a little way just to motivate you to kind of go into your networks and say, hey, do I have anyone who qualify for that job? But your help shouldn't start there. We all want to work with studying colleagues. We want to all have amazing teammates and you might know those people. So make sure that we get to know them as well. And on Fridays, the team is going to be working very, very focused on sourcing on Fridays. And that's a fun little thing to do too if you just put an hour in your calendar to say, I'm going to go treasure hunting for an hour on Friday and send all the gold that you find over to the recruiting team. So with that, I will open it up to questions. Hey, Barbie, this is Ashisha, I have a question. So as I've joined the team, a lot of people have been curious, I've told my network how great this company is to work for. They should come join. I've made a couple of referrals but there have been a couple of instances in which people saw an opening and were curious about the role, wanted to know more. So they wanted to have kind of an informal conversation or interview with somebody in the company or in that team to know more. So is there a mechanism or do we want to create a mechanism like that? I know that's a lot of overhead then for a lot of people. But if there's somebody who's referred and you know them but they're not sure if they want to go through the process yet because they want to understand exactly what that role entails. Is it something that we do today or something we can think about doing? Well, I'll be honest, normally referrals are people that the person who refers them would be having a conversation with them about the company. Normally it's natural if I know you. It's not the company, it's the particular role, right? Okay, yeah. I may not know a lot about what a director for CICD, I know what the director will do and what they will deliver. But what are the particular challenges they're looking to solve? And so that candidate, there's a candidate I referred to your team and they wanted to know more about exactly what it meant. And I gave them the best information I could. But it would be great if they really want to talk to somebody and not go through the whole interview process before they think it's a match. It's something they're going to be passionate about. So just a suggestion. Yeah, no, I think that that can happen and I think that there's no problem with that happening. I think that what you should do probably, and I'm thinking out loud here, is reach out to the recruiter and then together between you and the recruiter and the hiring manager, you guys can determine who the best person for them to talk to is. I would also say that I really encourage very good and viable referrals. I know sometimes it's hard for us to say to our friends, yeah, it's great that you're interested, but I really don't think you're the right fit for GitLab or this role. And you know the person well enough to know that they're probably not going to get to the process, but you don't want to tell them that. Probably not best to use the hiring manager's time and the recruiter's time, putting extra effort towards a candidate that... Yeah, no, no, I agree. I think the person I wanted to refer was a good fit. There have been others that I've thought, okay, they would not function in this environment. They're too into his lipstick or the culture isn't right. But if there is a candidate who's strong and they just are curious to know what there is, that's a good suggestion to go through. Yeah, then certainly we can put the time there. And I do think that referrals do garner a little bit of a different treatment in terms of they've actually been referred. We should acknowledge that. And it doesn't mean that the person who referred them is going to get all the details about why they were hired or not, because that's confidential to the candidate, but we should ensure to be giving good service to all our candidates. But an example of them we'll hear about when we don't, we'll hear from our referrals because they'll tell the people who referred them, right? And that's when we can get a lot of good feedback on our recruiting process, because quite often referrals are the ones to be the most direct with us. Yep, patience. So wonder if recruiting team can meet with two or three of these on our sourcing Fridays. That's from GitLab moderator. Don't know who GitLab moderator is. Bobby, it's me, it's Nadia. Oh, okay. I don't know why I'm moderator again. Okay. But what do you mean by two or three of these? Well, of these candidates that get referred that maybe wants to speak to someone internally. I was just wondering if maybe we could use our sourcing Fridays to early in the morning or late in the afternoon to meet with two or three of these referrals because it helps with sourcing as well, so just an option. Yeah, certainly no reason not to, right? And since that I regularly take calls from people interested in working at GitLab, I do too. I think it's a natural thing you do. A lot of these candidates, you're kind of just planting the seed of them wanting to work here someday. And it might not happen that week where they raise their hand and say, yep, I officially want to apply, but you might find over time as you continue to talk about what a great place to work it is and how unique it is, then eventually they finally decide, wait, I actually should really consider this. So it can be a definitely good investment. Indeed, and she's like just introduce them to the person that knows more about the role. Like anyone at GitLab should take a, getting to know another person called. Great, thank you. It is great though. In the informal getting to know people called I Love, but if someone's actually been referred, I would like notes and lever. Oh yeah, for sure. What that discussion was and what the person they talked to felt. If it's the more informal thing, that's less easy to do because they might not be in lever, but if they are officially applied, let's try to have updated notes and lever. From Dmitri would be a solution to create more async personal culture, create a video that tells the story for each role and explains the problems and challenges. Sometimes you just want to see a human. It's an interesting idea, Dmitri. That's a fun thing that we could probably think about doing in the future for the roles that we have a lot of, can we do an SDR video of a day in the life of an SDR, or a BDR, or an account manager, or a dev ops for production engineer, or that could be an interesting thing for us to consider. I hadn't thought about it, but it's certainly an idea that we could think about as a team. And I go on scrolling up, see what I missed here. What about doing an external GitLab 101? AMA once per period. Sid, do you post your GitLab 101s on YouTube? No, not the one-on-ones, because those are new people, so it's a comfortable environment. But I think an external is like an AMA, like that's common on Reddit and things like that. So if someone's to set it up, probably somebody marketing that has experienced live streaming, I'd be happy to go on a call for 15 minutes and ensure the famous YouTube comments. Or we can have a get a room, but let's do YouTube comments because I love to be myself. And Lyle, I would be happy to do that as well. We do it at the summit. I know we do the external AMAs at the summit. I'm not quite sure how often we do it outside of that, but I think as a new candidate, that was really helpful at the last summit. I watched those a lot. Oh, good. Good. Then yeah, we probably should think about doing more of those. So Sid and I will follow up with marketing. Keep scrolling up. If anyone sees something I missed, I love the comments in group chat, but I'm also happy to have you just speak up. So if I missed yours and you're sick of me scrolling, just speak up. Yeah, there's a question from Clément. Yeah. And how do you get up under internal promotions? What was the question? I see the office hours one. Yeah, it's a question from Clément actually. How do we get up under internal promotions? How do we do internal promotions? Exactly. Okay. Yeah, how do we handle them? Excellent question. You can get more details in the transfer policy update link on these slides. That actually takes you to the promotion and transfers page. So it'll have a lot of good detail for you there, but philosophically wise, promotions are a combination of doing amazing work and growing in a way that a promotion is the right thing. There's different kinds of promotions. There's going up a level as an individual contributor and there's going into management. When you start thinking about going into management or team lead, then it's gonna be doing your current job great, but it's also gonna be about your skills on giving feedback, on setting context, on hiring, on the management, the cross functional, all those things are gonna come into play as well. So it's a little bit of what you can do in your achievements and your abilities. It's also a little bit of luck because the needs of the organization come into play here too. So we don't need two CEOs. So if you wanna be CEO of GitLab, there's gotta be a CEO vacancy there, right? So there's a little bit of luck in play too, which is more difficult to handle because you wanna think if I do everything right, then it'll come and it may, but it may not come at the exact timing you were hoping for, depending on what the needs of the organization are. So, but there's a lot of details on how we handle that here at GitLab in that link. And, but anyway, if you wanna be CEO, you gotta apply to the board. And if the board hires you, I cannot block you from being hired. That's the point. That is true. That is true. Go for it. Come on. So. Thanks. Yeah, promotions, internal promotions are a great thing. And so are internal transfers. I just wanna make sure we do it in the right way. I'm not seeing, I'm still not seeing that question, come on. But thank you very much for raising it for my attention. Oh, there it is, found it. Okay. We already write down a lot of questions we get from candidates during the hiring process to help with making those videos that Dmitri suggested. Okay, excellent. You can feed us with some content. That's excellent. Okay, more support for the AMAs. Oh, okay, so Abby asked, can you apply for the transfer even if there's no headcount for that team? And she starts that with, I'm asking a question without reading the handbook, sorry in advance, please do not be sorry. None of us can know and memorize everything in the handbook. I don't want anyone ever feeling uncomfortable for asking a question that's in there. I know sometimes when I say something like it's in that link that is not said to make you feel like you shouldn't have asked it. It's just said to help you get more information in context because my answer might not be as inclusive as that link is. But please, please, please ask questions. Don't worry about that. Transfer, yes, you can technically not apply for transfer if the headcount's not there because the vacancy won't be there to apply to. So the transfer process includes you going through the applying to the role, interviewing for the role, for the vacancy. And if it's not there, then you won't have that. However, I would say there is no problem at all with being interested in a team, going out there and having an informational discussion with that manager of that team or some of those team members saying, hey, what it's like on this team? What it's like to work here? Might you have openings going forward? You can absolutely have those informational and exploratory discussions and shouldn't be afraid to do that. Excellent question. Great questions this today, everybody. Anything else that I think, oh, I have one next. Okay, go ahead and then I'll do the question from Jacob. So one of the things I thought about with this job titles thing is one of the fun things that we did at Google was you were allowed to set a working title. So we had a bunch of boring job level titles, but it was also possible to set a custom title based on your personality. So I kind of feel like we have the boring solution and the quirkiness as both options. Yeah, official, I think it was called working title is you could still use it externally. So you could still make it visibly external, but you still had an official people ops title. Yeah, I think that isn't uncommon when you have your titling that you have in your company for levels and for everyone understanding and then you have people who wanna put open source guru or something different on their business project or LinkedIn profile. I don't think we have anything official on that at GitLab yet. So Sid, you can speak up to you, but I personally, I don't mind some creativity there, but go ahead, Sid. I do mind creativity. You have one title, that's it. Organizations like Google are super hard to navigate externally and tripping people up by unofficial titles is one of the ways. It's the same thing why we don't have names for our releases. It's not called a funny badger or like those Ubuntu names because you end up with two titles for every release. I got a Google twice to find something. So you have one title. However, we're not using the expertise is enough. So you can add expertise is all you like and people are not doing that enough. So I really encourage people to add more expertise and if you wanna have an expertise of open source, source, I'm not your guru, but expert, that is totally fine. So be a bit more generous with the expertise is on the team page. Feel free to add them yourself. Feel free to have your manager merge them. And what we want with the expertise is to be able to be the answer questions like, I have an, I don't know, a problem with LDAP. Who's an expert? I have a problem with internal transfers. Who's an expert? I have a problem. Well, you can think of all the categories with open source licensing, who's an expert? So feel free to add those liberally. But we have one title. The idea of titles is like organizations are hard to navigate both externally and internally. So that's why we have an org chart on our team structure page and we're not gonna confuse that by having multiple titles. So different opinions on that one. So we can, I think that what Seth said makes sense. I also think that the exact levels of titles don't always make sense. So I think that the two, the three, the staff, the, those levels and things that we can, we can debate on that some more. And then going back up to Jacob, could a transfer ever be temporarily rejected because the original team can't afford to lose you or similar? I'm gonna say no, but I think that that's what the transition plan has to help solve. I think ideally just try to have short transition plans. It's very difficult for a teammate to be kind of straddling two teams and trying to divide their work up. It can get very challenging for them. So as quickly as possible, you should have a clean transition. That doesn't mean that day one will be the transfer day. There needs to be thinking about the best interests of the company and the business and what we've got committed and work that might need to get finished. All those things are where we need to use excellent judgment on determining that transition and that timing. But I don't consider that a temporary block. I consider that a transition. Thanks a lot. So Mont Asif is a way to incentivize more experts. There might be, you guys tell me, do you think you need to be incentivized to put that up on there? To put where your pieces are on? I mean, I feel like the incentive should be that people will recognize what you're an expert in and you'll be able to have more clarification on those things that you should be reached out for and that you can help with and that you can find it's a fortuitous cycle. If you're looking for an expertise, you can find it as well. Is there more incentive we need? Maybe managers could reach out to each individual and maybe bring that conversation during the review time, performance review to have another loop to remind ourselves to add to that page because I know a lot of people may forget that it's there. Okay, that's a good idea. I think it might be interesting during a functional group update to have the presenter of FGU present out their team and like introduce team members and their expertise to the rest of the company. I would certainly be interested in hearing about that for other groups and that might incentivize people to get their expertise up to date. I like it. You guys have some really fun ideas. We'll have to figure out which ones to experiment with first. Best goal ever, but we're out of time. Okay, thank you everyone. Thanks for the questions.