 Thank you very much for taking the time to join this session, particularly on a Friday if you're here for the live show. And thank you for people who are watching the recording. I thought it would be good to talk about promotions this time, mainly because we are doing performance reviews at the moment and it's a good time for managers to start thinking about people in their team as you're writing their reviews and you may be thinking about perhaps they need to be moved up a level. So that was kind of my thinking behind scheduling this for this week. So I will just go ahead and share my screen. So I'm in full screen mode now so I won't see the questions coming in but please go ahead and add your notes to the doc and ask questions in the chat and that would be really great. So I just wanted to cover a couple of things. I'm going to be talking about promotions at GitLab and then briefly talking about the current promotions process that we have. My intention as always is to make a change to the handbook. I've been doing that for all of the sessions so far based on our discussions and things that we've talked about. So as usual I want to do that with this as well. I will stop talking after we've gone over that and then I will pass over to Sean and Lee who will give us some real-life examples of how they've carried out promotions, what they've done and that kind of thing and then we can open it up for discussion. And then I've added a final slide with some additional reading, a couple of things that I found that were quite useful. So one of the things I thought might be a first question perhaps for some managers who are with us already but for any managers who are joining us in the future, who haven't been through this before, how can you identify people who need to be promoted? Particularly at GitLab as we work remotely. It may not always be obvious and we have one-on-ones and I mentioned the performance reviews with obviously being a software company. We can get data from merge requests and issues and I remembered seeing, I think Jake mentioned this before, the graph with all the activities. I think it's the activity log. I think that's what it is. Anyway, I forgot to put that in here but that's usually a good indication of things that people have been working on in terms of productivity. Also, our values. Somebody who is clearly demonstrating that they're able to perform at the next position level and we talked on the career mapping session about having levels defined for each job and I think in the development teams certainly from the people ops team, we always see requests coming in from people in development which makes sense because that is the largest team, I believe, at GitLab. And then the next question, when should you promote someone? And the answer is anytime. We don't as yet have any strict periods of time when somebody can be promoted but I would say to just exercise a little bit of caution and not promote somebody too soon. You may find that somebody is in the role and they're like totally exceeding expectations, they're performing really well. But then when they move to the next level up, they may, if it's too early, they may go down to just like meeting expectations until they have time to ramp up. So I've put a link to the promotions process section in the handbook. This is actually in the compensation and title changes page. It's a very long page. But we do have a promotions process there, which I won't talk about too much because as I say, it does need to be updated. And the majority of it is kind of what happens once you decide that you want to make a want to promote someone in terms of you've already gone through the stages that Sean and Lee are going to talk about in a minute. But it's still useful to go and check that out. And I will obviously update this to include the bits behind before you get to actually the processing of the promotion. And also, there is a merge request already open for updating the salary review. Sorry, for, I lost my train. I'll start again. Usually promotions will include a salary review and increase. There is a merge request that's related to that. And I just wanted to make mention of if you haven't seen it, please go ahead and check that out and add any other comments that you want to do that. So that is the end of me talking for a little bit. I'm going to pass it over. I think Lee, if you're here, I think I did see if you want to take it from here. Sure. Sure. Happily. Sean and I lead teams, everyone in this room also leads teams. So really excited to be talking about these things. I'm on the support side, Sean's in development. And really, we wanted to take some time to just talk out loud, open the floor to kind of riff on experiences we've had with deciding when how to promote people positive experiences, Acutlab in other places as well and just understanding like when and how. And so Sean and I talked a little bit about that earlier, and we'll dive in here. I think the one thing that stood out to me in our earlier conversation, Sean, was this idea that when do we promote someone and the ways to start that? What were your thoughts there, Sean? Yeah, so first of all, I should say that Lee and certainly pretty much everybody else in this room is a more experienced manager than I am. So if I say something stupid, that's on me. Like, you know, that's not necessarily everybody. So I am definitely very feelings based, at least initially. I think feelings based is perhaps a negative way of putting it, but definitely very qualitative. Like, in the past, when I promoted someone, I've used evidence and I've been able to provide evidence. But before that, that's sort of how I feel about working with them. And I will often, and I'm sure everybody is in this situation, like I, as certainly development needs, like I do some development, and I try and dig into issues and understand what's up and try and give as much detail as possible. When we're scheduling something so that someone's got a framework to work off. But I can't, like, do that all the time. And there are definitely issues that come up where I'm just like, I can't deal with I can't look into this right now. So, like, I'll just give it to someone on my team. Can you take this? And for me, a really good indicator is like, you know, I will do that to different members on my team anyway. But like how they handle that is a really great indication of how senior they are, because someone being senior to me means that they need less supervision. They can just take something complicated that I myself don't know what's going on. And they can just run with it for days or even weeks without much input from me and just keep working with the people to hammer away at it and get it forward. So that's definitely a big thing for me. The I know you've got a very structured approach as well. Yeah, Sean and I talked about this and I agree with him that there is usually that that moment where you'll have a feeling where you'll say, Yeah, I think this person is ready. But I try really hard to remove that from the equation and use evidence as much as possible. So we all have job descriptions. You know, we have our job, our roles, our teams, we have those. And for me, when I build a path to promotion doc for my entire team, one as a motivation to as a as a thing that makes it easy to see where you are and what you're progressing and what you should work on next. I use that as as much evidence as possible. And and in talking with Sean earlier, I talked about this idea that for me, you know, one of the big words is trust like Sean was saying that you can give that person a task and you know that they'll accomplish it and they'll do it. And for me, that's important as well. But we'll have times where through the process of working through the path to promotion doc, I'll spend that time figuring out in what ways do I need to be more comfortable with giving this person responsibility? You know, and that's one of the big, big takeaways that Sean was talking about as well. But I try and avoid the feeling side as much as possible just to share an anecdote. You know, I've worked in other companies. We've all worked in other places. And I was right on the cusp of a promotion. But looking back, the cycle took way too long. And I was asking and asking and asking. And my manager was always just like, Yeah, we're almost there. We're almost there. You know, and it was always we're almost there, which now, you know, looking back, it's it was clear that there was something that they didn't trust or or that there was some reason why, right? But I try and get rid of all of those reasons as a manager that I shouldn't, you know, stop or prolong this process. And then also, you know, I talked with Sean and I used the phrase, and I mean it in a positive way, give the person as much rope as they can handle, you know, that they could hang themselves and not in a way that it's like, okay, you know, like you could fail, but in a way that's like, okay, show me that you can do it now, you know, and that's really, really important. So I encourage teams to obviously gut feelings are important. And if you feel like somebody isn't ready, you know, working through that and figuring that out, but getting as much objective data as possible and making it as uniform across the team. And one of the other things that we talked about, Sean and I, was being able to then identify, you may be crushing in your current role, but actually going up to the next level, you may start floundering, you know, and that's a different thing. Sean, do you have, do you have any ideas on that? Do you remember what we were talking about there? Yeah, well, I think one thing, even before that stage was like, you know, because you have this document that you're talking about, which I'm trying to get in place for all of my team right now. One thing that really sort of brings home is that I think, maybe it's not everybody, but certainly a lot of people and certainly me and I, you know, am a proxy for everybody in my opinion. Like, it's more fun to work on things you're good at, right? So like, if I'm good at something, I want to try and improve there. But like, when you're looking at someone's promotion, they might already be like, you know, easily passing the bar in some criteria, but in other criteria they've got work to do to get up to that level. And it's no good for you or for them to tell them to keep working at the things they're already good enough at. They need to come up to that level all the way around, and then they can go again on the things that they find fun that they find interesting and dive into those. Or if they're not so interested in the promotion, maybe they don't want to do that, but at least that they have the information available to them. Because I think that's something that I've sort of, you know, for me personally, like I said, like, you know, I work on things that are fun for me, and like, doing a promotion doc for all of my team isn't fun for me to do, but it's important for me to do probably because it's not fun to me to do, and I need to get better at it. Yeah, and for me to share in the support side, for example, leadership is a strong thing for a senior person in support, and that doesn't mean that they have to be vocal, or that they have to be doing lead type things, but thought leadership, and being a bastion of knowledge, and amplifying their reach. You know, that's a big way that I would describe leadership is amplifying the reach, and that's one of the things that I'm working with a lot on my team to help people understand that you have a ton of skills, but we have to work on the pieces that are going to allow you to amplify those skills across people, and that's just identifying those weaknesses, and the path to promotion doc, which again, like I said, it's literally taking the job description, putting it in a Google doc, outlining what are the things that you want to see that will say, yep, those are the pieces that will make me qualified to say that you have that experience, you know, and identifying, okay, these are the spots that I think are going to be good, or you already have, or this is where we need to focus, and looping back on that, and then identifying the ways that, you know, each individual can grow in those things, and it is difficult, it is, I agree with you, Sean, that it gets very difficult because you're like, you want to do the things you're good at, you know, but also you need to grow in these other things, and this kind of leads to this other side topic that Sean and I talked about a bit, with performance reviews as a place for promotions, but also promotions can have, can happen at any other time, and also for me just sharing this tidbit of the way that I've been thinking about things that has been a little bit wrong, so we have the compensation calculator, which has levels, junior, intermediate, senior, staff, lead, has these levels, and then you have the experience factors of 0.8 to 1.2, and the way that I've been going about it in my head, because I've also been treating experience factors as sort of a promotion or a proxy of you're going to get more salary, I'm expecting more from you, because you have more experience, this is also promotion doc, this is the way to get to the next level, you know, but also something that I've learned is that, or the way that I've been approaching it is that, okay, I will adjust a team member when they've reached the full mark, so if they're at a 0.9, when they have done all of the things to get to 1.0, which begs the question, what are those things, and in support I'm trying to define that right now, I'm trying to, I want to have a very clear transparent framework to just say like there should be no feeling based on someone's skills going in and what they're doing, it should be as clear as possible, but trying to identify that, what does it take to get from a 0.9 to a 1.0 and then what happens, and also the thing that I've learned, the key point here is that we have full use of all of the band, I've been treating it as you have to go from 0.8 to 0.9, but there's, you actually have, you can get somebody out of 0.85 and there's a lot more flexibility there to use compensation and to help level up in that way as well, so keep that in mind, maybe you've been approaching that differently, or I'm not sure how other teams have been approaching reviewing, and as we get into this review cycle which leads to potential compensation changes and potential promotions, understanding that they are oftentimes together, but they also can be different and separate, and that's an important thing. Sean, do you have any last bits that you want to talk about here? Yeah, I actually wanted to ask you a question that I didn't ask you earlier, so yeah, let's do it. You're on the spot, so one thing that I think about a lot is that as a development team, we use the word senior in a way that, like, so the word senior developer can mean different things at different places, at some places it means, you know, you stuck around a couple of years, good job, at some places it means, like, you know, you're like super awesome, like, you're getting paid a ton of money, like, you know, you're basically leading stuff, like, there's not really a lot of consistency with that, and I think certainly in the development side of that, when we say someone's senior, like, we, we mean it, like, we take that seriously, and that's good, because every single one of our senior developers is incredible, and, you know, we don't have anybody at that level who, you know, like, drags it down, like, they're all above average, it's like, Lake Wobegon, but that does mean that for someone to go from intermediate to senior might take a long time, and how do you manage that sort of, those expectations around, like, the time frame of this, how do you, like, get, tell people, like, you know, this, this doc could be with you for, like, years, potentially. Yeah, yeah, yeah. I think that's a, that's a good framework. I think for me, the way that I've been approaching it now is, most of my team is, is close to or near transition, but if I was thinking about somebody who had a long frame, I might chunk it out into this is how you gain more experience factor, just to give it that shorter term time frame, you know, because there's definitely other levels that they can level up on, on their way to senior, and I think the big, the big takeaway there is making sure that there are short-term goals, those short terms might be the next two weeks or the next three months, you know, depending on your time scale, and then a bigger picture goal, so I think that that's important, but yeah, I definitely agree that, and something that I'm holding dear as well is that, you know, senior means something here at GitLab, it's not just tenure, it's not just you're good, it's a, there's a lot that comes with that, and that's important as well to to make clear to the team exactly that, that it could take time, and the one piece that for me, that on my side, the way that it's been working really well is, when you give someone that doc, and it basically puts the ball in their court, they can run as fast as they want to, you know, and if you make it clear, like these are the pieces that you need to work on, and if they're super motivated, they can go quick, you know, and in theory, they may be able to move quicker than you expect, depending on how motivated they are, and that also is a signal to pay attention to, because then you can gauge, okay, they're not moving on this as quick as possible, what's a shorter term goal that I should give them that will help reward them with compensation or some other recognition that will help them level up and not feel like it's just so far away, because there's definitely layers, you know, and you're gonna level up as you go through. I think the answer is no, but I just want to call it out, I don't think you would use a bonus as like one of those short-term goals, right, like bonuses are completely separate from like this process as it is, like, you know, if someone's working towards a promotion, but they're not quite there yet, and they're working towards intermediate goals, that doesn't mean a bonus, that's just a you know, a bump in experience factor, like you said. Right, right, I would treat it more as a bump in experience factor and defining that and making it clear, like, if you own this and run this and launch this and do this in this way, that to me will signify that you've gained experience and we'll talk about it and we'll do this, and then that process and working through that, and then say, okay, you have now gained more experience, we'll adjust this experience factor accordingly. I wouldn't particularly use a bonus, because it's just that spot thing and I'm a little bit just personally, the way that I run my team, a little bit anti-bonus, you know, it's to me, it's one of those things where it's just like really special. I treat bonuses as like a wow, you've done something like crazy and that was, I hesitate to use the word heroic, but that was like, wow, that was like, okay, yeah, yeah, bonus, done, wow, okay, but I like to build more of a, like you said, a process and something that's more regular and something that's more structured, whereas the bonus, that spot nature of it, I think doesn't necessarily act as a good goal, because then you would motivate the person by saying, okay, if you do this thing, you'll get a bonus and that to me doesn't feel like that shouldn't, I don't think that's the way that we should go, but that's a great question. Lee, I have a question now that you said this, like if I understood you correctly, basically what you're saying, you level up people on experience factor and a couple of other factors and you don't like using bonuses, but how do you actually recognize good work from people who are making a lot of waves and, but they are still not there to get the promotion, they're definitely still not there to get that experience level up, but they have achieved something in the period and they have made a change, like how do you recognize that? I think, yeah, I think you're spot on, I think that if that is the case, I absolutely think that that is a bonus zone, where it's like you are halfway between everything, you're doing great, here's a bonus, the way that I, the way that things are playing out right now in my team, I'm not finding that to happen at the moment, I think that people are able to, I think it's just a nature of the way support works, I think that once you get it and once you could start troubleshooting quickly, you can start to level up and gain experience on now you've got LDAP and CI, like you've debugged enough of that, that you can kind of get more experience factor, but I completely agree on the dev side that that may be much longer of a process, so I think that in that space bonuses make perfect sense, and that's great, this is good, there's a good feedback from me, because I'm like, bonuses don't usually play out in support side, based on the way that the team is operating right now, but learning more about dev, it seems like bonuses fit really well to give someone that bonus, who might be intermediary, so great question, Martin, I love it. I've got a question as well, so someone messaged me this on Slack, I won't say who, because obviously this will give information about people in the teams, but it's certainly a problem people in various teams have, and I think maybe this is more of a question for Abby than for Lee, but if you have someone who's red-circled, which in GitLab terms, in case anybody's unfamiliar with the term, means that basically either you are hired before the calculator, or something's come up so that what the calculator says is your level is actually below your current salary, and in that case we don't currently give raises as raises, we give them as lump sums, how do you manage that, because if someone's in that position, you can only give them lump sums until they increase level, which as we've talked about, might take a really long time. Yeah, I will try to answer you, because I know that this is kind of links back to the whole trying to improve the compensation calculator in the first place, which is something that obviously we're working on, and we'll continue to work on. The simple answer I have for you is I don't know at this point, I think we don't want to continue with that, because obviously it's not very, it's not a good process, it was something that we need to fix. Okay, thanks Abby. Yeah, I just wanted to get that out there, because I think it is definitely a concern for... Yeah, I know it will come up again, and we ran into this before, so yeah. Yeah, and obviously we're working on the calculator as well, so I know that too, but it's an important point. Also, I wanted to ask, I don't know, maybe another development lead, maybe Marin or Andrew, because I know they've done some promotions recently-ish, and I think Jacob has as well, or maybe that was Tim, someone in the front-end team got a promotion recently. So when I said feelings-based, what I mean is I've tried to, I've just created an MMR to try and capture this, but a lot of what we do when we review things is qualitative. That's not to say that it's undefinable, it's just that it's, you know, it does rely a lot on judgment and taste, certainly how I feel, and like, you know, when we review code, we rely a lot on our judgment and taste, and we provide guidelines that those mostly come out of judgment and taste, rather than coming, you know, those mostly get extracted, rather than like, you know, you don't inherit those guidelines, you take your taste and you discuss it with the team and you provide that as a guideline. So I'm curious about how you two, well, anybody who wants to jump in would go without that. I think like what Lee said in the beginning about trust is a lot of it. Can you guys hear me? I don't know, I'm on a different, yeah, and you know, I think a lot of it is basically, is particularly with the senior developer, it's, you can give that person like some work and they'll run off and you can kind of trust that they're doing it and they're going to get it done in the right time, and it's totally about trust, and I saw your major question, I really agreed with all the points, but as you say, like, I don't know how you quantify trust, it's like a thing that when you ask someone to do something, if they have any questions, they, you know, they're not clear about something, they'll come back to you straight away, and you can just leave it with them, and you don't have to manage them. So I agree, I think it's quite difficult. Most of my team are intermediate developers at the moment, and so this is a question I'm thinking, like, at what point are they going to be ready for that promotion? In each case, I've got basically a document that's got the what it takes to be a senior developer, and you know, every few weeks they go and update that with things that they've done, that match that, and I find that works really well and and helps motivate them. And obviously, yes, the code style is very much subjective, and you know, someone can agree and disagree with you, but what I think people in general should mostly agree with you is the things we have in our handbook. Like, for me, a senior has to be almost one-on- one with what they have for our culture, so embodying transparency, embodying, you know, like all of the other things we have, obviously diversity is a controversial topic, so I'm going to skip this one, but once we have a path for that, that is going to be a thing that I'm also counting on. So not only that you give a task to a person and they run off with it, it's also that trust that you just said, like, when they run off with it, that they can actually work within our handbook and within our culture values, so making sure that everyone is informed, that you escalate in time, that you're transparent, and that you're considerate of others, so and believe it or not, a lot of those things can actually be measured, and for most of those things, it's very hard to achieve them very quickly, so you need some time to actually get into all of those. I want to take a quick second to jump in and talk a little bit about actually, we've been talking about intermediate to senior, which I think really does apply as well, but on my team, I've had two instances of a intern to junior or a junior to intermediate as well, and that was really important because if we think on that, it helps us to see what the differences might be from going intermediate to senior, and someone, so for example, I've had two internships now, and the first one I think worked, but was not well-defined, and I think that in that space, in the second internship, what really, really, really worked was making sure that the person knew where they could get help, making sure that the person knew that the pieces that they were responsible for, and then it gave them a floor to run with things, as if they were on the team, and learning more about them, and building that trust, and then transitioning up, so that was, you know, just thinking back to that, that was really helpful in setting the scope. I think the big takeaway here is to remind everyone, just setting scope, and like Martin said, values, alignment, super helpful, so, so, so great, and on both sides, on the junior to intermediate side, and on the intermediate to senior, figuring out ways to show those values, and measure those values, means that that person is going to find success here, and I think that, as leads, we all are figuring those things out ourselves as well, and it helps to set the tone. Yeah, I think values is this huge one that I was thinking about a lot during the reviews, maybe because it's one I care about a lot personally, but is also, I think, critical to the others, is transparency, and I found that with that, because of the nature of what the value is, it's super easy to give people good models to follow, because like, if someone's being transparent, it's really easy to see that, because they're being transparent, right? So I'm going to call a couple of people out who aren't on this call, who I thought were really great models of that, because I've been sort of telling people like, you know, look at what Jarek does, he's in Seth's team, he's just awesome, like, you know, his level of documentation, his level of detail that he goes into when he does something, is amazing, like you really know, you get the whole context, you don't have to go digging around to figure out, like, why he did something, and another one in Dower's team is Nick, who works on a bunch of different things, does them all really well, but also, like, again, provides this amazing context, works really well with people on the issue transfer, even if they're from the community and they're reporting a bug, it's just, you know, really easy to see that, because you can see that in public, because it's transparency, and I really like having those models to show people that, like, you know, this is what it looks like, you know, this is how you do it, and I think it's probably the same in other teams, it's just maybe not necessarily publicly visible, like, you have to say, like, look at these tickets and how they handle them or something for the support team. Awesome, anybody have any other questions or things that you feel like we didn't touch? Ask the hard stuff, let's do it, let's dive in. This is all for us to learn together, so feel free, if not. Can I ask a question? Yeah, go, Abby. I'm curious to know if any of your team members have come to you with their promotion doc already prepared and saying, this is it, I'm ready to go to the next level. In my team, not independently of telling them that promotion docs were the way that we wanted to go. Nobody had prepared one prior, but now that they're prepared, they're moving along and it's working great. I don't know if any other teams have examples of that. Nope, my team didn't even think about promotions or anything, so I'm for it. I did have somebody before we did the split, somebody that did keep asking over and over when, you know, when am I going to get promoted and here's the things that you lined out that we need and here's where I'm at and all that stuff, so that person did eventually get promoted, but they did come and they were like, you know, on it and they did not drop that they were like, let's do this. Okay, I'm just interested because we say that, you know, people should take control of their own career ladders and things like that, but I think sometimes that can be difficult, so I was interested to know if anybody has actually come forward and said I'm ready. I think that that, along with all the other things, embodies the kind of senior or more advanced situation because when I think of senior, the thing I think of is like you guys were saying, but I always think of it as called self-sufficiency and it's the question of whether or not this person is going to be doing the things that you would normally do for them, so and I think I was going to say before, the one thing that I feel like for developers at least always comes last that really is like the switch where you say this person's ready is time when they can accurately, not necessarily accurately because it's so hard to estimate, but when they can more accurately estimate their time or when they start taking charge of the time that they're going to spend on something and say this is not going to make it in or and they're really early about it and they start to like really gain a sense of that and they have all the other things then I usually feel like that is at least one of the big things that I like to recall. It's like what would I be doing for them and now what are they going to take on themselves? Nice and also Abby, I'm laughing now because I forgot, I did that. I brought that to Ernst, I looked at the job description, I outlined it, I outlined the things that I didn't think that I had, we worked on a plan to make sure that I showed those things and then we did it. So in poetic form, yes, Jacob had one and I had done that and I think that that's why it works really well. Yeah, actually I remember that I did something similar only without any documenting, I just pushed my way into making a theme for myself. Bring force, I like it. Which ever way it works, right? Awesome, anybody have any last questions here? Cool, I love this one, great format here Abby, this one was a fun one, let's do more like this, more conversations team, I think this was great, I love this group, I think that this has been really helpful for me, I've gotten a ton of ideas as well through these sessions and we're going to keep getting more, so this is awesome. Great, thanks everyone and thank you for, I kind of like this one because it was all the development managers which was very interesting for me to have you all in, all in one place near enough. I would love to, I would actually love to see yourself. Yeah, me too, it would have been good if if there were, I'm sorry, I think we're both off. I was just going to say it was a shame that there weren't some other managers from other teams here as well, but I think I mentioned already that development is kind of the place where most of the promotions happen, so it's kind of, in a way it kind of made sense, but yeah. Next time I will, I think because most people are in the European time zone over here which is another reason why there might be less people from non-development world, but anyway I really enjoyed it too and thanks everyone for joining, particularly on a Friday afternoon, I really appreciate it and yeah please, anything that I can do further I will do and I will carry on and schedule these until you tell me stop. Have a good rest of the day everybody. Thanks Abhi.