 11 o'clock here in South Carolina, so I'm gonna get started with the second ever DevBackend FGU. I have a few celebrations I wanna call out for the department and then keeping up with my pattern, my pattern that is now two FGUs long, talk about a couple of interesting challenges that we're facing right now and how we're thinking about them and move in for questions. So from a celebration standpoint, this by no means an exhaustive list, but a few highlights off the top of my head for things to be excited about in the DevBackend department. We have Rachel and Liam who both came on board in the past couple of weeks as new managers and I'm excited to have their expertise and experience and have them help round out our management team and help make the team better in that regard. I'm excited as well with Rachel coming on board, she gets to really stand in his interim management role for GEO, so he's gonna get to pivot his full attention to the engineering fellow role. I'm excited to see how that's gonna play out and what a more concerted effort from Stan is gonna do as far as driving better impact and change across the organization. Giddily 1.0 is done, the long march is over. 1.1 is close, we have a few cleanup tasks last that we still need to drive, but we've been able to start unmounting NFS or production, we're able to start having conversations with customers about how they're gonna be able to use Giddily across the board now, so that's super exciting. And then finally, Gitter, this is exciting to me because this is a team, this is a product that didn't even have anybody working on it full time a few months ago and now we're having exciting conversations about how it's gonna impact our strategy, we're having conversations, I had a few conversations with customers at the summit and it's really exciting to see some energy built up around that and I can't wait to get to a point where we have a more specific roadmap that we can share with everyone about the direction that product is going to take. But with all that, the first challenging area right now that I wanted to talk about is hiring. This is perhaps a bit of a simplistic diagram but it's a diagram that helps serve the point. This is a Venn diagram that tries to show that where we hire, where we've had a lot of success hiring over our career has been hiring people who are both great engineers who want to work at GitLab. So that's an area that we've done well in and we wanna continue to do well in but when we look at the reality of the situation right now, we're not keeping up with our hiring plan. We spent a lot of time making improvements to the process and I think that's all added value but it hasn't done anything to increase our throughput for people that we're bringing onto the team. So the next area that we wanna look at is maybe that overlap, maybe that intersection of people who are great engineers who wanna work at GitLab is not big enough right now for us to hire as quickly as we want to. And there are a few possibilities listed here. This is by no means an exhaustive list but it could be that there aren't enough people that know what GitLab does. There may not be enough people that know about GitLab who fit in that criteria. So we may need to do some work to increase awareness. It may be that there's a poor understanding of what's involved and what the potential rewards are for coming on board at a company that has the potential to get lab does as a mid-stage startup. It could be that we have poor alignment around compensation and that's a topic that we need to explore as well. So we've been thinking about this a lot and trying to figure out how we can move forward. One, I wanna thank Eric for taking some time to help us think through what some active manager led sourcing might look like and in this case what we really mean is having the hiring managers have some pre-built messaging that works well with marketing practices and everything while still being honest and ethical but we can reach out to candidates and say, hey, I wanna talk to you about potentially coming to work on my team and let's set up a call and let's have a live conversation where we can say like for you personally what we see is the potential risks and rewards and what the value of coming to work for GitLab and why we wanna pursue you as a candidate. We can do a little bit of a better job communicating what our teams do, especially now that we've broken up the hiring pool process, we have specific positions listed like an engineer for manage or GEO or what have you listed on the jobs page. Saying what those individual teams do is gonna be important for us and it's something that's gonna be front of mind for the candidates. So there's a great example that Marin put together a while back for the distribution team where we have listed out what the team does, what its responsibilities are, how it plays into the overall mission of GitLab and being able to communicate that and celebrate that and make it exciting is something that's gonna help put more people into that. I wanna work at GitLab bucket. And then finally, and this is the tricky one, evaluating our compensation strategies market fit. And I say this one's tricky because we have a few different competing tensions to balance. We wanna make us able to hire faster but we also need to be fair and equitable to the current team and we need to make sure we prioritize fiscal responsibilities of company. I could say right now we need to increase our benchmark by 100% and I can guarantee that would help us hire faster and it would be equitable to the team if we gave everybody 100% raises but it wouldn't be fiscally responsible on the other end. So we're having to try to figure out what we can do there in order to balance those potential, those potential solutions and keep everybody happy as we go through that conversation. So that's hiring on the other end after we've hired people we get to talk about career development. So we had the engineering survey that went out I believe back in July and there's a link here to the specific slide where we ask people questions about career development and you can see that the scores are not great compared to other areas in the survey. So we've been thinking through what can we do to try to improve career development for folks? And there are the two major ways that I think we have room to improve. One, we can provide a clearer process for working with people and coaching them through career development and helping them understand where they are and where they need to go but then also provide better clarity around what are different levels internal to engineering mean and what behaviors people exhibit in order to get there and exhibit when they do get there. What does it mean in a much cleaner way to be a senior developer or staff developer in good lab? For coaching, I did update the career development page a little earlier this week and there's a link to a template there for a coaching document that I've been using some for folks who are looking at a senior developer position. The reason to create something like that we do have some career development tools right now with the evidence of promotion doc experience factor worksheet but a lot of this is very past focused it's very much what have you done? What have you demonstrated? Where are you right now? And so providing a coaching tool lets us be future focused and say let's assess where you are now and where you want to improve and how are we going to help you get there? What are the next action items? What are the next areas for improvement? That could be, we need to sit down and create a plan for figuring out how we can do better code review or it could be we need to sit down and talk about how we can do communication better and maybe we need to read crucial conversations together or something like that I don't know but create that kind of future focused coaching plan to help move people through career development give them a better understanding of where they are in that process. Right now that documentation is based off of the job family descriptions that we have live on the website which can be problematic because job descriptions aren't always great for coaching and there are a few specific examples here from our developer breakdown. One that has kind of jumped out to me is interesting since I started is the difference between an intermediate and a senior is one writes good code and one writes great code. And this is a good marketing message and it's a good way to help attract people to the role and help them understand how we view the difference from a subjective standpoint but I can't exactly go to a developer on the team and say, well, you write good code but it's not great yet because the follow-up question is gonna be what do you mean? What do I have to do to make it great code? And if we don't have a good understanding of what that is, a good objective understanding we're not gonna be able to coach people clearly we're not gonna be able to coach people consistently. In the same way, we talk a lot about what people do when they're seniors or when they're staff level engineers we don't talk about how they do it about how they make the team better while they're doing it. And that's an important aspect of coaching that we need to make sure we capture. And we also need to make sure that we're less vague in talking about how we're gonna do coaching. Catch bugs and style issues is the one that I threw out here. Well, if I have a merger quest that has 10 bugs in it and you catch one of them in code review technically you've done that. You've caught bugs and style issues in code reviews but that's not really what we're talking about and that's really not the behavior that we would try to drive in a coaching and situation. All of these are fine for our job descriptions. I think there's a lot to a job description where it needs to be something that's attractive to a candidate and it needs to be something that communicates in a way that isn't gonna turn people off or be overly specific. But for coaching or promotion decisions we do need to take a step back and say we need to provide something more objective, something more behavioral, something more specific. And that's where tools like a career matrix comes into play. I'm really excited to have Dahlia as a partner on this and to have Jessica as a partner on this in HR because we've all had good experience with tools like this in the past. And so I'm really looking forward to getting some time over the next quarter to sit down with them and sit down with Eric and figure out how we can put something like this together and provide a more concrete base for folks to do coaching as we move forward in engineering. With that, let me check and see if we have any questions in chat. But if anybody has any questions to jump in, please let me know. Alejandro points out that the pattern technically is one FGU long, not two. So yes, thank you Alejandro. Tom says in the Venn diagram, is there another subsection for people we want to work at GitLab? Yeah, Tom, I think if I was gonna draw a realistic version of that Venn diagram, it would probably have eight circles, not two or three. So like I mentioned, it's kind of intentionally a simplistic model to help illustrate that what we wanna do is we don't wanna compromise on hiring great engineers. And we don't wanna compromise on finding people who are excited about what we do at GitLab. The question is how can we increase that so that we have a bigger applicant pool to pull from and to hire from quickly? Brandon had a question about giddily changing deployment targets. And it looks like Jason and Lyle have responded to that. But if there are any other questions around that, please feel free to speak up. And then the rest of the discussion looks like it's a follow on for that. So I'm gonna pull a page from Sid's book here and say that I'm not gonna end the FGU until somebody asks another question. Tom, I actually do have a quick question for ya. Shoot, Jason. Over in distribution. Congratulations to everybody that worked on giddily and all the surrounding information. Where do you see the impact of giddily being to allow other people to actually scale more easily than has been done in the past? Yeah, so I think that's a good question, which I think is something people always say when they need to buy time to think about the answer. I think there are a couple of different aspects to that and it's a little bit longer term. I think there's a lot of immediate attraction to being able to say you don't have to depend on NFS because as we know, NFS can be a scaling problem and it can be a technology difficult to work around in that area. On the other hand, we also know that giddily as a project is not HA capable yet. And that's one of the things that we started to run into. I know as we started to market things like the home charts for cloud native, for Kubernetes, where people are excited to jump on board, but then we get to this idea where okay, well, we still have giddily as a single point of failure. So we're working through that and we're trying to think through what does a highly available architecture for giddily look like? And we should have within the next month a lot more details around that. If you're interested, we'd be happy to tag you in on the issue, but now that we've gotten to the point where we're using giddily across the board, that's one of the very next milestones that we're looking at is how can we take giddily and take it from something that simply obviates the need for us to interact with NFS and puts it squarely in. Giddily is now something that makes us significantly more reliable and fault tolerant. Hey, Tom, this is John May on that giddily for HA issue. I've got a number of customers, very large customers at GitLab, investment banks that have not gone to HA because of some of these issues. And it actually almost derailed a deal with Verizon yesterday because they're looking for SSO inside Redis or giddily. And so there's, I think what we're finding is that there's a lot of impact that not being able to deploy HA in a giddily sense is really becoming impactful. Yeah, and I think, and hopefully I communicated that, I think we're aware of that concern and aware of that pressure and we're trying to work to mitigate it as quickly as we can. You say SSO inside, do you mean encryption, like SSL or is that? Yeah. Okay. I don't know. Your core requirement for them has to be encrypted. Yeah, okay. Well, James, I see you're on the call. James James is the product manager for giddily. So I don't know if we've looked at the encryption angle yet but that's definitely something where we wanna make sure we're responding to the needs our various customers and users might have in terms of how they wanna deploy this. Maybe we should have a giddily FGU. Since we're spawning a lot of interesting questions there, I don't think we have one on the calendar yet. Yeah, so Ben notes transport security separate from HA. I agree, it is a separate issue but if it's an important issue, if it's an important separate issue, then we should be accounting for it in the roadmap for sure. That's what I was intending to communicate there. All right, lazy Friday FGUs. Okay, just as I was about to wrap up, thanks Cynthia. Do you have an example of what you mean by matrix style evaluation slash coaching for performance? I don't have a specific example that I'm kind of like doing a screen share of an old matrix or anything like that on the dot. But generally what I mean is like, let's take some of these ideas, let's take write good code versus write great code for example, and actually add it to a document. So the way the matrix typically works is you have the levels down one side. So we would have for engineers, we would have junior and immediate seniors, so on down the line. And then across the top end of the matrix, we would have different categories. For example, like code authorship could be one. And then we would describe in an objective way based on behaviors and based on qualities what those different aspects look like for each one of the levels. So we just break it out and add a lot more detail and it's a lot of detail that you can't really add in a job description without it being overwhelming. But it is something that we can add specifically when we talk about coaching or promotion styles where we can go through and we can say, these are the things that we expect of, for example, a senior developer at GitLab. And so historically I've done things like say, let's anchor that around. How well do they follow things like solid principles or other good practices for object oriented programming? That kind of thing. And then we can break that down and make it really specific and really objective. And everybody has a very clear understanding of what it means to be a senior, if they're an intermediate right now, why they're not a senior yet. And that gives them a very clear direction for how they can improve and what they need to be working with their manager on in order to get ready for that next level if that's something that they wanna pursue. We wanna have everything spelled out to the point where nobody should be asking things like why am I not a senior yet? Or why am I not a staff yet? Because they can look and they can know and they can agree, yes, I do or do not meet those criteria and go from there. And then Dolly just shared a link so that describes building one in the chat. If anybody's not watching the chat. Okay, thanks everyone for the participation. I hope everybody enjoys the rest of your Friday and has a good weekend and we'll see everyone in the team call.