 I think this is the third FGU of 2018 for the engineering function. Maybe the second, I'm not sure, but welcome. It's Friday the 13th. That's not on us at all. I'm not superstitious, but we're going to talk about hiring the shape of the department by the end of the year. Our pace against our hiring goals and also how we're going to iterate towards that, that shape. We'll talk about our goals as a group or as a function in the form of OKRs, of course, and then we'll talk about reviews. And I'll share some of my review, as a matter of fact. So hiring shape and pace. If you click on the link here, you can view our hiring plan of record. And this is derived from our product roadmap. So in the case of product engineering, we reflect what product management says we want to build. And what they've done is tell us sort of buy back in team by feature set exactly what they want to do a lot more. So you can see here, I put in, you know, monitoring as well as Kathy's team security are going to more than double platform discussion. CICD, the production team database are going to double a little bit less activity and distribution quality UX front end in the management positions. That's myself, director, you have market, et cetera. And then one person for Phillips teams and holding steady. So a lot of growth in a lot of different places. But this is where you, if you want to get a sense of kind of where we're growing, just report us to other areas. This is sort of the list, but this can change as the roadmap changes as priorities change, we can adapt as we go. So we're very flexible about this. If you're looking at this spreadsheet where it gets down to specific numbers, just be aware that this is all a product development. That's how our CFO looks at it, right? So it includes product management numbers. Support engineering is separate from this. There's a separate model that drives out and that has to do with how many customers we have, what support level those customers have, et cetera. So Lee has covered that, I think, in detail in his FGUs. Just look at the archives if you want to dive in there more a little bit. And then there's some new capabilities that are kind of not really reflected in our chart today. Those are package management and configuration or operations. So the way to think of this is like, well, how are we going to grow into having teams for this? We actually did a handbook update that sort of set out a framework for this. So the idea is we've got roadmap for a year. We've got a manager and a senior engineer, maybe a newer manager and a staff engineer. We've got two intermediate or seniors to join the team. And then we've got two approved vacancies. So about four people kind of turning into a team of five or six with a healthy amount of roadmap to sort of bite into. And then we feel like we can start a team. We can name them, they're aligned with a product manager and they go on the team chart. But that doesn't mean that we can't make progress against these goals until we have a sort of fully formed team critical mass. Those issues, those ethics can get scheduled on current teams that are, let's say, the best fit to do progress against that work in the meantime. PACE. So I have a spreadsheet where I've calculated this. It happens to contain rent index and some other potentially sensitive information. So I can't share the link in this case, but it'll just have to trust me. We're on PACE currently to fall short of our goal. I want to say for developers, it's 153 by the end of the year. Or sorry, 163. And I think we're on PACE to 153. So fall short by tandem error about negative 12%. So thoughts, that's not that bad. You know, I think about something we're doing over the course of a year or three quarters in this case, we can make up, you know, 12%. That's not, that's not terribly worrying. I love to hit it on the nose for sure. But, but I feel like we're in it within spitting distance. But that's general. The PACE is sort of uneven. So we have some teams that are sort of a hat or overachieving. And then we have some that we haven't done a lot of ironing for and are sort of behind. It's very similar to unit test coverage where as a project we're at 90 to 95%, which is great. But if you look at specific directories or files, we could be at 0%. And we obviously want to address that. What are we doing to get caught up for these teams of particular like monitoring CIC, Dahlia is now here as our director of engineering allows back in. And this is one of her main goals is really figure out how we're going to hire, drive that. And we're thinking of a pool process, which allows her to sort of get kickstarted by Tommy, Dahlia, Sean, Mary and everything that they've been doing on the dev backend side of things. But also numbers and percents don't take into account that we've got specific vacancies that are really hyper important. And one of them, if for instance, this is director of infrastructure. So despite that, I feel good about the pace and things like that. We know we have certain roles that are like a number one prime priorities and we're really buckling down and partnering with recruiting to fill those. Some key hires we've made recently. I mentioned Dahlia. We've also got Roger who just joined our security team. Talk about getting thrown into the fire right away. He joined in his first week. We gave him a very important issue related to large, large repos that are slowing down our geo migration there for the GSP migration. So we really appreciate in pitching in in his first week and just kind of learning on the job. We've got someone joining the security team as well with a title senior threat intelligence engineer, probably the best title in the company. Do you want to know more about that tune in for Kathy's next FGU on Friday? We have an engineering manager starting for CICD and for production. That's exciting. That's going to help out with hiring and lots of other things. And we've got some platform engineers and discussion engineers in the pipeline, but not yet signed. And so I didn't want to kind of, you know, tell that here. These are picking up some key vacancies. There's our director of infrastructure. If you care to, if you think you've got a network with some of these folks in there by all means take these URLs, post them to your LinkedIn. We really appreciate that. We love referrals. Referrals are proven to be higher performers and to stay longer at startups if they're referred by an internal employee. So refer your friend, refer your past colleagues. That's great. If you want to see all the jobs, click on this page here. The latest change you made to this is that we separately had a heading for, let's say edge for platform. We recently just removed that and had engineering. So that way someone that's coming to the get lab jobs is interested in all the engineering jobs. They're not grouped together. They're right there. And it's very sort of consumable and they can understand what they need to apply for without being sort of all scattered around. Okay. So this is our company and department rather function goals. So Q one, we've now closed this out. They are moved to an archive page. You can click here and you can read that the retrospection and the squaring of them is ongoing. The goal is to do that by today. I think we're probably 80, 85% there. Am I skidding into next week a little bit? But I want to highlight two experiments that we ran the Q one. Okay, ours. One was community contributions. So we're an open source company that's really important. It's part of our heritage, but it's also part of our strategy going forward. And we noticed that those were giving in Q one, the amount of community contributions that we merged. So we put that in. Okay, ours. And then we can already tell that that had dramatic effect in Q two. And that went way up, which is great. Special thanks to Dawa and, and Sean whose teams are sort of frontline on this. And they did a fantastic job. In fact, when I proposed this, they came back with a KR that was actually more aggressively worded than what I have been thinking and they, they really delivered this, which is great. And thanks to, to Remy for pulling these metrics. It's tremendously helpful to understand what's going on at high level across, it was a pretty large department. And then next, we also took on an okay, our to measure how many issues we're delivering against our goals. This is new. We don't do estimation. We don't do velocity tracking as some other companies do. The thinking is, is that some companies get into the rituals. They spend four hours in a planning meeting, four hours in a feedback meeting. We'd rather have that time back to do work. But this is sort of a free lightweight way to kind of get a sense of our velocity. So this is a whip with this isn't done yet, but this is sort of our first data point. And we did decide to carry this strategy over into Q2 as you'll see. So we'll have some sort of time series information. The goal is to be accurately representing our bandwidth to product managers so they can make the best prioritization decisions about how to spend that budget against the future goals that we have. So Q2, so these are authored and they're already kicked off. They're kicked off on the first day of the quarter, which is great. As I mentioned, there's a total of three questions that we have about the production and products against them. Some changes that we made even dent everything so that way, even if your manager or me, let's say, has an okay art to do something on the handbook beside the other thing, but don't necessarily have a goal for the GSP migration, which is really important. The indentation implies that your manager, your director, me are still responsible for those things, even if the words don't directly line up against our title. We're doing the release commitment. K.R.'s resourcing and for recruiting. And then we also made a decision as an exec staff to limit ourselves to three goals. In other words, let's be more focused. But that leads to some hard decisions. So there wasn't room this time around to do the community merger, K.R.'s. Let's see if that has an effect or not. If they go down substantially, we'll figure out a way to drive that up again. And I'm just about ten minutes. I'm going to take two more minutes just to cover the reviews and then we'll go into questions. So it's review time. This can be a stressful or anxiety-provoking time for people. It's really about how to get better at your work. It's natural to kind of take these things personally, but really this is about improving, becoming more efficient and functioning better as a company so that we can meet our goals. So I thought it'd be useful for me to share some of my personal feedback just so everybody gets more comfortable with what they're going through with their managers and their peers over the same time period. So I got lots of good stuff. That's great, but that's never the interesting stuff, right? I do encourage you to focus on that, but for this time, I'll focus more on the opportunities for improvement. The one good thing I want to call out because I'll close the loop later in terms of areas of improvement is the results. If you say it, I know that it will be done. I really appreciate you getting that feedback. I put a high bar on the promises that I make and that's important to me, but perhaps there's a failure mode in there too. So in terms of areas for improvement, iteration, make the changes that you're thinking about quicker. To me, I think it's the other side of the coin of this. I really want to deliver on the things that I say, which means the things that I say really have to have high confidence and that means it takes longer to get to the high confidence. So I'm adapting to GitLab and I'm learning that I need to be more comfortable proposing ideas that have, let's say, 50% confidence and getting it out there and then making changes. Similarly for transparency, I think that's also the same side of the coin where I don't want to keep secrets. I want to be transparent. However, I don't want to tell people that I'm not confident and that might mean that I'm holding things back occasionally. And again, I need to get more comfortable saying, look, this is the current state, 25% confidence, it could change next week. And just like that's the way you want to operate. So I'm adapting to that. The other angle on transparency is that my previous company was a drone company. So that means I came from the aerospace industry, which was new for me. I came from very transparent companies before that. But aerospace, as a conservative industry, there's lots of people from defense, even though we weren't building weapons, there are people from the defense industry there. And that's a secret keeping industry. And I couldn't help but adapt to that environment somewhat. And that means I need to regrow this muscle of transparency. And I'm doing that. I very much believe in this value, but old habits sort of die hard. But there's no desire to keep secrets. It's just a matter of reminding yourself to get to kind of push that information out there, even if you're uncomfortable with it. And then the last thing I'll say is diversity. I really appreciate that someone gave me this feedback. I really valued it. I want to be better at this. This was a surprise to me. It feels to me like it was a misunderstanding, but that doesn't matter. We're accountable, not just for what we intend to say, how that information is received. And in this case, I said actually a couple or a few things that made this person think that I was making assumptions about their capabilities, due to different attributes that they have. I couldn't list those attributes here, because I don't want to obviously reveal who the person was. But you know, trust me that this is something that I value hearing I really want to get better at. And I really appreciate that this person took the time to bring it up. You know, it's easy with all the things going in the world, like hate speech and marches going on to think that like, oh, well, there's these really, you know, extreme examples of things going on there that are bad examples of diversity and inclusion. And those things are bad and they need to change. But those are also like the 1% cases. Diversity and inclusion to me is really the everyday things. It's well intentioned people, nevertheless, unintentionally injuring one another due to ignorance. And that means we all have to sort of, you know, get better at that and own that. So again, something I want to get better at and I appreciate the feedback. So with that, apologies going over a couple minutes. We'll jump into questions. Let me read through the chat first. Let's see. Marin, sorry, said that explains today. I'm not sure what that I didn't catch one exactly that. Maybe Friday the 13th. Ah, okay. Let's see. Thank you for the comments and diversity and bias. We all have built in biases. Could you remind of that? Thanks, Mark. Clement, thanks for sharing your view. Sure. Let's see. Brendan wants to share his. Sure. Let's see. Clement doesn't see leadership doing this very often. I really appreciate it. Sid is pretty dang transparent, I'll say. I think we're all striving to catch up with him. But this is definitely deliberate on my part to like make myself a little bit uncomfortable. So making progress there. Let's see. Any questions? So lots of good feedback. That's great to see. But any questions, goals, shape of the department, vision, direction. Yeah, Tommy, thanks for the help. No questions? All right. Well, going once, going twice. All right. Well, if you have any questions, jump in the VPE Slack channel. Schedule coffee break with me. I'm happy to talk about this stuff offline. So cheers. You got 15 minutes back and have a good day and a great weekend.