 friends, get labbers, countrymen, lend me your ears. Today I have a support functional group update for you. Give me a second to share my screen. I would normally be doing this with two screens, but my second screen seems to have comped out on me today. So I'm going to need some help to make sure that you can see my screen so if I can get a thumbs up, you can see my screen. Alright, golden, great. It makes me happy. And then I'm going to go ahead and share my screen. Now I'm in the deep end. I'll see you on the other side. So I want to talk about a few things today. We'll touch on a few topics. The center right there will be the meat and treat us on time. This will be a challenge for myself and yourself. I want to think about that. So look forward to that. And then I'm very excited to hear what questions you have for me at the end. So let's see what we can get into on the accomplishment side. I'm really excited about the energy on the team right now. There's a buzz. We're trying to really morph into the next evolution of support at get lab. This is happening on both bands in support. We have support engineering, and we have services support, and both are trying to go through radical transformation to be very different organizations in a positive way. One of the big driving factors there, support fix on the support engineering side. That is super exciting. This is support actually getting in doing engineering, doing fixes. And I've been interviewing a lot of candidates and people talking about how in other companies that's restricted only certain people can commit to the code base. And this is really an ideal at get lab where everyone can contribute. And we want support to contribute and solve problems, not just be a customer interface, not just help get things to dev, but actually say, I can fix that and be empowered to do so. One of the other really exciting things right now is we're exploring support ops, TM. I'm trademarking that. If you don't know what that's about, stay tuned. We'll talk about it. So I want to transition and talk a bit about our historical graph. We've been using this backlog. If you're new to get lab or never seen one of these, this is kind of the heartbeat of what support does and what it looks like. The goal is to get it to zero. And here you can kind of see the tail in one line of what we've been doing, right? We've been trying to push down, but we've been not able to. But this is a good thing to show that our team is just too small. It is not totally blown out of the water or it's not completely getting outpaced. But the fact that we're able to hold this shows that we're just the right size, but obviously we want to push this down as hard as possible. We want to get to zero. We're pushing as hard as possible to get to zero because one, that's incredible. And two, that frees us up to be a lot more flexible when we have pushed down as far as possible. So going into the future, we're going to be deprecating that graph. And we want to deprecate it because we're thinking about support now, not just from the overarching perspective, but again as the smaller bands that are moving much quicker. Services and support engineering. So we want to very much think about it in that way. So the overall view helps, but I don't think it helps as much anymore. And we want to go ahead and iterate and get better clearer graphics. On the graphical front, this is on the services support side. You can see that with high impact hires, Lio, Namho, Arihan is also working in this group here. We've been able to push up our services support experience for Git host and GitLab.com customers as dedicated focus process improvements and attention. Look how much we've just been able to push that up. Very, very, very excited about this. We also driving that, you know, in November, I took a look, grabbed some tickets, made a made a graph, right and took an idea got an overarching view of the problem. Lio's come in and through his dedicated effort, you know, took a two week sample over the last four months and started diving in and really trying to understand what is driving the ticket creation for services. And this is exactly what we need to be doing, because he is now focusing on building out process, because we're about to bring more people in. So once we have our next take on process, it needs to be iterated on. Then those people can start applying it and growing it and we'll go from there and iterate and grow. So it's really exciting to see Lio diving in and understanding what are the pieces that our services customers and users are facing and how we can better fix them. So that's something on my mind. Now, this is another services graph here. This is just a dot com free users. And as you can see our SLA here is not rising. We've been focusing on our customers. We have to put our customers first in the short term. But Lyle and I are working on plans to make this rise as well in the long term. So bringing in three new hires. We have three hires in the late stages. We're trying to close or pushing to close them by the end of the quarter. It's one of our goals. Very excited about that. They're going to drive the customer SLA to 100. And then we're thinking about how to drive the free user experience up to 100 as well and start pushing beyond that. So very excited about that opportunity coming forward. Now, this is the self hosted side, which is support engineering is responsible for this. We had this bull run happening, which was really powerful and empowering. And a few weeks ago, we had, we had a couple hundred percent days, right where we hit 100% of our SLAs those days, which was awesome. And then we were in the high 90s, which was incredible. And then we had an incredibly hard taxing challenging week that put us behind and extremely dipped us as you see here. And that has been pushing us. We've been pushing back up. But that one hard week, right, just put us in a place that we were behind the eight ball. And that's something that we're trying to better understand how to prepare for those peaks, because in the average we're doing well, but if we have a spike, what caused it, and how to affect that better. So we started building out some new graphs as well, because what we're noticing and what we're thinking about is premium versus starter, the difference in SLA premium being four hours starter being 24. We have to give premium focus, but we have to balance that with starter, and we have to figure out the ways in which we can say we're providing consistent experience to premium customers, but they're also not zapping all of our attention, all of our energy and making that balance. So this was a graph that we started thinking about, which was, you know, over the last year, what does our premium ticket volume week over week look like. Each week, how many tickets were created and you can see we're dealing with more premium tickets per week, pretty much as we're going forward. And then we also are thinking about our premium comments per week. And obviously they should track, but the reality is this bottom graph here this week over week, the ratio should be a horizontal line. And what does that mean, that means that if the ratio is a horizontal line that our experience is consistent across premium tickets going forward that we're not inflating we're not pushing out tickets and things like that. So it's one of these pieces that we think we can use this metric to say, if this, you know, you can see this line has been subtly going up, we can use this as a proxy for training. We can use this as a proxy to just say, if we are well trained, if we are well prepared, this line should be as horizontal as possible because premium tickets coming in, should it be any kind of surprise or anything like that. So we also took a look at this in the short term, over the last 12 weeks, and we implemented this graph around week seven, and we put a target around five. And as you can see, you optimize for what you measure and starting to measure this and starting to think about it. We've already started to drop this right so we're pushing that down, which I'm really excited about to understand is this the right metric and a good metric that will help us say, yes, premium support is stabilized, we're comfortable and more confident operating from a position of strength. So this is something that we'll be paying attention to. Now, to think about time. I have gone insane. My entire mind has lost its place in time. And the reason why is because if you are here with me right now, we are sharing a moment in time. There's a different moment in time, based on your reference point, your clock may have a different number than mine, but it is the same hour now if you are watching this on a recording you are watching this in a different hour on a different day. We have to think about time as what is it, right. And the reasons why I say that are, there are 39 time zones in 24 hours, right and does that affect our numbers and things like that. And what is a solar hour and how does time move across the world in a way that we can represent coverage and ticket volume so this graph here is an attempt to say, what is the global map in the background. That is an attempt to say, this is our coverage, our possible peak coverage in any region. Right and you can see that West Coast America has the possible highest number of coverage in all of our regions. Right so that's one piece here one component that we're trying to model and represent. You can see our coverage map and what that means is right people starting on the East Coast Americas will go and cover into West Coast people starting in the West Coast will cover there and people even starting in Australia will cover some of that West Coast which gives it that strong dark purple. Now, the ticket creation was the hardest part and Alex S and I from the support team have spent a lot of time yesterday about 30 minutes diving in and trying to understand is this overlay correct. This map effectively where the ticket came from. And that is the hardest question, because we have a time that the ticket came from, but that doesn't necessarily mean a location, but that does correlate somewhere because things happen and time moves. And we have to understand so this purple. The purple is our coverage. The orange is where we think the tickets are coming in. As a reflection of that coverage over the last 90 days the volume so you can see a majority of our volume comes in in the Americas, right and it bleeds into a pack. So we're trying to put people in front of this volume so that they can rise into it, but we can also put people behind this volume to act kind of as a sweep, right and to to act as a cleanup a goal if you will. So take this graph. Imagine if we hire four more engineers to in a Mia to in a pack. This is what this graph would look like. And this is our vision. This is where we want to go to right so to give you an opportunity to see that one more time, just adding four more engineers in strategic locations right this is what it'll look like and this is what we're really excited about what we need a Mia coverage will really push us forward. This was something that was very important for me to get because I think that it now shows us just the real need and where we have to focus and as we grow this may change. So we're looking to double our team size over the next year so this we want to get everything to purple we want that entire globe to be dark get lab purple, right, but we also have to do that in a way that in the short term, we're not just hiring anyone we're hiring strategically to make impact high impact hires. So that's something we're thinking about. On the challenges side, Salesforce, Zendesk, they work together to help us deliver SLAs there are problems with that. But we're really starting a ton of momentum. We have a crew together with UX and product Diana, Sarah, Jeremy, myself have been working together and are going to meet to really make this very robust for our customers to make the SLA experience. We're going to start tracking where our system is failing so we can understand that integrity, right, and that comes into support apps. So that's really exciting. That's one of the next things that I want to talk to you about support apps being how can we automate using CI using GitLab based tools, chat apps, all of these things. How can we automate so much and you know get us this green checkbox to say yes, everything in Salesforce is in Zendesk, or if it's red, right, we go on high alert and we immediately fix it and that happens in the background every day. And we can start to understand from both sides Zendesk Salesforce where things are failing and how we can build tooling to improve the support experience. And this is something that I've talked to the support team about support can be improved through technical expertise improving customer experience through technical expertise. That's our vision. That's our goal. So I challenge other teams. What can you do better? What can you make more programmatic to solve your problems so that you're not toiling away. So on the goal side, I want to point out that we want to use support apps to guarantee data integrity. We want to start thinking about premium tickets, their ratio as a proxy for training. And we want to start really working closer with Tams. Tams have ramped up really quickly and are providing a lot of value but the bridge and the workflows are very disjointed right now. And it's because they're new. It's nothing beyond they're new. Now we just have to start coalescing and working together, bringing those gears together. So I want to stop my share and get a chance to look at some questions. I see, I see 20 on the bubble. I'll see what we got here and go from there. So we got any of the new ones based in EMEA. I'm assuming that means hires. Yeah, so Lyle says yes. A question for Lyle. Joshua says what was the cause of the of the hard week of bad release. It didn't seem to be that it seemed to be customers trying to deploy GitLab on edges. Right. And what I mean by that is they're deploying with Kubernetes and they're using auto scaling runners and they're using AWS technologies and they're using very complex high technologies. So when one piece gets a little bit awry, you have to troubleshoot every single one to isolate the problem. So the stack starts to get really big. So it's one of those things that we're thinking about. And as Lyle says, it was 100 tickets, right? It was, it was just that many tickets and premium tickets are a huge train here. Toby says, so a lot of tickets from West Africa, right? So that's, that's the big question. We have to say the ticket necessarily doesn't come from West Africa, but it comes from a time that would be covered by West Africa. I think it's the right way to think about it. So this is something that we've spent a lot of time and this weekend I'm going to continue to meditate on this to understand. Yes, it seems so simple and we built graphs and we talked about it, but I really want to make sure that that is the core of our model and that we completely understand it with absolute resolution. So Kristen Lawrence asks, what is the services role in the support team? What does that mean? So that's a great question, Kristen. And the difference is we have getlab.com, which is a product which we are managing, which gives us a lot more resources and control. So someone who is in the services group, they'll be focusing on helping customers interface with that product. So those customers don't need to know how to set up a Linux machine or do a lot of the deep diving, managing infrastructure. Those customers are usually having questions like, hey, my commit is taking a long time to push. Can you check that out? Or, hey, I don't understand how to use the CI thing. Can you help me more? Right? So services is focusing on getlab.com and gethost, where we have the keys to the castle. And because of that, we have much more power to build tooling. And one of the best ways to think about it is that team can be a lot more proactive for the customer and be in front of it. And those learnings from that team will get back to the product, which will effectively help the support engineering group, which will be focusing there on the on-prem, excuse me, self-hosted customer product. Whereas traditionally self-hosted is a little bit more reactive, because we can improve documentation, we can try and fix features, but customers are deploying getlab as I describe it on the edges, right? A lot of our customers are really excited and doing very complex, incredible things. But that means that we're finding these edge case bugs and figuring those out. So the role is getlab.com support, gethost support. So any other questions here? If there are none, I will give a minute. If there are no other questions, we will wrap up. Thank you for your time. Well, thank you for sharing this time with me. The question remains, what is time? How does it work? And where will it go? Thank you all. Have a great Friday. Have fun.