 Welcome to the February engineering FGU. Here's the agenda, what we're going to go through today. I'll update you on our OKRs. A nice engineering survey we did. Talk a little bit about changes to our release process, some status on the availability of gitlab.com. Looks like releases in there twice, oops. Update on people, some challenges, and then we'll go to questions. So if you have questions, start populating them in chat. So first update on the GCP migration project. We did a course correction here, so we will be moving to GCP as quickly as possible using the current omnibus installer and then iterating towards continuous delivery and adopting our cloud native stuff over time after that. Andrew talked about this in his infrastructure FGU on Friday, so I linked to the presentation here. That's got all the detail, and if you have questions, by all means ask him. But I won't be covering it more in this presentation. So next OKRs, we got them completely scored and retrospected on. I did some back of the napkin math, and we achieved about 60% of them, which is up from about 20 to 30% in pass quarters, which is great in incrementally getting to where we want to be, which is about 80%. And we did that through a combination of things. First and foremost, if you're at 20% or 30%, it's like, let's make sure we're setting more realistic goals. It's not like we can just say, hey, work harder and get from 20% to 100%. We're taking on too much. So we asked every team to really think about what's the highest priority stuff they could be working on, and then a sub should cut line and say, we're not going to do anything below this, and then we demonstrated incremental improvement. And we hope to dial that up again in Q1 and get in that 80% range. If you're doing that on a regular basis, it means you're taking on aggressive but achievable goals, and you're leaving that range from 80% to 100% for your best quarter ever. That's for overachievement. So we got the first iteration of our Q1 OKRs kicked off on the first day of the quarter, which is great. So people have the entire quarter to address them. And we added a couple of things. One, we noticed that open source or community sourced MRs were declining. So each team is going to take responsibility for at least making sure that the backlog of open source contributions is groomed enough to date, but certainly that includes merging more than we did in Q4. And then also adding a goal to make sure that each team delivers 100% of their commitments for each release. And we don't have a mechanized way to track this right now. So we came up with a process whereby I think it's about every eighth of the month. So after the feature freeze, managers will go in, look at what they committed to for that release and update their KR, because of course, those items typically then roll over to the next release, and we lose the ability to account for them. So we're going to track this manually. But again, the goal is to make sure that they are representing accurately the bandwidth that they have to their product managers. If we're doing 20% of what we can commit to in a release, that means we're just not prioritizing effectively enough. And then when teams get into that 70% range, it's like, okay, push harder. Let's focus on productivity. That's the way you kind of close that gap. Next, the engineering survey. So Jessica Mitchell and PeopleOps was kind enough to really drive this, and I worked together and the questions were going to ask, and she put it together in Google Forms and did this nice analysis. So a big thanks to her. The highlights here are, you know, I have a clear understanding of GitLab.com company objectives, 93%. I think that's unusually high compared to what I've seen at past companies. And so that's great. I think the fact that we have public OKRs goes a long way towards closing this gap. And I think Sid is also he's very clear and directed, like we don't have 50 goals, we've got three, you know, and he talks about them a lot. And so people say they they're receiving that, which is good. Even more importantly, the next one, I understand how my work contributes to GitLab.com objectives and goals, 97%. And this is really important because at past companies in here, I've seen this question be by far the biggest driver towards engagement. If people understand how they're contributing to the rest of the company, they're very engaged. They like their work. And most importantly, when something comes on your plate, that isn't necessarily fun or intrinsically motivating, the fact that you can map it to something very important for your coworkers or for the company allows you to kind of get excited about it in a different way. So 97%. This was this was really, really great to see. In terms of engineering leadership, people feel pretty good about about their their managers, which is fantastic, almost 90%. And likewise, engagement, this is sort of roll up number. People are generally highly engaged. We can of course do better, but, you know, didn't know what to expect. We're establishing a baseline here. And this was this was nice to see it was this high. In terms of lowlights, I plucked out four here. One is decisions made by the exec team, people feel that they're not communicated out in a timely manner. So we can make progress on that. Is the exec team paying careful attention to employee suggestions, people don't feel that that's happening. So we can make progress on that. Within the engineering team, my manager is consistent, timely and fair feedback. People don't feel like they're getting that. I've actually seen this before at my company, immediately prior, and we were able to fix this through some changes to to one on ones. And so we'll do that same thing here and see if this if if this if people don't change their feelings about this by the next survey, maybe we'll do this every six months or so. And then the other big one was I understand what I need to do to advance in my career. So I actually had already taken on it. Okay, are to redo our job descriptions and come up with some career matrices and things like that. So, you know, that aligns perfectly with this, but certainly my urgency to do that one and make sure we do that one well is a lot higher because I think this was the single lowest favorability rating for any any question. So we hear you will make progress on this and and we'll make it better. Similar to the retrospective meeting, you know, I first time I went to one of those, I said, you know, there's a world where you're taking on 50 action items I've been meeting like that or you're taking zero. The middle ground is where we want to be. So we start in the retrospective really just allowing one action item from each retrospective and over time, sure enough, we've noticed things get better from taking on just like a focused item. So out of this survey, there's lots of stuff to do, but these are the two that I want to focus on to make progress on the feedback issue and the career tracking issue. And if you solve these next time around, hopefully we see them improved and then we'll move on to the to the next one, but I don't want to spread myself or managers to them. Let's let's knock these two ones out of the park. So again, big thanks to Jessica. She was kind of to analyze all the results by team and the link to the presentation is here. So people can read these dive in. There were some qualitative questions and people can read through the answers as those as well. It's basically unredacted. So it's the raw data were an open transparent company. I was comfortable just sharing sharing everything with with anybody. Something I thought was interesting. Some people did have concerns about the survey. We did ask what team are on. Some people felt like, well, this is anonymous. Is that really okay? I think it is like we only group teams that have enough critical mass where you really, you know, if it's team of two, we didn't we didn't show per team results because yeah, it would be pretty obvious who that was. We group teams that have a relatively large head count of people to increase anonymity, but it's important because it showed things like, you know, some of these things that were general trends did not appear on the UX team. I mean, Sarah doesn't need to have a sense of urgency about fixing those. She can move on to other other things. Likewise, there was something on the front end team that no other team really demonstrated, which was people don't feel secure speaking up in big meetings on that team. So that's something that our leadership of our front end team, they can zoom in a little bit. They know they have an issue that other teams don't have and they can concentrate on it. So that's that's why we're asking, you know, people to kind of self identify what teams they're on. Even more interesting, Jessica grouped the teams that or the people were not comfortable identifying what team they're on. And those people had more negative answers to other questions. And so, you know, we can address those problems generally, but we can't do it in this more targeted way. So, you know, I hope that we build trust in people that want to fill out the survey and to self identify, it's just going to make us more effective in addressing some of these goals. So, moving on, glab.com availability and performance. The first thing to say is that this monitoring is not nearly as sophisticated as it needs to be. So, you know, take these numbers with a grain of salt, but look at the trend, you know, through a combination of manual QI and thanks to BJ for organizing it and the product managers for stepping up and doing a bunch of it and a lot of other people as well, that had an impact. The changes are at least process that Marin has been driving had a huge impact. And we're able, at least for our issue page to check in with a month, that's 100%. But again, more importantly, you can clearly see the trend going up into the right. In January, we dipped a little bit, we took some downtime due to the Intel bug that affected everybody, the chip bug. But, you know, we can annotate that one away and say, you know, that's not something that would have been under our control, but things have gotten much better in terms of performance and availability on .com. So thanks to everybody who's doing things the hard way to make that happen. Releases, this is a comment from Stan, 10-4 was the smoothest release ever. That was great to see. We definitely want to establish a track record of these, like 10-5, 10-6, 10-7. If they continue to go this way, I feel like we've solved something, but it was great to kind of like get here. We had a very straightforward and actually very short retrospective document for 10-4, which is, which is good. It feels like we're getting good at this. So thanks to Marin, Luke, and Robert who kind of drove that release and keep it up, please. People. So we added 16 people to our team, which is great. I think we did it with raising the technical and cultural standards. And we still managed to add quite a few people to our team. So excited for all our new team members. And it's something that managers and interviewees put a lot of time and effort into. We're trying to get more efficient at this, the technical screening process. We're doing some self-service things and that led to a couple of hires. So it was good to see. And we did need to get better at making sure we're efficient, that we're targeting some low-rent areas for specific roles. And we need to start doing some active sourcing there to get better at that. And then unfortunately, we had two departures. It's always a shame to see people go. But I like the team that we have going forward. And I've been pleasantly surprised with our ability to add to it and to add to it in a way that preserves our culture and grows it. Hiring efficiently, yeah, this is really about making sure we're a global company and making sure we're a distributed company, hiring people all over. It means we're hiring in places. We don't have benchmarks. We need to get benchmarks. We need to do active sourcing in areas. But this is an important thing. It's a win-win. We can hire someone in an area that's a very efficient place for us money-wise. It's a great offer for them. It raises their standard of living. So in that sense, it's a win-win. And then the more efficient we are in building the company that we want to build it and increases the value of all of our equity. And so we love referrals. And those of you who are in areas that have beneficial real estate prices, we're all jealous of that. New York and San Francisco and these other places, if you're lucky enough to live in one of these places, please refer your friends. Because it's a win-win for them and for the company, the more efficient we are with hiring. But that's probably our biggest challenge today on the people front is adding great people and making sure we're doing it in a way that's consistent with our global values and in particular that efficiency core value. So that's it. Questions? Let me move over to the chat here. Oh, Sid said, sorry he was unmuted. No worries, Sid. Clement, shouldn't it be front-end and back-end engineers versus developers on the new higher section? Yes, that's probably correct. Developers are preferred nomenclature. That's probably just me thinking back to past companies. So I need to retrain myself there. Thanks for calling me out on that. Any other questions from anybody else? What's the best way to suggest people to hire? Philippe, one of our new additions actually. So I think there's a hiring slack channel. I think there's a people app slack channel. To the extent you're able to go into lever and actually see the recruiter for a given role, you can shorten the time by going directly to those people. But I think when in doubt, just get into that people apps channel and they're pretty responsive. They'll pick you up and they'll get that person in lever and in front of the hiring manager. It looks like Sean actually linked to the handbook page about how to make a referral. So we've got a process there. Anything from anybody else? Jason P, a reminder that the handbook should always be the single source of truth. Yes. And Sid and I merged a comment. I think it was about a month ago, but it was about being handbook first. So the extent that you are thinking about a process change, those of us from past companies are accustomed to maybe doing a Google presentation or a Google doc using that to collaborate, getting consensus and then rolling out the process and announcing it and then getting it into the handbook to make it official. Try to flip that around and do it the other way. Try to propose the process in the form of a merge request to the handbook, have the discussion to the extent consensus or communication is needed. Do that in the discussion of the merge request. And that way you can go in front of Sid if he's the ultimate approval and he can just read a diff and you know that the lines removed or things we're not doing anymore, the new lines or the change lines are what the proposal is and then it goes right into the handbook. So being handbook first really increases the likelihood that it gets into the handbook and therefore the handbook can truly be the single source of truth that we want it to be. And let me tell you, everybody loves the handbook internally, but I would say 90% of people that I interview bring it up to me without prompting. A lot of people read a significant portion of it just in the interview process, so they're aware of it. And so people even outside the company value it and people that want to work here, it's always in their top reasons of why they want to work here. So let's preserve it and have it live up to the ambition of being that single source of truth and being as open and transparent as possible. Anything else from anybody? Going once, going twice, okay. Well, thanks for watching and you've got 15 minutes left and I'll see you on the team call. Cheers.