 Hi, I'm Sid. I'm the CEO and co-founder at GitLab, and this is an AMA where team members at GitLab ask me preferably hard questions, and I try to answer them. Hey, Sid. Just wanted to get your thoughts on the early returns on the CEO shadow program and how that's, you know, living up to your expectations and what the plans are for that going forward. Yeah. Better than expectations so far. So the goal of the program is to make sure that people, more people at GitLab have kind of a global overview of the company and understand like how everything fits together. What's been ahead of expectations has been the collaboration with the executive team. Someone's mic is open who's typing. Executive team has, every single member has allowed the shadow to join their conversations and follow like 95, 98% of the conversations. So that's been really, really good. So they get a lot of access. It's also been very, it's been fun, like Erika published a blog post yesterday. You can read it about our COSLA visit. I thought it was an excellent output of it. Michael, who I'll give the word later, I was the current shadow. He, for example, yesterday he did a red team exercise and at six o'clock he was at a press event telling journalists about what he was doing and like representing the company in a very positive way. So it's it's been really good, but I want to give it to the word Michael a bit about how she what's it what's it like from his perspective. So from my perspective, it's been a great experience. This is what my third week with GitLab first week I, you know, you know, requested to be a part of the shadow program and the next week I was out. So it's been really exciting and very humbling. Overall, I feel like I've learned more in the last week on the shadow program and at GitLab alone with versus the last year or so in my previous position. I think that is also that's due and very, very highly because of the shadow program. It's kind of like, you know, I've already known I knew how to manage people, but now I'm observing Sid and his management style and how he solves problems with people. And I feel like every day it's I'm learning a lot more very rapidly. I'm starting to understand the reasons why there's certain management styles and ways you want to actually track things and build things. But overall it's been an excellent experience. I feel like I've grown leaps and bounds and I'm really looking forward to the next two weeks. So, yeah. Thanks, Michael. Next question is from Simon. Simon, you want to verbalize your question? Sure. So this the context for this is a customer, a large customer in EMEA asked about just some high level, instance-wide statistics about the code that they have in GitLab. And I just wondered if we could take it a step further and start looking at code analytics. The idea being customers have their code in GitLab. What actionable insights can we surf this to customers from the nature of that data? Yeah, thanks for that. And I'll screen share. This is the issue you refer to with code statistics. I have an opinion and I wrote that up three years ago, 2015, that was a busy year. But anyway, I think we should have great code analytics in GitLab. We should show a lot of things that are actionable. So it's always very important that when you have analytics, what is the action you take? So it should show code coverage, but also developer churn code hotspots, burn down charts, bus factors, test coverage, books for certain pieces of code, complexity, like cyclomatic complexity, code added in crunch time, how many people worked on something when things were modified, especially if you work with lots of contractors, these things are super, super useful. So I think those are things we should help our customers with. And I linked to the issue from the agenda. So just out of interest, just as a follow up, what's the main use cases for those analytics? Would you say is it around managing developer productivity? Would you say it's one? That's an excellent question. So you, for example, developer churn, you want to see, hey, which are the teams where many, many different people are touching the same piece of code? That probably means that you have a problem keeping people on the same project. So in some companies, developers are viewed as interchangeable. And they, depending on like the priority of that month, they work on a certain piece of code. With that, you get reduced stewardship of that piece of code. No one's really owning it. No one is responsible. No one is doing the final peer review. There is not one view in which it's made like one mental model. So you get like a spaghetti of many mental models. So it reduces the quality. So you want to preferably see not too much different developers doing it over time. At the same time, you don't, you don't want too few. So that's the buzz factor. Like, hey, if there's a certain part of the code base where there's no other people, that's not a good sign as well, because that means that if one person leaves or is, has to do something else, suddenly nobody knows anymore. So you don't want it too high, don't want it too low. Code hotspots is where you see frequent changes. That's, that might be an indication that that piece of code is very complex and has it has too many responsibilities. So you want to reduce that maybe split that off or find another abstraction or use a DSL or things like that. Burn down charts, much more about like productivity. Like, are we getting enough done? Obviously, these are just indicators. So your lines of code are an indicator, but never use it as a final metric. Test coverage, the higher the test coverage, you assume it's more reliable. Issues open per key for pieces of code. Like if you have code, which has a lot of issues open for it, there's probably lots of bugs in it. And it's probably code you should consider refactoring. Cyclomatic complexity, the more complex, the harder to understand, you want to reduce that in general. Code added just before releases. That's like crunch time code, like that. There's something wrong that all of a sudden we have to fix this just before we do a release out. So and when pieces of code were modified, it's something you see when you have assignments where you have contractors on something for a month. You expect kind of changing that code over the month. If you only see it in the last week, probably something is going wrong in the process. It should be evenly distributed over the assigned period. If it's only happening in the last week, there's something holding them back from working on it earlier. And that's not a good thing. So thanks for the question. I hope this was insightful. Well, insightful. I hope this was useful. Definitely. Thank you. Hey, Sid, I'm just wondering what scares the crap out of you. What keeps you up at night in regards to GitLab? Yeah, thanks for that. I get a question a lot. So I'm starting to write it down, but I haven't done a good job of posting it to the handbook yet. So it's open here in my editor. Biggest fears. Scaling, lowering the hiring bar, onboarding, we have to onboard a lot of people and kind of extra layers of management. Lowering the hiring bar, what are we doing to prevent it? Reviewing new hires like bar raising. Now me and Carol are doing that. Comparing titles, making sure we have a good grip on the performance and we identify it early and we take action. I'm typing as we go because I have to get this into the leadership principles. Onboarding. So what's the onboarding time? How long does it take? Do people get productive quickly? Well, for developers, do they start contributing? And salespeople, do they ramp up? This is a misspelled value survey. I can spell. But do people think that our values are used to kind of promote people and give people bonuses? Extra layers of management like do have directly responsible individuals? Is there clear job family? Is there clear org chart? Is our open core model working? Is there velocity? What we're shipping? How many contributors do we have from the wider community? So those are the things I... Those are the biggest fears and what we're doing about them. If people think that there's different things I should focus on, feel free to speak up. Lyle, you want to verbalize your question? Yeah, sorry, I was in the middle of typing. I just wanted to talk about gitlab.com and in the handbook we have a thing that says gitlab.com is not a role. Do you think that's still working? Is gitlab.com sort of like the future of gitlab? And if it is, does it make sense to make gitlab.com a role? Yeah, I think that's still working. So the future of gitlab is gitlab. It may be a bit of Meltano. Gitlab.com is just a different way of delivering the same product. It's different packaging, should be the same product. And for example, like of what not to do, I saw a vault issue yesterday which said oh we'll have vault for gitlab.com but we won't add it to our self-managed installation. Okay, well the idea with vault is to make sure that people in gitlab have a secure... People using gitlab have a secure store for their secrets. Like you add lots of secrets to gitlab like Kubernetes credentials, environmental variables, all kinds of sensitive stuff that you want to be a very good steward of. If we ship it with gitlab.com but not with self-hosted gitlab, we cannot say hey everything that's sensitive in gitlab is going to go into or everything that's sensitive, everything that's a secret will go into vault because we get this split between the two products. So we really want to prevent that, I want to keep it. The same thing, just different packaging. Just like you can... I can get my hair gel, I can buy one packet at the drugstore or I can buy a six-pack at Costco. It's the same product, different way of delivering with different implications but if we start making them different products we get into a world of hurt and we've seen that at our competitors where changes take an extraordinary amount of time because we have two versions. We've seen that at gitlab, we got a CE and an EE distribution. We all know, well we all know it's a lot of pain. If you ask people in engineering they'll say yeah it's a lot of pain and we're now doing an enormous effort to bring the two code bases into one repository. That's how it is if you let them do different things, you'll end up with that inefficiency again and want to prevent that. We do expect that .com will grow over time. People want to consume software as a service, preferably they don't want to be running it and you're now seeing the first big customers there. Will that go all the way? I think that's unlikely. I think we'll always have people that host things themselves. With Kubernetes and those technologies it gets easier to self-host things and with new regulations there's more pressure to be a good steward of any data you produce as a company. There might be a movement where people take more things in-house. We shouldn't bet on any future. We should just make sure we have two great ways of distributing gitlab and anything we do like for example collecting feedback from our users should work the same way in both products. I guess sort of my concern here is that .com kind of breaks the model of self-managed where an admin user on .com doesn't have the same admin privileges. They can't do some of the same like some of the self-service things that they would expect to do on the self-managed version and so I'd like in the hair gel model it's sort of like you can have a squeeze hair gel or you can have like a pump. It's the same stuff inside but it is subtly different. I like the squeeze in the pump. Yeah I agree it's different and what we're seeing is that a lot of the things that we have on an instance level we're now adding on a group level and we're seeing that for example with any templates and in Kubernetes clusters with single sign-on with SAML. Historically we had most usage on self-managed so we added things first there and we're now adding the same things to .com and probably we're going towards a future where there's very few things that you can do self-managed that are still relevant for .com but you can't do there even though you'd like to. I think that's almost going away. I can't name any example where that's going to be a permanent future. John want to verbalize your question? Yeah I was just wondering if you're still receiving your CEO mentoring and if so what's some good advice you received recently maybe around scaling the company? Yeah I am the name is Dan Levin he's the old COO of Box he's an awesome person and the nice thing is that COSLA hired him just to do that and it comes with the COSLA package so we're not paying for it separately we're not paying for it at all like these people invest and help you obviously when they invest they get shares but it's pretty nice of COSLA to still be supporting us so many years later after the transaction and it's it's been really good What are you talking about? I think there's a to scale a company it's a lot about consistency so we talked about hey the process for updating job descriptions should be very clear. How do we do bonuses? What's the size of the bonus pool? How do we determine that? Do we give everyone the same or does it depend on the individual performance or not? Do we do yearly bonuses? Are we measuring if people on a PIP in 50% of the cases they should still be at the company after a year? We want to make sure that PIP performance improvement plans are not the end of the road but they are like survivable and you can be successful at the company afterwards. We dove into our termination numbers involuntary voluntary termination numbers. We looked at hey do we want to give everyone the same refresh or do we want to give half the people a refresh or do we want to do something on top for high performers? Promotions are the promotions evenly distributed throughout the company. What is the number it should be? Probably about 30% of the people in any year should get a promotion but it's very important that it's distributed evenly, that there's not so many managers making much easier to get one and some managers making it almost impossible. We reviewed my calendar and he noticed a few things. First of all I wasn't in a lot of staff meetings which is unusual but I see as a good thing because I don't want to be in people's hair too much but one thing that I did change is that I'm going to do skip level meetings. So I'm going to meet the reports of a manager without the manager present to hear what's going on in that department. He's going to maybe do a training program for GitLab and he's going to try to do that remote so that's great. Talent retention program, identifying high performance and things like that. So lots of things. All the things I talked about were just exploratory discussions like I am not announcing any compensation changes here on the call. It's just that we, composition is really important to get right and especially as we scale I want to make sure that I know what all the best practices are and I know what I want to learn from experience of people who did it really good at scale. I think I'm up next. You kind of hit on that and I think the term is actually skip level versus level down but I guess my question is what do you anticipate or what do you most want to get out of those? Yeah the term is skip level. Thanks for that Derek. I think there's a few things. First of all as the CEO you tend to be the last person to know like your information you get is filtered by many many layers before it reaches you. So I want to get a get a heads up if there's a problem in the company a bit earlier. Also it's a way to to kind of see whether there's there's something that that can be improved in the performance of the executive. So it's also a way to like hey how can I I'm the manager of the executive. I try to like give them feedback. This is what you can improve. This is what you should focus on but I don't have a whole lot. I haven't some input on how they're managing up but I don't have a whole lot of input of how they're managing down. So this is to get more input for like to help them coach them on the managing down. Cool thank you. Derek I think you have the next question as well. Uh that should be the same one. Ah so cool thanks for that. Those were all the questions. Thanks everyone for joining and have a great day.