 Okay. I have 11 a.m. here in South Carolina. So I'm a wish everyone a good morning and welcome to the first ever Dev back end functional group update. I'd like to start off by sharing a little bit about me since this is the first time I'm doing an FGU at GitLab. Talk about my experience here. I've got to read me online in the handbook if you want to click through and see some more details about who I am how I prefer to operate all of that jazz. I do want to go ahead and get ahead of a few questions though and say yes, I know I need a new headshot since I've started shaving. That is how my beard grows naturally. I do not diet. I was not struck by lightning nor was I touched by a ghost. If you have any alternative theories for why it works that way I'm happy to hear I've got a small collection going. I can say, though I've been at GitLab for four months as far as I know I'm the first director of engineering that we've had. I have a question that comes up a lot for me. What would you say you do here exactly it's not a role that's very well understood, I think so. I'd like to take a little bit of time talking through what my team looks like. And then I'd like to focus on a couple of the different areas in which I've been focusing my effort over the past few months, share some challenges some results and some things that we know we need to do so that we can get a better understanding there. So as my team is concerned, the back end teams at GitLab are organized around our different product areas. So this product categories page is really useful for me especially since we've got this diagram up or since I found it anyway I just have to do this in interviews talking about the DevOps diagram with folks to help them understand but divided sort of down the middle of this diagram so Dahlia is our director of engineering for ops back end so all the teams that operate on the ops side of the cycle report through to her where I'm roughly responsible for everything on the dev side. What that means in practice. You can see the list of teams and their managers that I'm responsible for on the left side of this slide. The right side is where we're moving in the near future. And the main impetus for that is, we have discussion and platform right now that don't really map very well to our product categories. So we're looking to split those out into four teams. So instead of platform and discussion we'd have admin create share and plan which align much better with the product categories that we've got so that's a work in progress. So I have an idea what the team looks like right now as opposed to what it'll look like in the near future. Outside of working with those managers. Here are a couple of the big areas where I've been focusing my time hiring is one of them obviously we're growing very quickly. So that's an important area for us, but also building out a strong engineering management culture and trying to help define that and what it means in engineering management at GitLab has been important. So, like to talk about both of those in turn, hiring, obviously being first on the list. We've had a few different challenges here, inconsistency from manager to manager from role to role, what we're looking for how we're looking for it that's varied a lot based on who's doing the hiring. It may seem like kind of a harsh word here but at the end of the day we haven't been hiring as quickly as we needed to, according to our plan. So, clearly there's some room for us to improve there. The process has been inefficient for folks where we spend a long time from when a candidate applies to when they reach the end of the interview process, which is particularly painful for both of us. Honestly, if we get through to the end of the interview process and then find out that you know they're not going to be a good fit for GitLab and we need to move on. And finally, we've been inundated just to keep up with my in prefix here with applicants and it's been kind of difficult for everybody to stay on top of the hiring process, especially since the GitHub acquisition announcement went out. We've had a ton of new applicants come in. And I really appreciate everything recruiting has been doing to try to stay on top of that but it's also been clear that with the size of that team right now that's not something they can stay on top of by themselves. So here are a few things that we've accomplished around that. There's a link here for the documentation if you're a GitLab employee you can click through and view that it's not open to the public. But we're starting to describe here's our rubric in terms of what we're looking for for new developer candidates. Here's definitions for how we do screening calls and we're planning to add more in there about the various interviews and how they all tie into the rubric and everything so that we can handle things more consistently. So doing that, then to train more of our engineering managers to step in and participate in the screening calls with reference calls. These are things that recruiting has historically handled, which means that we're able to lower that burden on them and help them stay on top of the work a little better. But it also means that we're able to give our managers more direct responsibility for who we're hiring and how we're looking for it, which is great. We've streamlined the process some and really what this means here is that we're trying to have fewer periods of time where we're waiting on the candidates to get back to us. So we're trying to schedule more things in parallel and help just kind of collapse that timeline as much as we naturally can. And finally, we've pulled a lot of our back end positions together. This may be a temporary thing we're kind of experimenting with it, but ideally it lets us treat all our candidates a lot more consistently. And it gives us more flexibility because we're able to kind of figure out where people are going to be a best fit rather than having them self select when they apply for a particular team or for a particular specialty. So we still need to do a lot of the stuff I just mentioned is really kind of low hanging fruit. So we need to tackle some of the more complex areas like for example our technical assessment, which right now is not very consistent from candidate to candidate because we're basically going and pulling an issue out of our CE tracker and asking them to build a merge request for it. It could be a very challenging issue could be a very simple issue, you're going to see some things in one issue that you don't see in another so there's a lot of inconsistency there but it also means that the candidate has a take home part to the test, where they could get back to us tomorrow they could get back to us two weeks from now. So trying to find the way that we can do that technical assessment and get that same kind of value out of it we're getting out of the current one. But taking so much time or so much variable time even is going to be important and we're hopeful that we can roll something out for that this quarter. We're also going to need to spell out a consistent process for engineering managers. That's been lower priority because we haven't had to hire as many engineering managers, but it's still going to be helpful as the team scales we're going to need to hire both developers and managers so we want to make sure that we have a clear process for both in place so that there's less conceptual overhead that always adds complexity and a hiring process. And then finally right now, Dolly and I are in what I call training wheels mode here, we're still involved very early in the process, helping to bet candidates and weed them out before they move on to later more expensive stages like the technical assessment. So we want to, as we're building out this documentation very quickly get ourselves pulled out of that one because it doesn't scale. There's only so much time that we have in order to participate in those interviews. But to because we want to get our engineering managers again more directly involved in hiring for their teams and doing that early level filtering. So, we're working right now towards getting ourselves extracted from that and maybe move towards the end of the process where we can take the role that Eric is filling right now, which is kind of a quality control final interview at the end of the process. So that's hiring. If we talk about engineering management. As a position, I think this is a relatively new concept to get lab. And this is one of the things that this is one of the major issues that we've had with it there's a lot lack of definition. It means that an engineering manager does. Exactly. It means different things in different companies and it means different things to different people. So a lot of people bring their own understanding their own biases about what a what the person in that position is supposed to do to the table. It's difficult to answer the question, you know, am I doing a good job if you don't have experience with it as a developer. It's really easy for you to track how many issues have I delivered. What's my code quality like right we have all these good metrics there but as a manager it gets a little fuzzier. And so, without giving our managers the tools that they need to understand that it we're not really setting them up for success, you can improve what you can measure. Right. And then a final note here is that a lot of the advice out in the wild. I was listening to a management podcast the other day where they spent probably 10 minutes talking about how important it was when you schedule a certain type of meeting to make sure that you needed much for participants. So there's a lot of stuff like that out in the wild where there's just a bunch of stuff that doesn't really apply to get lab, or maybe it seems like it applies to get lab but it assumes that you're operating in an office working face to face with folks. So what we've been trying to do here is build out the handbook. First of all, we've added a new engineering management section to the handbook you can click through and look at that there's a brief listing of the topics that are covered here. We've also been leaning in a lot doing individual coaching with managers people have different issues like I mentioned earlier people bring their own biases about what the position is and is it supposed to be. So working through that and kind of a coaching environment is always really important. And then things that we know we need to do more the same that handbook entry is still scarce we still need to expand it add more to it. So basics, how do we measure our teams output is an example that I have here where you can see a couple of merge requests that we're going through right now, in order to try to make a decision about that. There's some other areas you know right now the handbook says engineering managers should do project management, but we don't go into a lot of detail about what that looks like and what processes we follow and we need to figure that out in a way that makes sense. We're trying to hire experienced managers we're trying to hire people that have done this, made a career of this already already have a good framework in their head about what it means to be an engineering manager and what's going to make them successful. But that doesn't mean they're going to have a good idea in their head of what's going to make them successful at get lab. So even though we're doing that and even though we think that's going to help. We need to get that defined really clearly for folks so that we're setting them up for success and give them a good transition into the company. So, with that, I will turn it over for questions. I'm a pop into chat here and see if there's anything but if not feel free to verbalize anything. Bob asked why would I shave with a beard like that. Medical reasons. Actually, Bob, I have, I have to wear a mask when I sleep, because I have sleep apnea. So the beard interferes with the mask. So I'm very sad to shave it. I was not looking forward to it, but I had to do that. Is there a merge request with the different engineering groups and their responsibilities. What about the transition from platform and discussion to share admin create and plan. Yeah, that's what I mean. Okay, there's not yet. You can look at the product categories page where I believe it's already gotten most of that, at least roughly outlined. But we're going to we're kind of going through those conversations right now and trying to figure out how we want to handle that organization and we'll get a merge request out for that as soon as we're done there. Yeah, Eric they have sleep apnea masks for beards they make them that only go over your nose. But I can't do that because I apparently habitually open my mouth when I sleep. And then I let all of that air pressure just right back out my mouth. So it's either where the full face mask or tie a rope around my head to keep me from opening my jaw. Any other questions. Feel free to chime in verbally as well. Hey Tommy, I have a question. An example or two of some of the unique challenges at good lab that that you've seen since your time is here we talked about engineering management should or could be different like your lab versus other traditional places. And I think a lot of it has less to do. I mean it's engineering management is the problem but it's less the engineering side of it and more just the management side of it. I think a lot of the training that you get naturally oriented you towards. Well, let's have a conversation. Right there's there's kind of the joke that as a manager you spend all of your time in meetings. And that's, that's been my experience I know that's been a lot of other people's experience as well. That's not very, that's not very get lab. If I can put it that way. And I'm sure if one of my particularly Sean Dower and Mara and if they're on the call they can probably chime in and they probably got a list, six or seven times long of times when I scheduled a meeting that I really should have probably just handled an issue or with the doc or something like that because that's still a default frame for me. And I'm trying to train myself out of that but part of a way that you can help with that is say okay let's build some of this documentation, right around here's how we handle some of these problems, right, instead of setting up regular meetings for the coaching, for example, what we can do is we can say let's have some document templates, or we can have people work on filling that out asynchronously, and then we can cut down on the amount of synchronous time that we need in order to resolve that issue, or help that employee out or whatever the goal is. So that's one of the big ones, I think a lot of the rest of it just boils down to being remote, right, if you're if you've never worked remotely before. So I did an interview with somebody the other day where they were talking about, for example, how they really prefer to have their one on one meetings in person over coffee. Kind of a thing because they feel like that helps them connect better with the people they're talking to. And maybe that does, but they're not going to be able to do that at GitLab. So if that was actually an important aspect of how they connect on a personal level with the people that they're responsible for managing. They're going to find other ways to do that and that's not always easy for people to make that adjustment. So those are a couple examples off the top of my head if that answers your question. It does, thank you. Sure. Cynthia. You mentioned that you consider the current hiring process to be too long what timeframe is the goal or what I consider to be ideal. Well, ideally, we're able to hire people within an hour after they've applied if they're great, right, but that doesn't really give us enough time to let them out. I think we're probably shooting for something like a two week cycle would be great if we can swing it. And that's an average, right, so we're a best case may even be a better way to look at it so there are going to be some people where through the scheduling reasons it stretches out longer than that. We've got everybody with the scheduling lines up and we're able to get them through the screening call and get them through manager interviews and get them through the technical assessment and get them through director level interviews and get all their reference checks done and get to a point where we're comfortable making them an offer if we can do that in two weeks. I think that's kind of the sweet spot and that's going to enable us to really compress the hiring pipeline and make sure we're getting people through as quickly as we can and into the team as quickly as we need to. In the past at companies, we've had a kind of unwritten rule that whatever meetings you might have scheduled, you always prioritize interviews over that because time is of the essence for candidates. I don't find that to be the case at GitLab. I find it's having to really work around managers or anyone on the interview schedule as meetings which can sometimes slow down scheduling. I think that that would ever be something you'd be comfortable with on your team saying, hey, if the recruiting team invites you to interview, that needs to be the priority for you. I mean, I personally I would be comfortable with that. I think there are a couple of considerations that come into play there. One is how we're scheduling interviews right now at GitLab, which is we send candidates calendar link and let them schedule themselves. And that doesn't lend itself well to that because that calendar link is not going to know, okay, which of my meetings can be moved, for example, it's just going to know that I have that calendar slot booked. So we're kind of putting them in a position where they are naturally having to work around the gaps in our process. Yeah. And obviously, if it's something that we can do, then I'd be more than I think we need to look around changing the process. I don't want a technology or process to guide our philosophy or our efforts. I want I want to lead with what should be done, not lead on the limitations. Yeah, and I've always been a big fan of exactly what you're describing right that the way I've always done it as I reach out and say hey let me know when you're available and I'll make something work. And if that means I have to move a bunch of meetings and I have to move a bunch of meetings but I want to make sure that we're talking to people at a really healthy pace. I think the other thing is I know in the handbook right now, especially as it relates to one on ones we have some language in there that says that those should not be rescheduled short of an emergency. So we'd have to not to say that that's an incontrovertible problem I just know that in the handbook right now we have some language around not rescheduling things like one on ones that make that kind of calendar manipulation a little bit more difficult. Yeah, good point. Thank you for that Tommy Tommy about that rescheduling I think we can easily adapt that rule that it's okay to reschedule a one on one for hiring. I've just, I'm not sure if I made that rule but I've seen it some other companies with a manager which is treat one on ones is like the last priority and would continually reschedule them. I think that's, that's not sending the right signal but I think, I think hiring, hiring is your future team member and it's a super high stakes events, I think it makes sense that that is an even higher priority. You said something about engineering managers being project managers. I don't, I don't recall that. What does that say. So not that engineering managers are project managers but that in that project management type work is a responsibility of the engineering manager. So right now product managers for example are doing a lot of work trying to figure out what kind of work should be scheduled for release for any given team. So we want to move that off of products plate and let the engineering managers handle that since they have a better understanding of their team's capacity and what they're going to be able to accomplish in any given cycle of work. How does that work because the product manager still need to say like this is these are the most important things to schedule and it's a cross team. It's a cross team problem that has to be solved. So we're not there yet. This is one of the reasons we're trying to kind of iterate towards that but the idea is that product managers should be responsible for exactly what you're talking about setting priority and providing any input that they need to provide into scheduling. So for example, if we've made a commitment to a customer that we're going to deliver something in a certain release or something along those lines, they need to own that and be responsible for making sure the engineering manager understands that. And then when it comes down to actually, you know, kind of assigning the work out for folks to complete we want the engineering managers to be responsible for making that call that makes sense. I wouldn't call that part. That's part of project management. I think we should be very clear that a lot of other things like project management fall on the individuals and it's not responsibility of an engineering manager. And we can we can definitely iterate on that language and try to move away from project management being the terminology we use there. By the way, I really love your presentation and I think you've you've incorporated a lot of the practices of good lap already there were many links in your presentation and many things written down so thanks for that. Thank you. All right. Any other questions. We still have nine minutes. Beard related or otherwise I'm open. Kathy notes that for highly competitive fields like security impressions with candidates make all the difference. Yes, and I think that's also true for other engineering positions as well maybe less so than it is in security but we definitely want to make sure we're building a good reputation of hiring people in a way that's very candidate friendly, or at least candidate sensitive. I'll put it that way. It's true for every single role that exists. Okay. Okay. Well, if there is nothing else, I will give everybody a little bit of time back before the team call. So thanks for attending. And if I don't see on the team call have a great rest of your Monday.