 All right, by my clock here in New York City, it is 11 a.m. Eastern time. It is a different time somewhere where you are, if you are not here with me in New York City. So welcome to the April edition of the Support Functional Update. We do this once every five weeks and I'm really excited to tell you about what has been going on. We'll jump right in the top of the order we wanna talk about accomplishments. We wanna talk about the things that we are doing in support that are making our team better and GitLab as a whole better. So I've been paying attention to a lot of GitLab, just trying to understand how different teams are structured and how they're working and what they're doing. And I started to realize that most teams are broken up by specialty. If you look at sales, we have account execs, we have BDRs, if you look at engineering, we have front end, back end, platform, discussion, very specialized. If you looked at support, it was one big bucket and that started to feel like it wasn't working. So we have demarcated ourselves into two smaller teams. We're calling them pods and I'll get into that in a minute and you can learn more about them at supportissue477 and supportissue474. I'll talk more about that in a few minutes. Other accomplishments that I'll highlight in this call, we are more efficient than we've ever been, which is exciting and knowledge sharing, which is something that we need as a support org, every support org needs is happening. So that's very, very, very exciting for me. So let's dive in, talk about pods, not the 2000s band, even though that is our anthem, we will talk about what we are doing with pods. So there are two. We've split it up into EE support, which is customer based, all every customer that is EE, we have the majority of the support team working in that pod. And then we have a smaller group focused exclusively on Git host and dot com related issues. Now we are one support organization. So to anyone in GitLab, the pod demarcation should mean nothing to you. You can go to support, you can ask us, we're gonna answer. We're all still dealing with GitLab, we're all still who we've been. It's been something that we, it's helping us make our workflows better. But to everyone on the outside, come to support will help you. The reason why pods were important for me is because there were too many unknown unknowns. I started to feel like there were a lot of things that we did not know and we are not uncovering because we're just all working from this big bucket and we're fragmented and we're not focused. So that was one of the other reasons why we've developed this pod solution. It's also based on this idea and my support team knows this. I'm a firm believer in the leader leader model. It's from a famous book called Turn This Ship Around and leader leader talks about this idea of responsibility and ownership and clarity about what it is that you do and need to do. Pods are making that very clear. Those who are doing EE support know 100% that that is what they should be focusing on. Those that are doing .com and Git host related things know that that is 100% what they should be focusing on. And that is eliminating know-ups which are no operation, there's nothing to do. What we were seeing before is because everyone in the one bucket model had different levels of permissions. Some people had access to gitlab.com production, some people had access to Git host production, some people had access to neither, some people had access to some combination. And that meant a ticket would pop up, you would look at it, you might be able to do it, you might not be able to do it, you might pass it to somebody else. If that happens, we're already behind the eight poll. So by splitting into pods, we're making it more efficient and more actionable. So this is something that we're trying out until the end of the quarter to understand our needs and to understand what we need to do to make support better at GitLab, solving the unknown unknowns. So we're gonna regroup at the end of the quarter as one support org understand how things are going, if it's helping, if it hurt, et cetera, et cetera, and see if this is something that helps. With that, I always report on this graph, every functional update. And this week, I am very excited. Find an accurate account of true support backlog is the title. This is the closest we have right now. We're still diving in, trying to get closer, get rid of all of the cruft, but get to what is our real risk? If you look at this graph, you'll notice it's not flashy, it's not very big, but there is a subtle shift happening where we are shrinking the backlog. We are starting to shrink the backlog, which is phenomenal. I know many, many, many support organizations that I've worked at and friends work out that this takes a really long time to get a grasp of and to start handling. We are doing it right now. It is very subtle, but it's happening. And this is our job to, if you remember last functional update, we talked about risk and our job is to reduce risk. This is what we're seeing right now and this is what's happening. So that's very, very good. I'm so, so, so excited about that. This is huge. The graph doesn't look exciting, but it is absolutely huge. I've also been working with the support team and in many calls we've talked about this idea where I've been setting the tone, hey, I think at GitLab we can resolve most tickets within seven days. I really think that that's possible. And I wanted to see if that was true, if that was happening, how far away we were from that. So what I did was I looked at our Q1 data for all tickets that were created in quarter one of 2017 and how long it took for them to be marked solved. And this histogram shows each bucket is a week worth of hours. So we can see already the majority of GitLab tickets are being resolved within a week. There's a huge drop off to two weeks and then from there further out. And this is something that I want to focus in on and I'm very excited about because now I can study those, the bucket of two weeks, see what took them so long and how to get them moved into one week and start making ourselves more efficient. The biggest thing as someone who's worked in many support teams, the biggest most important thing is making sure that we're working more efficiently and not just harder. And this is one of those things where I'm gonna dive in and understand is it just the problem took too long to scope or the problem was very large or what was the reasons that we saw? What were the reasons that we saw for those tickets taking so long? So for sales, for other departments, understand that right now this phrase for the most part is true. Most GitLab tickets should be resolved within seven days, which I'm very excited about. That's awesome. And as we go forward into the future, we'll see what we can do with that number. But I think that's a very reasonable estimate of something comes in, something unknown, and within seven days, GitLab should be able to turn it into something actionable. I am so, so excited to share this chart, which I share in Functional Updates and I share weekly with the support team. Effectively, the things that I've been working on and trying to do is get us to maximum efficiency, which is resolving tickets that were created. And we need to keep up with the number of tickets that are created. And if you look at this table here, anything highlighted green means that during that week, we kept up or we exceeded the number of tickets created. So that's creeping into resolving backlog. So while it may not be as flashy as closing a new big deal or a new product feature, this is what we do. We solve tickets. And if you look at the last four weeks, we have been better than we've been ever before. And that to me is phenomenal. And that's something that I'm so proud of that this team is able to hit it. It gets scary because we now need to maintain it. But at the same time, this is something that we're doing and we're keeping an eye on and that this is essential to reducing the backlog and to providing the best customer experience possible. So all of these steps are coming together and the team is doing phenomenal, phenomenal work to make this happen. And we're not working harder. We're splitting things up. We're trying to work smarter. And that to me is the key to making support successful. The last piece to helping the support org get to where we need to be. GitLab is ever changing, ever growing. New problems will arise, new solutions will arise as we develop this awesome product. And what that means is we need to share our knowledge. So we developed a system where part of our Q2 goals are 15 pairing sessions between two service engineers, excuse me, support engineers at GitLab. So we've already started and we can see here people on the team, my team that we're pairing, we're sharing knowledge. And the real key that I explained to the team, the real win here is that this allows us to asynchronously work together where people pair, we debrief and I can review the debriefs and then find out if they're common trends or if they're things that need to be documented and working with other departments on, hey, DeVette and Abu Bakr shared here and they found this problem. We need help with documentation. Can you help us? Or this allows me to really pinpoint the whole cycle of these people found a problem, this is the problem, how do we get it solved and this is where it starts. So this is something that I'm super excited about. The team is doing them, we're having a blast and I'm tracking this and it allows me, other leads be aware, something that I struggle with all the time is making sure that I'm being an effective lead and having insight into what's going on. This allows me to just check in and see and see what people are learning and leveling up without having to be overbearing. It's a very natural process. You pair, you debrief, I can review them, we can work together and get understanding and it's been working phenomenal. Already I found three things that we need to document better and we're starting to get that and I have that insight so I can help the team solve the problems. So that's awesome. So I'm super proud of the support team for just picking this up. It was a crazy idea I had and I said, hey everybody, we're gonna pair a ton, let's do it and it's happening. So I wanna end with shout outs. I wanna shout out to the dev team as always, especially Dawa and Stan, you guys have jumped into crazy customer calls with me, especially also jumping in all the time to help with weird issues. We'll move the things forward faster than we've ever done before and that's something that we should all be proud of. Sales, you guys are selling premium, which is awesome. I'm so excited about that. With that, premium license over a hundred seats, there come trainings and we want to, we need to deliver these trainings. There is a little bit of a backlog right now so be understanding with us and set the tone that it might take some time for us to get into those but we're working on them, working with customer success to get those delivered so that is really, really, really awesome. So team, keep it up, so excited. Support has been moving, we're getting more efficient, we're getting more clarity and those are the things that we need. Like I said, what we do may not be super flashy but we solve tickets and we're doing that and we're doing that better than we've ever done before. So I will open the floor up to questions. I'm gonna look in the chat really quickly and see if there's anything that anyone has for me. Okay, let's see. What do you think about cross-team knowledge sharing, pairing sessions, front-end team, expanding console leisure stuff? Yeah, Tim asks about how can we do cross-team sharing? I'm all in. The more the merrier, the more sharing we can do, absolutely that's something that I think we can do. It's gonna take an effort working with other teams to figure out how that will work. So let's explore that, I think it's a great idea and I made it clear to my team that if you pool in a dev and they're helping you solve a ticket and that's what you need, that can be considered a pairing session for our goal but the whole idea is just continue to work together to solve problems and contribute. Sid asks the question, how can engineering docs help to, engineering slash the docs team help to reduce the inflow of tickets? This is a great question. We're not seeing any kind of crazy uptick or anything like that, it's moving along. Tickets are in lockstep with customer growth, it seems to be, it's nothing, it seems to be spiraling. The biggest thing that I think engineering can help with is making sure that regressions are getting fixed and I sound like a broken record because engineers, you know, we've talked about this a ton so you've heard me say that a billion times and we're doing it, we're doing a great job but every regression is a case where it can bubble into 10, 15, 20 tickets. For example, recently there was a problem with LDAP in 9.0, I believe we first saw it, that it's the faster we can fix that, the less tickets we can see about it. But that said, the support team is doing our best to identify problems and then correlate issues to tickets. So even if 100 customers have that problem, we can correlate it to that issue and help dev like, hey, guys, get this worked out and I think that to be honest at the moment, that's the best way to go forward. Continuing to work regressions as fast as possible, which we do devs, you guys are crushing that, you guys are crushing that. So you guys are doing great there and support making sure that we identify them and get them worked on, which will, you know, some people may not hit it or may not realize and that's gonna help reduce the tickets that we're seeing. We have Jim asking, what is your trial of, how is your trial of Zendesk Enterprise going? ZD Enterprise is really interesting. We need it for larger customers that have interesting contractual obligations about privacy and data protection. We have signed on for ZD Enterprise, so it's working, it's solving our needs. Most of the features we used before, the charting and the reporting, we still have access to. So it was a core functionality. The one thing that we really needed was role-based support, which means that specific agents can access specific accounts and other agents cannot see any data related to those accounts, can know that those accounts exist, but nothing beyond that. So that is something that was the one piece we need. Sid asks, what do you need to switch to service desk? The biggest thing right now, the thing that I want to do, part of splitting up the team into pods, I want .com and Git host related issues to go into service desk. That's something that we have on our roadmap of, we have a good chunk of volume, but it's not our biggest volume. So that's something that I want to move and we're trying to figure out how we can move .com into service desk and Git host into service desk. That's something that's definitely on our radar. We're going to continue to focus on ZD for now for enterprise customers because it makes sense with the need for privacy concerns around role-based and things like that. But I absolutely think service desk in its current iteration can meet the needs of the Git host and the .com pod. So that is something that's on our radar. And I think service desk can be very, very interesting. And we've already seen, Victor has seen a couple of people commenting and trialing it out and giving feedback. So I have a ticket on my, or excuse me, an issue on my desk to respond to where some people are asking about service desk. So we're seeing customers pick it up. We want to dog food it as well. And I think we can. So I'm very excited about that. So team, if there are no more questions, we will wrap this functional update. Thanks for joining me on this wild journey. Jim says he would love to see the ticket flow from customers versus social media. That's a great question. We, none of my reports address any of the social media stuff. We are talking specifically about paying customers. Social media has a huge impact. And that team community advocacy has a ton of volume that they go through. So that's something that'll be interesting. I will see what I can do for you, Jim, to get that into the next report. All right, team, enjoy your Thursday. If it's Thursday where you are, it might not be. If it's not, enjoy whatever day it is where you are. And peace.